Clash Meta·Mihomo 규칙 우선순위: 먼저 잡히는 한 줄과 MATCH (2026)

1. 머릿속 모델: “한 줄, 한 번”

mode: rule이 전제일 때, 코어는 각 연결(또는 DNS 요청)에 대해 rules 목록을 위에서부터 읽습니다. 어느 한 줄이 조건을 만족하면, 그 줄 오른쪽에 있는 정책 이름을 선택한 뒤 그 이후의 줄은 보지 않습니다. 그래서 “나중에 쓴 예쁜 DOMAIN 규칙”이, 맨 위에 있는 “덜 정교한 GEOIP·넓은 IP-CIDR”에 가로막힌 것처럼 느껴질 수 있습니다. 이는 버그가 아니라, 이 엔진이 애초에 그렇게 설계됐다고 이해하는 편이 빠릅니다.

이 동일한 원리가 RULE-SET,provider-name,POLICY로 펼쳐진 외부 묶음에도 그대로 적용됩니다. provider 안의 순서는 또 하나의 “소규칙집”이고, 그 한 줄이 rules의 그 위치에 펼쳐졌다고 상상하면 이해에 도움이 됩니다. (실제 머지 방식·성능은 버전·behavior에 따르므로, 최종은 공식 문서·로그로 확인하세요.)

2MATCH는 “남는 것 전부”

MATCH,정책는 조건이 비어 있고 항상 참인 특수한 한 줄로, 흔히 가장 맨 아래에 둡니다. 위쪽 어떤 줄에도 걸리지 않은 연결은 전부 여기로 떨어집니다. 그래서 “기본이 다이렉트인지 프록시인지”는 MATCH가 가리키는 정책에 달렸다고 봐도 됩니다. 만약 MATCH,PROXY로 닫혀 있는데, 분명 국내만 DIRECT로 보내는 줄을 그 아래에 써 두었다면, 그 줄은 절대 실행되지 않습니다. 순서를 바꾸는 것이 먼저입니다.

# Concept sketch — final line catches everything that fell through
rules:
  - DOMAIN-SUFFIX,example.com,DIRECT
  - GEOIP,KR,DIRECT
  - MATCH,PROXY

위 스케치에서 한국 IP는 GEOIP,KR이 먼저 잡을 수도 있고, example.com은 첫 줄이 먼저 잡을 수도 있습니다. 남는 트래픽만 PROXY로 흐릅니다. 정책 그룹 이름은 프로필 안의 proxy-groups·proxy 정의와 완전히 같아야 합니다. 오타 한 글자면 이상한 기본 정책이나 오류로 이어질 수 있습니다.

3규칙 순서 vs proxy-groups 선언 순서

흔한 혼동은 YAML 파일에서 proxy-groups가 위에 있고 rules가 아래에 있다는 점을, “그룹이 먼저 평가된다”고 착각하는 것입니다. 실제 흐름은 대략 이렇게 기억하면 됩니다. (1) 연결이 생기고 (2) rules가 위에서 아래로 매칭되어 정책 이름 하나를 고릅니다. (3) 그 이름이 select·url-test 등 그룹이면, 그때서야 그 그룹의 로직이 가동돼 실제 노드(프록시)를 고릅니다. 그래서 “rules에서 이미 DIRECT로 떨어졌다”면, 아래에 멋지게 써 둔 url-test 그룹은 그 연결에겐 쓰이지 않습니다. 반대로 rules가 PROXY 그룹을 가리키는데, 그 그룹 안에 마음에 드는 노드가 없다면, 그때는 url-test·fallback 설정을 봅니다. 문제를 “규칙 층”과 “그룹 층”으로 나누는 것이 체감 분류(왜 이 사이트가 이 국가로 갔는지)를 풀 때 중요합니다.

4RULE-SET·구독 끼워 넣는 위치

원격 rule-providers로 받은 RULE-SET,이름,정책 한 줄은, 인라인으로 쓴 줄과 똑같이 그 세로 위치에서 경쟁합니다. “새 룰셋을 맨 뒤에 붙였는데”가 아니라, GUI나 스크립트가 수제 규칙 앞/뒤 중 어디에 넣었는지가 핵심입니다. 큰 집합을 위에 올리면(예: 광역 GEOSITE·GEOIP 묶음) 그 아래의 좁은 예외는 영원히 도달하지 못할 수 있습니다. GEOIP·GEOSITE를 이미 쓰고 있다면, 그 글의 “넓은 것과 좁은 것” 절을 이 “한 줄, 한 번” 모델과 겹쳐서 읽으면 정리가 빨라집니다.

5규칙이 “맞는데” 이상한 경우: DNS·이름·스니퍼

순서를 바로 잡아도, 도메인 규칙이 조건에 도달조차 하지 못하면 여전히 MATCH나 IP 위주의 줄만이 승리합니다. 예를 들어 HTTPS에서 코어가 처음에 IP만 본다면, GEOSITE·DOMAIN이 비어 있어 매칭이 안 될 수 있습니다. 이때는 Sniffer로 SNI를 살리거나, DNS·FakeIP·TUN이 같은 전제를 공유하는지 살핍니다. 이 글의 범위는 규칙만 맞췄을 때의 엔진이고, 이름이 규칙에 도착하는 경로는 앞의 두 가지와 함께 봐야 “완전한” 답이 됩니다. 앱마다 쪼갠다면 PROCESS-NAME 쪽도 겹쳐서 보세요.

6. 점검 체크리스트 (현장용)

• 연결·DNS 로그에 어느 규칙이 매칭됐다고 찍히는가? (이름 또는 규칙 식별)
• 그보다 위에 더 일반적인 GEOIP·IP-CIDR·RULE-SET이 있지 않은가?
• 마지막 MATCH가 기대한 정책을 가리키는가? (그 아래에 “특이 케이스”를 써 둔 실수)
• rules가 가리킨 정책 그룹 이름이 proxy-groups와 일치하는가? (클라이언트의 수동 선택이 자동·규칙을 덮는지)
• 구독/머지 후 최종 YAML의 rules 배열이 예상한 순서인가?

7. 오픈소스와 설치

Mihomo 소스·이슈·라이선스는 GitHub에서 열람할 수 있지만, 클라이언트 설치 패키지의 주요 진입점으로는 이 사이트의 다운로드 페이지를 권장합니다. 저장소는 신뢰·투명성용이고, 실제로 설치를 고를 때는 허브에서 플랫폼에 맞게 고르면 혼선이 줄어듭니다. 규칙 순서를 실험할 때는 한 번에 한 가지만 바꾸고 로그로 확인하는 짧은 루프가, 긴 복붙보다 훨씬 오류를 덜 냅니다. 같은 엔진이라도 GUI마다 “rules 편집”이 숨겨진 경로가 달라, Yacd 같은 external-controller로 최종 머지 결과를 읽는 일이 섞이기도 합니다.

맺음말

Clash Meta·Mihomo에서 “분류가 먹지 않는다”는 느낌은, 종종 문법보다 규칙 우선순위·MATCH가 받는 잔여·정책 그룹으로의 연결에서 먼저 풀립니다. 위에서 아래 첫 일치와 맨 끝 MATCH만 확실히 이해해도, GEOIP·GEOSITE를 어디에 두고 예외 DOMAIN을 어디에 둘지가 한결 또렷해집니다. RULE-SET·구독 룰의 수직 위치와, 머지·GUI가 만든 실제 rules 배열까지 점검하면, “썼는데 안 된다”는 소모전을 많이 줄일 수 있습니다. 다른 도구에 비해 코어는 “어느 줄이 먹었는지”를 로그에 읽기 쉽게 남기는 편이라, 한 번 루틴을 잡아 두면 이후는 유지가 편해집니다. 비슷한 도구에 비해도 정책 이름과 매칭 결과의 대응이 비교적 직선적이라, 반복 읽기에 좋은 편입니다.

→ Clash를 무료로 내려받고, rules 순서·MATCH·정책 그룹을 한 프로필에서 검증해 보세요