Clash 규칙 모드·전역 모드·직접 연결 모드 비교 및 선택 가이드

프록시 모드와 트래픽 가로채기를 구분하세요

Clash의 세 가지 프록시 모드는 코어에 들어온 연결이 어떤 출구를 사용할지 결정합니다. 규칙 모드는 규칙에 따라 트래픽을 분기하고, 전역 모드는 전역 정책을 따르며, 직접 연결 모드는 대상에 바로 연결합니다. 이 세 모드는 기기 트래픽을 코어로 가져오는 방법이나 속도 설정 단계가 아닙니다.

시스템 프록시, 앱 내 프록시, TUN은 연결을 코어로 전달하는 역할을 합니다. 예를 들어 브라우저에서 127.0.0.1:7890을 HTTP 프록시로 사용하면 브라우저의 해당 요청이 이 포트로 전달됩니다. 시스템 프록시를 사용하지 않는 앱은 자체적으로 인터넷에 연결할 수 있습니다. 전역 모드를 켜도 이 동작이 자동으로 바뀌지는 않습니다.

세 가지 모드의 트래픽 흐름 비교

여기서 ‘직접 연결’은 여전히 코어의 처리 과정을 거칩니다. 클라이언트를 종료하는 것과는 다릅니다. DNS, 수신 포트, 이미 활성화된 트래픽 가로채기 기능은 계속 연결에 관여할 수 있습니다. 또한 세 모드가 노드 정보 누락을 보완하거나 구독을 복구하고 서버 설정을 변경해 주지는 않습니다.

규칙 모드: 순서대로 일치 항목을 찾아 프록시 그룹으로 전달

규칙 모드는 상시 사용에 적합합니다. 코어는 rules를 위에서 아래로 확인하고, 처음 일치하는 규칙이 지정한 대상을 사용합니다. 대상은 DIRECT, REJECT, 특정 프록시 노드 또는 설정에 이미 정의된 프록시 그룹일 수 있습니다.

규칙 대상 지정과 프록시 그룹 선택은 별개의 단계입니다

도메인 규칙이 ‘노드 선택’을 가리킨다고 가정해 보겠습니다. 코어는 먼저 해당 연결의 대상을 ‘노드 선택’으로 정한 다음, 그룹 유형과 현재 상태에 따라 실제 출구를 결정합니다. 수동 선택 그룹은 현재 선택된 항목을 사용하고, 자동 테스트 그룹은 자체 설정에 따라 출구를 고릅니다. 규칙이 특정 그룹과 일치해도 반드시 원격 노드를 통해 전달되는 것은 아닙니다. 그룹에서 DIRECT를 선택했다면 최종 연결은 직접 연결입니다.

아래는 규칙 순서를 이해하기 위한 설정 예시이며, 전체 구독 설정은 아닙니다. ‘노드 선택’은 기존 proxy-groups에 지정된 이름과 정확히 일치해야 합니다. 다른 규칙을 이 규칙보다 앞에 둬야 하는지도 확인하세요.

mode: rule

rules:
  - DOMAIN-SUFFIX,home.arpa,DIRECT
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - IP-CIDR,10.0.0.0/8,DIRECT,no-resolve
  - IP-CIDR,172.16.0.0/12,DIRECT,no-resolve
  - MATCH,노드 선택

• DOMAIN-SUFFIX는 도메인 접미사를 기준으로 일치 항목을 찾습니다. 코어에서 해당 도메인 정보를 확인할 수 있어야 하며, 순수 IP 연결도 도메인 규칙에 일치한다고 가정해서는 안 됩니다.
• IP-CIDR은 대상 IP 대역을 기준으로 일치 항목을 찾습니다. 아래 세 대역은 일반적인 사설 IPv4 주소 범위를 포함합니다.
• no-resolve는 해당 IP 규칙을 위해 별도의 도메인 조회를 수행하지 않는다는 뜻입니다. 이미 대상 IP를 알고 있는 연결은 여전히 규칙과 일치할 수 있습니다.
• MATCH는 최종 대체 규칙이므로 우선 적용해야 할 규칙 뒤에 둬야 합니다. 맨 앞에 배치하면 뒤에 있는 일반 규칙이 일치할 기회를 얻지 못합니다.

웹사이트가 잘못된 출구를 사용할 때 확인할 항목

연결 세부 정보를 열고 대상 도메인 또는 IP, 일치한 규칙, 프록시 그룹 경로, 최종 노드를 차례로 확인하세요. 연결이 MATCH와 일치했다면 앞선 규칙이 연결을 처리하지 못한 것입니다. 올바른 프록시 그룹과 일치했는데도 잘못된 노드를 사용한다면 비슷한 규칙을 더 추가하지 말고 그룹 내 선택을 바꾸세요. 추가 설정은 고급 설정 가이드의 프록시 그룹 설명을 참고하세요.

전역 모드: GLOBAL을 통해 일시적으로 규칙 분기를 건너뛰기

전역 모드는 코어에 들어온 연결을 GLOBAL 프록시 그룹에 전달하며, 일반적인 rules 목록에 따른 출구 분기는 적용하지 않습니다. 클라이언트 인터페이스에서 전역 정책을 선택할 수 있지만, 메뉴 이름과 위치는 클라이언트 버전에 따라 다릅니다.

global로 전환한 뒤에는 GLOBAL에서 무엇이 선택됐는지 확인해야 합니다. 노드, 프록시 그룹 또는 DIRECT가 선택되어 있을 수 있습니다. ‘전역 모드’라는 문구만으로는 실제 출구를 알 수 없습니다. 규칙 모드에서 사용하던 ‘노드 선택’이 현재 전역 설정으로 적용된다는 보장도 없습니다.

전역 모드로 규칙 문제와 노드 문제 구분하기

1. 현재 규칙 모드에서 열리지 않는 URL과 연결 세부 정보에 표시된 일치 규칙을 기록합니다.
2. 전역 모드로 전환한 뒤 GLOBAL에서 테스트할 노드를 직접 선택합니다.
3. 해당 URL의 기존 연결을 종료하고 요청을 다시 보내 새 연결 기록을 확인합니다.
4. 전역 모드에서는 되지만 규칙 모드에서는 되지 않는다면 규칙 일치 결과와 프록시 그룹 선택을 먼저 확인하세요. 두 모드 모두 연결되지 않으면 노드, DNS, 트래픽이 코어로 전달되는 경로를 점검하세요.
5. 테스트가 끝나면 규칙 모드로 되돌리고 일상적으로 사용할 프록시 그룹을 다시 확인합니다.

직접 연결 모드: 로컬 네트워크 점검용이며 Clash를 끄는 것은 아닙니다

직접 연결 모드에서는 프록시 노드를 거치지 않고 코어가 대상에 직접 연결합니다. ‘같은 요청이 원격 프록시 출구를 거치지 않아도 성공하는가?’라는 질문을 확인할 때 유용합니다. 예를 들어 라우터 관리 페이지가 열리지 않는다면 직접 연결 모드로 전환하고 새 연결을 만든 뒤 접속이 복구되는지 살펴보세요.

다만 직접 연결 모드가 ‘순수한 일반 네트워크’를 완전히 재현하는 것은 아닙니다. TUN이 켜져 있다면 해당 연결이 가상 네트워크 인터페이스를 계속 거칠 수 있습니다. mihomo DNS 또는 Fake-IP가 활성화된 경우에도 코어가 도메인 조회와 주소 매핑을 처리할 수 있습니다. 앱이 코어를 완전히 우회하는 상황을 테스트하려면 관련 트래픽 가로채기 경로를 종료해야 합니다.

원인을 혼동하지 않도록 두 단계로 비교하세요

• 1단계: 시스템 프록시나 TUN은 그대로 둔 채 직접 연결 모드로만 전환합니다. 프록시 노드 또는 출구 선택이 원인인지 주로 확인합니다.
• 2단계: 클라이언트에서 시스템 프록시와 TUN을 끄고 브라우저에 별도 프록시가 설정되어 있는지도 확인합니다. 코어의 트래픽 가로채기, DNS 또는 앱 프록시가 원인인지 주로 확인합니다.

1단계에서는 여전히 실패하지만 2단계에서 정상이라 해도 ‘로컬 네트워크 문제’라고 단정할 수 없습니다. DNS 설정, 가상 네트워크 인터페이스의 라우팅, 프록시 수신 포트, 방화벽을 추가로 확인해야 합니다. 반대로 직접 연결은 실패하고 프록시 연결은 성공할 수 있습니다. 이는 대상 서비스까지의 로컬 네트워크 경로가 다르기 때문일 수 있으며, 규칙 모드에 문제가 있다는 뜻은 아닙니다.

모드 전환 위치와 설정 필드 확인하기

데스크톱 클라이언트에서는 보통 메인 화면의 ‘프록시 모드’ 또는 트레이 메뉴의 ‘규칙 / 전역 / 직접 연결’에서 모드를 바꿀 수 있습니다. 모바일에서는 홈 화면의 모드 선택 항목이나 사이드 메뉴에 있을 수 있습니다. 클라이언트마다 화면 구성이 다르므로 특정 클라이언트의 메뉴 경로를 모든 Clash 클라이언트에 공통으로 적용해서는 안 됩니다.

확인할 때는 실제로 선택된 모드와 코어의 실행 상태를 기준으로 삼으세요. YAML을 직접 편집한다면 모드 필드는 최상위에 두고 dns, tun, proxy-groups 안에는 넣지 않습니다.

# 최상위 필드; 사용 가능한 값은 rule, global, direct
mode: rule

파일을 수정한 뒤에는 보통 설정을 다시 불러와야 합니다. 일부 클라이언트는 인터페이스 설정, 오버라이드 설정 또는 실행 중인 상태를 최종 설정에 병합합니다. 따라서 파일에 rule이 적혀 있어도 코어가 실제로 rule을 사용한다고 항상 단정할 수는 없습니다. 구독을 업데이트한 뒤에는 로컬 수정 사항이 유지됐는지도 확인하세요.

포트와 모드는 별도의 설정입니다

mixed-port: 7890은 7890 포트에서 HTTP와 SOCKS를 함께 사용하는 프록시 수신 서비스를 제공한다는 뜻이며, mode와는 별개의 필드입니다. 브라우저가 이전 포트인 7890에 연결하는데 실제 수신 포트가 7891로 바뀌었다면 모드를 전환해도 포트 불일치를 해결할 수 없습니다. 앱 프록시 또는 시스템 프록시의 주소와 포트를 함께 수정하세요.

사용 상황에 맞는 모드를 선택해 불필요한 전환을 줄이세요

일상적인 인터넷 사용: 규칙 모드

중국 내 서비스, LAN 기기, 프록시가 필요한 사이트를 함께 이용한다면 규칙 모드를 우선 사용하세요. 규칙 순서와 프록시 그룹의 연결 관계를 먼저 정리한 뒤, 실제 연결 기록을 바탕으로 규칙을 추가하면 됩니다. 특정 사이트 하나 때문에 코어로 들어오는 모든 트래픽을 계속 같은 원격 출구로 보낼 필요는 없습니다.

노드 임시 테스트: 전역 모드

규칙의 영향을 제외해야 한다면 전역 모드로 전환해 노드를 직접 선택하세요. 가능한 한 대상 URL, 트래픽 가로채기 방식, DNS 조건을 고정하고 한 번에 변수 하나만 바꾸세요. 노드 지연 시간 테스트에 성공해도 당시 테스트 대상에 연결할 수 있다는 뜻일 뿐, 브라우저에서 접속하는 다른 도메인도 반드시 열린다는 보장은 없습니다.

라우터·NAS·로컬 서비스 점검: 직접 연결로 비교한 뒤 규칙 모드로 복귀

192.168.1.1 또는 로컬 개발 서비스에 접속할 때는 직접 연결 모드로 잠시 비교해 볼 수 있습니다. 전역 프록시 출구 때문에 실패하는 것으로 확인되면, 보통 규칙 모드로 되돌리고 실제 LAN 대역에 직접 연결 규칙을 설정하는 것이 장기적인 해결책입니다. TUN 라우팅 제외는 별도의 설정 계층이므로 규칙의 DIRECT와 혼동하지 마세요.

모든 사설 주소를 접속 가능한 리소스로 간주하지 마세요. 회사 VPN, 원격 근무 네트워크, 로컬 네트워크에서 같은 대역을 사용할 수 있습니다. 이런 경우에는 일반 설정 예시를 그대로 적용하기보다 라우팅 테이블과 회사 네트워크 정책을 함께 고려해 출구를 정해야 합니다.

모드 전환 후에도 달라지지 않을 때: 기존 연결, DNS, 트래픽 가로채기 범위 확인

1. 먼저 연결 기록을 확인하세요. 해당하는 새 연결이 없다면 앱이 시스템 프록시를 사용하는지, 또는 해당 트래픽이 TUN을 통해 전달되는지 확인합니다. 시스템 프록시는 모든 앱이나 모든 UDP 트래픽을 처리하지 못할 수 있습니다.
2. 그다음 실제 출구를 확인하세요. 현재 모드, 일치한 규칙, 프록시 그룹 경로를 점검합니다. 전역 모드에서는 GLOBAL을, 규칙 모드에서는 일치한 대상 그룹을 확인하세요.
3. 테스트 연결을 새로 만드세요. 진행 중인 다운로드, 장시간 연결, 브라우저 연결 풀은 모드를 바꿔도 새 경로로 전환되지 않을 수 있습니다. 클라이언트에서 해당 연결을 종료한 뒤 다시 접속하세요. 필요한 경우 브라우저를 완전히 종료했다가 다시 실행합니다.
4. DNS는 별도로 점검하세요. 도메인 조회 실패가 곧 규칙 오류를 뜻하지는 않습니다. DNS 요청이 정상인지, 조회 결과가 예상과 일치하는지 확인하세요. 모드를 바꿔도 앱 캐시가 반드시 지워지거나 DNS 업스트림이 바뀌는 것은 아닙니다.
5. 마지막으로 실행 중인 설정을 확인하세요. 구독이 정상적으로 불러와졌는지, 오버라이드가 적용됐는지, 인터페이스에서 선택한 모드가 YAML 설정을 덮어쓰는지 점검합니다.

모드를 선택할 때는 변수를 통제하는 것이 핵심입니다. 일상적으로 사용할 때는 규칙에 따라 연결 경로를 정하고, 문제를 점검할 때는 전역 모드에서 프록시 출구를 고정한 뒤 직접 연결과 비교하세요. 전환할 때마다 새 연결 하나의 실제 경로를 확인하면 여러 설정을 반복해서 바꾸는 것보다 문제를 쉽게 찾을 수 있습니다. 시스템 프록시나 TUN을 처음 설정한다면 사용 가이드의 프록시 모드 안내를 참고하세요.