GEOIP와 DOMAIN-SUFFIX로 구현하는 Clash 라우팅 규칙

1. 먼저 라우팅 기준 정하기: 도메인, 대상 IP, 기본 정책

중국 본토와 해외를 나누는 기준은 웹페이지 언어나 회사의 등록 국가가 아닙니다. Clash 규칙 엔진은 연결에서 확인할 수 있는 도메인과 대상 IP 등의 정보를 바탕으로 설정 순서대로 일치하는 항목을 찾습니다. 이 글에서는 직접 연결 대상으로 지정한 도메인을 우선 연결하고, 중국 본토 IP로 확인되는 주소는 직접 연결을 시도하며, 나머지 연결은 프록시 그룹으로 보내는 방식을 다룹니다.

이 방식은 관리하기 쉬운 라우팅 전략이지, 모든 웹사이트의 위치를 정확하게 분류하는 방법은 아닙니다. 다국적 서비스가 중국 본토 CDN을 사용할 수도 있고, 중국 본토 서비스가 해외 API에 접속할 수도 있습니다. 도메인 규칙은 접속 의도를 나타내고 GEOIP는 IP 주소의 국가·지역 정보를 보완하므로 서로 대체할 수 없습니다.

규칙	판단 기준	적용 범위
`DOMAIN`	전체 도메인	특정 호스트 이름에 적용하는 예외
`DOMAIN-SUFFIX`	도메인 접미사	기본 도메인과 하위 도메인
`GEOIP`	대상 IP의 데이터베이스상 위치	추가 도메인 목록에 포함되지 않은 연결
`MATCH`	앞선 규칙에 모두 일치하지 않음	나머지 모든 연결의 기본 처리

설정 적용을 위한 세 가지 조건

클라이언트가 rule 규칙 모드여야 합니다. 전역 모드에서는 이 글의 규칙 목록에 따라 출구를 선택하지 않습니다.
대상 애플리케이션의 트래픽이 실제로 클라이언트를 통과해야 합니다. 시스템 프록시는 프록시 설정을 따르는 앱에만 적용되며, TUN은 가상 네트워크 어댑터와 라우팅 및 권한 설정에 따라 동작합니다.
규칙에서 참조하는 프록시 그룹이 이미 있어야 합니다. 이 글에서는 그룹 이름을 해외 프록시로 사용하므로 현재 설정에 있는 실제 이름으로 바꿔야 합니다.

2. GEOIP보다 앞에 DOMAIN-SUFFIX 배치하기

DOMAIN-SUFFIX,qq.com,DIRECT는 qq.com과 mail.qq.com에 일치하지만 notqq.com에는 일치하지 않습니다. 규칙은 도메인 레이블 경계를 기준으로 접미사를 확인하므로 *.qq.com처럼 쓸 필요가 없습니다. 도메인 필드에 https://, 포트 또는 URL 경로를 넣어서도 안 됩니다.

일반 규칙 목록은 위에서 아래로 검사해 처음 일치하는 규칙을 적용하며, 더 구체적인 규칙을 자동으로 선택하지 않습니다. 따라서 같은 사이트에 예외를 둘 때는 정확한 도메인을 넓은 범위의 접미사 규칙보다 먼저 작성해야 합니다. 접미사 규칙이 먼저 일치하면 뒤에 있는 GEOIP 규칙은 결과를 바꾸지 못합니다.

기본 규칙 예시

mode: rule

rules:
  - DOMAIN,localhost,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
  - DOMAIN-SUFFIX,qq.com,DIRECT
  - DOMAIN-SUFFIX,taobao.com,DIRECT
  - GEOIP,CN,DIRECT,no-resolve
  - MATCH,해외 프록시

이 예시는 일반적인 사설 네트워크 주소와 IPv6 고유 로컬 주소, 루프백 주소를 직접 연결한 다음, 지정한 두 도메인 접미사를 처리합니다. 모든 특수 목적 주소를 빠짐없이 포함한 목록은 아닙니다. 네트워크에서 IPv6 링크 로컬 주소나 멀티캐스트, 기업 자체 라우팅을 사용하는 경우 기존 LAN 규칙과 함께 필요한 항목을 추가하세요. 기존 설정의 관련 규칙을 무작정 삭제하면 안 됩니다.

DIRECT는 내장 직접 연결 정책입니다. 트래픽이 클라이언트를 거치지 않는다는 뜻이 아니라, 클라이언트가 직접 연결 방식으로 외부 연결을 수립한다는 의미입니다.
해외 프록시는 사용자가 지정하는 정책 그룹 이름입니다. 규칙에 적는 이름은 proxy-groups에 설정된 이름과 정확히 일치해야 합니다.
MATCH는 마지막에 배치하세요. 앞에 두면 뒤에 나오는 규칙은 일치할 기회가 없습니다.

“특정 하위 도메인은 프록시를 사용하고, 나머지 기본 도메인은 직접 연결”하려면 접미사 규칙보다 앞에 DOMAIN,지정한 전체 호스트 이름,해외 프록시를 추가하면 됩니다. 인터페이스 하나를 처리하기 위해 대형 서비스의 도메인 접미사 전체를 프록시로 바꾸지 마세요. 변경 범위가 커지고 검증도 어려워집니다.

3. GEOIP와 no-resolve: 규칙을 위해 도메인을 직접 조회할지 여부

GEOIP,CN,DIRECT는 IP 데이터베이스를 조회하는 규칙이지, 웹사이트가 속한 국가를 온라인으로 확인하는 기능이 아닙니다. 현재 연결에 도메인만 있는 경우 IP 규칙을 적용하려면 규칙 엔진이 먼저 도메인을 조회해야 할 수 있습니다. 실제 조회 동작은 코어 구현, DNS 모드, 연결에 이미 포함된 메타데이터에 따라서도 달라집니다.

no-resolve를 추가하면 해당 IP 규칙을 위해 도메인을 별도로 조회하지 않습니다. 연결에 규칙 매칭에 사용할 대상 IP가 이미 있으면 여전히 일치할 수 있습니다. 사용 가능한 IP가 없으면 다음 규칙을 확인합니다. 이는 “DNS 비활성화”나 “DNS 요청 차단” 옵션이 아닙니다.

설정	도메인만 있는 경우	장단점
`GEOIP,CN,DIRECT`	IP 판별을 위해 조회가 발생할 수 있음	IP 위치에 따른 직접 연결 가능성이 커지지만 DNS 조회에 의존함
`GEOIP,CN,DIRECT,no-resolve`	이 규칙을 위해 별도로 조회하지 않음	매칭 단계의 추가 조회를 줄이며, 일부 도메인 연결은 기본 규칙으로 넘어감

선택 방법

직접 연결할 도메인 목록을 충분히 관리하고 있으며 나머지 도메인을 프록시 그룹으로 보내려면 no-resolve를 우선 고려할 수 있습니다.
목록에 없는 중국 본토 도메인을 IP 위치로 추가 분류하려면 이 옵션을 사용하지 않는 방법을 검토하되, DNS가 정상적으로 작동하는지와 조회 결과를 함께 확인하세요.
앱이 IP 주소로 직접 접속하는 경우 대상 주소가 이미 있으므로, 일반적으로 no-resolve가 해당 주소의 규칙 매칭을 방해하지 않습니다.

GEOIP의 정확도는 로컬 데이터베이스에도 좌우됩니다. IP 대역 이전, 데이터베이스 업데이트 지연, CDN의 연결 분배로 인해 결과가 달라질 수 있습니다. mihomo의 지리 정보 설정도 실제로 읽는 데이터 파일에 영향을 줍니다. 시작 로그에 데이터베이스 누락이나 읽기 실패가 표시되면 규칙 순서를 계속 바꾸기보다 먼저 데이터 로딩 문제를 해결하세요.

4. rule-providers: 직접 연결 도메인을 관리하기 쉬운 파일로 분리하기

도메인 예외가 몇 개에서 수십 개로 늘어나면 주 설정에 계속 추가하는 방식은 중복이나 오타를 만들기 쉽습니다. mihomo에서는 rule-providers로 규칙 제공자를 선언한 다음 RULE-SET으로 참조할 수 있습니다. 제공자는 매칭 조건을 보관하고, 실제로 적용할 정책은 주 설정의 참조 규칙에서 결정합니다.

주 설정: 로컬 도메인 규칙 세트 선언

rule-providers:
  domestic-domains:
    type: file
    behavior: domain
    format: yaml
    path: ./rules/domestic-domains.yaml

rules:
  - DOMAIN,localhost,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
  - RULE-SET,domestic-domains,DIRECT
  - GEOIP,CN,DIRECT,no-resolve
  - MATCH,해외 프록시

규칙 파일: rules/domestic-domains.yaml

payload:
  - '+.qq.com'
  - '+.taobao.com'
  - '+.jd.com'

mihomo의 domain 유형 규칙 세트에서 +.qq.com은 해당 도메인과 하위 도메인을 뜻합니다. 작은따옴표는 도메인 패턴의 원래 텍스트를 유지합니다. 여기에 DOMAIN-SUFFIX,qq.com,DIRECT를 쓰면 안 됩니다. 이 파일에서 요구하는 도메인 항목 형식이 아닙니다.

behavior: domain: 파일에 도메인 매칭 항목을 저장하며, 직접 연결 또는 프록시 도메인 목록에 적합합니다.
behavior: ipcidr: 파일에 IP 대역을 저장합니다. 도메인 항목을 섞어 넣을 수 없습니다.
behavior: classical: 파일에 DOMAIN-SUFFIX,qq.com 같은 규칙 표현식을 저장합니다. 일반적으로 항목 끝에 정책 이름을 붙이지 않습니다.

상대 경로는 코어의 작업 디렉터리와 클라이언트의 파일 접근 제한을 기준으로 해석해야 하며, 현재 수정 중인 구독 파일을 기준으로 하는 것은 아닙니다. 모바일 클라이언트에서는 파일 가져오기와 저장 위치가 제한될 수도 있습니다. 저장한 뒤 규칙 세트가 정상적으로 로드됐는지와 항목 수가 적절한지 확인하고 새 연결로 테스트하세요. 로컬 type: file은 네트워크에서 내용을 자동으로 내려받지 않으며 원격 업데이트용 interval도 필요하지 않습니다.

원격 규칙 세트를 사용하려면 원본 파일의 behavior와 format부터 확인하세요. 도메인 일반 텍스트 목록을 YAML 파일로 읽으려 하거나, 다른 코어 전용 바이너리 파일을 해당 형식을 지원하지 않는 버전에 전달해서는 안 됩니다.

5. DNS, 시스템 프록시, TUN: 규칙에서 확인할 수 있는 정보

규칙이 적용되지 않는다고 해서 반드시 문법이 잘못된 것은 아닙니다. 먼저 연결이 클라이언트에 들어올 때 어떤 정보를 전달하는지 확인하세요. HTTP 프록시 요청에는 보통 대상 호스트 이름이 포함됩니다. 일부 SOCKS 앱은 로컬에서 먼저 주소를 조회한 뒤 IP만 클라이언트에 전달합니다. 같은 웹사이트에 접속하더라도 후자의 경우 도메인 접미사 규칙에 바로 일치하지 않을 수 있습니다.

자주 발생하는 세 가지 경계 사례

프록시보다 로컬 조회가 먼저 이루어짐. 앱이 대상 IP만 전달하면 도메인 규칙과 직접 비교할 정보가 없습니다. 도메인 스니핑을 지원하는 코어는 일부 프로토콜에서 호스트 이름을 보완할 수 있지만 모든 연결에서 복원되는 것은 아닙니다.
DNS 가로채기 범위가 부족함. TUN의 DNS 가로채기 설정만으로 모든 암호화 DNS를 식별할 수 있는 것은 아닙니다. 앱에 내장된 DoH는 HTTPS 연결을 사용하므로 일반적인 UDP 53 조회와 동일하게 취급할 수 없습니다.
IPv4와 IPv6의 경로가 다름. 같은 도메인에서 A 레코드와 AAAA 레코드가 함께 반환될 수 있으며, 연결마다 다른 주소를 사용할 수 있습니다. IPv4 테스트만으로 IPv6 연결도 같은 정책을 선택한다고 단정할 수 없습니다.

TUN은 라우팅 조건에 맞는 IP 트래픽을 가로채는 기능이며 잘못된 규칙 목록을 자동으로 수정하지는 않습니다. 시스템 프록시와 TUN을 함께 켰다면 테스트 중인 앱이 실제로 어느 경로를 이용하는지 확인하세요. 기업 VPN, 컨테이너 네트워크, 가상 머신 네트워크가 라우팅을 바꿀 수도 있습니다. 내부 네트워크 접속에 문제가 생기면 직접 연결 규칙을 추가하기 전에 대역이 겹치는지부터 확인하세요.

DNS와 외부 연결은 따로 검증해야 합니다. 주소를 조회했다는 사실만으로 대상 포트에 연결할 수 있다는 뜻은 아니며, DIRECT 규칙에 일치해도 직접 연결 회선이 정상이라는 보장은 없습니다. 도메인이 해외 주소로 조회되어 GEOIP 규칙에 일치하지 않았다면 현재 데이터에 따라 규칙이 동작한 결과일 수 있으며, 반드시 규칙 엔진 오류인 것은 아닙니다.

6. 규칙 미적용 문제의 점검 순서와 검증 사례

문제를 점검할 때는 한 번에 변수 하나만 바꾸세요. 실패한 연결의 도메인과 대상 IP, 포트, 일치한 규칙, 실제 정책을 먼저 기록한 뒤 도메인 목록을 수정할지 IP 규칙을 바꿀지 결정합니다. 아래 표는 예상 결과를 정리한 것으로, 실제 회선 속도 측정 결과가 아닙니다. 각 결과는 현재 설정과 네트워크에서 직접 확인해야 합니다.

검증 대상	예상되는 일치 규칙	확인할 사항
`192.168.1.1:80`	사설 IP 규칙 → DIRECT	해당 주소가 실제 로컬 게이트웨이인 경우에만 테스트
`www.qq.com:443`	도메인 접미사 또는 규칙 세트 → DIRECT	연결 기록에 도메인이 남아 있는지
도메인 목록에 없는 CN 주소	GEOIP → DIRECT	연결에 매칭 가능한 IP가 이미 있는지
그 외 새 연결	MATCH → 해외 프록시	그룹에서 실제로 선택한 노드 또는 정책

클라이언트를 재설치하기 전에 다음 6단계를 확인하세요

활성 설정과 모드 확인. 현재 설정 이름을 확인하고 규칙 모드인지 점검하세요. 편집기의 파일뿐 아니라 실행 중인 규칙 목록도 확인해야 합니다.
연결이 클라이언트에 들어오는지 확인. 연결 패널에서 대상 요청을 찾으세요. 기록이 전혀 없다면 시스템 프록시와 TUN 라우팅, 앱 자체의 프록시 설정부터 확인합니다.
처음 일치한 규칙 확인. 앞쪽의 범위가 넓은 도메인 규칙이 먼저 적용됐다면 더 구체적인 예외를 앞에 배치하세요. MATCH가 너무 앞에서 적용됐다면 기본 규칙의 위치를 먼저 바로잡습니다.
조회 결과와 데이터베이스 확인. 대상 IP와 IPv4·IPv6 여부, 지리 정보 로드 로그를 확인하세요. no-resolve를 사용한다면 사용 가능한 IP가 없어 규칙이 적용되지 않은 것은 아닌지 점검합니다.
규칙 세트 로드 상태 확인. 경로 또는 들여쓰기 오류, 형식 불일치로 제공자를 사용할 수 없을 수 있습니다. 파일을 읽을 수 있는지와 항목이 로드됐는지 먼저 확인한 뒤 RULE-SET의 위치를 점검하세요.
연결을 새로 수립. 대상 앱의 기존 세션을 닫거나 클라이언트에서 해당 연결을 끊은 뒤 다시 시도하세요. 이미 유지 중인 장기 연결은 규칙 파일이 바뀌어도 다른 경로로 자동 전환되지 않는 경우가 많습니다.

검증이 끝나면 프록시 그룹에서 실제로 무엇을 선택했는지도 확인하세요. 규칙이 “해외 프록시”에 일치했다는 것은 연결을 해당 그룹에 전달했다는 뜻일 뿐입니다. 그룹 안에서 DIRECT를 선택하면 최종 연결은 직접 연결됩니다. 반대로 직접 연결 규칙에 일치해도 페이지가 열리지 않는다면 DNS나 대상 서비스, 로컬 네트워크 문제일 수 있으므로 곧바로 라우팅 규칙이 작동하지 않는다고 판단하지 마세요.