Mihomo 사용자 규칙 설정 가이드: 규칙 유형·매칭 순서·우선순위 문제 해결

규칙 구조와 적용 전 확인 사항

Mihomo의 rules는 순서가 있는 규칙 목록입니다. 일반적인 형식은 규칙 유형,매칭 대상,정책이며, 마지막 기본 규칙은 MATCH,정책으로 작성합니다. 정책에는 DIRECT, REJECT 같은 내장 옵션이나 설정에 정의된 프록시·정책 그룹 이름을 사용할 수 있습니다.

규칙은 연결을 어떤 대상으로 처리할지 결정하며, 시스템의 모든 트래픽을 자동으로 가로채지는 않습니다. 브라우저가 시스템 프록시를 사용하는지, 앱에서 프록시를 직접 지정했는지, 클라이언트가 TUN으로 연결을 가로채는지에 따라 커널이 요청을 확인할 수 있는지가 달라집니다. 연결 목록에 해당 앱의 트래픽이 아예 없다면 규칙을 바꾸기 전에 연결 방식을 먼저 확인하세요.

먼저 확인할 세 가지

현재 모드가 rule인지 확인하세요. Global 모드에서는 일반 규칙 목록에 따라 트래픽을 분기하지 않으며, Direct 모드에서는 모두 직접 연결됩니다.
현재 실행 중인 설정을 편집하고 저장한 뒤 다시 불러왔는지 확인하세요. 클라이언트 편집기에 보이는 내용이 커널에서 실제로 불러온 설정과 다를 수 있습니다.
대상 정책이 모두 실제로 존재하는지 확인하세요. 예를 들어 규칙에 PROXY를 지정했다면 설정에 이름이 정확히 일치하는 프록시나 정책 그룹이 있어야 합니다. 대소문자와 공백도 일치해야 합니다.

mode: rule

rules:
  - DOMAIN,example.com,DIRECT
  - DOMAIN-SUFFIX,example.org,DIRECT
  - MATCH,PROXY

아래 내용은 기존 설정에 추가하는 조각이며, 노드·DNS·수신 포트까지 포함한 전체 설정이 아닙니다. 예시에서는 기존 정책 그룹 이름이 PROXY라고 가정합니다. 실제 그룹 이름이 “노드 선택”이라면 해당 대상을 그 이름으로 바꾸세요. example.com과 example.org는 문서용 예시 도메인이므로 실제로 분기할 서비스에 맞게 수정해야 합니다.

DOMAIN 규칙: 정확히 일치·도메인 접미사·키워드

도메인 규칙은 웹사이트나 도메인 기반 API 서비스에 적합합니다. 규칙 유형을 정할 때는 먼저 매칭 범위를 정하고, 모든 도메인을 키워드로 처리하지 마세요. 키워드 범위가 너무 넓으면 이름만 비슷하고 관계없는 서비스까지 함께 분기될 수 있습니다.

유형	예시	매칭 범위
DOMAIN	`DOMAIN,api.example.com,DIRECT`	api.example.com과 정확히 일치하는 도메인만
DOMAIN-SUFFIX	`DOMAIN-SUFFIX,example.com,DIRECT`	example.com 및 모든 하위 도메인
DOMAIN-KEYWORD	`DOMAIN-KEYWORD,example,DIRECT`	도메인 이름에 example이 포함된 대상

규칙에 프로토콜과 페이지 경로는 쓰지 않습니다

DOMAIN의 매칭 대상은 도메인이며 전체 URL이 아닙니다. https://api.example.com/v1을 DOMAIN 규칙에 넣어도 웹페이지 경로에 따라 트래픽을 분기할 수 없습니다. 일반 도메인 규칙은 같은 도메인에 속한 서로 다른 페이지도 구분하지 않습니다.

rules:
  - DOMAIN,api.example.com,PROXY
  - DOMAIN-SUFFIX,example.com,DIRECT
  - MATCH,PROXY

이 규칙은 api.example.com을 PROXY로 보내고 나머지 example.com 하위 도메인은 직접 연결합니다. DOMAIN 규칙에 자동으로 더 높은 우선순위가 부여되는 것이 아니라 작성 순서에 따라 적용됩니다. 앞의 두 줄을 바꾸면 접미사 규칙이 먼저 일치해 정확히 지정한 규칙은 적용되지 않습니다.

GEOSITE와 규칙 세트: 분류는 고정된 목록이 아닙니다

GEOSITE는 도메인 분류 데이터를 사용합니다. 예를 들어 GEOSITE,cn,DIRECT는 현재 geosite 데이터에서 cn이라는 분류에 속하는 항목을 매칭합니다. 웹사이트 서버의 위치를 기준으로 판별하는 것도, 중국어 웹페이지를 모두 찾아내는 것도 아닙니다. 실제 매칭 범위는 사용 중인 데이터 소스와 업데이트 상태에 따라 달라집니다.

rules:
  - DOMAIN,api.example.com,PROXY
  - GEOSITE,cn,DIRECT
  - GEOIP,CN,DIRECT,no-resolve
  - MATCH,PROXY

GEOSITE는 도메인 분류에, GEOIP는 대상 IP가 속한 분류에 사용되므로 서로 바꿔 쓸 수 없습니다.
규칙을 참조하기 전에 해당 데이터를 사용할 수 있는지 확인하세요. 데이터 파일이 없거나 다운로드에 실패했거나 분류 이름이 존재하지 않으면 설정을 불러오는 중 오류가 발생할 수 있습니다.
사용자 지정 예외 규칙은 분류 규칙보다 앞에 두세요. 특정 도메인을 프록시로 보내려면 해당 도메인을 이미 포함하는 직접 연결 분류 규칙 뒤에 배치하지 않아야 합니다.

RULE-SET을 사용하려면 provider를 먼저 정의하세요

RULE-SET은 rule-providers에 정의된 이름을 참조합니다. 아래 예시는 원격 다운로드 문제와 매칭 문제를 분리해 확인할 수 있도록 로컬 파일을 사용합니다. 파일 경로는 커널의 작업 디렉터리를 기준으로 하며, 클라이언트에 따라 접근 가능한 경로가 제한될 수 있습니다.

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

rules:
  - RULE-SET,local-direct,DIRECT
  - MATCH,PROXY

해당하는 local-direct.yaml의 내용은 다음과 같습니다.

payload:
  - 'example.com'
  - '+.example.org'

behavior: domain의 payload에는 도메인 매칭 항목을 작성합니다. +.example.org는 해당 도메인과 모든 하위 도메인을 포함합니다. behavior: classical을 사용한다면 payload에 DOMAIN-SUFFIX,example.org 같은 규칙 표현식을 작성해야 하며, 트래픽을 보낼 대상은 보통 바깥쪽 RULE-SET에서 지정합니다. 두 형식의 내용을 섞어 쓰지 말고, 파일 확장자만으로 규칙 세트 유형을 판단하지 마세요.

IP-CIDR와 no-resolve: 대상 주소 매칭

IP-CIDR은 IPv4 주소 대역을, IP-CIDR6은 IPv6 주소 대역을 매칭합니다. 슬래시 뒤 숫자는 프리픽스 길이입니다. /32는 단일 IPv4 주소, /24는 256개 주소를 포함하는 네트워크를 뜻합니다. 여기서 확인하는 것은 대상 주소이며, 접속 기기의 출발지 주소가 아닙니다.

rules:
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - IP-CIDR,10.0.0.0/8,DIRECT,no-resolve
  - IP-CIDR,172.16.0.0/12,DIRECT,no-resolve
  - IP-CIDR6,fc00::/7,DIRECT,no-resolve
  - MATCH,PROXY

no-resolve는 DNS를 끄는 옵션이 아닙니다

no-resolve는 현재 IP 규칙을 위해 도메인 이름 조회를 새로 요청하지 않는다는 뜻입니다. 연결에 사용할 수 있는 대상 IP가 이미 있다면 규칙이 적용될 수 있지만, 연결에 도메인만 있고 사용할 IP가 아직 없다면 해당 IP 규칙을 건너뛰고 다음 규칙을 확인할 수 있습니다. 이 옵션은 전역 DNS 설정이 아니며, 다른 단계에서 도메인이 전혀 조회되지 않는다고 보장하지도 않습니다.

따라서 IP 규칙에 no-resolve를 추가했다고 해서 특정 도메인이 최종적으로 확인된 IP 주소에 따라 분기된다고 단정할 수 없습니다. 내부망으로 직접 연결해야 하는 도메인은 일반적으로 해당 도메인 규칙도 함께 설정하고, 커널 DNS가 올바른 내부 DNS 서버를 통해 주소를 가져오는지 확인해야 합니다.

PROCESS-NAME: 프로세스 식별과 권한 범위

PROCESS-NAME은 프로세스 이름으로 매칭하므로 특정 앱 전체를 같은 경로로 연결할 때 적합합니다. 커널이 운영체제에서 프로세스 정보를 가져와야 하며, 도메인만으로 앱을 추정하는 방식은 아닙니다. 사용 가능 여부는 운영체제, 클라이언트 구현, 실행 권한, 트래픽 연결 방식에 따라 달라집니다.

find-process-mode: strict

rules:
  - PROCESS-NAME,curl,DIRECT
  - PROCESS-NAME,curl.exe,DIRECT
  - DOMAIN-SUFFIX,example.com,PROXY
  - MATCH,PROXY

strict는 필요할 때 프로세스를 조회하는 모드입니다. 문제를 확인하는 동안에는 always로 잠시 바꿔 프로세스 정보를 가져올 수 있는지 살펴볼 수 있습니다. 확인을 마친 뒤 실제 요구에 맞게 설정하세요. 프로세스 이름은 연결 상세 정보나 운영체제에 표시되는 실제 실행 파일 이름을 기준으로 해야 하며, 바탕 화면 바로 가기의 이름을 그대로 쓰면 안 됩니다.

Windows에서는 이름에 .exe가 포함되는 경우가 많으며, 다른 데스크톱 운영체제에서는 실행 파일 이름이 다를 수 있습니다.
브라우저, 런처, 다운로드 도구는 하위 프로세스를 사용할 수 있습니다. 메인 창에 표시되는 이름과 실제 연결을 생성하는 프로세스 이름이 다를 수 있습니다.
요청이 다른 로컬 프록시 프로그램을 거쳐 전달되면 커널은 전달 프로그램만 식별하고, 최초로 요청을 보낸 앱은 알아내지 못할 수 있습니다.
TUN을 사용하면 더 많은 앱의 트래픽을 연결할 수 있지만, 모든 플랫폼에서 완전한 프로세스 정보가 제공되는 것은 아닙니다. 프로세스 필드가 비어 있다면 먼저 권한과 플랫폼 지원 여부를 확인하세요.

프로세스 규칙을 도메인 규칙보다 앞에 두면 해당 프로세스의 연결은 먼저 프로세스 정책에 따라 처리됩니다. 브라우저에서 일부 사이트는 직접 연결하고 나머지는 프록시로 보내려면 도메인 예외 규칙을 브라우저 프로세스 규칙보다 앞에 두세요.

매칭 순서: 첫 번째 일치 규칙과 MATCH 기본 처리

이 문서에서 다루는 일반 규칙 목록은 위에서부터 차례대로 확인해 첫 번째로 일치하는 규칙의 대상을 선택한다고 이해하면 됩니다. 이미 일치한 규칙을 건너뛰고 더 긴 도메인 접미사를 찾거나, 프로세스 규칙을 도메인 규칙보다 자동으로 앞세우지 않습니다.

자주 하는 실수: 범위가 넓은 규칙이 구체적인 규칙을 가립니다

rules:
  - DOMAIN-SUFFIX,example.com,DIRECT
  - DOMAIN,api.example.com,PROXY
  - MATCH,PROXY

여기서는 api.example.com에 접속하면 첫 번째 줄이 먼저 적용됩니다. 해결하려면 같은 규칙을 반복해서 추가하는 대신 정확히 지정한 예외를 도메인 접미사 규칙보다 앞에 두세요. 앞쪽의 GEOSITE, RULE-SET, 프로세스 규칙도 뒤에 있는 사용자 규칙보다 먼저 적용될 수 있습니다.

권장하는 규칙 배치 순서

범위가 명확한 소수의 예외: 특정 도메인, 특정 프로세스, 특수 주소
LAN 및 내부망 서비스: 실제 환경에 맞춰 도메인과 주소 대역 배치
서비스 규칙 세트와 지역 분류: 적용 범위가 넓으므로 서로 겹치는지 먼저 확인
MATCH: 앞선 규칙에 일치하지 않은 연결을 처리하는 마지막 기본 규칙

이 순서는 유지 관리를 위한 권장 사항이지 커널이 강제하는 것은 아닙니다. 특정 프로세스의 프록시 규칙보다 LAN 직접 연결을 우선해야 한다면 LAN 규칙을 더 앞에 두세요. MATCH에는 매칭 대상 필드가 없으므로 MATCH,PROXY처럼 작성하면 됩니다. 목록 중간에 배치하면 뒤에 있는 일반 규칙은 적용될 기회를 잃습니다.

정책 그룹에 매칭됐다고 최종 노드까지 정해진 것은 아닙니다. 규칙에서 PROXY를 지정했더라도 해당 그룹에서 현재 DIRECT를 선택했다면 실제 연결은 직접 연결됩니다. 문제를 확인할 때는 “어떤 규칙이 적용됐는지”와 “정책 그룹에서 최종적으로 어떤 출구를 선택했는지”를 구분해서 살펴보세요.

규칙이 작동하지 않을 때: 연결 정보를 기준으로 점검하기

DNS, TUN, 전체 규칙을 한 번에 바꾸지 마세요. 반복해서 접속할 수 있는 대상을 하나 정하고, 대상 도메인·요청 시간·적용된 규칙·정책 경로·로그 오류를 기록한 다음 변수 하나만 바꾸세요. 클라이언트마다 메뉴 이름이 다르므로 연결 상세 정보, 실행 로그, 현재 설정 화면을 찾아 확인하면 됩니다.

연결이 커널에 전달되는지 확인하세요. 새 요청을 보낸 뒤 연결 목록에서 대상 도메인이나 프로세스를 검색합니다. 기록이 없다면 시스템 프록시, 앱에 지정한 프록시 주소, TUN의 트래픽 가로채기 범위를 확인하세요.
수신 포트를 확인하세요. 설정이 mixed-port: 7890이라면 테스트 도구는 127.0.0.1:7890에 연결해야 합니다. 다른 클라이언트에서 사용하던 포트를 그대로 쓰면 안 됩니다.
현재 모드와 설정 적용 결과를 확인하세요. Rule 모드인지 확인하고, 설정을 다시 불러올 때 YAML 오류, 존재하지 않는 정책, 규칙 세트 로딩 오류가 발생했는지 살펴보세요.
실제로 매칭되는 대상을 확인하세요. 접속 중 다른 도메인으로 이동하는지, 여러 정적 리소스 도메인이나 API 도메인을 함께 사용하는지 확인합니다. 페이지의 기본 도메인만 분기했다고 해서 모든 리소스가 같은 경로를 이용하는 것은 아닙니다.
적용된 규칙보다 앞쪽을 확인하세요. 앞에 배치된 DOMAIN-SUFFIX, GEOSITE, RULE-SET, 프로세스 규칙 또는 MATCH가 대상을 먼저 처리하고 있는지 살펴보세요.
출구와 새 연결을 확인하세요. 정책 그룹에서 현재 선택된 대상을 확인한 뒤 기존 연결을 닫거나 테스트 앱을 다시 시작하세요. 설정을 다시 불러온 뒤에도 기존의 장시간 연결은 새 규칙을 확인하는 테스트 대상으로 사용하면 안 됩니다.

curl로 테스트 경로 고정하기

아래 명령은 로컬 설정에서 mixed-port: 7890을 활성화한 경우에 사용할 수 있습니다. --noproxy ""는 이번 요청의 프록시 우회 목록을 비워 환경 변수의 영향을 줄이며, -I는 HEAD 요청을 보내 연결 설정과 규칙 적용 여부를 확인하는 데 사용됩니다. Windows PowerShell에서는 curl.exe로 실행 파일을 직접 지정할 수 있습니다.

curl --noproxy "" -I --proxy http://127.0.0.1:7890 https://example.com
curl --noproxy "" -I --proxy socks5h://127.0.0.1:7890 https://example.com

socks5h는 대상 도메인을 프록시 측에서 처리하므로 로컬에서 먼저 조회해 결과가 달라지는 상황을 줄이는 데 적합합니다. 아래 두 명령은 명시적 프록시 경로를 확인하기 위한 것이며 TUN 경로까지 검증하는 것은 아닙니다. TUN을 테스트할 때는 앱이 명시적 프록시를 사용하지 않는지 별도로 확인하고, 클라이언트 연결 기록을 통해 트래픽이 실제 가상 네트워크 인터페이스에 들어왔는지 확인하세요.

증상	우선 확인할 항목	해결 방향
저장한 뒤 설정을 다시 불러올 수 없음	들여쓰기, 정책 이름, 분류 데이터, 규칙 세트 형식	로그에 표시된 줄을 수정하고 공백으로 들여쓰기했는지 확인
항상 MATCH가 적용됨	도메인이 일치하는지, 프로세스 정보를 사용할 수 있는지	주소 표시줄만 보지 말고 연결에 실제로 전달된 필드를 확인
PROXY가 적용됐는데도 직접 연결됨	정책 그룹에서 DIRECT 또는 내부의 직접 연결 그룹을 선택했는지	전체 정책 경로를 펼쳐 최종 출구를 확인
구독을 업데이트한 뒤 사용자 규칙이 사라짐	구독에서 생성된 파일을 직접 수정했는지	클라이언트가 지원하는 영구 오버라이드 기능 사용

구독 업데이트와 규칙 관리

구독은 전체 설정을 제공할 수도 있고 노드만 제공할 수도 있습니다. 전체 구독에서 생성된 파일을 직접 수정하면 다음 업데이트 때 변경 내용이 덮어써질 수 있습니다. 클라이언트에 오버라이드, 병합, 스크립트 처리 기능이 있다면 rules를 어떻게 처리하는지 먼저 확인하세요. 전체 교체인지, 앞에 삽입하는지, 끝에 추가하는지 살펴봐야 합니다.

특히 규칙을 목록 끝에 추가하면 “규칙은 있는데 적용되지 않는” 상황이 쉽게 발생합니다. 원본 구독의 마지막에 MATCH가 있다면 새 규칙은 최종 적용 설정에서 MATCH보다 앞에 있어야 합니다. 오버라이드 편집 화면만 확인하지 말고 병합된 규칙 순서도 점검한 뒤 새 연결로 테스트하세요.

되돌릴 수 있도록 변경 내역을 보관하세요

한 번에 목적이 명확한 규칙 묶음 하나만 추가하고, 대상 도메인·예상 출구·추가 이유를 기록하세요.
외부 파일을 잃지 않도록 로컬 규칙 세트도 기본 설정과 함께 백업하세요. YAML만 복원하면 외부 파일이 빠질 수 있습니다.
클라이언트나 커널을 업데이트한 뒤에는 프로세스 식별, 규칙 세트 로딩, 주요 예외 규칙을 다시 확인하세요. 이전 연결 결과에 의존하지 마세요.
로그를 공유하기 전에 구독 주소, 노드 인증 정보, 컨트롤 인터페이스 키를 숨기세요. 문제를 확인할 때는 규칙 일부와 매칭 정보를 우선 제공하면 됩니다.

규칙 관리의 핵심은 적용 범위와 순서를 명확히 설명할 수 있게 하는 것입니다. 구체적인 예외는 이를 덮을 수 있는 넓은 범위의 규칙보다 앞에 두고, 기본 규칙은 마지막에 배치하며, 연결 상세 정보로 실제 적용 결과를 확인하세요. 트래픽이 들어오는 경로를 먼저 검증하고, 매칭 필드와 정책 경로를 차례로 살펴보면 모드를 반복해서 바꾸는 것보다 문제를 쉽게 찾을 수 있습니다.