Clash 규칙과 라우팅 실전: 중국 본토는 직접 연결, 해외는 프록시로 설정하는 방법

라우팅 목표부터 정하기: 도메인으로 판단하고 IP로 누락 보완

“중국 본토는 직접 연결, 해외는 프록시”라고 해서 모든 트래픽을 단순히 두 지역으로 나누는 것은 아닙니다. Clash가 실제로 처리하는 것은 연결 요청이며, 각 요청에는 도메인만 있거나 대상 IP만 있을 수 있고, DNS 조회 후 연결이 수립되기도 합니다. 안정적인 설정은 보통 먼저 도메인 규칙으로 대상을 식별하고, IP 지역 규칙으로 누락을 보완한 뒤, 매칭되지 않은 트래픽은 마지막 기본 규칙으로 처리합니다.

Clash Meta, 즉 현재 널리 사용되는 mihomo 코어를 기준으로 하면 하나의 연결은 rules에 정의된 순서대로 위에서 아래로 검사됩니다. 처음 매칭된 규칙이 해당 연결이 어느 전략 그룹으로 들어갈지 즉시 결정하며, 이후 규칙은 실행되지 않습니다. 따라서 규칙 유형을 충분히 갖추는 것뿐 아니라 배열 순서도 최종 결과를 좌우합니다.

트래픽 유형	권장 동작	주요 판단 기준	대표 사례
로컬 네트워크 및 로컬 호스트 주소	`DIRECT`	사설 도메인, 사설 IP 대역	`192.168.1.1`、`10.0.0.0/8`
중국 본토의 명확한 사이트	`DIRECT`	GEOSITE 또는 도메인 규칙 세트	중국 본토의 동영상·결제·지도 서비스
중국 본토로 확인되는 IP	`DIRECT`	`GEOIP,CN`	도메인 데이터베이스에 등록되지 않은 중국 본토 서비스
프록시 사용이 명시된 서비스	`PROXY`	독립 도메인 규칙 또는 규칙 세트	항상 프록시를 사용해야 하는 개발 서비스
그 밖의 미매칭 연결	`PROXY`	`MATCH`	새 도메인, 잘 알려지지 않은 도메인, 알 수 없는 대상

GEOIP,CN만 작성하면 안 되는 이유

GEOIP,CN,DIRECT는 코어가 대상 IP를 확보한 뒤에야 지역을 판단할 수 있습니다. 연결이 아직 도메인 매칭 단계에 있거나 DNS가 Fake-IP 모드라면 GEOIP만으로는 도메인 단위 라우팅을 완전히 표현할 수 없습니다. 또한 CDN 노드의 위치가 서비스가 속한 지역과 항상 일치하는 것도 아닙니다. 같은 도메인이라도 네트워크, 시간, DNS 결과에 따라 다른 지역의 IP를 반환할 수 있습니다.

더 안정적인 구조는 “도메인 우선, IP로 누락 보완”입니다. 먼저 GEOSITE,cn,DIRECT 또는 중국 본토 도메인 규칙 세트로 알려진 사이트를 처리한 다음, GEOIP,CN,DIRECT로 등록되지 않았지만 중국 본토 주소로 해석되는 연결을 받습니다. 이렇게 하면 불필요한 DNS 의존성을 줄이면서 IP만 사용하는 요청도 처리할 수 있습니다.

GEOIP, GEOSITE, RULE-SET의 역할

GEOIP: 대상 IP의 지역 정보로 매칭

GEOIP 규칙은 IP 주소와 지역 코드 사이의 매핑을 조회합니다. 일반적인 작성법인 GEOIP,CN,DIRECT는 대상 IP가 중국 본토 주소로 식별될 때 직접 연결을 사용한다는 뜻입니다. 중국 본토 트래픽의 누락 보완 규칙으로 적합하지만, 모든 도메인 라우팅을 단독으로 맡기에는 적합하지 않습니다.

rules:
  - GEOIP,CN,DIRECT
  - MATCH,PROXY

no-resolve 매개변수는 이 IP 규칙을 매칭할 때 대상 IP를 얻기 위해 도메인을 적극적으로 조회하지 않는다는 뜻입니다. 예를 들어 GEOIP,CN,DIRECT,no-resolve는 규칙 매칭 단계에서 추가 DNS 조회가 발생하는 것을 막을 수 있지만, 요청에 도메인만 있는 경우에는 이 규칙이 매칭되지 않을 수도 있습니다. 이 매개변수를 추가할지는 앞 단계에 충분한 도메인 규칙이 있는지와 함께 판단해야 합니다.

GEOSITE: 도메인 집합으로 매칭

GEOSITE는 mihomo 같은 코어가 지원하는 도메인 분류 기능입니다. GEOSITE,cn,DIRECT는 geosite 데이터베이스에서 cn 분류에 속한 도메인을 직접 연결 전략으로 전달합니다. 현재 도메인이 어떤 IP로 해석되는지는 기준으로 삼지 않으므로 “어떤 서비스가 어느 유형의 사이트에 속하는가”를 표현하는 데 더 적합합니다.

rules:
  - GEOSITE,private,DIRECT
  - GEOSITE,cn,DIRECT
  - GEOIP,CN,DIRECT
  - MATCH,PROXY

GEOSITE가 정상적으로 작동하는지는 코어와 지리 데이터 파일에 따라 달라집니다. 구버전 Clash 코어, 서로 다른 클라이언트 분기, mihomo의 데이터 모드는 완전히 동일하지 않습니다. 설정에서 unsupported rule type GEOSITE 오류가 발생하면 규칙 순서를 계속 조정하지 말고, 먼저 클라이언트가 사용하는 코어 유형을 확인한 뒤 클라이언트의 코어 또는 지리 데이터 업데이트 메뉴에서 업데이트해야 합니다.

RULE-SET: 외부 규칙 파일을 기본 설정에 연결

규칙이 수백 또는 수천 개에 이르면 모두 기본 설정의 rules 아래에 넣는 방식은 적합하지 않습니다. rule-providers로 별도의 규칙 파일을 정의한 다음 RULE-SET으로 불러올 수 있습니다. 이렇게 하면 업데이트·그룹화·검사가 쉬워지고, 규칙을 관리할 때 전략 그룹이나 DNS 설정을 매번 수정하지 않아도 됩니다.

rule-providers:
  cn-domain:
    type: file
    behavior: domain
    format: yaml
    path: ./ruleset/cn-domain.yaml

  direct-extra:
    type: file
    behavior: classical
    format: yaml
    path: ./ruleset/direct-extra.yaml

rules:
  - RULE-SET,direct-extra,DIRECT
  - RULE-SET,cn-domain,DIRECT
  - GEOIP,CN,DIRECT
  - MATCH,PROXY

behavior: domain은 도메인 항목만 포함한 규칙 세트에 적합하고, behavior: ipcidr은 IP 대역에 사용합니다. behavior: classical은 DOMAIN, DOMAIN-SUFFIX, IP-CIDR 같은 전체 규칙을 저장할 수 있습니다. 규칙 파일의 동작 유형은 내용과 일치해야 하며, 그렇지 않으면 로드 실패나 항목 매칭 오류가 발생할 수 있습니다.

로컬 도메인 규칙 파일은 다음과 같이 작성할 수 있습니다.

payload:
  - '+.bilibili.com'
  - '+.jd.com'
  - '+.taobao.com'
  - 'cn.bing.com'

여기서 +.example.com은 기본 도메인과 하위 도메인을 뜻합니다. 정확한 호스트 이름 하나만 매칭하려면 접미사 형식이 아니라 전체 도메인을 작성해야 합니다. 파일을 수정한 뒤에는 클라이언트에서 설정을 다시 로드해야 합니다. 파일만 저장하고 다시 로드하지 않으면 실행 중인 코어가 새 규칙을 자동으로 적용하지 않습니다.

바로 조정할 수 있는 전략 그룹과 규칙 뼈대

아래 설정은 기본 프록시 그룹 하나, 자동 속도 테스트 그룹 하나, 기본 규칙 하나로 구성됩니다. 노드 이름은 실제 구독에서 제공하는 이름과 일치해야 합니다. 클라이언트가 구독으로 프록시 노드를 생성한다면 다음 구독 업데이트 때 덮어써지는 임시 파일을 직접 수정하기보다 구독 오버라이드나 설정 병합 기능에 전략 그룹을 추가하는 것이 일반적으로 더 좋습니다.

mixed-port: 7890
mode: rule
log-level: info
allow-lan: false
external-controller: 127.0.0.1:9090

proxy-groups:
  - name: PROXY
    type: select
    proxies:
      - AUTO
      - DIRECT
      - 홍콩 노드
      - 일본 노드
      - 싱가포르 노드

  - name: AUTO
    type: url-test
    proxies:
      - 홍콩 노드
      - 일본 노드
      - 싱가포르 노드
    url: https://www.gstatic.com/generate_204
    interval: 300
    tolerance: 80

rules:
  - GEOSITE,private,DIRECT
  - GEOIP,private,DIRECT,no-resolve
  - GEOSITE,cn,DIRECT
  - GEOIP,CN,DIRECT
  - MATCH,PROXY

mode: rule은 규칙 기반 라우팅을 활성화하기 위한 전제입니다. 클라이언트가 현재 Global 모드라면 모든 연결이 하나의 전역 전략 그룹으로 들어가고, Direct 모드라면 모든 연결이 프록시를 우회합니다. “규칙이 매칭되지 않는다”는 문제의 상당수는 실제로 실행 모드가 Rule로 전환되지 않은 것이 원인입니다.

url-test는 지정한 주소를 기준으로 주기적으로 노드 지연 시간을 측정합니다. 예시의 interval: 300은 300초마다 한 번 테스트한다는 뜻이고, tolerance: 80은 현재 노드와 더 빠른 노드의 지연 시간 차이가 80밀리초를 초과할 때만 전환을 고려한다는 뜻입니다. 지나치게 잦은 속도 측정은 연결과 배터리 소모를 늘리므로 데스크톱에서는 보통 300~600초가 더 적합합니다.

구독 프로바이더를 사용할 때의 전략 그룹 작성법

노드가 proxy-providers에서 제공된다면 전략 그룹에서 use로 프로바이더를 참조하여 모든 노드 이름을 기본 설정에 일일이 작성하지 않아도 됩니다. 다음 구조는 설정에 airport라는 이름의 프록시 프로바이더가 이미 존재한다고 가정합니다.

proxy-groups:
  - name: PROXY
    type: select
    proxies:
      - AUTO
      - DIRECT
    use:
      - airport

  - name: AUTO
    type: url-test
    use:
      - airport
    url: https://www.gstatic.com/generate_204
    interval: 300
    tolerance: 80

구독이 업데이트되면 새 노드는 해당 프로바이더를 참조하는 전략 그룹에 들어갑니다. 클라이언트가 설정 병합을 지원한다면 사용자 지정 규칙과 전략 그룹을 오버라이드 파일에 넣는 것이 좋습니다. 구체적인 메뉴는 보통 「설정」→「구성」→「오버라이드」 또는 「구독」→「설정 편집」에 있습니다. 클라이언트마다 메뉴 이름은 다를 수 있지만 원칙은 같습니다. 원본 구독은 유지하고 로컬 라우팅 로직은 독립적인 병합 계층으로 관리합니다.

DNS와 Fake-IP가 라우팅 결과에 미치는 영향

규칙이 올바르게 보이는데도 중국 본토 웹사이트가 프록시로 연결된다면 DNS를 반드시 확인해야 합니다. Clash가 DNS를 인계하면 도메인 조회, 규칙 스니핑, 연결 수립이 서로 연동됩니다. 시스템 DNS, 브라우저 보안 DNS, Clash DNS가 동시에 작동하면 일부 요청이 코어의 도메인 판단을 우회하여 최종적으로 IP 정보만 남을 수 있습니다.

mihomo에서 자주 사용하는 Fake-IP 설정은 다음과 같습니다. 수신 포트 1053을 사용하면 시스템의 53번 포트를 직접 점유하지 않으며, 클라이언트가 시스템 DNS 요청을 해당 수신 주소로 전달합니다.

dns:
  enable: true
  listen: 127.0.0.1:1053
  ipv6: false
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  default-nameserver:
    - 223.5.5.5
    - 119.29.29.29
  nameserver:
    - https://dns.alidns.com/dns-query
    - https://doh.pub/dns-query
  fake-ip-filter:
    - '*.lan'
    - '*.local'
    - 'localhost.ptlogin2.qq.com'

Fake-IP 모드에서는 먼저 198.18.0.0/16 범위의 예약 주소를 애플리케이션에 반환하고, 코어가 Fake-IP와 원래 도메인의 매핑을 저장합니다. 따라서 애플리케이션이 이후 IP로 연결하더라도 코어는 도메인을 복원하여 DOMAIN, GEOSITE 또는 도메인 규칙 세트를 실행할 수 있습니다. 로컬 네트워크 장치 검색, 프린터, 일부 로그인 구성 요소가 Fake-IP와 맞지 않는 경우에는 fake-ip-filter에 추가할 수 있습니다.

브라우저 보안 DNS가 판단을 방해하는 이유

브라우저에서 독립적인 DoH를 사용하면 DNS 조회가 HTTPS 트래픽으로 브라우저가 지정한 해석 서비스에 전달될 수 있습니다. Clash는 이 HTTPS 연결을 프록시할 수 있지만, 이후 업무 도메인과 시스템 DNS가 동일하게 매핑되는지 확인하지 못할 수 있습니다. 문제를 확인하는 동안에는 브라우저의 보안 DNS를 잠시 끄거나 “현재 서비스 제공업체 사용”으로 설정한 다음, 브라우저 DNS 캐시를 삭제하고 다시 테스트해 보세요.

Windows에서는 먼저 ipconfig /flushdns를 실행해 시스템 캐시를 삭제할 수 있습니다. Chromium 계열 브라우저는 관련 프로세스를 완전히 종료한 뒤 다시 실행해야 이전 연결 재사용으로 인한 오판을 배제할 수 있습니다. DNS 설정을 변경한 후에는 클라이언트에서 「구성」→「다시 로드」를 실행하고, 시스템 프록시 또는 TUN 연결을 끊었다가 다시 연결해야 합니다.

시스템 프록시와 TUN 모드는 어떻게 선택할까

시스템 프록시는 보통 HTTP 및 HTTPS 요청을 mixed-port: 7890으로 보냅니다. 시스템 프록시 설정을 따르는 브라우저·다운로더·개발 도구는 정상적으로 Clash에 연결되지만, 일부 게임·명령줄 프로그램·스토어 앱·자체 네트워크 스택을 구현한 소프트웨어는 시스템 프록시를 우회할 수 있습니다.

TUN 모드는 가상 네트워크 인터페이스를 통해 더 넓은 범위의 TCP·UDP·DNS 트래픽을 인계하므로, 데스크톱에서 일관된 라우팅이 필요할 때 적합합니다. mihomo의 기본 설정은 다음과 같이 작성할 수 있습니다.

tun:
  enable: true
  stack: mixed
  auto-route: true
  auto-detect-interface: true
  strict-route: true
  dns-hijack:
    - any:53
    - tcp://any:53

stack: mixed는 시스템 스택 호환성과 UDP 처리를 함께 지원하고, auto-route는 라우팅을 자동으로 기록하며, auto-detect-interface는 현재 외부 연결에 사용하는 네트워크 어댑터를 식별합니다. strict-route는 트래픽이 TUN을 우회하는 상황을 줄일 수 있습니다. TUN을 활성화하려면 보통 관리자 권한이 필요하며, 처음 실행할 때 가상 네트워크 어댑터나 네트워크 확장 권한을 요청할 수 있습니다.

사용 환경	권장 모드	중점 확인 사항
주로 브라우저와 시스템 프록시를 따르는 소프트웨어를 사용하는 경우	시스템 프록시	HTTP 프록시가 `127.0.0.1:7890`을 가리키는가
명령줄·스토어 앱·게임까지 통합적으로 인계해야 하는 경우	TUN	관리자 권한, 가상 네트워크 어댑터, 라우팅 테이블
규칙 설정만 확인하려는 경우	먼저 시스템 프록시 사용	라우팅 및 DNS 가로채기 변수를 줄이기
TUN을 활성화한 뒤 로컬 네트워크 장치에 접근할 수 없는 경우	strict-route와 사설 네트워크 대역 규칙 확인	`GEOSITE,private`、`GEOIP,private`

중국 본토 직접 연결과 해외 프록시가 적용됐는지 확인하는 방법

1단계: 실행 모드와 설정 재로드 상태 확인

클라이언트 홈 화면에서 실행 모드가 Rule 또는 규칙 모드인지 확인합니다.
「구성」→「현재 구성」으로 이동하여 방금 편집한 파일이 활성화되어 있는지 확인합니다.
「구성」→「다시 로드」를 실행합니다. TUN을 방금 수정했다면 연결을 끊었다가 다시 연결하세요.
로그 수준을 잠시 info로 설정하고, 처음부터 출력량이 더 많은 debug를 사용할 필요는 없습니다.

2단계: 연결 목록에서 매칭 경로 확인

클라이언트의 「연결」 또는 「Connections」 페이지를 열고 중국 본토 사이트와 프록시가 필요한 사이트를 각각 방문합니다. 중국 본토 요청에는 GEOSITE,cn → DIRECT, RULE-SET,cn-domain → DIRECT 또는 GEOIP,CN → DIRECT와 비슷한 표시가 나타나야 합니다. 그 밖의 요청에는 MATCH → PROXY → 특정 노드가 표시되어야 합니다.

하나의 웹페이지는 보통 메인 사이트 도메인, 이미지 CDN, 통계 API, 로그인 API, 서드파티 리소스를 동시에 요청합니다. 따라서 연결 목록에 DIRECT와 PROXY가 함께 나타난다고 해서 반드시 오류는 아닙니다. 판단할 때는 페이지의 메인 도메인만 보지 말고 특정 연결을 선택하여 대상 도메인, 매칭 규칙, 전략 그룹, 최종 노드를 확인해야 합니다.

3단계: 명령줄로 브라우저 캐시 우회

시스템 프록시 모드에서는 로컬 혼합 포트를 명시하여 테스트할 수 있습니다. 다음 두 명령은 모두 127.0.0.1:7890을 통해 Clash로 들어가며, 이후 규칙이 직접 연결 또는 프록시를 결정합니다.

curl -I --proxy http://127.0.0.1:7890 https://www.baidu.com
curl -I --proxy http://127.0.0.1:7890 https://www.google.com/generate_204

명령을 실행하면서 연결 패널도 함께 확인하세요. 첫 번째 요청은 보통 중국 본토 도메인 규칙 또는 중국 본토 IP 규칙에 매칭되고, 두 번째 요청은 PROXY로 들어가야 합니다. HTTP 상태 코드는 대상이 응답했는지만 보여 줄 뿐이며, 실제 라우팅 판단은 연결 상세 정보의 규칙 경로와 최종 전략을 기준으로 해야 합니다.

자주 발생하는 이상 현상과 확인 순서

중국 본토 웹사이트가 모두 PROXY로 연결됨

GEOSITE,cn,DIRECT와 GEOIP,CN,DIRECT가 MATCH보다 앞에 있는지 확인합니다.
코어가 GEOSITE를 지원하는지, 지리 데이터 파일이 로드되었는지 확인합니다.
현재 모드가 실수로 Global로 설정되어 있지 않은지 확인합니다.
연결 상세 정보에서 대상이 도메인인지 IP인지 확인합니다. IP만 표시된다면 DNS가 다른 프로그램에 의해 우회되고 있는지 계속 점검합니다.
일부 도메인에만 영향을 준다면 해당 도메인을 로컬 DIRECT 규칙 세트에 추가하고, 전체 프록시 그룹을 직접 연결로 바꾸지는 마세요.

해외 웹사이트에 MATCH가 표시되지만 여전히 접속할 수 없음

MATCH,PROXY에 매칭되었다는 것은 규칙 선택이 올바르다는 뜻일 뿐, 전략 그룹의 노드를 사용할 수 있다는 의미는 아닙니다. 연결 경로를 계속 펼쳐 PROXY가 최종적으로 어떤 노드를 선택했는지 확인하세요. DIRECT에서 멈춘다면 전략 그룹이 수동으로 직접 연결에 전환된 것입니다. 노드가 선택되었는데 연결 시간이 초과된다면 노드 상태, 구독 업데이트, 대상 프로토콜 지원 여부를 확인해야 합니다.

규칙 파일을 업데이트해도 변경 사항이 적용되지 않음

type: file인 로컬 규칙은 자동으로 다운로드되지 않으므로 수정 후 반드시 설정을 다시 로드해야 합니다.
type: http 규칙 프로바이더는 interval의 영향을 받으며, 클라이언트의 프로바이더 페이지에서 수동으로 업데이트할 수도 있습니다.
path가 클라이언트에서 접근을 허용한 설정 디렉터리를 가리키는지 확인합니다.
YAML 들여쓰기를 확인합니다. 목록 항목 앞에는 보통 공백 두 칸과 하이픈 하나를 사용하며, 탭 문자를 섞어 쓰면 안 됩니다.
behavior가 파일 내용과 일치하는지 확인합니다. 도메인 payload를 ipcidr로 선언해서는 안 됩니다.

TUN을 활성화한 뒤 로컬 네트워크 장치에 접근할 수 없음

먼저 사설 주소 규칙이 다른 광범위한 규칙보다 앞에 있고 일반적인 대역을 포함하는지 확인합니다. 대표적인 사설 주소는 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16입니다. .local 접미사를 사용하는 장치에 접근한다면 해당 도메인도 Fake-IP 필터 목록에 추가해야 합니다. 그다음 시스템 방화벽이 새로 생성된 TUN 네트워크 어댑터를 공용 네트워크로 인식하여 로컬 네트워크 통신을 제한하는지 확인합니다.

설정 유지 관리 팁: 통제 가능한 최소 구조 유지

중국 본토 직접 연결과 해외 프록시를 위해 규칙 유형을 계속 늘릴 필요는 없습니다. 대부분의 설정에서는 사설 주소 직접 연결, 중국 본토 도메인 직접 연결, 중국 본토 IP 누락 보완, 지정 서비스 예외, 최종 프록시 기본 규칙이면 충분합니다. 규칙이 많아질수록 출처·업데이트 시점·우선순위를 명확히 관리해야 합니다. 그렇지 않으면 규칙 세트 업데이트 한 번으로 기존 동작이 바뀔 수 있습니다.

사용자 지정 항목을 세 계층으로 나누는 것이 좋습니다. 구독은 노드를 제공하고, 전략 그룹은 노드를 선택하며, 규칙 세트는 트래픽이 어느 전략으로 들어갈지 결정합니다. 구독을 업데이트할 때 로컬 규칙을 덮어쓰지 말고, 규칙 세트를 업데이트할 때 프록시 노드를 다시 작성하지 마세요. 노드를 전환할 때도 규칙을 수정할 필요가 없습니다. 세 계층의 책임을 분리하면 문제는 “노드 사용 불가”, “전략 선택 오류”, “규칙 미매칭” 중 한 계층에 안정적으로 귀결됩니다.

설정을 완료한 뒤에는 최소한 다음 세 가지 정보를 저장해 두세요. 현재 코어 이름과 버전, 실제로 로드된 설정 파일, 중국 본토 요청 한 건과 프록시 요청 한 건의 연결 상세 정보입니다. 이후 문제가 발생했을 때 이 정보가 단순히 “사이트가 열리지 않는다”고 설명하는 것보다 원인을 찾는 데 훨씬 유용합니다.