Clash 국내외 트래픽 분기 규칙 설정 실전: 도메인 규칙, GEOIP와 최종 대체 전략

먼저 목표를 정하세요: 국내 트래픽은 직접 연결하고 해외 트래픽은 정책 그룹으로

Clash의 규칙 모드는 웹사이트가 “국내”인지 “해외”인지 먼저 판단해 출구를 자동으로 선택하지 않습니다. 커널이 실제로 처리하는 방식은 위에서 아래로 정렬된 규칙 목록입니다. 새 연결은 규칙을 순서대로 확인하고 첫 번째로 일치하는 규칙에서 즉시 멈춘 뒤, 해당 규칙이 지정한 정책 그룹이나 프록시 노드 또는 DIRECT로 전달됩니다. 따라서 분기 결과는 무엇보다 규칙 순서에 좌우되며, 그다음으로 규칙 데이터베이스의 범위와 노드 상태가 영향을 줍니다.

이 글에서는 바로 적용할 수 있는 목표를 기준으로 합니다. LAN과 중국 본토 도메인은 직접 연결하고, 프록시가 필요한 도메인은 “해외 트래픽” 정책 그룹으로 보내며, 나머지는 GEOIP로 판단한 뒤 마지막에 MATCH로 일괄 처리합니다. 예시는 mihomo v1.19 계열이 지원하는 기본 규칙 문법을 기준으로 하며, Clash YAML 설정을 읽는 대부분의 그래픽 클라이언트에서도 사용할 수 있습니다.

트래픽 유형	권장 동작	주요 규칙	배치 위치
로컬 및 LAN 주소	DIRECT	IP-CIDR	맨 앞
프록시를 강제할 도메인	해외 트래픽	DOMAIN、DOMAIN-SUFFIX	국내 규칙 앞
명확한 중국 본토 도메인	DIRECT	DOMAIN-SUFFIX	중간
중국 본토로 확인되는 IP	DIRECT	GEOIP,CN	끝부분 직전
그 밖의 미일치 연결	해외 트래픽	MATCH	마지막 규칙

규칙 문법: DOMAIN, DOMAIN-SUFFIX와 IP-CIDR

정확한 도메인과 도메인 접미사

DOMAIN은 완전한 호스트 이름 하나만 일치시킵니다. 예를 들어 DOMAIN,api.example.com,해외 트래픽은 api.example.com과 일치하지만 www.example.com에는 적용되지 않습니다. 단일 API 도메인, 업데이트 서버 또는 일반 규칙보다 우선 처리해야 하는 특정 호스트에 적합합니다.

DOMAIN-SUFFIX는 지정한 도메인과 하위 서브도메인까지 일치시킵니다. DOMAIN-SUFFIX,example.com,해외 트래픽 규칙은 example.com, www.example.com, api.eu.example.com에 모두 적용됩니다. 실제 관리에서는 호스트 이름을 하나씩 나열하는 것보다 접미사 규칙이 간결하지만 적용 범위도 넓습니다. 하나의 API를 처리하려고 전체 서비스 도메인을 프록시로 보내지 않도록 주의하세요.

rules:
  - DOMAIN,api.example.com,해외 트래픽
  - DOMAIN-SUFFIX,wikipedia.org,해외 트래픽
  - DOMAIN-SUFFIX,qq.com,DIRECT
  - DOMAIN-SUFFIX,taobao.com,DIRECT

규칙에 사용하는 정책 이름은 proxy-groups에 등록된 이름과 한 글자까지 같아야 합니다. 정책 그룹 이름이 “노드 선택”이라면 규칙 끝에도 “노드 선택”을 써야 하며, “해외 트래픽”으로 바꿔 쓸 수 없습니다. 이름이 다르면 자동 매핑되지 않고 설정 검사에서 정책을 찾을 수 없다는 오류가 발생합니다.

LAN 주소는 IP-CIDR로 먼저 직접 연결

공유기 관리 페이지, NAS, 프린터와 로컬 개발 서비스는 보통 사설 주소를 사용합니다. 이러한 주소를 앞쪽에 배치하면 192.168.1.1, 10.0.0.20 같은 장치 접속이 원격 프록시로 전달되는 것을 막을 수 있습니다. IPv4의 대표적인 사설 네트워크 대역은 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16입니다.

rules:
  - 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

no-resolve는 해당 IP 대역을 매칭할 때 도메인에 대한 추가 조회를 수행하지 않는다는 뜻입니다. 명확한 사설 주소 규칙에 사용하면 불필요한 DNS 조회를 줄일 수 있습니다. DNS를 끄는 설정은 아니며, 이미 확인된 대상 IP를 변경하지도 않습니다.

GEOIP,CN의 역할과 한계

GEOIP,CN,DIRECT는 대상 IP의 지리적 소속 데이터베이스를 기준으로 판단합니다. 연결 대상이 이미 IP 주소이거나 커널이 규칙 매칭을 위해 도메인 조회 결과를 확보한 경우, 해당 IP가 데이터베이스에서 CN으로 분류되면 직접 연결합니다. 넓은 범위의 중국 본토 직접 연결을 위한 보조 규칙으로 유용하지만 모든 도메인 규칙을 대신해서는 안 됩니다.

도메인의 소속 지역과 서버 IP의 위치가 항상 일치하는 것은 아닙니다. 중국 본토 서비스가 해외 CDN 노드를 사용할 수도 있고, 해외 서비스가 중국 본토에 위치한 엣지 노드로 정적 리소스를 제공할 수도 있습니다. GEOIP 데이터에는 업데이트 주기도 있어 데이터센터를 이전했거나 새로 할당된 주소 대역이 한동안 잘못 분류될 수 있습니다. 안정성이 중요한 서비스는 DOMAIN 또는 DOMAIN-SUFFIX로 방향을 먼저 지정하고, GEOIP는 도메인 규칙 뒤에서 보완하는 편이 좋습니다.

GEOIP에 no-resolve를 추가해야 할까요?

다음 두 작성 방식은 결과가 달라질 수 있습니다.

- GEOIP,CN,DIRECT
- GEOIP,CN,DIRECT,no-resolve

첫 번째 방식은 필요할 때 커널이 도메인을 조회해 IP를 얻은 뒤 지리적 매칭을 수행하도록 합니다. 두 번째 방식은 이 규칙으로 인한 추가 조회를 막습니다. 앞에 중국 본토 도메인을 충분히 포괄하는 규칙 집합이 있다면 GEOIP에 no-resolve를 추가해 규칙 매칭 단계의 조회 작업을 줄일 수 있습니다. 반대로 직접 작성한 도메인 규칙이 적은 상태에서 no-resolve를 너무 일찍 사용하면 목록에 없는 중국 본토 도메인이 MATCH로 넘어가 프록시를 사용할 수 있습니다.

실제 설정에서는 먼저 no-resolve 없이 작성한 뒤 연결 로그와 DNS 지연 시간을 확인해 보세요. 테스트 환경에서 캐시되지 않은 도메인 20곳을 처음 연속으로 접속할 때 추가 조회로 수 밀리초에서 수십 밀리초의 대기가 발생할 수 있으며, 정확한 값은 로컬 DNS, 네트워크 거리와 캐시 적중률에 따라 달라집니다. GEOSITE 또는 rule-provider를 충분히 적용했다면 로그를 확인한 뒤 GEOIP의 조회 동작을 줄일지 결정하세요.

GEOIP 데이터는 커널 리소스와 함께 업데이트해야 합니다

mihomo는 일반적으로 GeoIP 데이터 파일을 통해 주소의 소속 지역을 판단합니다. 그래픽 클라이언트는 커널 업데이트, 설정 리소스 업데이트 또는 별도의 데이터베이스 업데이트 메뉴에서 이 파일을 관리할 수 있습니다. 자주 사용하는 중국 본토 IP가 대량으로 대체 정책으로 잘못 분류된다면 규칙 순서뿐 아니라 GeoIP 파일이 정상적으로 로드되었는지도 확인해야 합니다. 로그에 리소스 파일 누락, 파싱 실패 또는 호환되지 않는 데이터베이스 형식이 표시될 때 DOMAIN-SUFFIX를 계속 추가하는 것은 일부 현상만 완화할 뿐 지리 규칙 자체를 해결하지 못합니다.

MATCH 대체 규칙: 마지막 규칙이 미지의 트래픽 출구를 결정합니다

MATCH는 앞에서 일치하지 않은 모든 연결을 받으므로 규칙 목록의 마지막에 배치해야 합니다. 중국 본토는 직접 연결하고 해외 트래픽은 프록시로 보내는 일반적인 구성은 MATCH,해외 트래픽입니다. 소속 지역을 확인하기 어려운 대상도 기본적으로 프록시 정책 그룹으로 보내므로 아직 규칙 데이터베이스에 등록되지 않은 새 도메인에 적합하고, 정책 그룹에서 노드를 바꾸기도 쉽습니다.

MATCH,DIRECT로 작성하면 등록되지 않은 해외 도메인도 직접 연결됩니다. 기본적으로 직접 연결하고 일부 서비스만 프록시로 보내는 구성에는 적합하지만 이 글의 목표와는 맞지 않습니다. 두 방식 모두 작동하며, 차이는 MATCH 자체의 우선순위가 아니라 미지의 트래픽에 적용되는 기본 출구입니다.

읽기 쉬운 전체 규칙 순서

아래 예시는 설정에 “해외 트래픽”이라는 정책 그룹이 이미 존재한다고 가정합니다. 노드 인증 정보와 구독 정보는 포함하지 않았으며, 클라이언트의 규칙 오버라이드 영역에 추가할 수 있습니다.

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

rules:
  - 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

  - DOMAIN-SUFFIX,wikipedia.org,해외 트래픽
  - DOMAIN-SUFFIX,githubusercontent.com,해외 트래픽

  - DOMAIN-SUFFIX,qq.com,DIRECT
  - DOMAIN-SUFFIX,taobao.com,DIRECT
  - DOMAIN-SUFFIX,jd.com,DIRECT
  - DOMAIN-SUFFIX,bilibili.com,DIRECT

  - GEOIP,CN,DIRECT
  - MATCH,해외 트래픽

mode: rule은 규칙 모드를 활성화하고, mixed-port: 7890은 일반적인 HTTP와 SOCKS 인바운드 연결을 동시에 받습니다. 클라이언트가 포트를 관리하고 있다면 오버라이드에서 중복 선언하지 않아야 인터페이스 설정과 충돌하지 않습니다. Clash Verge Rev 2.3.x에서는 「설정」→「Clash 설정」에서 현재 포트와 실행 모드를 확인할 수 있습니다. 버전에 따라 그룹 이름은 조금 다를 수 있지만 모드가 Global이나 Direct가 아닌 Rule로 표시되는지 확인하세요.

규칙 사이에 빈 줄을 넣을 필요는 없습니다. 예시의 빈 줄은 LAN, 강제 프록시, 중국 본토 도메인, 대체 규칙의 네 계층을 구분하기 위한 것입니다. YAML은 공백으로 들여쓰며 탭 문자는 사용할 수 없습니다. 저장 후 클라이언트에서 파싱 오류가 표시되면 먼저 콜론 뒤의 공백, 목록 앞의 하이픈, 정책 그룹 이름을 확인하세요.

구독 설정을 유지하는 방법

구독으로 생성된 설정을 직접 열어 수정하면 잠시 동안은 적용 결과를 볼 수 있지만, 다음 구독 업데이트 때 덮어써지는 경우가 많습니다. 그래픽 클라이언트는 일반적으로 “오버라이드”, “설정 병합” 또는 “확장 스크립트” 기능을 제공하며, 구독 내용을 불러온 뒤 필드를 추가하거나 조정할 수 있습니다. 어떤 방식을 사용할지는 클라이언트가 규칙 앞 삽입, 뒤 삽입, 배열 교체를 지원하는지에 따라 달라집니다.

현재 설정을 먼저 복사한 뒤 복사본에서 규칙을 테스트하세요.
클라이언트의 오버라이드 방식이 rules를 추가하는지, 기존 규칙 배열을 완전히 교체하는지 확인하세요.
먼저 일치해야 하는 사용자 지정 규칙은 구독 규칙 앞에 배치해야 하며, MATCH 뒤에 추가하는 것만으로는 부족합니다.
저장한 뒤 설정을 다시 불러오고, 편집기 소스 파일이 아니라 실제 실행 중인 설정을 확인하세요.
구독을 한 번 수동으로 업데이트해 사용자 지정 규칙이 그대로 남아 있고 원래 순서도 유지되는지 확인하세요.

“끝에 추가”는 가장 흔한 적용 실패 원인입니다. 구독 규칙은 보통 MATCH 또는 FINAL로 이미 끝나므로 그 뒤에 추가한 규칙은 절대 일치하지 않습니다. 클라이언트가 규칙 추가만 지원한다면 prepend, 규칙 앞 삽입 또는 스크립트 주입 기능을 사용하세요. 전체 교체만 가능하다면 구독에 포함된 중요한 직접 연결, 차단, LAN 규칙도 함께 관리해야 합니다.

트래픽 분기가 실제로 적용되는지 확인하기

먼저 모드, 포트와 시스템 프록시를 확인하세요

규칙이 올바르더라도 트래픽이 Clash로 들어오지 않으면 로그에 해당 연결이 나타나지 않습니다. 데스크톱 클라이언트에서는 먼저 Rule 모드가 활성화되어 있는지 확인한 다음 시스템 프록시가 현재 수신 포트를 가리키는지 확인하세요. 이 글의 예시는 127.0.0.1:7890을 사용합니다. 인터페이스에 7897, 7899 또는 다른 포트가 표시된다면 테스트 명령도 동일하게 수정해야 합니다.

curl -I -x http://127.0.0.1:7890 https://www.qq.com/
curl -I -x http://127.0.0.1:7890 https://www.wikipedia.org/

다음 두 명령은 요청이 지정한 HTTP 프록시 포트를 거치는지만 확인합니다. 200, 301, 302가 반환되면 원격 HTTP 응답을 받은 것이지만 상태 코드만으로 출구를 판단할 수는 없습니다. 실제 분기 결과는 클라이언트 연결 목록이나 로그에 표시되는 규칙 이름, 정책 그룹, 실제 노드를 함께 확인해야 합니다.

연결 로그에서 확인할 세 가지 항목

대상 호스트: 로그에 예상한 도메인이 기록되었는지, 백그라운드 요청이나 페이지 내부의 타사 리소스가 기록된 것은 아닌지 확인합니다.
일치한 규칙: 중국 본토 사이트에서는 DOMAIN-SUFFIX 또는 GEOIP,CN이 표시되어야 하며, 해외 테스트 도메인에서는 지정한 접미사 규칙이나 MATCH가 표시되어야 합니다.
최종 경로: DIRECT는 직접 연결을 의미하며, 정책 그룹 이름 뒤에는 보통 실제로 선택된 노드도 표시됩니다.

웹페이지 하나가 메인 도메인, 이미지 CDN, 통계 API, 글꼴 리소스와 동영상 조각에 동시에 연결할 수 있으므로 같은 페이지에서 DIRECT와 프록시 연결이 함께 나타나도 이상하지 않습니다. 분기 확인은 브라우저 탭 전체가 아니라 개별 연결을 기준으로 해야 합니다. 연결 기록을 지운 뒤 시크릿 창에서 다시 열면 처음 생성되는 연결을 관찰하기가 더 쉽습니다.

임시 규칙으로 우선순위 확인하기

규칙 순서가 잘못되었다고 의심되면 맨 앞에 식별하기 쉬운 테스트 규칙을 임시로 추가해 보세요. 예를 들어 특정 중국 본토 도메인을 “해외 트래픽”으로 보내는 방식입니다. 설정을 다시 불러온 뒤 해당 도메인에 접속했는데도 로그에 DIRECT가 표시된다면 현재 실행 설정이 이 규칙을 사용하지 않거나 앞단 오버라이드가 적용되지 않은 것입니다. 테스트가 끝나면 임시 규칙을 삭제해 서비스 접속 경로가 장기간 바뀌지 않도록 하세요.

TUN 모드에서 추가로 확인할 사항

시스템 프록시는 프록시 설정을 직접 읽는 애플리케이션에만 적용되지만, TUN 모드는 가상 네트워크 장치를 통해 더 많은 TCP, UDP와 시스템 프록시 설정을 따르지 않는 트래픽을 가로챕니다. 규칙 문법은 여전히 같은 순서로 매칭되지만 DNS, 라우팅 테이블과 앱 자체의 암호화 DNS가 결과에 더 큰 영향을 줄 수 있습니다.

TUN을 활성화한 뒤에는 먼저 클라이언트가 가상 네트워크 장치를 생성하는 데 필요한 시스템 권한을 확보했는지 확인하세요. Windows에서는 가상 네트워크 어댑터가 정상적으로 설치되고 활성화되었는지 확인할 수 있습니다. macOS에서는 네트워크 확장 또는 VPN 설정 권한을 승인해야 하며, Linux에서는 사용 가능한 /dev/net/tun과 필요한 capability가 보통 필요합니다. 권한이 실패하면 인터페이스에서 TUN 전환이 완료된 것처럼 보여도 실제 연결은 시스템 프록시만 거칠 수 있습니다.

브라우저에서 별도의 보안 DNS를 사용하면 설정에 지정한 DNS 수신 방식을 우회해 도메인 조회 결과가 규칙 엔진의 예상과 달라질 수 있습니다. 문제를 확인하는 동안에는 브라우저가 시스템 DNS를 사용하도록 임시 변경한 뒤 연결 로그를 비교해 보세요. mihomo 설정에서 자주 사용하는 DNS 수신 포트는 1053이고 프록시 혼합 포트는 보통 7890입니다. 용도가 다르므로 시스템 프록시를 DNS 포트로 지정하면 안 됩니다.

자주 발생하는 오류와 해결 방법

현상	일반적인 원인	해결 방법
모든 웹사이트가 같은 노드를 사용함	현재 Global 모드로 실행 중임	Rule로 전환한 뒤 연결을 다시 생성하세요
사용자 지정 규칙이 전혀 일치하지 않음	규칙이 MATCH 뒤에 추가됨	규칙 앞 삽입 또는 전체 병합을 사용하세요
중국 본토 도메인이 간헐적으로 프록시를 사용함	도메인이 등록되지 않았고 조회된 IP도 CN으로 분류되지 않음	정확한 도메인 규칙을 추가하고 GeoIP 데이터를 업데이트하세요
LAN 장치를 열 수 없음	사설 주소가 대체 규칙에 의해 처리됨	사설 네트워크 대역의 IP-CIDR을 맨 앞에 배치하세요
구독 업데이트 후 규칙이 사라짐	구독으로 생성된 파일을 직접 수정함	클라이언트 오버라이드 또는 설정 병합으로 옮기세요
규칙은 일치하지만 웹페이지가 여전히 열리지 않음	정책 그룹에서 선택한 노드를 사용할 수 없음	지연 시간 테스트, 핸드셰이크 로그와 노드 선택을 확인하세요

설정을 완료한 뒤 규칙 수를 무조건 늘릴 필요는 없습니다. 사설 주소, 소수의 강제 예외, 관리된 중국 본토 도메인 규칙, GEOIP, 최종 MATCH로 계층을 명확하게 유지하는 편이 안정적입니다. 한 번에 한 계층만 조정하고 로그로 일치 결과를 확인하면, 새 도메인이 생겼을 때 정확한 규칙을 추가할지, 규칙 집합을 업데이트할지, 정책 그룹을 수정할지도 쉽게 판단할 수 있습니다.