Clash 규칙 기반 트래픽 분리 설정 가이드: 중국 본토는 직접 연결, 해외는 프록시

1. 설정 전 확인할 사항: 코어, 모드, 정책 그룹

‘중국 본토는 직접 연결, 해외는 프록시’는 모든 웹사이트의 위치를 자동으로 판단하는 스위치가 아닙니다. 보통 명시적인 도메인 규칙, 도메인 또는 IP 분류 데이터베이스, 마지막 기본 규칙으로 구성합니다. 자주 사용하는 중국 본토 서비스는 우선 직접 연결하고, 지정한 해외 서비스는 프록시 정책 그룹으로 보내며, 분류되지 않은 연결은 예측 가능한 경로로 처리하는 것이 목표입니다.

이 글에서는 mihomo를 기준으로 설명합니다. mihomo는 Clash Meta에서 이어서 사용하는 코어 이름입니다. 기존 Clash 코어, 각종 포크, 클라이언트 내장 설정 변환기는 지원하는 필드가 서로 다를 수 있습니다. 특히 GEOSITE와 지리 데이터베이스 설정은 클라이언트 이름만으로 사용 가능 여부를 판단할 수 없습니다.

실행 중인 코어를 확인합니다. 클라이언트의 ‘정보’ 또는 코어 정보 화면에서 코어 이름과 버전을 확인하세요. 설정 검사에서 규칙 유형을 지원하지 않는다는 오류가 나오면 같은 유형의 규칙을 더 추가하기 전에 코어의 지원 여부부터 확인해야 합니다.
규칙 모드를 선택합니다. 규칙 기반 트래픽 분리에는 mode: rule이 필요합니다. 전역 모드에서는 보통 모든 연결이 전역 정책을 따르고, 직접 연결 모드에서는 이 글의 규칙에 따라 프록시를 선택하지 않습니다.
아웃바운드 이름을 확인합니다. 이 글에서는 기존 프록시 정책 그룹을 Proxy라고 표기합니다. 이름은 대소문자를 구분합니다. 현재 설정의 proxy-groups에 해당 그룹이 있어야 하며, 사용할 수 있는 노드를 선택할 수 있어야 합니다.
현재 설정을 백업합니다. 구독으로 생성된 설정은 업데이트 후 덮어써질 수 있습니다. 클라이언트가 제공하는 영구 오버라이드, 설정 병합 또는 규칙 편집 기능을 우선 사용하고, 최종 적용된 설정도 확인하세요.

2. 규칙 매칭 순서: 위에서 아래로, 먼저 일치하는 규칙 적용

규칙 모드에서는 코어가 rules를 순서대로 검사합니다. 일반적인 트래픽 분리에서는 규칙이 하나라도 일치하면 해당 규칙의 아웃바운드를 사용하며, 더 ‘정확한’ 다음 규칙을 계속 찾지 않습니다. 따라서 규칙 개수보다 순서가 중요합니다. 수동 예외를 앞에 두고, 분류 규칙을 그다음에 배치한 뒤 MATCH를 마지막에 둡니다.

규칙 유형	적용 대상	주요 차이점
`DOMAIN`	단일 도메인	정확히 일치하며 다른 하위 도메인까지 자동으로 포함하지 않음
`DOMAIN-SUFFIX`	도메인 및 하위 도메인	`github.com`은 `api.github.com`도 포함합니다.
`GEOSITE`	데이터베이스의 도메인 집합	로컬 데이터베이스에 해당 분류가 있어야 합니다.
`GEOIP`	대상 IP가 속한 지역	이를 근거로 웹사이트, 계정 또는 운영 주체의 소재지를 판단할 수 없습니다.
`RULE-SET`	규칙 제공자에 등록된 항목	집합은 `rule-providers`에서 정의합니다.
`MATCH`	앞선 규칙과 일치하지 않은 연결	마지막 기본 규칙으로 사용하며 ‘해외 판별’을 의미하지 않습니다.

도메인 규칙 두 개로 순서를 확인하기

rules:
  - DOMAIN,api.github.com,Proxy
  - DOMAIN-SUFFIX,github.com,DIRECT
  - MATCH,Proxy

이 설정은 규칙 우선순위를 보여 주기 위한 예시입니다. api.github.com은 첫 번째 규칙에 일치해 Proxy로 연결되고, github.com과 다른 하위 도메인은 두 번째 규칙에 일치해 직접 연결될 수 있습니다. 앞의 두 규칙 순서를 바꾸면 접미사 규칙이 먼저 api.github.com을 처리하므로 정확한 도메인 규칙은 적용되지 않습니다. 실제 환경에서는 필요에 따라 GitHub 관련 연결의 경로를 통일하세요. 비교용 예제를 그대로 적용할 필요는 없습니다.

MATCH,DIRECT를 규칙 맨 앞에 두지 마세요. 같은 도메인에 대해 가장 세부적인 규칙이 자동으로 선택된다고 가정해서도 안 됩니다. 광고 차단, 사내 네트워크, 다운로드 사이트 같은 예외도 ‘더 구체적인 조건을 먼저 작성한다’는 원칙을 따릅니다.

3. 기본 트래픽 분리: 도메인 우선, GEOIP 보완, 프록시 기본 경로

외부 규칙 파일 없이 적은 수의 도메인 규칙으로 검증 가능한 기본 구성을 만들 수 있습니다. 아래 예시는 로컬 사설 IPv4 주소는 직접 연결하고, Bilibili 주요 도메인은 직접 연결하며, GitHub 관련 주요 도메인은 프록시를 사용합니다. 중국 본토의 대상 IP는 직접 연결하고 나머지 연결은 Proxy로 보냅니다.

mode: rule

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,bilibili.com,DIRECT
  - DOMAIN-SUFFIX,bilivideo.com,DIRECT
  - DOMAIN-SUFFIX,github.com,Proxy
  - DOMAIN-SUFFIX,githubusercontent.com,Proxy
  - GEOIP,CN,DIRECT,no-resolve
  - MATCH,Proxy

`no-resolve`는 ‘DNS 끄기’가 아닙니다.

no-resolve는 이 IP 규칙을 적용하기 위해 도메인 조회를 새로 요청하지 않는다는 뜻입니다. 연결 정보에 일치 여부를 판단할 수 있는 실제 대상 IP가 이미 있으면 지정된 네트워크 대역이나 지역에 속하는지 확인할 수 있습니다. 아직 도메인만 있고 사용할 수 있는 IP가 없다면 이 규칙을 건너뛰고 다음 규칙을 확인할 수 있습니다.

따라서 위의 GEOIP,CN,DIRECT,no-resolve만으로 중국 본토의 모든 도메인이 직접 연결된다고 보장할 수는 없습니다. 도메인 규칙에 포함되지 않았고 그때 사용할 수 있는 IP도 없는 중국 본토 도메인은 최종적으로 Proxy를 사용할 수 있습니다. IP 분류에만 의존하기보다 중국 본토 도메인 집합을 추가하는 편이 동작을 더 세밀하게 제어할 수 있습니다. IP 규칙이 도메인 조회를 유발하도록 바꿀 경우에는 조회 경로와 소요 시간, 반환 주소가 예상에 맞는지도 함께 확인하세요.

사설 네트워크 대역 규칙은 코어에 들어온 연결의 아웃바운드만 결정합니다. 로컬 네트워크 경로를 자동으로 만들거나 앱에 내부 네트워크 접근 권한을 부여하지는 않습니다.
이 예시는 자주 쓰이는 사설 IPv4 대역만 다룹니다. IPv6 내부 네트워크를 사용한다면 실제 네트워크 환경에 맞는 규칙도 추가해야 합니다.
fake-ip DNS를 사용할 때는 코어가 복원한 도메인과 실제 DNS 응답을 확인하세요. fake-ip 주소 대역을 일반적인 직접 연결 대역으로 단순 추가하지 마세요.
하나의 서비스가 여러 도메인을 사용할 수 있습니다. 메인 페이지는 열리지만 이미지, 로그인 또는 다운로드가 실패한다면 연결 기록에서 누락된 도메인을 찾아보세요. 곧바로 모든 트래픽을 직접 연결로 바꾸지는 마세요.

4. GEOSITE 추가하기: 도메인 분류로 중국 본토 직접 연결 보완

GEOSITE는 도메인 집합을 기준으로 매칭하며 서버 IP를 바탕으로 도메인의 소속을 추측하지 않습니다. 이미 분류된 중국 본토 도메인을 DIRECT로 보내도록 GEOIP보다 앞에 배치하는 방식이 적합합니다. 다만 집합의 내용은 데이터베이스에 따라 다르므로 분류명과 적용 범위가 모든 데이터 소스에서 같지는 않습니다.

mihomo에서는 아래와 같은 일부 구성을 사용할 수 있습니다. 병합할 때는 앞 절에서 확인한 로컬 네트워크 대역과 수동 예외를 유지하세요. 여기의 짧은 rules를 기존 목록 전체를 대체해야 하는 완성된 설정으로 오해하지 마세요.

geodata-mode: true

rules:
  - DOMAIN-SUFFIX,github.com,Proxy
  - DOMAIN-SUFFIX,githubusercontent.com,Proxy
  - GEOSITE,cn,DIRECT
  - GEOIP,CN,DIRECT,no-resolve
  - MATCH,Proxy

geodata-mode: true를 설정하면 GEOIP에서 DAT 데이터 모드를 사용합니다. 이 방식에는 사용 가능한 geoip.dat가 필요하며, GEOSITE도 geosite.dat에 의존합니다. 클라이언트가 사용하는 코어 작업 디렉터리, 데이터베이스 로드 로그, 데이터 소스에 cn 분류가 실제로 있는지 확인하세요. 해당 분류가 없다면 대소문자를 바꾸거나 계속 재시작해도 해결되지 않습니다.

로그에 데이터베이스 로드 실패 또는 분류 없음이 표시되면 먼저 앞 절의 기본 규칙으로 되돌린 다음 데이터 파일을 복구하세요. DNS, 데이터베이스, 프록시 노드를 한 번에 모두 바꾸면 어떤 변경이 동작을 바꿨는지 파악하기 어렵습니다.

5. rule-providers 활용: 수동 규칙을 관리하기 쉬운 파일로 분리

규칙이 늘어나면 중국 본토 직접 연결 항목과 강제 프록시 항목을 파일 두 개로 분리해 주 설정의 반복 편집을 줄일 수 있습니다. 아래에서는 출처가 불분명한 규칙 주소를 설정에 추가하지 않도록 로컬 file 유형을 사용합니다. 파일 경로는 현재 코어가 실제로 사용하는 설정 디렉터리를 기준으로 합니다. 클라이언트에서 가져올 때 설정 디렉터리를 복사하거나 경로를 변경하는지도 확인하세요.

1단계: 규칙 파일 두 개 만들기

코어 설정 디렉터리에 rules 폴더를 만든 다음 아래 내용을 각각 rules/direct.yaml과 rules/proxy.yaml로 저장합니다. 여기서는 classical 동작을 사용하므로 각 항목에 규칙 유형을 포함하되 마지막 아웃바운드 이름은 넣지 않습니다.

# rules/direct.yaml
payload:
  - DOMAIN-SUFFIX,bilibili.com
  - DOMAIN-SUFFIX,bilivideo.com
  - DOMAIN-SUFFIX,qq.com
  - DOMAIN-SUFFIX,jd.com

# rules/proxy.yaml
payload:
  - DOMAIN-SUFFIX,github.com
  - DOMAIN-SUFFIX,githubusercontent.com
  - DOMAIN-SUFFIX,wikipedia.org

2단계: 제공자를 정의하고 규칙에 연결하기

아래 예시는 로컬 IPv4 대역, 두 규칙 집합, 중국 본토 도메인 분류, IP 분류를 함께 구성합니다. 기존 설정에 사용할 수 있는 Proxy 정책 그룹이 이미 정의되어 있어야 하며, 앞 절에서 다룬 데이터베이스도 정상적으로 로드되어야 합니다.

mode: rule
geodata-mode: true

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

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
  - RULE-SET,local-proxy,Proxy
  - RULE-SET,local-direct,DIRECT
  - GEOSITE,cn,DIRECT
  - GEOIP,CN,DIRECT,no-resolve
  - MATCH,Proxy

두 집합에 같은 도메인이 있으면 주 설정의 RULE-SET 순서에 따라 처리됩니다. 이 예시에서는 강제 프록시 집합을 중국 본토 직접 연결 집합보다 앞에 두어 예외 규칙으로 적용합니다. 집합 이름은 식별자일 뿐 우선순위를 자동으로 결정하지 않습니다.

3단계: 형식과 업데이트 방식 확인하기

YAML 들여쓰기: 탭 대신 공백을 사용합니다. 설정 전체에서 최상위 rules와 최상위 rule-providers는 각각 하나만 유지하고 새 항목을 기존 목록에 합치세요.
동작 유형과 내용: classical 파일에는 DOMAIN-SUFFIX,github.com처럼 규칙 조건을 완전히 작성합니다. 도메인만 나열한 목록을 섞어 넣지 마세요. domain과 ipcidr 동작에는 각각 별도의 콘텐츠 형식이 있습니다.
로컬 업데이트: type: file은 네트워크에서 콘텐츠를 정기적으로 가져오지 않습니다. 파일을 수정한 뒤 클라이언트의 다시 로드 또는 규칙 집합 업데이트 기능을 사용하고 로그에서 적용 여부를 확인하세요.
원격 업데이트: type: http를 사용하려면 신뢰할 수 있는 실제 URL, 캐시 경로, 업데이트 간격도 지정해야 합니다. 예를 들어 interval: 86400은 86400밀리초가 아니라 86400초, 즉 24시간을 뜻합니다.

구독 업데이트와 규칙 제공자 업데이트는 서로 다른 작업입니다. 전자는 전체 설정을 다시 만들 수 있고, 후자는 보통 특정 규칙 집합만 업데이트합니다. 구독을 업데이트할 때마다 규칙이 사라진다면 임시로 생성된 파일을 반복해서 편집하지 말고 클라이언트의 오버라이드 병합 순서를 확인하세요.

6. 트래픽 분리 확인: 규칙, 정책 경로, 새 연결 점검

웹페이지가 열린다는 사실만으로는 어떤 접속 경로가 작동한다는 것만 알 수 있을 뿐, 예상한 규칙이 적용됐다는 뜻은 아닙니다. 먼저 로그 수준을 info로 설정하고 연결 화면에서 대상 도메인, 대상 IP, 일치한 규칙, 아웃바운드 경로를 함께 확인하세요. 클라이언트마다 화면 이름은 다를 수 있으므로 실제 표시 항목을 기준으로 점검합니다.

불러오기 전에 구문을 확인합니다. mihomo를 직접 관리한다면 같은 작업 디렉터리에서 mihomo -t -f ./config.yaml을 실행할 수 있습니다. 설정 파일 이름과 경로는 실제 파일에 맞춰야 합니다. GUI 클라이언트에서는 자체 설정 검사 기능도 사용하세요.
직접 연결을 테스트합니다. www.bilibili.com에 새로 접속해 local-direct 규칙과 일치하고 최종적으로 DIRECT를 사용하는지 확인하세요. 페이지의 다른 리소스는 다른 규칙에 일치할 수 있으므로 연결 기록을 하나씩 살펴봐야 합니다.
프록시 연결을 테스트합니다. github.com에 새로 접속해 local-proxy 규칙과 일치하는지 확인하세요. 아웃바운드 경로를 펼쳐 Proxy에서 프록시 노드를 선택했는지, 그룹 내부의 DIRECT를 선택한 것은 아닌지 확인합니다.
기본 규칙을 테스트합니다. 수동 규칙 집합에 없는 도메인을 골라 GEOSITE, GEOIP, MATCH 중 어떤 규칙에 일치하는지 살펴보세요. ‘수동 규칙에 없는 도메인’이 반드시 프록시를 사용한다고 미리 단정하지 마세요.
기존 연결을 닫고 다시 테스트합니다. 규칙을 다시 불러와도 이미 연결된 세션은 보통 다른 경로로 옮겨지지 않습니다. 브라우저의 연결 재사용, HTTP/2, QUIC 때문에 기존 경로가 계속 유지될 수 있습니다. 관련 연결을 닫거나 앱을 종료한 다음 새 요청을 보내세요.

명시적 프록시 요청으로 ‘트래픽이 코어에 들어오지 않음’과 ‘규칙이 일치하지 않음’을 구분하기

설정된 mixed-port가 7890이라면 터미널에서 다음 두 요청을 실행할 수 있습니다. 포트가 다르면 실제 값으로 바꾸세요. Windows PowerShell에서는 다른 명령의 별칭과 혼동되지 않도록 curl.exe를 사용할 수 있습니다. 7890은 예시 포트이며 모든 클라이언트의 고정 포트가 아닙니다.

curl -I --proxy http://127.0.0.1:7890 https://www.bilibili.com
curl -I --proxy http://127.0.0.1:7890 https://github.com

서버는 HEAD 요청에 리디렉션이나 거부 상태를 반환할 수 있지만, 이 때문에 연결이 코어에 들어왔는지 확인하지 못하는 것은 아닙니다. 연결 기록을 함께 확인하는 것이 중요합니다. 명시적 프록시 요청은 기록되는데 브라우저나 게임은 기록되지 않는다면 규칙 목록을 늘리기 전에 시스템 프록시, 앱 자체 프록시 설정, TUN이 처리하는 범위를 먼저 확인하세요.

TUN 모드는 라우팅 조건에 맞는 네트워크 트래픽을 받아들이는 기능이지, 모든 트래픽을 강제로 프록시로 보내는 기능은 아닙니다. 트래픽이 코어에 들어온 뒤에도 모드와 규칙에 따라 아웃바운드를 선택합니다. 모든 앱이 시스템 프록시를 따르는 것도 아닙니다. 시스템 프록시와 TUN은 트래픽이 코어로 들어오는 경로를 다루며 규칙 매칭을 대체하지 않습니다.

7. 자주 발생하는 문제와 점검 순서

증상	먼저 확인할 항목	해결 방법
중국 본토 웹사이트가 계속 프록시를 사용함	MATCH에 일치했는지, 도메인 정보만 있는지 확인	도메인 규칙을 보완하고 GEOSITE 분류 및 no-resolve의 영향을 확인
Proxy로 표시되지만 로컬 경로로 연결됨	정책 그룹에서 현재 선택한 항목과 전체 아웃바운드 경로	그룹에서 DIRECT가 아닌 사용 가능한 프록시 노드를 선택했는지 확인
수정 후에도 동작이 바뀌지 않음	실제 적용된 설정, 현재 모드, 기존 연결	올바른 설정을 다시 불러오고 기존 연결을 닫은 뒤 재검사
규칙 제공자를 불러오지 못함	파일 경로, payload, behavior, 들여쓰기	먼저 로컬 파일을 수정한 다음 원격 다운로드 문제를 확인
이미지 일부 또는 로그인이 실패함	실패한 요청에서 사용한 다른 도메인과 해당 아웃바운드	필요한 관련 도메인에 일관된 아웃바운드를 지정
특정 앱만 규칙대로 연결되지 않음	해당 앱의 연결이 코어에 표시되는지 확인	분류 데이터베이스를 바꾸기 전에 앱 프록시 설정 또는 TUN 라우팅 범위를 확인

유지보수할 때는 ‘트래픽이 코어에 들어오는 경로 → 규칙 모드 → 적용된 설정 → 일치한 규칙 → 정책 그룹 선택 항목 → 노드 연결 상태’ 순서로 점검하세요. 규칙은 아웃바운드를 선택할 뿐, 작동하지 않는 노드를 복구하거나 직접 연결 경로의 사용 가능 여부를 보장하지 않습니다. 올바른 규칙과 일치하는 것이 확인됐다면 같은 도메인을 반복해서 추가하지 말고 해당 아웃바운드를 계속 점검하세요.

규칙 모드, 리스닝 포트, 정책 그룹에 대한 자세한 내용은 프록시 모드 안내, 포트 안내, 정책 그룹 안내를 참고하세요. 구독 업데이트로 설정이 덮어써지는 문제는 구독 관련 문제 해결에서 이어서 확인할 수 있습니다.