mihomo 규칙 분기 설정 실전: GEOSITE·GEOIP·MATCH로 중국 본토와 해외 트래픽 나누기

1. 최소 규칙으로 트래픽 분리하기

사용 가능한 구독 설정이 있다면 노드와 정책 그룹은 그대로 두고 규칙 부분만 교체하세요. 아래 설정은 사설 주소, 중국 본토 도메인과 중국 본토 IP를 직접 연결하고, 나머지 요청은 PROXY로 보냅니다. 전체 설정이 아니라 기존 설정에 병합할 조각입니다.

mode: rule
geodata-mode: true

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
  - GEOSITE,cn,DIRECT
  - GEOIP,CN,DIRECT
  - MATCH,PROXY

여기서 ‘중국 본토 직접 연결’은 데이터베이스 분류에 따른 라우팅 선택을 뜻하며, 웹사이트의 운영 주체·언어·서버 위치를 단정하는 기준은 아닙니다. 데이터베이스에 누락이 있을 수 있고 CDN 주소도 바뀔 수 있습니다. 중요한 서비스는 도메인 규칙을 명시적으로 추가하고 연결 기록으로 확인하세요.

구독을 사용하는 클라이언트에서는 수정 내용을 저장할 위치도 확인해야 합니다. 클라이언트가 지원하는 오버라이드, 설정 병합 또는 영구 확장 기능을 이용하세요. 구독을 내려받아 생성된 파일을 직접 수정하면 다음 업데이트 때 덮어써질 수 있습니다. 클라이언트마다 메뉴가 다르므로 현재 사용 중인 클라이언트의 안내를 따르세요.

2. 규칙 순서: 위에서 아래로, 처음 일치하는 규칙

mihomo는 rules를 나열된 순서대로 확인합니다. 사용할 수 있는 규칙과 일치하면 해당 규칙이 지정한 아웃바운드를 적용하고, 뒤에 있는 ‘더 구체적인’ 규칙을 계속 찾지 않습니다. 도메인 길이를 기준으로 규칙을 자동 정렬하는 기능은 없습니다.

명시적인 예외를 일반 분류보다 먼저 배치

rules:
  - DOMAIN-SUFFIX,example.com,PROXY
  - DOMAIN,downloads.example.org,DIRECT
  - GEOSITE,cn,DIRECT
  - GEOIP,CN,DIRECT
  - MATCH,PROXY

여기 나온 도메인 두 개는 문법을 설명하기 위한 예시일 뿐, 실제 서비스를 가리키지 않습니다. DOMAIN-SUFFIX,example.com은 최상위 도메인과 하위 도메인(예: api.example.com)을 모두 매칭합니다. DOMAIN은 지정한 호스트명만 매칭합니다. 도메인이 앞선 규칙에서 이미 프록시로 전송됐다면, 뒤에 있는 중국 본토 IP 규칙으로 직접 연결되도록 바뀌지 않습니다.

첫 번째 단계: 프록시 사용, 직접 연결 또는 차단을 강제할 구체적인 예외.
두 번째 단계: 로컬 네트워크 주소와 서비스별 규칙 집합.
세 번째 단계: GEOSITE, GEOIP 등 범위가 넓은 분류.
마지막 단계: MATCH로 앞선 규칙과 일치하지 않은 연결을 처리합니다.

MATCH는 ‘해외 주소를 찾았다’는 뜻이 아니라 조건 없이 적용되는 기본 규칙입니다. 이 예제에서는 분류되지 않은 트래픽을 프록시로 보내므로 데이터베이스에서 누락된 중국 본토 도메인도 프록시를 사용할 수 있습니다. 첫 줄에 배치하면 이후의 트래픽 분리 규칙은 적용되지 않습니다.

3. GEOSITE와 GEOIP의 역할

규칙 유형	판단 기준	적용 위치
GEOSITE,cn	도메인 데이터베이스의 cn 분류	도메인 예외 다음, IP 분류 이전
GEOIP,CN	대상 IP의 데이터베이스 분류	도메인 규칙으로 처리되지 않은 연결 보완
MATCH	추가 매칭 조건 없음	규칙 목록 끝의 기본 규칙

GEOSITE는 서버 위치를 먼저 확인할 필요가 없습니다

연결에 사용할 수 있는 도메인 정보가 있으면 GEOSITE,cn,DIRECT로 도메인 분류를 바로 확인할 수 있습니다. 중국 본토 웹사이트가 해외 CDN을 사용하더라도 도메인 데이터베이스의 분류가 자동으로 바뀌지는 않습니다. 반대로 해외 서비스가 중국 본토 IP를 사용한다고 해서 GEOSITE에서 반드시 cn으로 분류되는 것도 아닙니다.

GEOIP는 도메인 조회를 유발할 수 있습니다

연결에 도메인만 있고 실제 대상 IP가 아직 없다면 IP 규칙을 적용할 때 DNS 조회가 필요할 수 있습니다. 따라서 GEOIP,CN,DIRECT는 도메인 분류 규칙과 일치하지 않은 연결을 보완할 수 있지만, 조회 결과와 DNS 경로가 최종 판단에 영향을 줍니다.

# 필요할 때 도메인을 조회해 대상 IP 확인
- GEOIP,CN,DIRECT

# 이 규칙에서는 도메인을 직접 조회하지 않음
- GEOIP,CN,DIRECT,no-resolve

no-resolve는 ‘DNS 전체를 끄는 옵션’도, ‘모든 트래픽을 빠르게 하는 만능 설정’도 아닙니다. 해당 IP 규칙에서 직접 DNS 조회를 시작하지 않도록 제한합니다. 연결에 대상 IP가 이미 있으면 계속 매칭에 참여할 수 있습니다. 도메인 연결을 GEOIP로 보완하려는 경우에도 no-resolve를 추가하면 일부 요청이 마지막의 MATCH로 넘어갈 수 있습니다.

4. rule-providers로 규칙 집합 분리하기

규칙이 늘어나면 도메인 목록을 기본 설정에서 분리할 수 있습니다. rule-providers는 규칙 집합의 출처와 형식을 정의하고, RULE-SET은 기본 규칙에서 적용할 위치와 일치 후 사용할 아웃바운드를 결정합니다. provider만 정의하고 참조하지 않으면 트래픽 분리에는 적용되지 않습니다.

확인하기 쉬운 로컬 도메인 목록부터 사용

아래는 local-direct라는 파일형 규칙 집합을 정의합니다. 경로는 mihomo 작업 디렉터리를 기준으로 합니다. 파일은 클라이언트에서 읽을 수 있는 설정 디렉터리에 두고 실제 작업 디렉터리를 확인하세요. 터미널의 현재 디렉터리를 기준으로 추측하면 안 됩니다.

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

rules:
  - RULE-SET,local-direct,DIRECT
  - GEOSITE,cn,DIRECT
  - GEOIP,CN,DIRECT
  - MATCH,PROXY

rules/local-direct.yaml 파일을 만들고 아래 내용을 그대로 저장하세요. 명시적으로 직접 연결할 두 도메인의 예시이며, 중국 본토 도메인 데이터베이스 전체를 담은 파일은 아닙니다.

payload:
  - '+.baidu.com'
  - '+.qq.com'

behavior: domain은 파일에 도메인 매칭 항목만 저장한다는 뜻입니다. DOMAIN-SUFFIX,baidu.com,DIRECT 전체를 넣으면 안 됩니다. 아웃바운드는 기본 설정의 RULE-SET,local-direct,DIRECT에서 이미 지정합니다. +. 표기는 해당 도메인과 하위 도메인에 모두 적용됩니다.

여러 규칙 유형을 섞으려면 classical 사용

같은 파일에서 도메인 조건과 IP 조건을 함께 사용하려면 behavior: classical로 바꾸고 해당 규칙 문법을 사용하세요. 아래는 규칙 집합 파일 내용입니다. 각 항목 뒤에 아웃바운드 이름은 넣지 않습니다.

payload:
  - DOMAIN-SUFFIX,baidu.com
  - IP-CIDR,192.168.0.0/16,no-resolve

파일 내용만 바꾸고 provider의 behavior를 수정하지 않는 실수에 주의하세요. 원격 규칙 집합을 사용한다면 선언된 형식도 확인해야 합니다. YAML, 일반 텍스트, 바이너리 규칙 집합은 임의로 혼용할 수 없습니다. HTTP 유형은 interval: 86400으로 86400초마다 업데이트를 확인할 수 있지만, 로컬 파일 유형은 이 매개변수로 파일을 동기화하지 않습니다.

5. DNS·fake-ip·TUN의 적용 범위

분기 규칙은 mihomo로 들어온 연결에만 적용됩니다. 시스템 프록시는 프록시 설정을 따르는 앱만 처리합니다. 명령줄 도구, 게임 또는 자체적으로 네트워크에 연결하는 프로그램은 우회할 수 있습니다. TUN 모드는 가상 네트워크 어댑터로 더 많은 IP 트래픽을 처리하지만, 실제로 트래픽을 가져올 수 있는지는 라우팅, 권한, 제외 항목에 따라 달라집니다.

트래픽 처리 단계: 먼저 앱 요청이 클라이언트 연결 목록에 표시되는지 확인하세요. 연결 기록이 없다면 시스템 프록시, 앱의 프록시 설정 또는 TUN 라우팅부터 살펴보세요.
정보 식별 단계: 연결 기록에 도메인이 있는지, IP만 있는지 확인하세요. 도메인이 없으면 GEOSITE가 직접 매칭할 도메인 정보를 얻기 어렵습니다.
규칙 적용 단계: 일치한 규칙, 선택된 정책 그룹, 실제 노드를 확인해 규칙의 결정과 노드 선택을 구분하세요.

fake-ip 모드에서는 DNS가 흔히 사용하는 198.18.0.1/16 주소 풀과 같은 합성 주소를 반환할 수 있습니다. 코어는 매핑을 통해 원래 도메인과 연결하므로 이 합성 주소를 지리적 위치에 따른 실제 서버 IP로 취급하면 안 됩니다. ‘GEOIP 문제’를 해결하겠다며 fake-ip 주소 풀 전체를 직접 연결 대상으로 추가하지 마세요.

브라우저의 암호화 DNS, 독립 DNS 클라이언트, TUN을 함께 사용할 때는 도메인 정보가 여전히 코어에 전달되는지 확인하세요. 스니핑은 일부 프로토콜에서 도메인 정보를 보완할 수 있지만 모든 연결의 도메인을 복원한다고 보장할 수는 없습니다. DNS가 처리되는 경로도 별도로 확인해야 합니다.

6. 설정을 점검하고 세 가지 연결 유형 확인하기

문법을 확인한 다음 클라이언트에 불러오기

mihomo의 설정 검사 기능을 직접 실행할 수 있습니다. 아래 명령은 설정 파일이 현재 디렉터리에 있다고 가정합니다. 클라이언트가 별도의 작업 디렉터리를 사용한다면 올바른 디렉터리도 지정하고, 그 안에 데이터베이스와 로컬 규칙 집합을 준비하세요.

mihomo -t -f ./config.yaml

검사를 통과했다는 것은 설정을 불러올 수 있다는 뜻일 뿐, 노드에 연결할 수 있거나 모든 도메인이 예상대로 분기된다는 의미는 아닙니다. 불러온 뒤 클라이언트가 규칙 모드인지 확인하세요. 전역 모드나 직접 연결 모드에서는 관찰 결과가 달라질 수 있습니다.

테스트 경로를 고정하고 실제 규칙 매칭 확인

클라이언트의 실제 HTTP 또는 mixed 수신 포트가 7890이라면 프록시를 명시해 테스트할 수 있습니다. 포트는 예시이므로 현재 설정을 기준으로 지정하세요. HTTP 프록시만 테스트한다면 테스트를 위해 TUN을 별도로 켤 필요는 없습니다.

curl -I --proxy http://127.0.0.1:7890 https://www.baidu.com/
curl -I --proxy http://127.0.0.1:7890 https://www.wikipedia.org/

중국 본토 도메인: GEOSITE 또는 사용자 지정 RULE-SET과 일치하는지, 아웃바운드가 DIRECT인지 확인하세요.
직접 연결 분류에 포함되지 않은 해외 도메인: MATCH로 처리되는지, PROXY에서 현재 프록시 노드를 선택했는지 확인하세요. DIRECT가 선택되어 있으면 안 됩니다.
로컬 네트워크 서비스: 실제로 사용 중인 라우터나 NAS 주소로 테스트해 사설 네트워크 규칙이 적용되는지 확인하세요. 로컬 네트워크 접속이 프록시를 거치는지는 앱의 우회 목록과 TUN 제외 경로에도 영향을 받습니다.

위 도메인은 확인 방법을 설명하기 위한 예시이며, 모든 버전의 데이터베이스에서 매칭된다고 전제하지 않습니다. HTTP 상태 코드가 200, 301 또는 403이라는 사실만으로는 트래픽이 올바르게 분기됐다고 볼 수 없습니다. 연결 세부 정보의 규칙 유형, 아웃바운드 체인, 로그를 함께 확인하세요.

7. 문제 유형별 해결 방법

중국 본토 웹사이트가 여전히 프록시를 사용함

먼저 앞부분에 더 일찍 적용되는 프록시 규칙이 있는지 확인하세요. 특히 구독에 포함된 서비스별 규칙 집합을 살펴보세요.
현재 GEOSITE 데이터에 해당 도메인이 있는지 확인하세요. 연결 기록에 IP만 표시된다면 GEOIP와 DNS 식별 경로를 확인하세요.
수정한 설정이 선택되지 않은 구독 복사본이 아니라 현재 활성 설정인지 확인하세요. 다시 불러온 뒤 새 연결을 만들어 테스트하세요.

모든 요청이 같은 출구를 사용함

mode: rule 설정, MATCH의 위치, PROXY 그룹에서 실제로 선택한 항목을 차례로 확인하세요. 정책 그룹 이름이 ‘프록시’라고 해서 내부에서 반드시 프록시 노드가 선택된 것은 아닙니다. 규칙을 수정해도 기존 장기 연결은 이전 아웃바운드를 계속 사용할 수 있습니다. 해당 연결을 닫거나 테스트 앱을 다시 시작하세요.

구독 업데이트 후 사용자 지정 규칙이 사라짐

규칙을 클라이언트가 지원하는 영구 오버라이드 또는 병합 설정으로 옮기고 병합 순서를 확인하세요. 사용자 지정 규칙을 기존 MATCH 뒤에 추가하면 저장되더라도 적용되지 않습니다. 구독을 업데이트할 때마다 직접 연결 도메인과 프록시 도메인을 하나씩 확인하세요.

웹페이지는 열리지만 게임이나 UDP 연결에 문제가 있음

먼저 앱 트래픽이 실제로 처리되는지 확인한 뒤 노드 프로토콜, 서버, 정책 그룹 선택이 필요한 UDP 전달을 지원하는지 살펴보세요. TUN은 트래픽을 가져오는 경로의 일부 문제를 해결할 뿐, UDP를 지원하지 않는 아웃바운드에 전달 기능을 추가하지는 않습니다. IPv6도 별도로 확인해야 합니다. IPv4 요청 한 번이 성공했다고 해서 듀얼 스택 검증이 끝난 것은 아닙니다.

마지막으로 설명하기 쉬운 규칙 순서를 유지하세요. 명시적 예외를 앞에 두고, 도메인 분류를 중간에 배치한 뒤, IP 분류로 보완하고 MATCH로 마무리합니다. 규칙을 추가할 때마다 연결 기록에서 실제로 무엇과 일치했는지 확인한 다음 목록을 확장하세요.