Clash 커스텀 규칙 작성법: 매칭 순서, 우선순위와 MATCH 기본 규칙

규칙이 분류를 결정하는 방식

Clash 코어는 연결이 들어올 때마다 목적지 주소, 포트, 출처 특징을 추출한 뒤 이 정보를 설정 파일의 rules 목록과 하나씩 비교합니다. 목록에서 가장 먼저 매칭되는 규칙이 해당 연결의 처리 방식을 결정합니다: 특정 프록시 노드, 특정 정책 그룹, 내장된 DIRECT 직접 연결, 또는 REJECT 차단 중 하나로 판정됩니다. 판정은 매칭되는 순간 끝나며, 그 뒤에 오는 규칙은 더 이상 관여하지 않습니다.

따라서 rules 목록은 Clash 분류의 유일한 기준입니다. 설정이 구독 링크에서 왔든, 클라이언트의 오버라이드 기능에서 왔든, 직접 편집한 것이든 결국은 한 줄씩 나열된 이 규칙 목록으로 귀결됩니다. 실무에서 규칙 유형을 잘못 쓰는 경우는 그리 많지 않으며, 예상과 다른 분류 결과는 대부분 순서 문제에서 비롯됩니다: 더 광범위한 규칙이 앞에 있으면 뒤쪽의 정밀한 규칙이 처리해야 할 트래픽을 미리 가로채 버립니다. 규칙 유형을 외우는 것보다 매칭 순서를 이해하는 것이 훨씬 중요합니다.

트래픽이 시스템 프록시, TUN 모드, 혼합 포트 중 어디로 들어오든 코어가 비교하는 것은 동일한 rules 목록이며, 순서 처리 방식은 완전히 동일합니다.

규칙 한 줄의 문법 구조

규칙 한 줄은 쉼표로 구분된 여러 항목으로 구성되며, 전체 형태는 4개 항목이지만 대부분의 유형은 앞 3개만 사용합니다:

유형,값,정책[,추가 옵션]

• 유형: 어떤 기준으로 매칭할지 결정합니다. 예: DOMAIN, DOMAIN-SUFFIX, IP-CIDR, GEOIP.
• 값: 매칭할 구체적인 대상입니다. 예: 도메인 하나, 특정 접미사, IP 대역, 국가 코드 등.
• 정책: 매칭되면 어디로 보낼지 결정합니다. DIRECT, REJECT 같은 내장 정책일 수도 있고, proxies나 proxy-groups에 정의된 노드명, 정책 그룹명일 수도 있습니다.
• 추가 옵션: 현재는 no-resolve만 있으며 IP 계열 규칙에서만 사용됩니다. 자세한 내용은 뒤에서 설명합니다.

작성 시 지켜야 할 규칙은 4가지입니다. 첫째, 규칙은 설정 파일의 rules 섹션 안에 모여 있어야 하며 YAML 형식에서는 각 줄이 하이픈으로 시작합니다. 둘째, 정책명은 설정에 정의된 이름과 대소문자, 공백까지 정확히 일치해야 하며, 틀리면 전체 설정 로드가 실패합니다. 셋째, 도메인 값은 항상 소문자로 쓰고 프로토콜 헤더나 경로를 붙이지 않아야 합니다. http:// 접두사가 붙은 형태는 절대 매칭되지 않습니다. 넷째, 井(#) 기호로 시작하는 줄은 주석이며 코어가 해석하지 않습니다.

rules:
  - DOMAIN,update.example.com,DIRECT
  - DOMAIN-SUFFIX,example.com,Proxy
  - DOMAIN-KEYWORD,tracker,REJECT
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - GEOIP,CN,DIRECT
  - MATCH,Proxy

자주 쓰는 규칙 유형 정리

아래 표는 커스텀 규칙에서 가장 자주 쓰이는 유형을 정리한 것입니다. GEOSITE, PROCESS-NAME 등은 mihomo 코어에서만 제공되며 오리지널 Clash Premium은 지원하지 않으므로 혼용하면 설정을 로드할 수 없습니다.

규모가 큰 목록은 rules에 한 줄씩 나열하기에 적합하지 않습니다. 수만 줄에 달하는 광고 도메인이나 사이트 분류는 rule-providers로 관리하는 것이 좋으며, rules에서는 RULE-SET,목록명,정책 형태로 한 줄만 참조하면 됩니다. 코어는 interval 주기에 따라 목록을 자동으로 갱신하므로 항목이 많아져도 매칭 위치는 한 줄만 차지해 로드와 관리가 훨씬 간편합니다.

매칭 순서: 위에서 아래로, 먼저 매칭되면 멈춤

코어는 각 연결을 처리할 때 rules 목록의 첫 줄부터 아래로 순서대로 비교하며, 가장 먼저 매칭된 규칙이 즉시 적용되고 비교는 그 자리에서 종료됩니다. 이 원리에서 세 가지 결론이 도출됩니다:

1. 정밀한 규칙은 반드시 광범위한 규칙보다 앞에 있어야 합니다. update.example.com은 직접 연결하고 example.com의 나머지 서브도메인은 프록시를 거치게 하려면 DOMAIN 항목을 DOMAIN-SUFFIX 항목보다 위에 써야 합니다. 순서가 뒤바뀌면 접미사 항목이 트래픽을 먼저 가로채 정밀 항목은 영원히 매칭될 기회를 얻지 못합니다.
2. 나중에 쓴 규칙이 먼저 쓴 규칙을 덮어쓸 수 없습니다. Clash에는 나중에 작성한 것이 우선한다는 계층 로직이 없습니다. 먼저 매칭되면 먼저 적용되며, 우선순위를 조정하는 유일한 방법은 줄 순서를 바꾸는 것입니다.
3. 커스텀 규칙과 구독 규칙의 우선순위는 최종 목록에서의 상대적 위치에 따라 결정됩니다. 대부분의 GUI 클라이언트는 오버라이드 기능으로 커스텀 규칙을 구독 규칙보다 앞에 삽입해 우선 매칭되도록 처리합니다. 반대로 클라이언트가 커스텀 항목을 구독 규칙 뒤에 붙이는 경우, 구독에 이미 더 광범위한 항목이 있으면 커스텀 항목은 영원히 매칭될 기회를 얻지 못할 수 있습니다.

규칙을 작성했는데도 적용되지 않는 경우, 먼저 확인할 것은 문법이 아니라 클라이언트가 표시하는 최종 rules 목록을 열어 해당 항목이 실제로 몇 번째 줄에 있는지입니다.

IP 계열 규칙과 no-resolve 옵션

도메인 계열 규칙은 연결에 담긴 도메인을 바로 비교하지만, IP-CIDR와 GEOIP는 IP가 있어야 비교할 수 있습니다. 목적지가 도메인일 경우 코어는 먼저 DNS 조회를 해서 결과를 얻어야 다음 판정을 진행할 수 있습니다. 즉, 목록에 IP 계열 규칙이 존재하면 앞의 도메인 규칙에 걸리지 않은 연결마다 추가로 조회가 한 번 더 발생할 수 있으며, 이는 지연 시간을 늘리고 DNS 조회 노출 범위도 넓힙니다.

no-resolve는 이 동작을 끄는 옵션입니다. no-resolve가 붙은 IP 규칙은 목적지가 이미 IP 리터럴일 때만 매칭에 참여하며, 코어는 이 규칙을 위해 도메인을 조회하지 않습니다:

IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
GEOIP,CN,DIRECT,no-resolve

내부망 대역, LAN 기기처럼 순수 IP 상황에서는 no-resolve를 항상 붙이는 것이 좋습니다. 반대로 먼저 조회한 뒤 소속 국가로 분류하는 GEOIP 규칙에는 이 옵션을 붙이면 안 됩니다. 그렇지 않으면 도메인으로 시작된 연결이 이 규칙을 그냥 지나쳐 뒤쪽 항목으로 넘어가게 됩니다.

MATCH 기본 규칙

MATCH는 값이 없는 유일한 규칙 유형이며, 형식은 MATCH,정책 두 항목뿐입니다. 앞의 규칙들에 매칭되지 않은 모든 연결을 처리하며, 사용 시 세 가지 원칙이 있습니다: rules 목록의 마지막 줄에 배치해야 하고, 설정 하나에는 MATCH가 한 줄만 있어야 하며, 코어의 기본 동작에 맡기지 말고 항상 명시적으로 작성하는 것이 좋습니다.

MATCH가 중간에 있으면 남은 모든 트래픽을 가로채 그 뒤의 규칙은 전부 죽은 줄이 되어버립니다. 이는 커스텀 규칙에서 가장 흔하면서도 발견하기 어려운 실수입니다. mihomo는 매칭되지 않은 트래픽을 기본적으로 직접 연결하지만, MATCH를 명시적으로 써두면 최종 흐름이 명확하고 읽기 쉬워져 나중에 유지보수할 때 코어의 동작을 추측할 필요가 없습니다.

흔히 쓰는 두 가지 방식이 있습니다. MATCH,Proxy는 별도로 지정되지 않은 트래픽은 전부 프록시를 거치도록 하는 것으로, 앞의 직접 연결 예외들과 함께 블랙리스트 방식에 해당합니다. MATCH,DIRECT는 목록에서 명시적으로 허용한 트래픽만 프록시를 거치고 나머지는 전부 직접 연결하는 방식으로, 화이트리스트 방식에 해당하며 일부 사이트에만 프록시가 필요한 경우에 적합합니다.

전체 예시와 매칭 확인

앞의 내용을 종합하면, 일반적인 커스텀 rules 섹션은 다음과 같은 형태가 됩니다:

rules:
  # 로컬 및 내부망: .lan 접미사와 내부망 대역은 직접 연결
  - DOMAIN-SUFFIX,lan,DIRECT
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  # 광고 및 트래킹: 키워드 매칭 시 차단
  - DOMAIN-KEYWORD,tracker,REJECT
  # 정밀 예외: 업데이트 서버는 직접 연결
  - DOMAIN,update.example.com,DIRECT
  # 나머지 example.com 서브도메인은 프록시 경유
  - DOMAIN-SUFFIX,example.com,Proxy
  # 국내 주소는 소속 국가 기준으로 직접 연결
  - GEOIP,CN,DIRECT
  # 기본 처리: 남은 트래픽은 프록시 경유
  - MATCH,Proxy

예시에서 GEOIP 항목에는 no-resolve가 붙어 있지 않다는 점에 주의하세요. 도메인으로 시작해 앞의 항목에 걸리지 않은 연결은 여기서 조회가 한 번 발생한 뒤 소속 국가로 판정됩니다. 이런 조회를 완전히 피하고 싶다면 GEOSITE 분류 목록을 사용해 도메인 단계에서 분류를 끝내고, GEOIP는 순수 IP 연결에만 no-resolve를 붙여 사용하는 것이 좋습니다.

규칙이 예상대로 동작하는지는 추측할 필요가 없습니다. Clash Verge Rev의 연결 페이지, 각종 Dashboard의 Connections 같은 GUI 클라이언트의 연결 패널을 보면 각 연결이 실제로 어떤 규칙과 정책에 매칭됐는지 실시간으로 확인할 수 있습니다. CLI 환경이라면 로그 레벨을 info로 설정하면 코어가 매칭 기록을 한 줄씩 출력합니다. 결과가 예상과 다르면 패널에 표시된 규칙명을 보고 목록의 줄 순서를 다시 확인하면 대개 원인이 바로 드러납니다.