Clash 규칙 분기 설정 실전: 도메인 접미사와 GeoIP로 중국 본토·해외 트래픽 나누기

1. 규칙 모드와 매칭 순서

Clash의 트래픽 분기 단위는 연결입니다. 연결이 코어에 들어오면 코어는 확인 가능한 대상 도메인, 대상 IP, 포트 등의 정보를 바탕으로 rules를 위에서부터 검사합니다. 처음 일치하는 규칙이 사용할 아웃바운드 정책을 결정하며, 일반적으로 이후 규칙은 해당 연결의 선택에 더 이상 관여하지 않습니다. 따라서 규칙은 개수보다 순서가 중요합니다.

이 글에서는 Clash에서 흔히 사용하는 기본 규칙 문법을 다룹니다. 해당 필드를 지원하는 Clash 및 Clash Meta／mihomo 코어에서 사용할 수 있습니다. 클라이언트마다 인터페이스 명칭은 다를 수 있지만, 설정의 mode: rule, rules, 정책 이름은 실제 실행 설정과 일치해야 합니다. 확장 규칙 유형과 데이터베이스 옵션이 모든 버전에서 공통으로 지원된다고 단정할 수는 없습니다.

수정 전에 세 가지 상태 확인

실행 모드: Rule／규칙 모드로 전환합니다. Global／전역 모드는 이 글의 규칙에 따라 연결별로 분기하지 않으며, Direct／직결 모드도 규칙 테스트 환경이 아닙니다.
트래픽 진입 경로: 브라우저의 연결이 시스템 프록시나 명시적 프록시를 통해 코어에 들어오는지 확인합니다. 시스템 프록시를 따르지 않는 프로그램까지 처리해야 한다면 TUN 모드를 검토하세요.
사용 가능한 아웃바운드: 설정에 작동하는 프록시 노드가 있거나 해당 노드를 포함한 정책 그룹이 있어야 합니다. 이 글에서는 정책 그룹 이름을 해외 프록시로 통일합니다.

시스템 프록시와 TUN은 어떤 연결이 코어에 들어오는지를 결정하고, 규칙은 들어온 연결을 어떻게 내보낼지 결정합니다. TUN을 켜도 모든 연결이 자동으로 프록시를 통하는 것은 아니며, 규칙 모드를 켜도 시스템의 모든 앱이 자동으로 연결되는 것은 아닙니다. 먼저 클라이언트의 연결 목록에 연결이 표시되는지 확인한 다음 분기 결과를 살펴보세요.

핵심 규칙 세 가지

규칙	매칭 기준	주요 용도
`DOMAIN-SUFFIX`	전체 도메인과 하위 도메인	특정 사이트를 직결 또는 프록시로 연결
`GEOIP`	대상 IP의 데이터베이스상 지역	CN 주소를 직결로 분류
`MATCH`	나머지 모든 연결	명확한 기본 아웃바운드 지정

DIRECT는 내장 직결 정책입니다. 해외 프록시는 사용자가 설정한 이름이지 코어의 내장 키워드가 아닙니다. 둘 다 규칙의 정책 위치에 쓸 수 있지만, 후자는 노드나 정책 그룹에 먼저 정의되어 있어야 하며 이름도 정확히 일치해야 합니다.

2. 중국 본토 직결·해외 프록시 기본 설정

먼저 현재 사용 중인 설정을 백업한 뒤 규칙 부분을 교체하세요. 아래는 기존 설정에 병합할 코드 조각으로, 구독 주소와 노드 인증 정보, 전체 정책 그룹은 포함하지 않습니다. 이미 mixed-port나 mode가 있다면 같은 수준에 중복 추가하지 말고 기존 항목을 수정하세요.

mixed-port: 7890
mode: rule
log-level: info

rules:
  # 로컬 네트워크 이름 및 자주 사용하는 로컬 주소
  - DOMAIN,localhost,DIRECT
  - DOMAIN-SUFFIX,lan,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

  # 명시적으로 지정하는 도메인 정책
  - DOMAIN-SUFFIX,qq.com,DIRECT
  - DOMAIN-SUFFIX,jd.com,DIRECT
  - DOMAIN-SUFFIX,github.com,해외 프록시
  - DOMAIN-SUFFIX,githubusercontent.com,해외 프록시
  - DOMAIN-SUFFIX,wikipedia.org,해외 프록시

  # IP 지역 판별 및 최종 기본 경로
  - GEOIP,CN,DIRECT
  - MATCH,해외 프록시

7890은 이 예시에서 사용하는 HTTP／SOCKS 혼합 포트이며, 모든 클라이언트의 기본 포트가 아닙니다. 현재 클라이언트가 다른 포트를 사용한다면 실제 값을 그대로 두세요. 정책 그룹도 확인해야 합니다. 규칙이 해외 프록시와 일치하더라도 그룹에서 DIRECT를 선택했다면 최종 연결은 직결됩니다.

GeoIP보다 명시적 도메인 규칙을 먼저 두는 이유

도메인 정책은 사용 의도를 나타내고 GeoIP는 IP 데이터베이스의 분류를 나타내므로 서로 같은 의미가 아닙니다. 프록시로 보내도록 명시한 도메인이 데이터베이스에서 CN으로 분류된 주소를 반환한다고 가정해 보세요. GEOIP,CN,DIRECT를 먼저 검사하면 연결이 그 규칙에서 일찍 직결됩니다. 명시적 도메인 규칙을 앞에 두어야 사이트별 정책이 IP 지역 분류보다 우선 적용됩니다.

마찬가지로 직결해야 하는 기업 서비스는 주소가 해외에 있더라도 앞쪽에 도메인 규칙을 두고 DIRECT로 지정할 수 있습니다. 여기서 ‘중국 본토와 해외 트래픽 분기’는 기본 정책이지 모든 사이트를 절대적으로 분류하는 방식은 아닙니다. 로그인, 결제, 기업 전용 회선 등의 서비스는 실제 네트워크 요구사항에 맞춰 별도로 설정하세요.

3. DOMAIN-SUFFIX 문법과 적용 범위

DOMAIN-SUFFIX,qq.com,DIRECT는 qq.com과 mail.qq.com 같은 하위 도메인을 매칭하며, 문자열이 비슷하다는 이유만으로 notqq.com까지 매칭하지는 않습니다. 필드에는 도메인만 입력하세요. https://, 경로, 쿼리 매개변수는 넣지 않으며 *.qq.com도 필요하지 않습니다.

정확한 호스트: DOMAIN,login.example.com,DIRECT는 해당 호스트 이름만 매칭합니다.
도메인 전체 범위: DOMAIN-SUFFIX,example.com,DIRECT는 루트 도메인과 하위 도메인을 모두 매칭합니다.
키워드: DOMAIN-KEYWORD는 문자열 포함 여부로 매칭하므로 범위가 더 넓습니다. 정확한 도메인 목록을 대신하는 용도로는 적합하지 않습니다.

위의 example.com은 문법 설명을 위한 예시입니다. 실제로 관리할 때는 확인된 서비스 도메인을 입력하세요. 웹페이지 하나가 메인 사이트, 이미지, API, 오브젝트 스토리지에 동시에 요청을 보낼 수 있습니다. 메인 도메인이 프록시 규칙에 매칭된다고 해서 모든 리소스에 같은 정책이 적용되는 것은 아닙니다. 예를 들어 GitHub 페이지와 일부 원본 파일은 각각 github.com과 githubusercontent.com을 사용하므로 연결 목록에서 하나씩 확인해야 합니다.

범위가 좁은 예외 규칙은 앞에 배치

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

이 코드 조각은 동일한 도메인 범위에서 예외를 두는 방법을 보여줍니다. 다운로드 호스트는 직결하고 나머지 하위 도메인은 프록시로 보냅니다. 앞의 두 규칙 순서를 바꾸면 접미사 규칙이 먼저 매칭되어 정확한 호스트 규칙이 적용되지 않습니다. 규칙을 추가할 때마다 위쪽에 더 넓은 범위의 규칙이 있는지 확인하세요.

4. GeoIP, DNS, no-resolve 함께 사용하기

GEOIP,CN,DIRECT는 ‘중국어 웹사이트 직결’도, ‘모든 .cn 도메인 직결’도 아닙니다. 대상 IP의 지역 정보를 기준으로 합니다. 도메인이 해외 CDN을 사용할 수도 있고 해외 사이트가 중국 본토 주소를 반환할 수도 있습니다. 데이터베이스 업데이트, 주소 이전, DNS 응답 결과에 따라 매칭 결과가 달라집니다.

기존 Clash는 GeoIP 데이터 제공에 Country.mmdb를 사용하는 경우가 많습니다. mihomo에는 실행 모드와 버전에 따라 달라지는 지리 데이터베이스 설정도 있습니다. 데이터를 불러오는 데 오류가 나면 현재 코어 로그와 실제 데이터베이스 설정부터 확인하세요. 다른 클라이언트의 데이터베이스 파일 이름, 업데이트 주소, 확장 필드를 그대로 복사하지 마세요.

no-resolve는 DNS를 끄는 옵션이 아닙니다

IP 규칙에 no-resolve를 추가하면 해당 규칙을 검사하기 위해 대상 도메인을 별도로 조회하지 않습니다. 연결에 대상 IP가 이미 포함되어 있다면 해당 주소를 기준으로 규칙이 매칭될 수 있습니다. 앱의 DNS 요청을 차단하거나 시스템 DNS 설정을 바꾸는 기능은 아닙니다.

설정 방식	대상이 도메인인 경우	주요 장단점
`GEOIP,CN,DIRECT`	필요하면 주소 지역 판별을 위해 조회를 수행할 수 있음	도메인 규칙에 걸리지 않았지만 IP가 CN인 연결도 처리
`GEOIP,CN,DIRECT,no-resolve`	이 규칙을 위해 도메인 조회를 추가로 수행하지 않음	사용할 수 있는 대상 IP가 없으면 기본 경로로 넘어갈 수 있음

이 글의 기본 설정에서는 사설 주소만 확인하려고 도메인을 미리 조회하지 않도록 로컬 네트워크 대역 규칙에 no-resolve를 추가했습니다. CN 규칙은 조회 기능을 유지합니다. 내부 도메인을 안정적으로 직결해야 한다면 사설 주소 규칙이 언제나 먼저 조회 결과를 얻는다고 가정하지 말고, 명시적 도메인 규칙을 추가하거나 내부 DNS를 올바르게 설정하세요.

Fake-IP와 도메인 정보 확인

Fake-IP 모드에서는 코어가 도메인과 가짜 주소 간의 매핑을 관리합니다. 연결이 코어에 들어오면 이 매핑을 이용해 도메인을 복원한 뒤 규칙을 판단할 수 있습니다. 흔히 사용하는 Fake-IP 주소 대역인 198.18.0.0/16을 실제 해외 서비스 대역으로 간주하지 마세요. ‘가짜 주소를 우회’하려고 해당 대역 전체를 강제로 직결해서도 안 됩니다.

반대로 앱이 자체 DNS를 사용하거나 IP에 직접 연결하거나 예상한 DNS 경로를 우회하면, 코어에 도메인 정보가 충분히 전달되지 않아 DOMAIN-SUFFIX 규칙이 매칭되지 않을 수 있습니다. mihomo의 스니핑 기능으로 일부 연결의 도메인 정보를 보완할 수 있지만 모든 프로토콜에서 복원되는 것은 아닙니다. 브라우저 주소창만 보지 말고 연결 상세 정보의 도메인, 대상 IP, 매칭된 규칙을 함께 확인하세요.

5. 설정 불러오기, 연결 검증, 로그 확인

검증은 두 단계로 진행합니다. 먼저 설정이 정상적으로 불러와졌는지 확인하고, 다음으로 새 연결이 예상한 정책에 매칭되는지 확인합니다. 파일을 저장했다고 해서 클라이언트가 새 규칙을 사용한다고 볼 수는 없습니다. 구독 설정은 클라이언트의 생성 단계에서 다시 처리될 수도 있으므로 실행 중인 설정이나 연결 상세 정보를 기준으로 확인하세요.

백업: 현재 설정을 내보내고 실행 모드, 수신 포트, 정책 그룹 선택을 기록합니다.
문법 확인: 반각 쉼표와 공백 들여쓰기를 사용하고 최상위 rules가 하나만 있는지 확인합니다.
다시 불러오기: 클라이언트의 설정 다시 불러오기 기능을 사용합니다. 실패하면 먼저 로그에 표시된 YAML 오류나 정책 이름 오류를 해결하세요.
새 연결 생성: 테스트 페이지의 기존 연결을 닫은 뒤 다시 요청합니다. 기존 연결은 생성 당시의 아웃바운드를 계속 사용할 수 있으며, 페이지를 새로고침해도 장시간 연결이 재사용될 수 있습니다.
세 가지 확인: 대상 도메인 또는 IP, 매칭된 규칙, 최종 아웃바운드 노드를 확인합니다. 세 항목이 모두 맞아야 이번 트래픽 분기가 예상대로 처리된 것입니다.

공인 IP만 확인하지 말고 명시적 진입 경로로 테스트

현재 혼합 포트가 실제로 7890이라면 다음 명령으로 로컬에서 코어를 통과하는 요청을 보낼 수 있습니다. 이 명령은 명시적 프록시 진입 경로만 검증하며, 다른 앱이 시스템 프록시나 TUN에 연결되어 있는지를 보여주지는 않습니다.

curl --proxy http://127.0.0.1:7890 --head --connect-timeout 10 https://github.com/

여기서 10은 연결 단계의 제한 시간(초)이지 속도 테스트 결과가 아닙니다. 실행 후 연결 목록에서 github.com을 찾아 앞쪽의 도메인 접미사 규칙이 매칭되었는지 확인하세요. 그다음 해외 프록시 정책 그룹을 거쳐 선택한 노드에 연결되어야 합니다. HTTP 리디렉션이나 다른 상태 코드가 반환됐다는 사실만으로 분기 오류라고 단정할 수는 없습니다.

GeoIP를 검증하려면 앞쪽의 도메인 규칙에 포함되지 않은 테스트 대상을 임시로 선택하고, 이번 조회에서 반환된 IP를 기록한 다음 CN 규칙에 매칭되는지 확인하세요. CDN 주소와 데이터베이스 내용은 바뀔 수 있으므로 특정 공용 사이트가 항상 같은 규칙에 매칭된다고 단정하지 마세요. 마지막 MATCH 규칙도 실제 연결 기록을 기준으로 검증해야 합니다.

6. 자주 하는 실수와 지속적인 관리

증상	우선 확인할 항목	해결 방법
새 연결이 모두 같은 정책으로 나감	실행 모드, 규칙 맨 위에 MATCH가 있는지	규칙 모드로 전환하고 MATCH를 마지막에 배치
설정을 다시 불러오지 못함	정책 이름, 쉼표, 들여쓰기, 중복 필드	로그에서 오류 줄을 찾아 실제 그룹 이름 확인
프록시 그룹에 매칭됐는데도 직결됨	그룹에서 현재 선택한 항목과 중첩 그룹	최종 단계의 아웃바운드가 DIRECT가 아닌지 확인
도메인 규칙이 매칭되지 않음	코어에 도메인 정보가 전달되는지, 앞서 매칭되는 규칙이 있는지	DNS 경로와 규칙 매칭 순서 확인
중국 본토 서비스가 기본 프록시 경로로 들어감	조회된 주소, GeoIP 데이터, no-resolve	확인된 근거에 따라 데이터베이스를 수정하거나 도메인 예외 추가
구독 업데이트 후 규칙이 사라짐	구독 원본을 수정했는지, 유지되는 덮어쓰기 설정을 수정했는지	클라이언트가 지원하는 덮어쓰기 또는 병합 기능 사용

구독 업데이트와 규칙 병합

구독은 설정이나 노드 데이터를 제공하며, 규칙이 유지되는지는 클라이언트가 설정을 처리하는 방식에 달려 있습니다. 한 번 생성된 파일을 직접 수정하면 다음 업데이트에서 변경 사항이 덮어써질 수 있습니다. 클라이언트가 공식 지원하는 지속적 덮어쓰기, 스크립트, 규칙 병합 기능을 사용하고 ‘앞에 추가’, ‘뒤에 추가’, ‘전체 교체’ 중 어떤 방식인지 확인하세요. 새 규칙을 기존 MATCH 뒤에 추가하면 문법상 문제가 없어도 분기는 적용되지 않습니다.

규칙이 많아지면 규칙 집합 관리를 고려할 수 있습니다. mihomo는 rule-providers로 규칙 집합을 불러온 뒤 RULE-SET으로 참조할 수 있습니다. 단, 동작 유형과 파일 형식이 서로 맞아야 합니다. 도메인만 한 열로 나열된 파일을 어떤 형식에나 통용되는 규칙 집합으로 간주하지 마세요. 도메인 예외 하나를 처리하려고 규칙 체계 전체를 교체할 필요도 없습니다.

최종 점검 목록

정확한 서비스 예외를 앞에, 일반 GeoIP 규칙을 뒤에 두고 MATCH는 마지막에 배치합니다.
도메인 규칙에는 프로토콜과 URL 경로를 넣지 않고, 정책 이름은 실제 설정과 일치시킵니다.
IPv4와 IPv6를 각각 확인합니다. 한 번 IPv4 연결이 성공했다고 해서 듀얼 스택 경로도 모두 정상이라고 단정하지 마세요.
한 번에 관련 규칙 한 묶음만 수정하고, 설정을 다시 불러온 뒤 새 연결로 확인한 다음 다음 항목을 변경합니다.
매칭된 규칙과 최종 노드를 기록하세요. 시간 초과가 발생하면 프록시 노드, DNS, 대상 서비스 연결 가능성을 각각 확인합니다.

기본 트래픽 분기의 안정적인 구조는 로컬 및 서비스 예외를 우선 적용하고, 그다음 도메인 정책을 적용한 뒤, 나머지 주소를 GeoIP로 처리하고 MATCH로 최종 출구를 지정하는 것입니다. 필드를 더 확인하려면 프로토콜 레퍼런스를 참고하세요. 클라이언트와 프록시 진입 경로 설정이 아직 끝나지 않았다면 설정 가이드를 따라 트래픽이 코어에 들어오는지 먼저 확인하세요.