먼저 커널, 규칙 모드, 프록시 그룹 확인하기

‘중국 본토는 직접 연결하고 해외 서비스는 프록시로 연결’하는 설정은 서비스 소재지를 자동으로 판단하는 단일 스위치가 아니라, 연결마다 적용되는 규칙 모음입니다. Clash는 rules의 첫 줄부터 차례로 확인하고, 처음 일치하는 규칙의 아웃바운드 정책을 적용합니다. 더 구체적인 규칙을 찾기 위해 계속 확인하지 않으므로 같은 도메인이라도 규칙의 위치에 따라 라우팅 결과가 달라질 수 있습니다.

이 글은 Clash Meta의 후속 커널인 mihomo를 기준으로 설명합니다. 클라이언트는 관리 인터페이스이고, 규칙을 해석하는 것은 커널입니다. 클라이언트 이름이 비슷해도 지원하는 필드까지 같은 것은 아닙니다. 구형 Clash 커널에서는 GEOSITE가 포함된 예제를 그대로 사용할 수 없습니다. 먼저 클라이언트의 커널 정보에서 실제 커널을 확인하고, 로그에 ‘알 수 없는 규칙 유형’이나 데이터 파일 로드 실패가 있는지 살펴보세요.

수정 전에 확인할 세 가지

  1. 모드는 Rule: 설정에 mode: rule이 있어야 합니다. Global 모드는 전역 정책을, Direct 모드는 직접 연결을 사용하므로 이 글의 규칙 목록에 따라 트래픽을 분리하지 않습니다.
  2. 프록시 그룹이 실제로 존재하는지 확인: 이 글에서 해외 서비스 프록시는 이미 만들어진 정책 그룹 이름입니다. 현재 설정에 실제로 존재하는 그룹 이름으로 바꾸고, 프록시 화면에서 해당 그룹에 사용할 수 있는 노드를 선택해야 합니다. 규칙만 수정한다고 노드가 생성되지는 않습니다.
  3. 기존 설정 보존: 먼저 현재 설정을 복사한 뒤 복사본에서 테스트하세요. 구독을 업데이트하면 직접 편집한 내용이 덮어써질 수 있습니다. 계속 사용하려면 클라이언트가 지원하는 오버라이드 또는 병합 기능으로 관리하고, 최종 적용된 설정을 확인하세요.

규칙 유형 네 가지: 도메인, 지리 데이터, 규칙 세트

유형매칭 대상사용 사례
DOMAIN-SUFFIX지정한 도메인과 하위 도메인일부 사이트에 대한 명확한 예외
GEOSITE도메인 분류 데이터중국 본토 도메인 및 해외 서비스 분류
GEOIP대상 IP가 속한 지역대상 IP가 확인된 경우 분리 규칙 보완
RULE-SET외부 또는 로컬 규칙 제공자사이트 규칙을 별도로 관리

DOMAIN-SUFFIX: 특정 도메인 예외를 정확히 지정

DOMAIN-SUFFIX,github.com,해외 서비스 프록시는 github.com과 api.github.com에 모두 적용되지만, githubusercontent.com에는 적용되지 않습니다. 후자는 별도 도메인이므로 규칙을 따로 추가해야 합니다. 호스트 하나에만 규칙을 적용하려면 DOMAIN,api.github.com,해외 서비스 프록시를 사용해 해당 도메인의 모든 서비스를 같은 경로로 보내지 않도록 하세요.

GEOSITE: 분류는 데이터 파일에 따라 달라집니다

GEOSITE,cn,DIRECT는 지리 도메인 데이터의 cn 분류를 사용하며, ‘.cn으로 끝나는 모든 도메인’을 뜻하지 않습니다. 마찬가지로 일반적인 데이터 세트의 geolocation-!cn은 해외 도메인 분류이며, 수학적으로 cn 집합을 완전히 뺀 여집합과 같지는 않습니다. 분류가 존재하는지, 어떤 사이트가 포함되는지는 실제로 불러온 데이터 파일과 업데이트 시점에 따라 달라집니다.

이 예제를 사용하기 전에 mihomo가 cn 및 geolocation-!cn을 포함한 geosite.dat와 GEOIP에 사용할 지리 IP 데이터를 정상적으로 불러왔는지 확인하세요. geodata-mode: true로 설정한 경우 geoip.dat를 사용합니다. 일반적인 기본 모드에서는 MMDB 데이터를 사용합니다. 데이터 업데이트 메뉴는 클라이언트마다 다르므로 로그에 정상적으로 로드되었다고 표시되는지 확인하세요.

GEOIP: IP를 판별하며 사이트의 소속 지역을 판별하지 않습니다

GEOIP,CN,DIRECT는 대상 IP가 중국 본토 주소 범위에 속하는지 확인합니다. 해외 서비스가 중국 본토 CDN을 사용하면 해당 IP가 CN으로 분류될 수도 있고, 중국 본토 서비스가 해외 클라우드 리소스를 사용하면 반대로 CN에 포함되지 않을 수도 있습니다. 서비스 차원의 접속 의도를 먼저 반영하려면 IP 분류보다 도메인 분류를 앞에 두세요.

규칙 끝의 no-resolve는 해당 IP 규칙을 위해 도메인 조회를 별도로 트리거하지 않는다는 뜻이지, ‘DNS 사용 금지’를 뜻하지는 않습니다. 연결에 실제 대상 IP가 이미 있으면 규칙이 적용될 수 있지만, 도메인만 있고 사용할 수 있는 실제 IP가 없으면 규칙이 건너뛰어질 수 있습니다. 따라서 이 옵션은 규칙 매칭으로 인한 조회를 줄일 수 있지만, 분류되지 않은 중국 본토 도메인이 모두 직접 연결된다고 보장하지는 않습니다.

규칙 순서: 로컬 네트워크, 명시적 예외, 분류, 기본 규칙

아래 설정은 ‘중국 본토에서 자주 쓰는 사이트는 직접 연결하고 나머지 트래픽은 기본적으로 프록시를 사용’하려는 경우에 적합합니다. 순서는 로컬 네트워크 우회, 수동 지정한 해외 사이트, 중국 본토 도메인 분류, 해외 도메인 분류, 중국 본토 IP, 최종 기본 규칙입니다. MATCH는 남은 연결을 조건 없이 매칭하므로 반드시 마지막에 배치해야 합니다.

# mihomo 설정 예시; 해외 서비스 프록시는 기존 정책 그룹이어야 합니다
mode: rule

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-CIDR,169.254.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,github.com,해외 서비스 프록시
  - DOMAIN-SUFFIX,githubusercontent.com,해외 서비스 프록시
  - DOMAIN-SUFFIX,githubassets.com,해외 서비스 프록시

  - GEOSITE,cn,DIRECT
  - GEOSITE,geolocation-!cn,해외 서비스 프록시
  - GEOIP,CN,DIRECT,no-resolve
  - MATCH,해외 서비스 프록시

로컬 네트워크 규칙을 맨 앞에 두는 이유

라우터 관리 페이지, NAS, 회사 내부 서비스는 대개 사설 IP 주소를 사용합니다. 예를 들어 192.168.1.1을 원격 프록시로 보내면 현재 네트워크의 라우터에 연결할 수 없습니다. 사설 주소를 먼저 직접 연결하면 마지막 기본 프록시 규칙에 걸리는 것을 방지할 수 있습니다. 172.16.0.0/12의 범위는 172.16부터 172.31까지입니다. 하나의 작은 서브넷만 포함하는 172.16.0.0/16으로 잘못 지정하지 마세요.

도메인 규칙은 아웃바운드 경로만 결정하며, 도메인 이름이 해석되는 것까지 보장하지는 않습니다. 회사 내부 도메인에는 사내 DNS가 필요할 수 있고, .local은 mDNS에 주로 사용되므로 도메인 직접 연결 규칙을 추가하는 것만으로 해결되지 않을 수 있습니다. TUN을 활성화했다면 내부 네트워크 경로와 DNS 가로채기 설정도 확인하세요. 규칙이 DIRECT에 매칭되는지와 시스템에서 로컬 네트워크에 접속할 수 있는지는 각각 확인해야 합니다.

기본 규칙에서 프록시와 직접 연결 중 선택하기

여기서 ‘해외 서비스 프록시’는 접속 정책을 뜻하며, 네트워크 품질을 보장하지 않습니다. 정책 그룹에서 DIRECT를 선택하면 규칙이 해당 그룹에 매칭되어도 최종 연결은 직접 연결됩니다. 문제를 확인할 때는 매칭된 규칙과 최종 아웃바운드 경로를 함께 살펴봐야 합니다.

RULE-SET: 자주 쓰는 사이트 규칙을 별도로 관리

수동으로 관리하는 도메인 규칙이 늘어나면 규칙 제공자로 옮길 수 있습니다. 아래 예제는 로컬 YAML 파일을 사용하므로 원격 규칙을 다운로드하지 않습니다. 파일은 커널이 읽을 수 있는 작업 디렉터리에 두어야 합니다. 상대 경로는 일반적으로 커널 작업 디렉터리를 기준으로 하며, 현재 구독 파일이 있는 디렉터리를 기준으로 하는 것은 아닙니다.

1단계: 로컬 규칙 파일 만들기

rules/overseas.yaml로 저장하세요. 이 파일은 규칙 세트 파일이지 클라이언트의 주 설정 파일이 아닙니다. 최상위 키는 반드시 payload여야 합니다. 아래는 classical 형식으로, 항목에 규칙 유형은 포함하지만 아웃바운드 정책은 포함하지 않습니다.

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

2단계: 주 설정에 선언하고 참조하기

아래 제공자 설정을 기존 rule-providers에 병합한 다음, 앞 절의 GitHub 도메인 규칙 세 개를 RULE-SET으로 바꾸세요. 참조 규칙은 로컬 네트워크 규칙 다음, GEOSITE 규칙 앞에 배치해야 합니다. 아래는 해당 위치 주변만 보여 주는 예시이므로 실제 설정에서는 생략된 기존 규칙을 유지하세요.

# 주 설정 예시: 로컬 제공자 선언
rule-providers:
  overseas-manual:
    type: file
    behavior: classical
    format: yaml
    path: ./rules/overseas.yaml
# rules 목록의 해당 위치에 넣을 예시이며 전체 목록이 아닙니다
  - RULE-SET,overseas-manual,해외 서비스 프록시
  - GEOSITE,cn,DIRECT
  - GEOSITE,geolocation-!cn,해외 서비스 프록시
  - GEOIP,CN,DIRECT,no-resolve
  - MATCH,해외 서비스 프록시

behavior: domain, ipcidr, classical은 항목 형식이 서로 다르므로 필드만 바꾸고 기존 파일 내용을 그대로 사용할 수 없습니다. HTTP 제공자로 전환할 경우 실제 출처, 캐시 경로, 업데이트 간격도 설정한 뒤 다운로드가 성공했는지 확인해야 합니다. 규칙 목록에 RULE-SET이 있다고 해서 규칙 파일이 정상적으로 로드된 것은 아닙니다. 제공자 상태와 커널 로그를 확인하세요.

트래픽 분리 확인: 웹페이지가 열리는지만 보지 말고 새 연결을 확인하세요

웹페이지가 열린다는 것은 접속 경로 중 하나가 작동한다는 뜻일 뿐, 예상한 경로를 사용했다는 증거는 아닙니다. 설정을 저장하고 다시 불러온 뒤 클라이언트의 ‘연결’ 화면에서 대상 도메인, 대상 IP, 매칭 규칙, 정책 체인을 확인하세요. ‘로그’ 화면에서는 규칙 파일 로드 오류를 살펴보세요. 화면 이름은 클라이언트마다 다를 수 있으니 프록시 스위치만 볼 것이 아니라 이 네 가지 항목을 찾는 것이 중요합니다.

반복해서 확인할 수 있는 점검 절차

  1. 설정의 mode: rule이 적용되었는지 확인하고, 우선 log-level: info를 사용하세요. DNS 해석 과정을 분석해야 할 때만 debug로 바꾸고, 분석을 마친 뒤 원래대로 돌려 대량의 로그가 계속 쌓이지 않게 하세요.
  2. 현재 테스트 연결을 닫고 새 요청을 보내세요. 브라우저가 연결을 재사용하면 이전 경로를 계속 이용할 수 있습니다. 규칙을 수정한 뒤에도 기존 연결이 보인다고 해서 새 규칙이 적용되지 않았다고 단정할 수는 없습니다.
  3. github.com에 접속해 수동 도메인 규칙 또는 overseas-manual에 매칭되는지 확인하고, 최종 경로에 선택한 프록시 노드가 포함되는지 확인하세요.
  4. 실제로 사용하는 중국 본토 사이트에 접속해 GEOSITE,cn에 매칭되는지 확인하세요. MATCH에 걸리면 먼저 도메인 분류와 DNS 결과를 확인하세요.
  5. 현재 네트워크에 실제로 있는 로컬 네트워크 장치에 접속해 해당 사설 네트워크 대역에 매칭되고 DIRECT를 사용하는지 확인하세요. 장치가 없다면 연결 시간 초과를 규칙 오류로 판단하지 마세요.

지정한 프록시 진입점으로 테스트하기

실제로 적용된 설정에 mixed-port: 7890이 있다면 아래 명령으로 로컬 HTTP 프록시 진입점을 명시해 사용하여 시스템 프록시 설정이 터미널에 적용되지 않은 문제를 배제할 수 있습니다. 포트 번호는 고정 표준이 아니므로 실제 포트가 다르면 명령의 숫자를 바꾸세요.

curl --proxy http://127.0.0.1:7890 --head --max-time 15 https://github.com

--max-time 15는 요청 전체의 최대 대기 시간을 15초로 설정하는 옵션이지, 접속 속도를 측정한 결과가 아닙니다. HTTP 상태 코드와 응답 시간만으로 규칙 매칭을 확인할 수는 없으므로 연결 화면의 라우팅 기록과 함께 살펴보세요. 이 명령은 명시적인 프록시 진입점을 테스트하며, 모든 TUN 트래픽이 가로채졌는지를 검증하지는 않습니다.

흔한 설정 오류와 DNS·TUN의 범위

증상우선 확인할 항목해결 방법
모든 연결이 같은 경로를 사용함모드가 Rule이 아니거나 MATCH가 맨 위에 있음규칙 모드를 활성화하고 기본 규칙을 맨 아래로 이동
설정을 불러올 수 없음정책 그룹 이름, YAML 들여쓰기, 커널 지원 여부로그를 확인하고 그룹 이름이 정확히 일치하는지 확인
GEOIP가 적용되지 않는 것처럼 보임no-resolve 설정과 실제 대상 IP 사용 가능 여부먼저 DNS와 도메인 규칙 매칭 상태를 확인
구독 업데이트 후 규칙이 사라짐오버라이드 원본이 아니라 생성된 파일을 수정함지원되는 오버라이드 방식으로 관리하고 최종 설정을 다시 확인
해외 서비스의 일부 리소스가 로드되지 않음리소스 도메인과 홈페이지 도메인이 다름실패한 연결 기록을 확인해 별도 도메인 규칙 추가
로컬 네트워크 도메인이 열리지 않음내부 DNS, TUN 경로, 대상에 접속 가능한지 확인먼저 올바른 주소로 해석되는지 확인한 뒤 직접 연결 규칙 점검

DNS 분리와 연결 분리는 서로 다릅니다

nameserver-policy는 도메인 조회에 사용할 DNS 서버를 선택하고, rules는 애플리케이션 연결의 아웃바운드 경로를 선택합니다. 두 설정의 역할은 다릅니다. 중국 본토 도메인에 로컬 DNS를 지정해도 해당 연결이 자동으로 직접 연결되지는 않습니다. 반대로 DIRECT 규칙을 사용해도 로컬 DNS로 조회한다고 보장할 수 없습니다. DNS 경로를 제어하려면 dns 설정을 별도로 확인해야 합니다.

관련 필드를 지원하는 mihomo에서는 respect-rules를 사용해 DNS 업스트림 연결이 라우팅 규칙을 따르게 할 수 있습니다. 하지만 활성화하기 전에 proxy-server-nameserver 같은 부트스트랩 조회 설정을 올바르게 구성해야 프록시 서버 도메인의 조회가 다시 프록시에 의존하는 상황을 방지할 수 있습니다. 임의의 설정에 이 옵션만 추가한다고 모든 DNS 문제가 해결되는 것은 아닙니다.

Fake-IP와 TUN을 사용해도 첫 매칭 규칙이 적용됩니다

Fake-IP는 매핑 주소와 도메인을 연결해 후속 연결 처리에 사용하도록 합니다. 모든 사이트를 중국 본토와 해외로 자동 분류하지는 않습니다. 대상 주소가 흔히 사용하는 매핑 범위인 198.18.0.0/16에 해당하더라도, 트래픽 분리 문제를 ‘해결’하려고 전체 범위를 DIRECT에 추가하지 마세요. 도메인 매핑과 규칙 매칭이 정상인지 확인해야 합니다.

TUN은 가로채는 트래픽의 범위를 넓힐 뿐, 규칙 모드를 전역 프록시로 바꾸지 않습니다. 시스템 프록시는 프록시 설정을 따르는 앱에만 영향을 주지만, TUN은 더 많은 IP 트래픽을 가로챌 수 있습니다. 다만 권한, 라우팅, 제외 설정의 영향을 받습니다. 커널로 들어온 연결에만 이 규칙이 적용됩니다. 다른 VPN, 시스템 라우팅, 앱이 직접 만든 연결은 각각 따로 확인해야 합니다.