중국 사이트는 직접 연결, 해외 서비스는 프록시로 보내는 설정: GEOSITE·rule-providers 실전

분할 라우팅의 기본: 규칙 모드와 프록시 정책 그룹

중국 사이트는 직접 연결하고 해외 사이트는 프록시로 보낼 때 도메인 목록, 대상 IP의 주소 대역, 규칙 순서에 따라 연결 경로를 결정합니다. 중국어 페이지도 해외 API를 사용할 수 있고, 해외 서비스가 중국 본토 CDN을 이용할 수도 있습니다. 따라서 설정 목표는 도메인 접미사로 서버 위치를 추측하는 것이 아니라, ‘확인된 중국 도메인은 직접 연결하고 나머지는 명확한 정책에 따라 처리’하는 것입니다.

이 내용은 Mihomo 커널을 사용하는 클라이언트에 적용됩니다. 시작하기 전에 모드를 Rule로 변경하고, 사용할 수 있는 노드를 가져왔는지, 설정에 PROXY라는 정책 그룹이 있는지 확인하세요. DIRECT는 커널에 내장된 직접 연결 정책이므로 따로 만들 필요가 없습니다. 반면 PROXY는 이 글에서 사용하는 그룹 이름일 뿐, 기본으로 제공되는 출구가 아닙니다.

실제 그룹 이름이 ‘节点选择’이라면 규칙의 대상으로 지정한 PROXY를 예시에서 모두 ‘节点选择’으로 바꾸세요. 그룹 이름은 실제 설정과 정확히 일치해야 합니다.
먼저 현재 설정을 백업한 뒤, 클라이언트의 오버라이드 또는 병합 기능으로 로컬 규칙을 저장하세요. 구독으로 생성된 파일을 직접 수정하면 다음 구독 업데이트 때 변경 사항이 덮어써질 수 있습니다.
앱 트래픽이 실제로 커널에 들어오는지 확인하세요. 시스템 프록시를 켰다고 해서 모든 앱이 프록시를 사용하는 것은 아닙니다. TUN은 더 많은 트래픽을 처리할 수 있지만 규칙의 첫 일치 순서는 바꾸지 않습니다.

GEOSITE 방식: 도메인, IP, 최종 대체 규칙 순서

사용 가능한 GeoSite 및 GeoIP 데이터가 있다면 아래 규칙으로 기본 구성을 만들 수 있습니다. 로컬 네트워크 주소를 앞에 두어 로컬 서비스가 프록시를 거치지 않게 하고, IP 소속 규칙보다 도메인 규칙을 먼저 두어 해외 서비스가 중국 본토 IP로 확인되더라도 앞서 직접 연결되지 않도록 합니다.

mode: rule

rules:
  - DOMAIN-SUFFIX,localhost,DIRECT
  - DOMAIN-SUFFIX,local,DIRECT
  - IP-CIDR,127.0.0.0/8,DIRECT,no-resolve
  - IP-CIDR,10.0.0.0/8,DIRECT,no-resolve
  - IP-CIDR,172.16.0.0/12,DIRECT,no-resolve
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - IP-CIDR6,::1/128,DIRECT,no-resolve
  - IP-CIDR6,fc00::/7,DIRECT,no-resolve
  - IP-CIDR6,fe80::/10,DIRECT,no-resolve
  - GEOSITE,cn,DIRECT
  - GEOSITE,geolocation-!cn,PROXY
  - GEOIP,CN,DIRECT,no-resolve
  - MATCH,PROXY

각 규칙 계층의 역할

규칙 계층	일치 기준	처리 결과
로컬 네트워크 예외	로컬 도메인, 루프백 및 사설 주소 대역	DIRECT
GEOSITE,cn	데이터 파일의 cn 도메인 목록	DIRECT
GEOSITE,geolocation-!cn	데이터 파일의 해당 도메인 목록	PROXY
GEOIP,CN	확인된 대상 IP의 소속	DIRECT
MATCH	앞선 규칙에 일치하지 않은 연결	PROXY

GEOSITE는 도메인 분류를 기준으로 일치 여부를 판단하며 현재 서버의 물리적 위치를 판별하지 않습니다. geolocation-!cn은 데이터 세트의 분류 이름이지, cn 결과를 실시간으로 반전하는 표현식이 아닙니다. 데이터 출처마다 포함 범위가 다르고 해당 분류가 없을 수도 있습니다. 분류를 찾을 수 없다는 오류가 발생하면 먼저 클라이언트에서 사용하는 GeoSite 데이터 출처를 확인하세요.

GEOIP,CN,DIRECT,no-resolve의 no-resolve는 이 규칙을 위해 도메인 조회를 새로 시작하지 않는다는 뜻입니다. 연결에 사용할 수 있는 실제 대상 IP가 이미 있으면 이를 기준으로 판단할 수 있습니다. 현재 도메인만 있고 앞선 도메인 목록에도 일치하지 않는 경우에는 이 규칙을 건너뛰고 MATCH로 처리할 수 있습니다. 추가 조회를 줄이는 대신 모든 중국 IP가 반드시 직접 연결되는 것은 아닙니다.

Geo 데이터 업데이트 시 확인할 점

GeoSite와 GeoIP는 로컬 데이터 파일입니다. 처음 불러올 때 사용할 수 있는 파일이 있거나 다운로드 출처에 접근할 수 있어야 합니다. 구독을 업데이트해도 이 데이터까지 함께 갱신된다고 볼 수는 없습니다. 클라이언트의 Geo 데이터 관리 항목, 커널 로그, 실제 데이터 출처를 각각 확인하세요. Geo 데이터 오류가 났을 때 노드 구독만 반복해서 새로고침하지 마세요.

rule-providers 방식: 원격 규칙 세트를 따로 업데이트

규칙 출처와 업데이트 주기를 별도로 관리하려면 rule-providers를 사용할 수 있습니다. 제공자는 규칙 모음을 다운로드하고 파싱하며, RULE-SET은 규칙 목록의 지정한 위치에서 해당 모음을 참조합니다. 제공자만 선언한다고 자동으로 트래픽이 분할되거나 규칙 모음이 목록 맨 위에 삽입되지는 않습니다.

아래는 Loyalsoldier/clash-rules의 공개 배포 파일을 문법 예시로 사용합니다. 두 파일은 YAML 형식의 도메인 목록이므로 behavior: domain과 format: yaml을 지정합니다. 적용하기 전에 출처의 콘텐츠와 현재 네트워크에서의 접근 가능 여부를 확인하세요. 이 주소는 노드 구독 주소가 아닙니다.

rule-providers:
  overseas-domains:
    type: http
    behavior: domain
    format: yaml
    url: "https://raw.githubusercontent.com/Loyalsoldier/clash-rules/release/proxy.txt"
    path: ./ruleset/overseas-domains.yaml
    interval: 86400

  domestic-domains:
    type: http
    behavior: domain
    format: yaml
    url: "https://raw.githubusercontent.com/Loyalsoldier/clash-rules/release/direct.txt"
    path: ./ruleset/domestic-domains.yaml
    interval: 86400

rules:
  - DOMAIN-SUFFIX,localhost,DIRECT
  - DOMAIN-SUFFIX,local,DIRECT
  - IP-CIDR,127.0.0.0/8,DIRECT,no-resolve
  - IP-CIDR,10.0.0.0/8,DIRECT,no-resolve
  - IP-CIDR,172.16.0.0/12,DIRECT,no-resolve
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - IP-CIDR6,::1/128,DIRECT,no-resolve
  - IP-CIDR6,fc00::/7,DIRECT,no-resolve
  - IP-CIDR6,fe80::/10,DIRECT,no-resolve
  - RULE-SET,overseas-domains,PROXY
  - RULE-SET,domestic-domains,DIRECT
  - MATCH,PROXY

이 목록은 앞 절의 rules를 대체해야 합니다. 두 개의 전체 목록을 앞뒤로 이어 붙이지 마세요. 앞 절의 MATCH는 나머지 모든 연결과 일치하므로 그 뒤의 규칙은 평가되지 않습니다. 이 예시는 GeoIP에 의존하지 않습니다. 목록에 없는 도메인과 로컬 네트워크 규칙에 일치하지 않은 IP 연결은 모두 프록시로 처리합니다.

interval: 86400의 단위는 초입니다. 즉, 24시간마다 업데이트를 확인한다는 뜻이며 캐시 파일의 유효 기간을 보장하지는 않습니다.
path는 커널 작업 디렉터리를 기준으로 한 로컬 파일 경로입니다. 서로 덮어쓰지 않도록 두 제공자에 다른 경로를 지정하세요.
overseas-domains와 domestic-domains는 사용자가 정하는 이름이므로 RULE-SET에 지정한 이름과 정확히 일치해야 합니다.
이 예시에서는 프록시 규칙 모음을 직접 연결 규칙 모음보다 앞에 둡니다. 두 목록에 같은 항목이 있으면 먼저 일치하는 프록시 규칙이 적용됩니다. 서로 다른 관리자가 만든 목록에 중복 항목이 없다고 가정하지 마세요.

규칙 형식: domain, ipcidr, classical

원격 주소가 열리는 것만으로 콘텐츠 형식이 올바르다고 볼 수는 없습니다. 구독 서비스가 반환하는 노드 설정, 로그인 안내가 포함된 HTML, 단순 도메인 텍스트를 구분 없이 같은 방식으로 파싱하면 안 됩니다. behavior는 항목이 의미하는 바를, format은 파일 인코딩 형식을 지정하므로 출처에 맞게 둘 다 설정해야 합니다.

behavior	YAML payload 항목 예시	적용 대상
domain	`'+ .example.com'`은 올바르지 않습니다. `'+\.example.com'`도 정식 형식이 아니며 `'+ .'` 역시 사용할 수 없습니다. 올바른 항목은 아래 코드를 참고하세요.	도메인 일치 목록
ipcidr	`'192.168.0.0/16'`	IP 주소 대역 목록
classical	`'DOMAIN-SUFFIX,example.com'`	규칙 유형을 포함한 항목

도메인 목록은 다음과 같이 간결하게 작성할 수 있습니다. +.example.com은 루트 도메인과 하위 도메인을 모두 일치시킵니다. 중간에 공백을 넣거나 백슬래시를 붙이지 않습니다.

payload:
  - '+.example.com'
  - 'api.example.net'

classical을 사용한다면 같은 항목을 다음 형식으로 작성합니다. 규칙 세트 항목에는 출구를 지정하지 않습니다. 출구는 바깥쪽의 RULE-SET,集合名称,策略에서 지정합니다.

payload:
  - DOMAIN-SUFFIX,example.com
  - DOMAIN,api.example.net

파일 확장자는 파싱 기준이 아닙니다. 앞에서 사용한 direct.txt는 .txt로 끝나지만, 내용은 payload를 포함한 YAML이므로 format: yaml로 설정합니다. 항목마다 한 줄씩 적힌 일반 텍스트 출처라면 해당 출처의 형식에 맞춰 format: text를 사용해야 합니다.

예외 규칙과 DNS: 중국 서비스가 프록시로 잘못 연결되지 않도록 하기

구체적인 예외를 규칙 목록보다 앞에 배치

로그인 보안 확인, 사내 네트워크 접속 또는 로컬 기기 검색 때문에 특정 서비스를 직접 연결해야 한다면 연결 기록에서 실제 요청 도메인을 확인한 뒤 정확한 예외 규칙을 추가하세요. API 하나에 문제가 있다고 해서 해외 도메인 전체를 직접 연결로 바꾸지는 마세요. 아래는 문법 예시이며, example.com은 설명용 예약 도메인입니다. 실제 설정에서는 연결 기록에 표시된 대상 도메인으로 바꾸세요.

rules:
  - DOMAIN,api.example.com,DIRECT
  - DOMAIN-SUFFIX,example.com,PROXY
  - RULE-SET,overseas-domains,PROXY
  - RULE-SET,domestic-domains,DIRECT
  - MATCH,PROXY

이 순서에서는 api.example.com이 먼저 직접 연결 규칙에 일치하고, 나머지 example.com 하위 도메인은 프록시 규칙으로 처리됩니다. 이는 구체적인 규칙을 넓은 규칙보다 먼저 두는 예시입니다. DOMAIN이 본래 DOMAIN-SUFFIX보다 우선하는 것은 아니며, 두 규칙의 순서를 바꾸면 결과도 달라집니다.

분할 라우팅 규칙은 DNS 분할과 다릅니다

GEOSITE,cn,DIRECT는 연결 경로를 결정할 뿐, 도메인을 어떤 DNS 서버로 조회할지는 지정하지 않습니다. DNS 상위 서버 선택은 dns의 nameserver 및 nameserver-policy 같은 설정을 확인해야 합니다. respect-rules를 활성화해 DNS 연결에도 라우팅 규칙을 적용한다면 현재 커널 문서를 참고해 노드 도메인 조회에 필요한 proxy-server-nameserver도 설정하세요. 조회 의존성이 순환하는 상황을 방지할 수 있습니다.

Fake-IP는 합성 주소를 반환하고 커널이 도메인과 연결의 대응 관계를 관리합니다. 합성 IP가 보인다고 해서 실제 IP의 위치를 판단하면 안 됩니다. redir-host는 실제 조회 결과에 더 크게 의존합니다. 두 모드 모두 연결 기록에서 도메인, 일치한 규칙, 최종 출구를 먼저 확인한 뒤 문제가 DNS 조회 단계인지 라우팅 단계인지 판단하세요.

검증 및 문제 해결: 연결 기록을 항목별로 확인

설정을 저장한 뒤 설정 검증과 다시 불러오기가 성공했는지 확인하고 새 연결로 테스트하세요. 이미 연결된 장시간 연결은 기존 출구를 계속 사용할 수 있습니다. 규칙을 바꾼 뒤에는 해당 연결을 끊거나 테스트 앱을 재시작하세요. 같은 페이지를 반복해서 새로고침하는 것보다 결과를 판단하기 쉽습니다.

실행 모드 확인. 현재 모드가 Rule인지 확인하세요. Global 모드에서 표시되는 전체 출구만으로는 이 규칙 목록이 올바른지 검증할 수 없습니다.
트래픽 유입 경로 확인. 클라이언트에 표시된 로컬 혼합 포트가 실제로 7890이라면 아래 명령에 프록시를 명시해 테스트할 수 있습니다. 포트가 다르면 화면에 표시된 실제 포트를 사용하세요.
일치 결과 확인. 클라이언트 연결 목록에서 대상 도메인, 규칙 유형, 규칙 항목, 정책 그룹, 실제 노드를 각각 확인하세요. PROXY에 일치하더라도 원격 노드를 사용한다고 단정할 수 없습니다. 해당 그룹에서 DIRECT를 선택했을 수도 있습니다.
제공자 상태 확인. 마지막 업데이트 시간과 항목 수를 확인하세요. 로그에 다운로드 시간 초과가 표시되면 원격 주소와 다운로드 경로를 먼저 확인하고, 파싱 오류가 발생하면 반환된 파일이 YAML, 일반 텍스트, HTML 중 무엇인지 확인하세요.
최종 병합 설정 확인. 로컬 오버라이드가 구독 규칙에 덮어써지지 않았는지, 사용자 지정 규칙이 대체 규칙보다 앞에 있는지, 규칙 대상 이름이 모두 실제로 존재하는지 확인하세요.

curl --proxy http://127.0.0.1:7890 --head https://www.baidu.com
curl --proxy http://127.0.0.1:7890 --head https://www.wikipedia.org

위 명령은 추적하기 쉬운 HTTP 프록시 연결을 만드는 용도입니다. 두 도메인이 모든 규칙 출처에서 반드시 특정 목록에 일치한다고 보장하지는 않습니다. HTTP 상태 코드만으로 라우팅이 성공했는지도 판단할 수 없습니다. 서버가 리디렉션하거나 접근을 거부할 수 있으므로 커널 연결 기록에서 실제 출구를 확인하세요.

자주 발생하는 문제와 확인 순서

중국 사이트가 프록시로 연결됨: 먼저 MATCH에 일치했는지 확인하세요. 일치했다면 직접 연결 목록에 도메인이 포함되어 있는지 확인하고, 그렇지 않다면 앞선 프록시 규칙이나 목록 간 중복을 확인하세요.
해외 사이트가 직접 연결로 표시됨: 앞선 도메인 예외 또는 GEOIP,CN 규칙에 일치했는지 확인한 다음, 프록시 그룹에서 직접 연결 출구를 선택한 것은 아닌지 살펴보세요.
브라우저는 정상인데 다른 앱은 작동하지 않음: 해당 앱이 시스템 프록시를 따르는지, TUN으로 트래픽을 처리해야 하는지 확인하세요. 먼저 규칙 세트에 도메인이 빠졌다고 단정하지 마세요.
규칙을 업데이트해도 달라지지 않음: 노드 구독이 아니라 규칙 제공자를 업데이트했는지 확인하세요. 새 연결을 만든 뒤 다시 테스트하고, 클라이언트에서 다른 설정 파일을 계속 불러오고 있지 않은지도 살펴보세요.

유지 관리 시에는 작고 명확한 로컬 예외 목록을 두고, GeoSite나 원격 규칙 세트 중 하나를 주요 분류 출처로 선택하세요. 한 번에 한 종류의 규칙만 수정하고 변경 전후의 일치 결과를 기록하면 데이터 누락, 규칙 순서, DNS 조회, 트래픽 처리 문제를 구분할 수 있습니다. 실제 원인을 찾지 못한 채 규칙 세트만 계속 추가하는 일을 피할 수 있습니다.