Clash 규칙 분기 설정 가이드: GEOIP·GEOSITE·RULE-SET으로 중국 본토와 해외 트래픽 나누기

적용 범위: 먼저 코어와 트래픽 유입 경로 확인

중국 본토와 해외 트래픽을 나누는 설정은 중국 본토의 업무·동영상·다운로드 서비스는 직접 연결하고, 해외 서비스는 지정한 프록시 그룹으로 보내려는 경우에 적합합니다. 여기서 ‘중국 본토/해외’는 규칙 데이터베이스가 도메인이나 IP를 분류한 결과를 뜻하며, 웹페이지 언어나 회사 등록 국가, 도메인 접미사만으로 판단하는 것은 아닙니다. 해외 서비스도 중국 본토 CDN을 이용할 수 있으므로 일반적으로 도메인 규칙을 IP 지리 규칙보다 앞에 배치해야 합니다.

이 글의 전체 예시는 Clash Meta, 즉 현재 mihomo로 불리는 코어를 기준으로 합니다. 클래식 Clash와 각 파생 버전은 GEOSITE, 규칙 세트 형식, 데이터 파일을 지원하는 방식이 서로 다를 수 있습니다. 클라이언트의 ‘정보’ 또는 코어 정보 화면에서 실제 코어를 확인하세요. 클라이언트 이름만 보고 판단하지 마세요. 로드할 때 알 수 없는 규칙 유형이라는 메시지가 나오면 들여쓰기를 계속 바꾸기보다 먼저 호환성을 확인해야 합니다.

실행 모드: 클라이언트의 ‘프록시’ 또는 ‘모드’ 화면에서 ‘규칙’을 선택하세요. 전역 모드에서는 이 글의 rules 목록에 따라 트래픽을 분기하지 않습니다.
트래픽 유입 경로: 먼저 브라우저에서 시스템 프록시를 통해 테스트하세요. 시스템 프록시를 따르지 않는 앱까지 처리해야 한다면 TUN을 별도로 확인하세요. TUN을 켜도 규칙 설정을 대신할 수는 없습니다.
프록시 그룹: 아래 예시에서는 해외 프록시라는 기존 프록시 그룹을 사용합니다. 이 그룹에는 사용 가능한 노드가 포함되어 있어야 하며 proxy-groups에 실제로 등록되어 있어야 합니다.
백업: 먼저 현재 설정을 내보내세요. 구독을 사용하는 경우 구독 업데이트로 로컬 수정 사항이 덮어써지지 않도록 클라이언트의 오버라이드, 확장 또는 병합 기능을 우선 사용하세요.

규칙 우선순위: 위에서 아래로 확인해 처음 일치하는 규칙 적용

규칙은 ‘더 구체적으로 작성한 규칙이 자동으로 우선한다’는 방식으로 정렬되지 않습니다. 여기서 다루는 일반적인 규칙은 목록 맨 위부터 차례로 확인하며, 일치하는 규칙을 찾으면 해당 규칙의 대상으로 연결합니다. 더 구체적인 도메인 규칙이 뒤에 있더라도 앞의 포괄적인 규칙이 이미 일치했다면 이를 뒤집지 못합니다.

rules:
  - DOMAIN,mail.example.com,DIRECT
  - DOMAIN-SUFFIX,example.com,해외 프록시
  - GEOIP,CN,DIRECT,no-resolve
  - MATCH,해외 프록시

이 예시에서는 mail.example.com이 직접 연결되고 www.example.com은 해외 프록시를 사용합니다. 두 도메인 모두 이후 GEOIP 규칙까지 넘어가지 않습니다. example.com은 규칙 동작을 설명하기 위한 예약 예시 도메인이며, 실제 접속 테스트에 사용할 서비스가 아닙니다.

권장 규칙 배치 순서

특정 도메인을 반드시 직접 연결하거나 프록시로 보내야 하는 경우 등 직접 지정한 예외
NAS, 라우터, 로컬 네트워크 서비스가 해외 프록시를 거치지 않도록 로컬 주소 대역 설정
해외 서비스 도메인 규칙 및 규칙 세트
중국 본토 도메인 목록을 배치한 뒤 중국 본토 IP 지리 규칙 추가
마지막에는 MATCH를 배치해 앞선 분류에 해당하지 않는 트래픽을 처리합니다.

GEOIP·GEOSITE·RULE-SET의 차이

규칙 유형	판단 기준	일반적인 작성법과 용도
GEOIP	대상 IP의 데이터 분류	`GEOIP,CN,DIRECT,no-resolve`로 중국 본토 IP 트래픽을 처리합니다.
GEOSITE	GeoSite 데이터베이스에 포함된 도메인 목록	`GEOSITE,cn,DIRECT`로 도메인을 기준 삼아 중국 본토 서비스를 식별합니다.
RULE-SET	지정한 rule-provider에서 제공하는 규칙	`RULE-SET,overseas-domains,해외 프록시`로 별도 관리하는 목록을 참조합니다.

GEOIP: IP를 식별하며 서비스 전체를 판별하는 것은 아닙니다

GEOIP,CN은 사용하는 지리 데이터베이스를 기준으로 대상 주소를 판별합니다. 데이터베이스 업데이트가 늦을 수 있고, 클라우드 서비스나 CDN 때문에 같은 도메인이 서로 다른 지역의 IP로 연결되기도 합니다. 프록시를 통해 보내야 할 서비스가 명확하다면 도메인 규칙을 우선 사용하세요. GEOIP 규칙 하나로 모든 서비스 요구 사항을 처리할 수 있다고 기대해서는 안 됩니다.

no-resolve는 이 IP 규칙을 확인하기 위해 도메인을 IP로 직접 조회하지 않는다는 뜻입니다. DNS 전체를 비활성화하는 설정은 아닙니다. 연결에 실제 대상 IP가 이미 있으면 규칙을 적용할 수 있지만, 사용할 수 있는 IP가 없다면 일치하지 않고 다음 규칙으로 넘어갈 수 있습니다. 프록시 노드 주소와 앱의 주소도 계속 정상적으로 확인할 수 있어야 합니다.

GEOSITE: GeoSite 데이터 파일 필요

GEOSITE,cn을 사용하려면 코어가 cn 분류를 포함한 GeoSite 데이터를 불러올 수 있어야 합니다. 배포 패키지에 데이터가 미리 포함된 경우도 있고, 처음 사용할 때 다운로드하는 경우도 있습니다. 로그에 파일이 없거나 분류를 찾을 수 없다는 메시지가 나오면 코어의 데이터 디렉터리, 다운로드 연결, 데이터 출처를 확인하세요. cn을 웹사이트 도메인으로 임의 변경해서는 안 됩니다. GEOSITE의 도메인 분류와 GEOIP의 IP 분류는 별개의 데이터입니다.

RULE-SET: 형식과 behavior를 일치시켜야 합니다

규칙 세트는 규칙 내용을 메인 설정과 분리해 정기적으로 업데이트할 때 유용합니다. 도메인 목록에는 behavior: domain, IP 대역 목록에는 ipcidr, 규칙 유형이 포함된 기존 규칙 목록에는 classical을 사용합니다. YAML, 일반 텍스트, MRS는 파싱 방식도 다릅니다. URL만 바꾸고 서로 맞지 않는 format과 behavior를 그대로 두면 안 됩니다.

설정 예시: 중국 본토는 직접 연결, 해외는 프록시

아래는 기존 mihomo 설정에 병합할 수 있는 완전한 rule-providers 및 rules 섹션입니다. 기존 설정의 노드, 프록시 그룹, DNS 설정은 그대로 유지하세요. 이 설정은 단독으로 실행되는 구독 파일이 아닙니다. 병합하기 전에 기존 프록시 그룹 이름을 해외 프록시로 지정하거나 코드에 나오는 해당 이름을 모두 실제 그룹 이름으로 바꾸세요.

Loyalsoldier의 Clash 도메인 규칙 세트 YAML 파일을 참조하는 예시입니다. 해외 목록을 먼저 적용하고, 중국 본토 목록을 다음에 적용한 뒤 GEOSITE와 GEOIP로 보완합니다. 중복되는 도메인은 목록에서 앞에 있는 규칙을 따릅니다. 중국 본토 도메인 목록을 한 곳에서만 관리하려면 중국 본토 RULE-SET 또는 GEOSITE 중 하나를 삭제하고 사용하지 않는 provider도 함께 정리하세요.

mode: rule

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,google.com,해외 프록시
  - DOMAIN-SUFFIX,github.com,해외 프록시
  - DOMAIN-SUFFIX,githubusercontent.com,해외 프록시
  - DOMAIN-SUFFIX,qq.com,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-CIDR,169.254.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,해외 프록시
  - RULE-SET,domestic-domains,DIRECT
  - GEOSITE,cn,DIRECT
  - GEOIP,CN,DIRECT,no-resolve
  - MATCH,해외 프록시

병합할 때 확인할 세 가지

최상위 키는 하나만 유지: 이미 rules:가 있다면 기존 목록을 수정하세요. 파일 끝에 같은 키를 다시 추가하면 안 됩니다. 중복 키는 오류를 일으키거나 앞선 설정을 덮어쓸 수 있습니다.
이름을 정확히 일치: RULE-SET의 두 번째 항목은 provider 이름과 일치해야 하며, 마지막 항목은 내장 동작 또는 실제로 존재하는 프록시 그룹이어야 합니다. 한글 이름, 공백, 대소문자를 모두 확인하세요.
필요한 IPv6 규칙 유지: 앱이 IPv6를 사용한다면 IPv4만 설정한 로컬 네트워크 및 공용 네트워크 규칙으로는 충분하지 않습니다. 문제 해결을 간단히 하려고 시스템 네트워크 기능을 함부로 삭제하지 마세요.

규칙 세트 업데이트: 구독·provider·지리 데이터 구분

interval: 86400의 단위는 초이므로 24시간입니다. 이 값은 HTTP rule-provider의 업데이트 확인 주기를 제어하며 노드 구독이나 GEOSITE 데이터 파일까지 함께 새로 고치지는 않습니다. 메인 설정, 규칙 세트 다운로드, 지리 데이터베이스 업데이트를 각각 확인해야 합니다.

설정을 저장하고 다시 불러온 다음, 코어에 YAML 파싱 오류나 프록시 그룹 누락 오류가 없는지 먼저 확인하세요.
클라이언트의 규칙 세트 화면에서 overseas-domains와 domestic-domains를 찾아보세요. 화면 구성은 클라이언트마다 다를 수 있으므로 스위치 상태만 보지 말고 항목 수, 업데이트 시간, 오류 로그도 확인하는 편이 정확합니다.
수동 업데이트를 한 번 실행해 다운로드가 성공하는지 확인하세요. 예시의 캐시 위치는 코어 작업 디렉터리 아래의 ./ruleset/이며, 시스템의 고정 절대 경로가 아닙니다.
그다음 노드 구독을 업데이트하고 설정을 다시 불러온 뒤 사용자 규칙이 남아 있는지 확인하세요. 사라졌다면 클라이언트에서 계속 유지되는 오버라이드 기능으로 수정 사항을 옮기세요.

처음 실행할 때 규칙 출처에 직접 연결할 수 없고 프록시 노드도 아직 사용할 수 없다면 규칙 세트 다운로드에 실패해 시작 단계에서 의존성 문제가 생길 수 있습니다. 먼저 작동하는 기본 설정을 복구한 다음 규칙 세트를 다운로드하세요. 해당 필드를 지원하는 mihomo에서는 HTTP provider에 proxy: 해외 프록시를 지정해 기존 프록시 그룹을 다운로드에 사용할 수도 있습니다. 이 그룹은 이미 불러온 노드로 동작해야 하며, 아직 다운로드되지 않은 리소스에 의존해 순환 참조가 생기지 않도록 하세요.

오프라인으로 배포해야 한다면 해당 YAML 파일을 미리 저장하고 provider를 type: file로 변경하세요. 올바른 path, behavior, format은 유지하고 HTTP 다운로드 필드는 삭제합니다. 이 경우 파일 업데이트는 로컬에서 직접 관리해야 하며 HTTP 업데이트 주기에 따라 자동으로 가져오지 않습니다.

트래픽 분기 확인: 웹페이지가 열리는지만 보지 말고 일치한 규칙 확인

클라이언트의 ‘연결’ 화면을 열고 직접 연결할 도메인과 프록시를 사용할 도메인에 각각 접속하세요. 대상 호스트, 일치한 규칙, 프록시 경로, 대상 IP를 확인합니다. 웹페이지가 열렸다는 것은 요청에 응답이 있었다는 뜻일 뿐, 예상한 경로를 사용했다는 증거는 아닙니다. 노드 선택기에서 노드를 골랐더라도 모든 연결이 해당 노드를 거치는 것은 아닙니다.

테스트 변수를 줄이려면 고정된 접속 경로 사용

현재 설정에서 혼합 포트가 7890이라면 터미널에서 아래 명령을 실행할 수 있습니다. 포트가 다르면 실제 값으로 바꾸세요. 이 명령은 HTTP 요청을 확인하는 용도이며 시스템 전체의 TUN 처리 범위나 속도를 테스트하지 않습니다.

curl -I --proxy http://127.0.0.1:7890 https://www.qq.com/
curl -I --proxy http://127.0.0.1:7890 https://github.com/

이 글의 규칙을 적용하면 첫 번째 요청은 DOMAIN-SUFFIX,qq.com과 일치해 직접 연결되고, 두 번째 요청은 DOMAIN-SUFFIX,github.com과 일치해 해외 프록시 그룹으로 들어가야 합니다. 서버가 리디렉션을 반환하거나 HEAD 요청을 거부할 수 있으므로 실제 분기 결과는 클라이언트의 연결 기록을 기준으로 확인하세요.

자주 발생하는 문제와 해결 방법

항상 MATCH에만 일치: 연결 기록에 도메인이 표시되는지, provider가 정상적으로 로드되었는지, GEOSITE 분류를 사용할 수 있는지 확인하세요. IP 주소로 직접 접속한 요청은 일반 도메인 규칙에 일치하지 않습니다.
수정 후에도 이전 노드를 사용: 기존 장기 연결은 이전 프록시 정책을 계속 사용할 수 있습니다. 테스트 연결을 새로 만들고 새 연결 기록을 확인하세요. 기존 연결을 계속 재사용하는 앱 창만 새로고침해서는 안 됩니다.
해외 서비스가 GEOIP 규칙에 따라 직접 연결: 서비스 도메인 규칙이 빠졌는지 확인하고 GEOIP 규칙보다 앞에 추가하세요. 한 번의 DNS 조회 결과를 서비스 전체의 기준으로 삼지 마세요.
브라우저와 다른 앱의 결과가 다름: 시스템 프록시, 앱 자체 프록시, TUN 경로, 브라우저 보안 DNS를 확인하세요. 스니핑은 일부 프로토콜에서 도메인을 복구하는 데 도움이 될 수 있지만 모든 암호화 트래픽에서 도메인을 알아낼 수 있는 것은 아닙니다.
fake-ip 환경에서 가상 주소가 표시됨: 이는 DNS 매핑 방식의 일부이며 코어는 일반적으로 이 매핑을 이용해 도메인을 복구합니다. fake-ip 주소 풀을 실제 해외 IP로 간주해 프록시 IP 목록에 추가하지 마세요.

유지 관리 순서: 작은 예외부터 추가하고 규칙 세트는 점진적으로 확대

일상적인 유지 관리를 위해 비슷한 규칙을 계속 추가할 필요는 없습니다. ‘정확한 예외, 도메인 목록, IP 보완, 최종 기본 규칙’의 네 단계부터 유지하고 연결 기록에서 실제 차이가 확인될 때 조정하세요. 규칙을 추가할 때 적용 도메인, 대상 정책, 추가 이유를 기록하세요. 테스트를 통과한 뒤 다른 기기에도 적용하면 됩니다.

여러 기기에서 같은 구독을 사용하더라도 모든 코어가 같은 설정 파일을 해석할 수 있는 것은 아닙니다. 다른 기기로 복사하기 전에 GEOSITE, IPv6, provider 형식, 사용자 오버라이드 기능을 지원하는지 확인하세요. 전체 설정 방법은 구독 가져오기 가이드를 참고하세요. 연결 경로에 문제가 있다면 시스템 프록시 설정과 포트 안내도 확인하세요.

최종 점검에서는 세 가지를 확인해야 합니다. 설정이 정상적으로 로드되고, 중국 본토와 해외 테스트 요청이 각각 예상한 규칙에 일치하며, 규칙 세트를 수동으로 업데이트할 수 있고 구독 업데이트 후에도 사용자 설정이 유지되어야 합니다. 세 항목을 모두 통과한 뒤 일상 앱에 적용하세요. DNS, TUN, 전체 규칙을 한 번에 바꾸는 것보다 문제를 찾기 쉽습니다.