Clash 사용자 규칙 작성법 상세 설명: 매칭 유형, 문법 형식과 우선순위 순서

Clash의 트래픽 분기 기능은 최종적으로 설정 파일의 rules 필드에서 결정됩니다. 하나의 규칙은 특정 트래픽이 어떤 정책 그룹으로 갈지를 정하는데, 순서를 잘못 쓰거나 매칭 유형을 잘못 사용하면 가볍게는 특정 사이트의 분기가 작동하지 않고, 심하게는 전체 정책 그룹이 무효화되거나 DNS 해석에 이상이 생길 수 있습니다. 이 글에서는 mihomo 코어(Clash Meta) 구현을 기준으로 자주 쓰이는 규칙 유형을 하나씩 풀어 문법과 적용 상황을 정리하고, 규칙이 "위에서 아래로" 어떻게 적용되는지 설명한 뒤, 그대로 적용할 수 있는 정렬 원칙을 제시합니다.

규칙 시스템의 기본 구조와 적용 순서

Clash 설정 파일의 rules는 배열이며, 한 줄이 하나의 규칙입니다. 형식은 다음과 같이 통일되어 있습니다:

규칙 유형,매칭 내용,정책 그룹[,추가 옵션]

예를 들면:

rules:
  - DOMAIN-SUFFIX,github.com,🚀 노드 선택
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - GEOIP,CN,DIRECT
  - MATCH,🚀 노드 선택

코어가 네트워크 요청을 처리할 때는 배열 순서대로 위에서 아래로 하나씩 비교하며, 어떤 규칙이 매칭에 성공하는 순간 그 규칙이 지정한 정책 그룹을 즉시 적용하고 이후 규칙은 모두 건너뛰어 더 이상 비교하지 않습니다. 이 "매칭되면 즉시 종료"라는 동작 방식은 전체 규칙 시스템에서 가장 쉽게 간과되고 문제가 자주 발생하는 부분입니다. 많은 사람이 규칙은 "더 정확한 쪽이 적용된다"고 생각하지만, 실제로는 앞에 쓰였는지 뒤에 쓰였는지에 전적으로 좌우됩니다.

바로 이런 이유로 규칙 파일 맨 끝에는 거의 항상 MATCH,정책 그룹이 기본값으로 등장합니다. 이는 "위의 모든 규칙에 매칭되지 않았을 때의 기본 경로"를 의미하며, 분기 표의 마지막 줄에 해당하기 때문에 반드시 배열의 맨 끝에 두어야 합니다. 앞쪽에 두면 그 뒤의 모든 규칙이 영원히 적용되지 않게 됩니다.

자주 쓰이는 매칭 유형 하나씩 살펴보기

mihomo가 지원하는 규칙 유형은 다양하지만, 실제 설정에서 자주 등장하는 것은 아래 몇 가지뿐입니다. 매칭 대상에 따라 도메인 계열, IP 계열, 지역 계열, 프로세스 계열로 나눌 수 있습니다.

도메인 계열: DOMAIN / DOMAIN-SUFFIX / DOMAIN-KEYWORD

• DOMAIN,www.example.com,정책 그룹 —— 완전한 도메인 하나를 정확히 매칭하며 서브도메인은 매칭되지 않습니다. 특정 도메인 하나만 개별적으로 처리하고 싶을 때 적합합니다.
• DOMAIN-SUFFIX,example.com,정책 그룹 —— 해당 도메인과 그 하위 도메인 전체를 매칭합니다(www.example.com, api.example.com 모두 매칭됨). 실제 설정에서 가장 많이 쓰이는 유형으로, 규칙 한 줄로 도메인 체계 전체를 커버할 수 있습니다.
• DOMAIN-KEYWORD,example,정책 그룹 —— 도메인에 이 키워드가 포함되어 있으면 매칭됩니다. 매칭 범위가 가장 넓어 관련 없는 도메인까지 잘못 걸릴 수 있으므로, 키워드가 충분히 특이하고 다른 서비스와 겹치지 않을 때만 사용하는 것이 좋습니다.

IP 및 대역 계열: IP-CIDR / IP-CIDR6

IP-CIDR,192.168.1.0/24,DIRECT,no-resolve와 같은 규칙은 CIDR 대역으로 목적지 IP를 매칭하며, LAN 대역, 내부망 서버, CDN 고정 IP 대역을 직접 허용하거나 특정 경로로 강제 라우팅할 때 자주 사용됩니다. IPv6 주소는 IP-CIDR6에 대응되며 작성법은 동일합니다. 이런 규칙은 대체로 규칙 표의 앞쪽에 두어야 하는데, LAN 접근이 도메인 규칙이나 GEOIP 규칙에 먼저 걸리면 오히려 프록시를 거쳐 우회하게 되기 때문입니다.

지역 계열: GEOIP

GEOIP,CN,DIRECT는 GeoIP 데이터베이스를 이용해 목적지 IP가 속한 국가나 지역을 판단합니다. 흔히 GEOIP,CN을 직접 연결 정책에 매핑해 중국 본토 IP가 프록시를 거치지 않도록 합니다. 이런 규칙은 매칭 범위가 매우 넓기 때문에 규칙 표의 뒤쪽에 두는 것이 자연스러운데, 앞쪽에 두면 세분화해서 처리해야 할 많은 트래픽이 미리 "흡수"되어 버립니다.

프로세스 계열: PROCESS-NAME / PROCESS-PATH

PROCESS-NAME,com.apple.WebKit.Networking,DIRECT는 요청을 보낸 프로세스 이름으로 매칭하며, 특정 클라이언트에만 개별 정책을 지정할 때 자주 사용됩니다. 예를 들어 특정 다운로드 도구는 항상 직접 연결시키거나, 특정 앱은 항상 지정된 노드를 거치게 할 수 있습니다. 데스크톱 플랫폼에서는 프로세스 규칙이 가장 세밀한 단위지만, 프로세스 이름은 시스템이나 버전에 따라 다를 수 있으므로 규칙이 적용되지 않을 때는 먼저 이름이 정확한지 확인해야 합니다.

논리 조합과 기본값: AND / OR / NOT / MATCH

mihomo는 여러 조건을 하나로 묶는 논리 규칙도 지원합니다. 예를 들면:

- AND,((DOMAIN-SUFFIX,example.com),(NETWORK,tcp)),정책 그룹

이런 작성법은 여러 조건을 동시에 만족해야 적용되는 세밀한 상황에 적합하며, 실제 설정에서 자주 쓰이지는 않지만 문법 구조를 알아두면 커뮤니티에서 공유하는 규칙 세트를 이해하는 데 도움이 됩니다. 마지막으로 MATCH,정책 그룹은 매칭 내용이 필요 없는 유일한 규칙 유형으로 기본 정책을 나타내며, 규칙 표에서 단 한 번만, 반드시 맨 마지막 줄에 등장해야 합니다.

no-resolve 옵션과 DNS 해석 시점

IP-CIDR와 IP-CIDR6 규칙은 끝에 no-resolve 옵션을 붙일 수 있는데, 실제 사용에서 가장 쉽게 놓치면서도 규칙이 "적용되지 않는 것처럼" 보이게 만드는 세부 사항입니다.

기본적으로 도메인 기반 규칙(예: DOMAIN-SUFFIX)은 매칭 전에 IP를 미리 해석할 필요 없이 도메인 문자열 자체를 비교합니다. 반면 IP-CIDR 계열 규칙은 본질적으로 "목적지 IP"를 대역과 비교하는 방식이라, 요청 자체가 도메인이면 코어가 먼저 도메인을 IP로 해석한 뒤 그 IP로 IP-CIDR 규칙을 매칭합니다. no-resolve를 붙이면 코어는 이 해석 단계를 건너뛰고, 요청 자체가 이미 IP인(도메인이 아닌) 연결에만 규칙을 적용하며, 규칙을 매칭하기 위해 별도의 DNS 조회를 능동적으로 발생시키지 않습니다.

실제로 규칙을 작성할 때의 판단 기준은 간단합니다. IP-CIDR 규칙이 명확히 IP 형태로 나타나는 트래픽(내부망 장치, IP를 직접 노출하는 서비스 등)을 대상으로 한다면 no-resolve를 붙이는 것이 좋고, 목적지가 도메인을 통해 접근되며 해석 결과에 따라 경로를 판단해야 하는 상황이라면 앞쪽의 도메인 계열 규칙에서 처리하는 것이 더 직접적이며, IP-CIDR까지 돌아갈 필요가 없습니다.

규칙 정렬의 실전 원칙과 흔한 실수

"위에서 아래로, 매칭되면 종료"라는 동작 방식을 이해하면 규칙 정렬에는 비교적 정해진 원칙이 있습니다. 매칭 범위가 좁은 것부터 넓은 것 순으로 배치하면 됩니다:

1. 먼저 LAN과 내부망 직결 규칙을 작성합니다. 사설 IP 대역과 내부망 도메인을 맨 앞에 두어, 뒤쪽의 더 넓은 규칙에 먼저 걸려서 내부망 접근까지 프록시를 거치는 상황을 막습니다.
2. 다음으로 특별히 처리해야 하는 구체적인 도메인이나 앱을 작성합니다. 예를 들어 특정 노드를 거쳐야 하는 스트리밍 도메인, 직결이 필요한 한국 국내 서비스 도메인 등을 DOMAIN-SUFFIX로 정확히 커버합니다.
3. 이어서 규칙 세트(rule-providers)를 배치합니다. 커뮤니티에서 관리하는 분류 규칙 세트, 예를 들어 광고 차단이나 주요 서비스 분류 등을 필요한 참조 순서대로 배치합니다.
4. 그 다음 지역 계열 규칙을 배치합니다. 대표적으로 GEOIP,CN,DIRECT를 두어 앞쪽 규칙에 매칭되지 않은 중국 본토 IP를 직접 허용합니다.
5. 마지막 줄은 항상 MATCH 기본값입니다. 매칭되지 않은 모든 트래픽이 이곳으로 모이며, 보통 노드 선택이나 정책 그룹을 가리킵니다.

흔한 정렬 실수는 크게 두 가지입니다. 하나는 GEOIP,CN,DIRECT를 너무 앞쪽에 두어, 원래는 세분화해서 프록시를 거쳐야 할 서비스가 해석된 IP가 마침 중국 본토 대역에 속한다는 이유로 미리 직결되어 버리는 경우입니다. 다른 하나는 MATCH 기본값 규칙을 중간에 잘못 배치해, 그 뒤에 열심히 작성한 모든 규칙이 사실상 영원히 실행되지 않는 경우입니다. 디버깅할 때는 특정 규칙의 문법이 잘못됐다고 오해하기 쉽지만 실제로는 정렬 문제인 경우가 많습니다. 이런 문제를 점검할 때는 먼저 규칙 배열의 순서를 확인하고, 그 다음에 구체적인 문법을 확인하는 것이 좋습니다. 순서가 잘못되면 문법이 아무리 정확해도 적용되지 않습니다.

규칙 세트로 대규모 규칙 관리하기

사용자 규칙 수가 수십~수백 개로 늘어나면 rules 배열에 모두 쌓아두는 방식은 유지보수가 어려워집니다. mihomo는 rule-providers 필드를 지원해 규칙을 독립된 원격 또는 로컬 파일로 분리하고, rules에서는 RULE-SET,규칙 세트 이름,정책 그룹 형태로 참조할 수 있습니다:

rule-providers:
  my-direct:
    type: http
    behavior: domain
    url: "https://example.com/rules/direct.yaml"
    path: ./rule-providers/direct.yaml
    interval: 86400

rules:
  - RULE-SET,my-direct,DIRECT
  - GEOIP,CN,DIRECT
  - MATCH,🚀 노드 선택

behavior 필드는 이 규칙 세트의 항목을 도메인, IP 대역, 분류 규칙 중 어떤 방식으로 해석할지 결정하며 규칙 파일의 실제 내용과 일치해야 합니다. interval은 자동으로 업데이트를 가져오는 주기를 결정합니다. 이 방식은 "분류 로직"과 "구체적인 규칙 내용"을 분리해, 규칙 세트 자체를 업데이트해도 메인 설정 파일의 정렬을 건드릴 필요가 없어 모든 규칙을 한 파일에 손으로 작성하는 것보다 유지보수 비용이 눈에 띄게 낮습니다.

규칙 작성 후 확인해야 할 두 가지

규칙을 다 작성한 뒤 실제로 사용하기 전에 두 가지를 확인하는 것이 좋습니다. 첫째, 규칙 배열에 MATCH가 단 하나만 있고 맨 끝에 위치하는지 확인합니다. 이는 가장 놓치기 쉬운 부분입니다. 둘째, 새로 추가한 IP-CIDR 규칙에서 no-resolve가 의도한 대로 추가되었는지 또는 생략되었는지 확인합니다. 특히 내부망 접근과 관련된 규칙은 잘못 추가하거나 빠뜨리면 겉보기에 "무작위"처럼 보이는 연결 이상을 일으킬 수 있습니다. 로그에 나타난 분기 결과가 예상과 다르다면, 먼저 규칙 배열을 순서대로 다시 읽어보는 것이 문법을 하나씩 확인하는 것보다 대개 더 빠르게 원인을 찾는 방법입니다.