Clash 국내외 트래픽 분기 설정법: GEOIP·GEOSITE·RULE-SET 조합 실전

먼저 커널과 규칙 모드 확인하기

국내외 트래픽 분기는 ‘국내 직접 연결’ 규칙 하나만으로 끝나지 않습니다. 도메인 분류, IP 주소의 국가 판별, 수동 예외, 마지막 기본 연결 경로가 각각 다른 역할을 합니다. 실용적인 구성은 명확한 예외를 먼저 처리하고, 국내 도메인을 매칭한 다음, 국내 IP로 누락을 보완한 뒤 나머지 연결을 지정한 정책 그룹으로 보내는 방식입니다.

이 설정은 Clash Meta, 즉 현재의 mihomo 커널을 대상으로 합니다. Clash는 커널과 클라이언트 생태계를 통칭하는 경우가 많지만, 모든 구형 커널이 같은 설정 항목을 지원하는 것은 아닙니다. 특히 GEOSITE와 geodata 설정은 모든 기존 Clash 버전에 그대로 적용할 수 없습니다. 설정을 수정하기 전에 클라이언트의 ‘정보’ 또는 커널 정보 화면에서 실제 커널을 확인하세요. 창 제목에 Clash라고 표시된 것만으로는 충분하지 않습니다.

모드를 Rule／규칙으로 설정하세요. 전역 모드에서는 이 문서의 규칙에 따라 연결 경로를 선택하지 않으며, 직접 연결 모드는 트래픽 분기 확인에 적합하지 않습니다.
사용 가능한 정책 그룹이 있는지 확인하세요. 아래 예시에서는 기존 설정에 해외 출구라는 그룹이 있고, 그룹 안에 사용할 수 있는 노드가 있다고 가정합니다. 그룹 이름은 정확히 일치해야 합니다.
구독 원본을 보존하세요. 사용자 지정 규칙은 클라이언트의 영구 오버라이드나 병합 기능으로 추가하는 것이 좋습니다. 구독에서 생성된 파일을 직접 수정하면 다음 업데이트 때 변경 사항이 사라질 수 있습니다.

규칙 개수보다 순서가 중요합니다

규칙은 위에서 아래 순서로 확인하며, 하나가 매칭되면 해당 규칙의 대상 정책을 사용하고 이후 규칙은 판단에 참여하지 않습니다. ‘더 구체적인 규칙이 우선’이라는 것은 커널이 자동으로 비교해 정하는 결과가 아니라, 설정 작성자가 해당 규칙을 앞에 배치해야 한다는 뜻입니다.

rules:
  - DOMAIN-SUFFIX,github.com,해외 출구
  - GEOSITE,cn,DIRECT
  - GEOIP,CN,DIRECT,no-resolve
  - MATCH,해외 출구

이 네 줄에서는 github.com과 그 하위 도메인이 먼저 수동 지정 그룹으로 연결됩니다. 국내 도메인 목록에 매칭되는 연결은 직접 연결되고, 대상 IP가 있으며 데이터베이스에서 중국 주소로 판별된 연결도 직접 연결됩니다. 나머지는 MATCH에 맡깁니다. 첫 번째 규칙은 해당 도메인 접미사에만 적용되며 GitHub에서 사용하는 모든 정적 리소스 도메인을 자동으로 포함하지는 않습니다.

헷갈리기 쉬운 용어 세 가지

규칙 유형	판단 기준	적합한 용도
`GEOSITE`	도메인 분류 데이터베이스의 항목	도메인 분류에 따라 트래픽을 나눠 IP 국가 판별 의존도 줄이기
`GEOIP`	대상 IP가 속한 국가 또는 지역	도메인 목록에서 누락된 연결 보완
`RULE-SET`	별도로 선언하는 규칙 제공자	별도 예외 목록이나 독립 규칙 파일 관리

DIRECT는 기본 제공 직접 연결 정책이고, 해외 출구는 이 문서에서 정한 정책 그룹 이름입니다. 둘은 서로 다른 유형의 객체입니다. 규칙이 정책 그룹을 가리킨다는 것은 ‘이 그룹으로 전달한다’는 뜻일 뿐입니다. 그룹에서 현재 노드를 선택했는지 DIRECT를 선택했는지는 추가로 확인해야 합니다.

GEOSITE 및 GEOIP 데이터 준비하기

GEOSITE,cn의 cn은 커널이 실시간으로 조회하는 국가 태그가 아니라 데이터베이스에 등록된 분류 이름입니다. 해당 분류의 존재 여부와 포함된 도메인은 사용 중인 geosite.dat에 따라 달라집니다. 마찬가지로 GEOIP,CN은 IP 데이터베이스에 기록된 주소의 국가를 판단하는 것으로, 웹사이트 운영사의 등록 국가나 서버의 실제 위치를 보장하지 않습니다.

아래 구성은 geodata-mode: true를 명시적으로 활성화하므로 GEOIP에는 geoip.dat를, GEOSITE에는 geosite.dat를 사용합니다. 클라이언트의 데이터 관리 기능으로 두 파일을 준비하고, 시작 로그에서 로드 오류가 없는지 확인하세요. 기존 설정이 MMDB 모드라면 데이터 파일을 준비하지 않은 채 전환 설정만 바꾸지 마세요.

데이터 파일은 신뢰할 수 있는 관리 주체에서 받아 현재 커널과 호환되는 것을 사용하세요. 파일 이름이 맞더라도 내부 형식까지 올바르다는 뜻은 아닙니다.
분류를 찾을 수 없다는 오류가 발생하면 먼저 데이터베이스에 포함된 분류 이름을 확인하세요. 기억에 의존해 cn을 다른 항목 이름으로 바꾸지 마세요.
데이터베이스를 업데이트하면 분류 결과가 달라질 수 있습니다. 기존 설정과 정상 작동이 확인된 데이터를 보관하고, 업데이트 후에는 같은 사이트 목록으로 다시 테스트하세요.

이 문서에서는 자동 다운로드 주소를 다루지 않습니다. ‘파일을 가져오지 못한 문제’와 ‘규칙을 잘못 작성한 문제’를 구분하기 위해서입니다. 처음 문제를 확인할 때는 로컬 데이터가 안정적으로 읽히는지 먼저 확인한 다음 업데이트 주기를 설정하면 원인을 더 쉽게 찾을 수 있습니다.

RULE-SET으로 수동 예외 관리하기

수동 예외는 분류 규칙보다 앞에 배치하세요. 특정 사이트의 분류가 적절하지 않을 때 작은 목록 하나만 수정하면 되므로 전체 규칙 데이터베이스를 복사할 필요가 없습니다. 아래 예시는 로컬 YAML 파일을 사용하므로 규칙 파일을 온라인에서 내려받을 필요가 없고, 실제로 어떤 내용이 로드됐는지도 확인하기 쉽습니다.

1단계: 규칙 제공자 두 개 선언하기

아래 항목을 기존 설정의 최상위에 병합하세요. 이미 rule-providers가 있다면 그 아래에 두 항목을 추가하고, 같은 이름의 최상위 키를 새로 만들지 마세요. 상대 경로는 실제 커널의 작업 디렉터리를 기준으로 하므로 다운로드 파일이 있는 디렉터리와 다를 수 있습니다. 샌드박스 방식의 클라이언트는 읽을 수 있는 경로를 제한할 수도 있습니다.

mode: rule
geodata-mode: true

rule-providers:
  local-direct:
    type: file
    behavior: classical
    format: yaml
    path: ./rules/local-direct.yaml

  local-proxy:
    type: file
    behavior: classical
    format: yaml
    path: ./rules/local-proxy.yaml

behavior: classical은 파일에 DOMAIN-SUFFIX 같은 규칙 유형을 포함한 항목을 작성한다는 뜻입니다. 제공자 항목에는 연결 경로를 적지 않습니다. 연결 경로는 기본 설정의 RULE-SET 행에서 지정합니다. behavior: domain으로 바꾸면 파일 문법도 함께 조정해야 하며, 기존 문법을 그대로 섞어 쓸 수 없습니다.

2단계: 로컬 목록 만들기

아래 두 파일은 ‘지정한 도메인을 직접 연결’하고 ‘지정한 도메인을 프록시로 연결’하는 방법을 보여 줍니다. example.com은 문서 예시용 도메인이며 연결 테스트 사이트로 권장하는 주소가 아닙니다. 실제로 사용할 때는 해당 항목을 삭제하고 필요에 맞게 목록을 관리하세요.

rules/local-direct.yaml：

payload:
  - DOMAIN-SUFFIX,example.com

rules/local-proxy.yaml：

payload:
  - DOMAIN-SUFFIX,github.com
  - DOMAIN-SUFFIX,githubusercontent.com

두 프록시 예외는 설정 방법을 보여 주기 위한 예시일 뿐, 모든 네트워크 환경에서 해당 서비스를 반드시 프록시로 연결해야 한다는 뜻도 아니고 관련 도메인을 전부 포함하는 것도 아닙니다. 웹페이지는 열리지만 이미지가 로드되지 않는다면 실패한 요청의 도메인을 추가로 확인하세요. CDN 전체 IP 대역을 같은 연결 경로로 지정하는 것은 피하는 편이 좋습니다.

3단계: 계층에 맞춰 rules 정리하기

기존 rules 목록을 아래 순서로 정리하세요. 예시에는 IPv4 루프백과 일반적인 사설 주소, IPv6 루프백·고유 로컬 주소·링크 로컬 주소가 포함되어 있습니다. 모든 특수 목적 주소를 빠짐없이 다룬 목록은 아닙니다.

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
  - IP-CIDR6,::1/128,DIRECT,no-resolve
  - IP-CIDR6,fc00::/7,DIRECT,no-resolve
  - IP-CIDR6,fe80::/10,DIRECT,no-resolve
  - RULE-SET,local-direct,DIRECT
  - RULE-SET,local-proxy,해외 출구
  - GEOSITE,cn,DIRECT
  - GEOIP,CN,DIRECT,no-resolve
  - MATCH,해외 출구

라우터나 내부 네트워크 서비스에 접속할 때 마지막 프록시 출구로 빠지지 않도록 로컬 주소를 먼저 처리합니다. 다만 이 주소 규칙에는 no-resolve가 설정되어 있어, 아직 확인되지 않은 도메인을 판별하기 위해 DNS 조회를 시작하지 않습니다. 내부 도메인을 사용하는 환경이라면 직접 연결 목록에 실제 도메인을 추가하고, 접근 가능한 내부 DNS도 설정하세요.

두 사용자 지정 목록에 같은 도메인이 있으면 앞에 배치된 local-direct가 먼저 매칭됩니다. 나중에 특정 규칙이 적용되지 않는 이유를 파악하기 어려워지지 않도록 목록이 서로 겹치지 않게 관리하세요. 구독에 포함된 차단·앱별·특정 서비스 규칙을 사용하는 경우에도 필요에 따라 위치를 다시 정해야 합니다. 기존 규칙을 무작정 삭제하지 마세요.

no-resolve와 MATCH의 적용 범위 이해하기

no-resolve는 DNS를 끄는 설정이 아닙니다

GEOIP,CN,DIRECT,no-resolve는 판단에 사용할 대상 IP가 아직 없으면 이 IP 규칙만을 위해 도메인을 조회하지 않는다는 뜻입니다. IP 주소로 직접 접속하거나 커널이 이미 사용할 수 있는 실제 대상 IP를 확보했다면 계속 매칭할 수 있습니다. 이 매개변수는 브라우저의 도메인 조회를 중단하거나 전체 DNS 모듈을 끄지 않습니다.

그 대신 다음과 같은 한계가 있습니다. 국내 도메인이 GEOSITE,cn에 포함되지 않았고 GEOIP 규칙에 도달했을 때 사용할 수 있는 IP도 없다면, 연결은 MATCH까지 내려가 최종적으로 프록시를 이용할 수 있습니다. 이는 보수적인 구성에서 예상되는 동작 범위이며, GEOIP를 커널이 무시했다고 단정할 이유는 아닙니다.

도메인 목록부터 수정하세요: 직접 연결이 필요한 것으로 확인된 도메인을 local-direct에 추가하세요. 결과를 명확하게 확인할 수 있고 되돌리기도 쉽습니다.
필요할 때만 조회를 허용하세요: GEOIP 규칙에서 no-resolve를 제거하면 IP 판별을 위한 조회가 실행될 수 있습니다. 단, 조회 대기 시간과 DNS 경로도 함께 확인해야 합니다.
fake-ip 주소를 서버 주소로 취급하지 마세요: 예를 들어 198.18.0.0/16은 fake-ip 주소 풀로 사용될 수 있으므로, 이 주소만으로 서비스 사이트의 위치를 판별하면 안 됩니다.

MATCH는 미매칭 연결의 기본 규칙이지 장애 전환이 아닙니다

MATCH,해외 출구는 앞선 규칙에 하나도 매칭되지 않을 때 명확한 연결 대상을 지정합니다. 프록시 노드 연결에 실패했다고 해서 직접 연결을 다시 시도하지는 않습니다. 노드 장애 전환이 필요하다면 정책 그룹에서 적절한 그룹 유형을 사용하고 상태 확인을 올바르게 설정하세요. 반대로 MATCH,DIRECT는 ‘분류되지 않은 연결을 모두 직접 연결’한다는 뜻이므로, 목록에 없는 해외 도메인이 직접 연결될 수 있습니다.

이 문서에서는 ‘국내 허용 목록은 직접 연결하고 나머지는 프록시로 연결’하는 방식을 선택합니다. 새 해외 도메인이 프록시 경로를 사용하게 하기는 쉽지만, 모든 국내 서비스를 정확히 판별한다고 보장할 수는 없습니다. 트래픽 분기 설정이 오판을 자동으로 없애 주지는 않으므로 마지막에는 소수의 수동 예외가 필요합니다.

연결 기록으로 실제 경로 확인하기

설정을 불러올 수 있다는 것은 문법과 참조 대상이 대체로 올바르다는 뜻일 뿐, 트래픽이 예상대로 커널을 통과한다는 뜻은 아닙니다. 먼저 브라우저가 시스템 프록시를 사용 중인지, 또는 TUN이 대상 앱의 트래픽을 제대로 가로채는지 확인하세요. 시스템 프록시는 보통 프록시 설정을 따르는 프로그램에만 영향을 줍니다. 이 사실만으로 모든 UDP 연결이나 별도의 네트워크 스택을 사용하는 앱까지 처리된다고 볼 수는 없습니다.

설정을 다시 불러오고 로그를 확인하세요. 규칙 파일 읽기 실패, GEOSITE 분류 누락, 대상 정책을 찾을 수 없는 오류가 없는지 확인합니다. 먼저 info 수준을 유지하고, 정보가 부족하면 잠시 debug를 켜서 문제를 재현한 다음 원래대로 되돌리세요.
먼저 수동 예외 하나를 테스트하세요. 목록에 있는 도메인에 접속한 뒤 연결 상세 정보에서 RuleSet 매칭 여부를 확인하고, 해당 제공자와 최종 정책 경로를 살펴보세요.
그다음 도메인 분류를 테스트하세요. 현재 데이터베이스의 cn 항목에 실제로 포함된 도메인을 하나 골라 규칙 유형이 GeoSite, 정책이 DIRECT인지 확인하세요.
마지막으로 기본 규칙을 확인하세요. 앞선 규칙에 매칭되지 않는 연결을 찾아 Match로 처리되는지 확인하고, 해외 출구에서 현재 선택된 실제 노드도 살펴보세요.

테스트할 때마다 관련된 기존 연결을 닫고 새 연결을 만드세요. 이미 설정된 TCP 연결은 규칙 파일을 수정해도 연결 경로가 자동으로 바뀌지 않습니다. 브라우저가 연결을 재사용하면 ‘규칙을 바꿨는데 달라진 게 없다’고 착각하기 쉽습니다. 테스트에서는 접속에 실패한 화면만 캡처하기보다 도메인, 대상 IP, 매칭 규칙, 최종 출구를 기록하는 편이 유용합니다.

자주 발생하는 오판과 수정 순서

증상	먼저 확인할 항목	해결 방법
국내 사이트가 프록시로 연결됨	Match에 매칭됐는지, 도메인이 목록에 있는지	서비스 도메인을 확인해 local-direct에 추가한 뒤 GEOIP에서 조회가 생략되는지 확인
해외 사이트가 직접 연결로 판별됨	GeoIP 또는 앞쪽의 직접 연결 목록에 매칭됐는지	도메인을 local-proxy에 추가하고 GEOSITE 및 GEOIP보다 앞에 배치
RULE-SET이 전혀 적용되지 않음	제공자 이름, 경로, 파일 형식	classical 항목 문법과 payload 계층을 확인하고, 다시 불러온 뒤 오류 로그 확인
프록시 그룹에 매칭됐는데도 직접 연결로 표시됨	그룹에서 현재 선택한 항목과 중첩된 정책 경로	그룹에서 DIRECT를 선택했는지 확인하고 최종 연결 경로까지 단계별로 점검
홈페이지는 열리지만 리소스 로드가 실패함	실패한 리소스가 사용하는 별도 도메인	실제 연결 기록을 바탕으로 리소스 도메인을 추가하고 공유 IP 대역 전체로 범위를 넓히지 않기
구독 업데이트 후 설정이 원래대로 돌아감	임시로 생성된 파일을 수정했는지	클라이언트의 영구 오버라이드 기능으로 옮기고 병합 후 최종 규칙 순서를 확인

국내 사이트가 해외 CDN으로 연결되는 경우, 도메인 규칙을 GEOIP보다 앞에 두면 효과가 있습니다. 도메인이 직접 연결 목록에 매칭되면 이후에 확인되는 해외 IP 소속이 결과를 바꾸지 않습니다. 반대로 해외 서비스가 국내 IP를 사용하는 경우에는 GEOIP만으로 직접 연결될 수 있으므로, 명시적인 프록시 예외를 IP 판별보다 앞에 배치해야 합니다.

마지막으로 작고 안정적인 테스트 목록을 유지하세요. 수동 직접 연결 도메인 하나, 수동 프록시 도메인 하나, 국내 분류 도메인 하나, 그리고 실제로 기본 규칙까지 내려가는 연결 하나면 충분합니다. 한 번에 한 곳만 수정하고 같은 요청으로 다시 테스트하세요. 각 연결이 왜 해당 경로를 이용하는지 설명할 수 있어야 트래픽 분기 설정이 제대로 적용된 것입니다. 규칙을 계속 추가해도 순서, DNS 또는 잘못된 정책 그룹 선택 문제는 대개 해결되지 않습니다.