Clash 규칙·전체·직접 연결 모드 선택법: 상황별 비교와 전환 시 유의사항

먼저 두 가지 스위치를 구분하세요: 트래픽 가로채기와 프록시 모드

Clash 클라이언트의 「시스템 프록시」, 「TUN 모드」와 「규칙·전체·직접 연결」은 같은 계층의 설정이 아닙니다. 시스템 프록시나 TUN은 트래픽을 Clash 코어로 전달하고, 프록시 모드는 코어에 들어온 연결을 프록시 노드로 보낼지, DIRECT로 직접 연결할지, REJECT로 거부할지를 결정합니다. 프록시 모드만 바꾼다고 시스템 프록시가 자동으로 켜지는 것은 아니며, TUN만 활성화해도 모든 연결이 원격 노드를 거치는 것은 아닙니다.

일반적인 설정을 예로 들면 HTTP와 SOCKS가 함께 사용하는 mixed-port가 7890으로 지정되고, 제어 인터페이스 external-controller가 127.0.0.1:9090으로 지정될 수 있습니다. 브라우저가 127.0.0.1:7890을 명시적으로 사용하거나 운영체제 프록시가 해당 포트를 가리켜야 요청이 코어로 들어갑니다. TUN을 활성화하면 시스템 프록시를 사용하지 않는 앱, UDP 트래픽, 일부 명령줄 프로그램까지 더 폭넓게 가로챌 수 있습니다. 포트는 설정값이므로 클라이언트마다 실제 숫자가 다를 수 있으며, 「설정」→「포트 설정」 또는 현재 설정 파일을 기준으로 확인해야 합니다.

세 모드는 모두 같은 가로챈 연결을 처리합니다

규칙 모드 rule: 설정의 rules를 순서대로 매칭하고, 일치한 규칙에 따라 정책 그룹, DIRECT 또는 REJECT를 선택합니다.
전체 모드 global: 일반 분기 규칙을 건너뛰고 연결을 GLOBAL이라는 전체 정책 진입점으로 보낸 뒤, 그 안에서 선택한 노드나 정책 그룹을 사용합니다.
직접 연결 모드 direct: 가로챈 연결이 대상 주소에 직접 접속하도록 하며, 일반적으로 원격 프록시 노드를 거치지 않습니다.

여기서 「규칙을 건너뛴다」는 표현에는 범위가 있습니다. 코어는 여전히 연결 수신, 대상 식별, DNS 같은 기본 작업을 수행하며, 클라이언트 자체의 LAN 우회, 프로세스 제외 또는 루프백 방지 로직이 남아 있을 수도 있습니다. 따라서 direct는 Clash를 종료한다는 뜻이 아닙니다. 가로채기를 완전히 중지하려면 시스템 프록시와 TUN을 별도로 끄고, 필요하면 코어도 중지해야 합니다.

규칙 모드: 일상 사용의 기본 선택

규칙 모드는 장기간 실행하기에 적합합니다. 위에서부터 규칙을 확인하며 처음 일치한 규칙이 즉시 적용되고 이후 규칙은 판단에 참여하지 않습니다. 일반적인 구성은 LAN과 중국 본토 사이트를 직접 연결하고, 지정 도메인이나 해외 트래픽은 프록시 정책 그룹으로 보내며, 마지막에 MATCH로 분류되지 않은 연결을 처리하는 방식입니다.

mode: rule
mixed-port: 7890

rules:
  - DOMAIN-SUFFIX,example.com,Proxy
  - DOMAIN-SUFFIX,cn,DIRECT
  - GEOIP,CN,DIRECT
  - MATCH,Proxy

이 예시에서는 example.com 접속이 첫 번째 규칙에 먼저 일치해 Proxy로 전달되고, .cn으로 끝나는 다른 도메인은 직접 연결됩니다. 그래도 일치하지 않은 중국 본토 IP는 GEOIP,CN이 처리하며, 마지막 남은 요청은 Proxy로 들어갑니다. 규칙 순서는 임의로 바꾸면 안 됩니다. 예를 들어 MATCH를 맨 앞에 두면 아래의 DOMAIN-SUFFIX와 GEOIP는 실행될 기회를 영원히 잃습니다.

규칙 모드가 적합한 구체적인 상황

일상적인 웹 이용: 중국 본토 서비스는 직접 연결하고 해외 서비스는 규칙에 따라 프록시로 보내 불필요한 원격 우회를 줄입니다.
동영상 및 다운로드 분기: 스트리밍 서비스, 게임 플랫폼 또는 대용량 파일 다운로드에 별도 정책 그룹을 지정하고 용도에 맞는 노드를 선택합니다.
LAN 기기 접속: 192.168.0.0/16, 10.0.0.0/8 등의 사설 주소를 직접 연결해 라우터나 NAS 접속이 프록시로 전달되지 않게 합니다.
장시간 TUN 가로채기: 시스템 트래픽 종류가 많을 때 규칙으로 TCP, UDP, 도메인 및 IP 요청의 출구를 정밀하게 결정합니다.

구독 설정을 사용할 때 규칙 모드의 결과는 구독에서 제공하는 규칙 세트와 정책 그룹에 따라 달라집니다. 이름이 비슷한 두 설정도 각각 GEOIP, GEOSITE, rule-providers 또는 다수의 DOMAIN-SUFFIX를 사용할 수 있어 최종 분기 결과가 다릅니다. 특정 사이트가 잘못된 출구로 나가면 먼저 연결 세부 정보에서 일치한 규칙과 정책을 확인하고, 곧바로 rule 모드가 작동하지 않는다고 판단하지 마세요.

규칙 매칭 이상을 점검하는 순서

「연결」 페이지에서 대상 도메인을 검색해 실제로 일치한 규칙 이름과 아웃바운드 정책을 확인합니다.
정책 그룹의 현재 선택을 확인합니다. 규칙이 Proxy를 가리키더라도 Proxy 내부에서 DIRECT가 선택되어 있지 않은지 살펴보세요.
도메인이 미리 IP로 해석되었는지 확인합니다. fake-ip와 redir-host를 사용할 때 코어에서 확인되는 대상 정보가 달라질 수 있습니다.
규칙 순서를 확인합니다. 특히 MATCH, FINAL, 범위가 넓은 DOMAIN-KEYWORD와 대규모 IP-CIDR을 점검하세요.
원격 규칙 세트를 업데이트한 뒤 설정을 다시 불러오고, 로그에 rule-provider 다운로드 또는 파싱 오류가 없는지 확인합니다.

전체 모드: 전체 트래픽 검증과 임시 규칙 우회

전체 모드는 테스트에 적합하지만 항상 유지할 필요는 없습니다. global로 전환하면 일반 업무 규칙이 출구를 결정하지 않고 연결이 모두 GLOBAL 정책 진입점으로 들어갑니다. 또한 GLOBAL에서 사용할 수 있는 노드를 명시적으로 선택해야 합니다. 현재 진입점에 DIRECT가 선택되어 있다면 화면에 전체 모드로 표시되어도 실제 연결은 직접 연결일 수 있습니다.

사용 상황	권장 모드	중점 확인 사항
규칙 때문에 사이트가 열리지 않는지 판단	일시적으로 global로 전환	같은 노드에서 즉시 접속이 복구되는지 확인
지정 노드의 전체 출구 점검	global	GLOBAL에서 대상 노드가 선택되어 있는지 확인
일상적인 중국 본토·해외 혼합 접속	rule	도메인, GEOIP 및 대체 규칙
프록시 노드가 이상을 일으키는지 판단	direct	직접 연결로 대상에 접속할 수 있는지 확인

예를 들어 규칙 모드에서 특정 사이트가 시간 초과되면 현재 노드를 기록한 뒤 global로 전환하고 GLOBAL에서 같은 노드를 선택해 보세요. 전체 모드에서 복구된다면 노드 자체는 정상일 가능성이 높고, 문제는 규칙 매칭, 정책 그룹의 연결 또는 DNS 분기에 있을 수 있습니다. 전체 모드에서도 실패한다면 노드 연결 상태, 핸드셰이크 로그, UDP 지원 여부와 대상 서비스 제한을 추가로 확인하세요.

전체 모드라고 해서 모든 프로그램이 반드시 프록시를 사용하는 것은 아닙니다

Clash로 들어온 트래픽만 global의 제어를 받습니다. 브라우저는 시스템 프록시를 사용하면 코어로 들어가지만, 일부 게임·가상 머신·컨테이너 또는 자체 네트워크 스택을 사용하는 프로그램은 시스템 프록시를 우회할 수 있습니다. 이런 프로그램까지 적용하려면 TUN이 실행 중인지, 운영체제에서 관리자 권한을 허용했는지, 클라이언트의 프로세스 제외 목록을 확인해야 합니다. Android에서는 VpnService 권한이 유효한지와 대상 앱이 「앱별 프록시」에서 제외되지 않았는지도 확인하세요.

직접 연결 모드: 프록시 영향을 확인하는 방법이지 종료 버튼이 아닙니다

direct 모드는 Clash에 들어온 새 연결이 로컬 네트워크를 통해 대상에 직접 접속하도록 합니다. 같은 기기와 DNS 환경에서 직접 연결로 전환했을 때 복구되는지 확인하는 비교 테스트에 가장 적합합니다. 복구된다면 문제는 프록시 노드, 정책 그룹 또는 원격 경로에 있을 수 있고, 계속 실패한다면 로컬 네트워크, 대상 서비스, DNS와 앱 자체를 점검해야 합니다.

직접 연결로 로컬 네트워크가 원래 접근할 수 없던 대상에 접근할 수 있게 되는 것은 아닙니다. 통신사 네트워크에서 특정 주소에 직접 연결할 수 없다면 direct에서도 시간 초과가 발생합니다. 또한 direct는 DNS 처리까지 끈다는 뜻이 아닙니다. DNS 요청을 Clash의 nameserver 모듈이 가로채는 경우 프록시 모드가 direct여도 도메인 해석은 설정된 로컬 또는 암호화 DNS 서버를 거칠 수 있습니다.

직접 연결로 전환하기 좋은 세 가지 상황

로컬 서비스가 갑자기 작동하지 않을 때: 프록시 라우팅이 회사 인트라넷, 학교 네트워크, NAS 또는 라우터 관리 페이지에 영향을 주는지 확인합니다.
다운로드 속도 비교: 같은 중국 본토 미러를 rule과 direct에서 각각 테스트해 원격 우회로 대역폭이 떨어지는지 확인합니다.
노드 장애 점검: 여러 노드에서 같은 오류가 발생할 때 direct로 대상 사이트나 로컬 DNS가 실제 원인인지 판단합니다.

direct를 클라이언트 종료의 대안으로 사용하지 마세요. 시스템 프록시가 여전히 127.0.0.1:7890을 가리킬 수 있고, TUN 가상 어댑터도 계속 실행되며, 연결 기록과 DNS 캐시는 코어가 계속 관리할 수 있습니다. 원래 네트워크 경로로 되돌리려면 「설정」→「시스템 프록시」를 끄고, 「설정」→「TUN 모드」를 끈 다음, 운영체제의 프록시 설정이 복원되었는지 확인하세요.

모드를 전환했는데 기존 연결이 바로 바뀌지 않는 이유

모드 전환은 주로 새로 생성되는 연결에 영향을 줍니다. 이미 연결된 TCP 세션은 앱이 연결을 닫거나 서버가 끊거나 코어가 직접 종료할 때까지 기존 출구를 계속 사용하는 경우가 많습니다. HTTP/2, WebSocket, QUIC 및 장시간 연결을 사용하는 앱에서 특히 두드러집니다. 페이지를 새로 고쳐도 기존 연결을 재사용하면 모드가 바뀌지 않은 것처럼 보일 수 있습니다.

전환 후 3~10초 정도 기다린 다음 요청을 다시 보내는 것이 좋습니다. 결과가 그대로라면 클라이언트의 「연결」 페이지에서 해당 연결을 닫거나 대상 앱을 완전히 종료한 뒤 다시 실행하세요. 브라우저로 테스트할 때 새 시크릿 창만으로는 충분하지 않을 수 있습니다. 브라우저 프로세스가 연결 풀을 공유할 수 있으므로 브라우저 프로세스를 완전히 종료한 뒤 다시 여는 편이 더 확실합니다.

DNS 캐시도 비교 결과를 방해할 수 있습니다

앱, 운영체제와 Clash 코어는 모두 DNS 결과를 저장할 수 있습니다. Windows에서는 터미널에서 ipconfig /flushdns를 실행해 시스템 DNS 캐시를 지울 수 있습니다. macOS는 버전에 따라 갱신 방식이 다르므로 대상 앱과 Clash 코어를 먼저 재시작하는 편이 안전합니다. fake-ip를 사용할 때 198.18.0.0/16 범위의 주소는 코어가 매핑한 결과이며, 웹사이트의 실제 서버가 해당 대역에 있다는 뜻은 아닙니다.

같은 사이트를 테스트할 때는 모드, 정책 그룹 노드, 일치한 규칙, 대상 도메인, 연결 프로토콜과 소요 시간을 함께 기록해야 합니다. 예를 들어 rule에서 DIRECT로 연결해 42ms, global에서 대상 노드를 거쳐 186ms가 걸렸다면 의미 있는 비교가 됩니다. 웹페이지가 체감상 얼마나 빨리 열리는지만 보면 캐시, 연결 재사용과 CDN 노드 변경의 영향을 받기 쉽습니다.

클라이언트에서 모드를 전환하는 방법과 설정 파일 저장 방식

그래픽 클라이언트마다 메뉴 이름은 조금씩 다르지만, 일반적으로 사이드바의 「프록시」 또는 「Proxies」 페이지 상단에 「규칙 / 전체 / 직접 연결」이 있습니다. 일부 클라이언트에서는 「설정」→「실행 모드」에 배치되어 있습니다. 전환 후 연결 페이지에서 새 요청을 보내 mode와 실제 아웃바운드가 일치하는지 확인하세요. 트레이 메뉴를 지원하는 클라이언트라면 트레이의 「프록시 모드」 하위 메뉴에서 빠르게 변경할 수도 있습니다.

mihomo 또는 호환 Clash 설정에서는 mode 필드로 설정을 불러올 때 사용할 기본 모드를 지정할 수 있습니다:

mode: rule

일반적으로 선택 가능한 값은 rule, global, direct입니다. 일부 클라이언트는 실행 중 선택한 값을 자체 설정 데이터베이스에 저장하고 다음 시작 때 설정 파일의 mode를 덮어씁니다. 따라서 YAML을 직접 편집한 뒤에는 클라이언트가 다시 불러올 때 변경 사항이 유지되는지 확인해야 합니다. 구독 업데이트가 현재 설정을 교체할 수도 있으므로 장기간 사용할 사용자 설정을 구독 생성 파일에만 직접 작성하는 것은 피하세요.

제어 인터페이스로 mihomo 모드 전환하기

external-controller를 활성화한 환경에서는 REST 인터페이스를 통해 실행 설정을 변경할 수 있습니다. 아래 예시는 제어 주소가 로컬 127.0.0.1:9090에서만 수신하고 secret을 설정하지 않은 경우를 가정합니다:

curl -X PATCH http://127.0.0.1:9090/configs \
  -H "Content-Type: application/json" \
  -d '{"mode":"rule"}'

rule을 global 또는 direct로 바꾸면 모드가 전환됩니다. secret을 설정했다면 Authorization: Bearer 비밀키 내용 요청 헤더를 사용하세요. 제어 인터페이스를 인터넷에 직접 노출해서는 안 됩니다. LAN에서 관리해야 한다면 수신 주소, 방화벽 허용 출처와 인증 키를 함께 제한하세요.

반복 가능한 모드 문제 진단 절차

모드 전환의 가장 유용한 목적은 무작정 반복 클릭하는 것이 아니라 통제된 조건에서 비교하는 것입니다. 같은 네트워크, 같은 대상과 같은 노드를 유지하고 다음 순서대로 확인하면 문제 지점을 빠르게 좁힐 수 있습니다.

시스템 프록시 또는 TUN이 켜져 있고 연결 목록에 대상 요청이 표시되는지 확인합니다.
rule로 새 연결을 만들고 일치한 규칙, 정책 그룹과 구체적인 노드를 기록합니다.
global로 전환한 뒤 GLOBAL에서 방금 사용한 같은 노드를 선택하고 기존 연결을 닫은 다음 다시 시도합니다.
direct로 전환하고 기존 연결을 다시 닫은 뒤 로컬 네트워크를 통한 직접 연결 결과를 테스트합니다.
세 번의 로그에서 DNS 결과, 연결 프로토콜, 핸드셰이크 오류와 소요 시간을 비교합니다.
테스트가 끝나면 rule로 복원하고 정책 그룹 선택과 TUN 상태가 평소 설정에 맞는지 확인합니다.

Rule 결과	Global 결과	Direct 결과	우선 점검 항목
실패	성공	실패	규칙 매칭 및 정책 그룹 연결
실패	실패	성공	프록시 노드, 프로토콜과 원격 경로
성공	성공	실패	정상적인 프록시 접속 가능 상황
모두 실패	모두 실패	모두 실패	트래픽 가로채기, DNS, 로컬 네트워크 또는 대상 서비스

최종 선택은 간단하게 정리할 수 있습니다. 일상 사용에는 rule, 특정 노드를 검증하거나 복잡한 규칙을 우회할 때는 임시로 global, 로컬 네트워크와 프록시 경로 중 무엇이 연결에 영향을 주는지 확인할 때는 direct를 사용하세요. 전환 후에는 항상 GLOBAL에서 선택한 대상을 확인하고 기존 연결을 닫으며, 시스템 프록시와 TUN을 별도의 스위치로 취급해야 세 모드의 판단이 뒤섞이지 않습니다.