Clash 규칙 라우팅 설정 가이드: GEOIP와 DOMAIN-SUFFIX를 조합해 트래픽 분리
실제 규칙으로 중국 본토 IP는 직접 연결하고 그 외 트래픽은 프록시로 보내는 방법을 살펴봅니다. 규칙 순서, MATCH 기본 처리, rule-provider 관리까지 안내합니다.
먼저 확인하기: 연결이 커널에 전달되고 모드는 Rule인지 확인
중국 본토와 해외 트래픽을 나누는 기준은 클라이언트 화면에 표시된 노드 이름이 아닙니다. 커널에 전달된 각 연결의 도메인이나 대상 IP 등을 기준으로 출구를 선택합니다. 이 글에서는 명시적인 직접 연결 도메인을 먼저 처리하고, 중국 본토 IP는 직접 연결한 뒤 나머지는 프록시 그룹으로 보내는 구성을 사용합니다. 여기서 말하는 지역 구분은 라우팅 정책을 간단히 표현한 것으로, 웹사이트의 등록 국가나 운영 주체, 콘텐츠의 지역을 정확히 판별한다는 뜻은 아닙니다.
Clash for Windows 원 프로젝트는 더 이상 유지 관리되지 않습니다. 기존 환경에서는 기본 규칙 문법을 참고할 수 있지만, 새 구성을 만들 때는 먼저 클라이언트 비교에서 유지 관리 상태와 커널 기능을 확인하세요. 아래 기본 규칙은 일반적인 Clash 설정에 적용되며, 규칙 집합 예시는 mihomo 환경을 기준으로 합니다. 최신 커널 기능이 구형 CFW에서도 반드시 지원된다고 가정하지 않습니다.
- Clash for Windows의 General → System Proxy에서 시스템 프록시를 켜면 Windows 프록시 설정을 따르는 프로그램이 클라이언트를 거칩니다. 시스템 프록시를 따르지 않는 프로그램은 별도로 프록시를 설정하거나, 올바르게 구성된 TUN을 사용해야 합니다.
- Proxies → Rule로 이동해 실행 모드가 규칙 모드인지 확인합니다. Global은 모든 연결을 전역 정책에 맡기고 Direct는 직접 연결하므로, 두 모드 모두 이 글의 규칙을 검증하는 데 적합하지 않습니다.
- Profiles에서 현재 활성화된 구성을 확인하고 프록시 정책 그룹이 있는지 살펴봅니다. 이 글에서는 기존 프록시 그룹 이름을
PROXY라고 표기합니다. 실제로 사용할 때는 설정에 있는 정확한 이름으로 바꿔야 합니다.
DOMAIN-SUFFIX, GEOIP, MATCH는 각각 다른 단계에서 작동합니다
Clash 규칙은 일반적으로 위에서 아래 순서로 확인하며, 출구를 결정하는 규칙이 일치하면 그 뒤의 규칙은 검사하지 않습니다. 규칙 목록이 자동으로 ‘더 정확한 규칙’을 골라 주는 것은 아닙니다. 범위가 넓은 규칙을 앞에 두면 뒤에 있는 구체적인 예외 규칙이 실행되지 않을 수 있습니다.
| 규칙 형식 | 매칭 대상 | 주의 사항 |
|---|---|---|
DOMAIN,example.com,DIRECT | 전체 도메인 | www.example.com은 일치하지 않습니다. |
DOMAIN-SUFFIX,example.com,DIRECT | 루트 도메인과 하위 도메인 | example.com과 a.example.com은 일치하지만 notexample.com은 일치하지 않습니다. |
GEOIP,CN,DIRECT | 대상 IP의 GeoIP 데이터상 국가·지역 | 로컬 데이터에 의존하며, 해당 웹사이트가 중국 기업 소유라는 뜻은 아닙니다. |
MATCH,PROXY | 앞선 규칙으로 출구가 결정되지 않은 연결 | 마지막에 배치해야 합니다. PROXY는 이미 존재하는 프록시 또는 정책 그룹이어야 합니다. |
도메인 규칙에는 URL을 넣지 마세요
DOMAIN-SUFFIX 뒤에는 도메인만 적고 https://, 포트, 경로는 포함하지 않습니다. 예를 들어 Alipay 관련 도메인을 직접 연결하려면 DOMAIN-SUFFIX,alipay.com,DIRECT라고 작성합니다. 웹 주소 전체를 넣으면 안 됩니다. 이 규칙은 URL의 /login이나 /video 같은 경로도 판별하지 않습니다.
도메인 접미사는 지리적 경계가 아닙니다. 모든 .com을 해외 도메인으로 간주하거나 .cn만으로 실제 서버 위치를 판단해서는 안 됩니다. 자주 사용하는 서비스는 도메인을 지정해 처리하고, 나머지는 IP의 국가·지역 정보를 기준으로 판단하는 편이 확인과 관리에 유리합니다.
기본 구성: 예외 규칙, GEOIP, 마지막 기본 규칙 순서
아래는 주 설정 파일의 일부이며 노드를 포함한 전체 구독 설정이 아닙니다. 사용하기 전에 현재 설정을 백업하고 PROXY라는 프록시 그룹이 있는지 확인하세요. 기존 노드, DNS, 포트 설정은 유지해야 합니다. 최상위에 rules:가 이미 있다면 기존 목록을 수정하고, 같은 이름의 키를 추가로 만들지 마세요.
mode: rule
rules:
# 로컬 장치 및 일반적인 LAN IPv4 주소
- 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
# 로컬 장치 및 LAN IPv6 주소
- IP-CIDR6,::1/128,DIRECT,no-resolve
- IP-CIDR6,fc00::/7,DIRECT,no-resolve
- IP-CIDR6,fe80::/10,DIRECT,no-resolve
# 실제 서비스에 맞춰 명시적인 도메인 정책 추가
- DOMAIN-SUFFIX,baidu.com,DIRECT
- DOMAIN-SUFFIX,qq.com,DIRECT
- DOMAIN-SUFFIX,alipay.com,DIRECT
- DOMAIN-SUFFIX,wikipedia.org,PROXY
# 도메인 규칙에 포함되지 않은 중국 본토 IP는 직접 연결
- GEOIP,CN,DIRECT
# 나머지 연결은 기존 프록시 그룹으로 전달
- MATCH,PROXY이 순서에서는 LAN 대상에 먼저 직접 연결한 다음, 명시적으로 지정한 도메인 예외를 처리합니다. 이어서 GEOIP,CN,DIRECT가 더 넓은 범위의 IP 국가·지역 판별을 맡고, 마지막으로 MATCH가 나머지 연결을 처리합니다. 예시 도메인은 작성 방법을 보여 주기 위한 것으로 중국 본토 서비스 전체 목록이 아닙니다. 한 앱이 이미지, 로그인, 결제, 업데이트에 각각 별도 도메인을 사용할 수도 있습니다.
GEOIP를 모든 도메인 규칙보다 앞에 두지 않는 이유
특정 서비스 도메인을 프록시로 보내야 하는데 현재 IP가 GeoIP 데이터에서 CN으로 분류된 경우를 생각해 보세요. GEOIP 직접 연결 규칙을 먼저 두면 뒤의 도메인 프록시 규칙이 적용되지 않을 수 있습니다. 명확한 서비스별 정책을 먼저 적용하고 지리 정보로 나머지를 판단하면 예외 규칙을 유지할 수 있습니다.
LAN 대역은 실제 네트워크 구성과도 일치해야 합니다. 예시에는 172.16.0.0/12가 포함되며 172.0.0.0/8 전체를 뜻하지 않습니다. 몇 줄을 줄이려고 공인 IP가 포함될 수 있는 대역 전체를 직접 연결로 설정하지 마세요. 위 규칙은 출구만 선택하며 TUN 라우팅, 네트워크 어댑터 우선순위, 방화벽 차단 문제를 자동으로 해결하지는 않습니다.
GEOIP의 no-resolve: DNS 조회를 줄이면 규칙에 걸리지 않을 수도 있습니다
트래픽 분리를 확인하다 보면 다음 두 가지 규칙을 자주 볼 수 있습니다. GEOIP,CN,DIRECT와 GEOIP,CN,DIRECT,no-resolve의 차이는 GeoIP 데이터가 아니라, 대상 IP를 판단하기 위해 규칙에서 도메인을 직접 조회할 수 있는지 여부입니다.
- no-resolve를 붙이지 않으면: 대상 IP가 있어야 판단할 수 있는 도메인 연결은 커널이 IP를 조회한 뒤 GeoIP로 판별할 수 있습니다. 위 기본 예시는 도메인 목록에 없는 중국 본토 서비스를 폭넓게 처리할 수 있도록 이 형식을 사용합니다.
- no-resolve를 붙이면: 이 규칙은 매칭을 위해 도메인 조회를 직접 시작하지 않습니다. 현재 연결에 사용할 수 있는 실제 대상 IP가 없으면 다음 MATCH 규칙으로 넘어갈 수 있습니다.
- 이미 IP를 확인한 경우: IP 주소로 직접 접속하거나 현재 연결 정보에 매칭 가능한 주소가 있으면 no-resolve가 붙은 IP 규칙도 일치할 수 있습니다. 설정 내용만 보고 추측하지 말고 연결 상세 정보를 확인하세요.
따라서 GEOIP에 no-resolve를 붙이면서 목록에 없는 모든 중국 본토 도메인까지 처리되기를 기대할 수는 없습니다. 트래픽 분리를 위한 DNS 조회를 최대한 줄이려면 도메인 규칙을 충분히 관리하고, 알 수 없는 일부 도메인이 프록시 기본 규칙으로 넘어갈 수 있다는 점을 감안해야 합니다.
fake-ip는 웹사이트의 실제 IP가 아닙니다
fake-ip를 사용하면 앱에 198.18.0.0/16 범위의 매핑 주소가 표시될 수 있습니다. 이는 커널이 도메인을 연결하기 위해 사용하는 가상 주소이지 웹사이트의 실제 위치가 아닙니다. ‘GEOIP를 고치기’ 위해 fake-ip 대역 전체를 직접 연결로 설정하지 마세요. 커널이 복원한 도메인, 실제 DNS 조회 결과, 일치한 규칙을 확인해야 합니다. DNS 설정은 사용 중인 커널 및 클라이언트 버전에 맞춰야 합니다. 자세한 내용은 설정 레퍼런스를 참조하세요.
rule-providers: 자주 쓰는 도메인 규칙을 관리하기 쉬운 파일로 분리
규칙이 수십 개에서 수백 개로 늘어나면 모든 도메인을 주 설정에 넣을수록 검토가 어려워집니다. rule-providers는 규칙의 출처를 선언하고, RULE-SET은 주 규칙 목록에서 해당 규칙 집합을 참조합니다. 아래 예시는 mihomo가 지원하는 로컬 파일 규칙 집합을 사용하므로 원격 규칙 다운로드와 주기적 업데이트를 기본 라우팅 문제와 분리해 점검할 수 있습니다.
1단계: 주 설정에서 선언하고 참조하기
관리할 도메인을 규칙 집합으로 옮긴 다음 아래 선언과 규칙 목록으로 주 설정의 해당 부분을 바꾸세요. local-direct는 사용자 지정 규칙 집합 이름이므로 참조할 때 철자까지 정확히 일치해야 합니다. 기존 LAN 규칙은 규칙 집합보다 앞에 유지하세요.
rule-providers:
local-direct:
type: file
behavior: classical
path: ./rules/local-direct.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
- IP-CIDR6,fe80::/10,DIRECT,no-resolve
- DOMAIN-SUFFIX,wikipedia.org,PROXY
- RULE-SET,local-direct,DIRECT
- GEOIP,CN,DIRECT
- MATCH,PROXY2단계: 규칙 집합 파일 만들기
커널 작업 디렉터리 기준 rules/local-direct.yaml에 다음 내용을 저장하세요. 상대 경로는 일반적으로 커널 작업 디렉터리를 기준으로 하며, 구독 파일을 다운로드한 디렉터리와 다를 수 있습니다. 클라이언트 로그와 실제 데이터 디렉터리를 확인하세요. mihomo는 경로 접근에 보안 제한을 두므로 허용된 데이터 디렉터리에 파일을 저장하는 것이 좋습니다.
payload:
- DOMAIN-SUFFIX,baidu.com
- DOMAIN-SUFFIX,qq.com
- DOMAIN-SUFFIX,alipay.com여기서 behavior: classical은 규칙 유형을 포함하는 형식으로 항목을 작성한다는 뜻입니다. 파일 안에 끝부분의 ,DIRECT가 없는 점에 유의하세요. 출구는 주 설정의 RULE-SET,local-direct,DIRECT에서 지정합니다. behavior: domain을 사용하려면 항목 형식도 함께 바꿔야 합니다. behavior만 바꾸고 기존 내용을 그대로 두면 안 됩니다.
로컬 파일 형식은 원격 구독의 업데이트 주기에 맞춰 새 내용을 자동으로 가져오지 않습니다. 파일을 수정한 뒤에는 클라이언트의 설정 다시 불러오기 또는 규칙 집합 다시 불러오기 기능을 사용하고 로그에서 정상적으로 읽혔는지 확인하세요. HTTP 형식 규칙 집합이 필요하다면 신뢰할 수 있는 출처, 캐시 경로, 업데이트 간격을 설정하세요. 예를 들어 interval: 86400의 단위는 초이며 하루를 뜻합니다. 출처의 형식도 behavior 설정과 일치해야 합니다.
구독 업데이트와 규칙 관리: 어떤 규칙이 먼저 적용되는지 확인하기
클라이언트가 생성한 구독 설정을 직접 수정하면 다음 업데이트 때 덮어쓰일 수 있습니다. 기존 구독은 노드 출처로 유지하고, 클라이언트가 지원하는 오버라이드, 병합 또는 확장 설정에서 사용자 규칙을 관리하는 편이 안전합니다. 클라이언트마다 병합 방식이 다릅니다. rules 전체를 바꾸는 경우도 있고 규칙을 앞에 추가하는 기능을 제공하는 경우도 있으므로, 저장에 성공했다는 사실만으로 순서가 올바르다고 판단하면 안 됩니다.
- 먼저 백업하기: 원본 설정과 현재 사용할 수 있는 규칙 집합 파일을 저장하고, 사용 중인 설정 이름을 기록해 두세요.
- 최종 설정 확인하기: 실제 실행 중인 설정에
mode: rule, 프록시 그룹 이름, 규칙 순서, rule-providers 선언이 포함되어 있는지 확인하세요. - 구독을 한 번 직접 업데이트하기: 업데이트가 끝난 뒤 다시 확인하세요. 다음 날 사용자 규칙이 사라진 것을 발견한 후에 점검하지 마세요.
- 한 번에 한 종류만 수정하기: 먼저 도메인 규칙을 검증하고, 다음으로 GEOIP를 추가한 뒤, 마지막으로 규칙 집합을 분리하세요. 문제가 생겼을 때 어느 단계에서 바뀌었는지 찾기 쉽습니다.
GeoIP 데이터 관리와 도메인 규칙 관리는 별개의 작업입니다. GeoIP 데이터를 업데이트해도 앱에 새로 추가된 도메인이 보완되지는 않습니다. 새 도메인 규칙을 추가해도 오래된 IP 국가·지역 정보가 수정되지는 않습니다. 데이터베이스 이름, 다운로드 방식, 업데이트 위치는 커널에 따라 다르므로 다른 클라이언트의 파일명을 CFW 디렉터리에 그대로 적용하지 마세요.
트래픽 분리 확인하기: 웹페이지가 열리는지가 아니라 일치한 규칙을 확인하세요
설정을 저장한 뒤 테스트할 연결을 새로 만드세요. 기존 장기 연결은 규칙을 바꿔도 출구가 자동으로 바뀌지 않는 경우가 많고, 브라우저가 연결을 재사용하면 이전 결과가 계속 나타날 수도 있습니다. 해당 연결을 닫고 다시 시도한 다음 클라이언트의 Connections 화면에서 대상 도메인, 일치한 규칙, 프록시 체인을 확인하세요. 클라이언트마다 표시되는 항목 이름은 조금씩 다를 수 있습니다.
| 테스트 상황 | 예시 설정에서 예상되는 결과 | 문제가 있을 때 먼저 확인할 항목 |
|---|---|---|
www.baidu.com에 접속 | 도메인 규칙 또는 local-direct에 일치하고 출구는 DIRECT | 도메인 철자, 규칙 집합 로드 여부, 앞선 차단 규칙 유무 |
www.wikipedia.org에 접속 | 도메인 규칙에 일치하고 PROXY 정책 그룹으로 전달 | 그룹에서 현재 선택된 항목이 DIRECT가 아니라 프록시 노드인지 확인 |
실제 라우터 주소에 접속(예: 192.168.1.1) | 커널에 전달되었다면 LAN 직접 연결 규칙과 일치해야 합니다 | 연결 목록에 기록이 없다면 시스템 프록시의 우회 목록을 통해 바로 연결되었을 수 있습니다. |
| 도메인 목록에 없는 공인 IP 대상에 접속 | GEOIP로 판별하고 일치하지 않으면 MATCH 규칙으로 처리 | 대상 도메인의 조회 IP, GeoIP 데이터, no-resolve 사용 여부 |
자주 하는 오해 세 가지
- PROXY가 표시되면 반드시 프록시 노드를 거친다고 생각하기: PROXY는 그룹 이름일 뿐입니다. 그룹에서 DIRECT를 선택했다면 최종 연결은 직접 연결입니다. 전체 프록시 체인을 확인하세요.
- 웹페이지가 열리면 모든 리소스가 같은 경로를 쓴다고 생각하기: 기본 페이지, 이미지, 로그인 API가 서로 다른 도메인에 연결될 수 있으므로 관련 연결을 하나씩 확인해야 합니다.
- 연결 목록에 기록이 없으면 규칙이 작동하지 않는다고 생각하기: 프로그램이 애초에 커널을 거치지 않았을 수 있습니다. 먼저 시스템 프록시나 TUN이 트래픽을 받아들이는지 확인한 뒤 규칙 매칭을 점검하세요.
잘못 분류되는 도메인이 있다면 ‘커널에 전달됐는지 → 실행 모드 → 실제 도메인과 IP → 일치한 규칙 → 최종 출구’ 순서로 확인하는 편이 노드를 계속 바꾸는 것보다 효과적입니다. 기본 구성이 안정되면 서비스 도메인과 규칙 집합을 단계적으로 보완하세요. 규칙 목록을 완벽해 보이게 만들려고 출처가 불분명하고 우선순위가 겹치는 목록을 여러 개 한꺼번에 추가하지 마세요.