Clash 커스텀 규칙 문법과 매칭 우선순위 완벽 분석

규칙(rules)은 Clash 설정에서 "이 연결이 어떤 프록시를 거칠지"를 결정하는 핵심 모듈입니다. 처음 설정 파일을 직접 수정할 때 규칙을 아무렇게나 쌓아두면, 분명히 제대로 작성한 규칙이 전혀 적용되지 않는 경우가 생기는데—이는 거의 항상 매칭 순서 문제입니다. 이 노트에서는 규칙 유형별로 문법을 하나씩 짚어보고, 매칭 엔진이 위에서 아래로 검사하며 매칭되면 즉시 멈추는 동작 방식을 설명하며, 커스텀 분류 규칙을 작성할 때 규칙 간 충돌을 피할 수 있는 실용적인 정렬 방법을 제시합니다.

규칙의 기본 구조와 실행 방식

Clash 설정 파일의 rules는 리스트이며, 각 줄이 하나의 규칙에 해당하고 형식은 다음 3단 구조로 통일되어 있습니다:

RULE-TYPE,VALUE,PROXY

첫 번째 항목은 규칙 유형, 두 번째는 매칭 값(일부 규칙 유형은 이 항목이 없는 경우도 있음, 예: MATCH), 세 번째는 매칭되었을 때 사용할 프록시 또는 프록시 그룹 이름입니다. 이 시스템을 이해하는 데 가장 중요한 점은 Clash가 새로운 연결을 처리할 때 규칙 리스트를 위에서 아래로 하나씩 검사하며, 어떤 규칙이 매칭되면 즉시 해당 프록시를 사용하고 이후 검사를 중단한다는 것입니다. 뒤에 매칭될 수 있는 규칙이 남아 있어도 더 이상 검사되지 않습니다.

이 "매칭되면 즉시 멈춤" 원칙 때문에 규칙의 배열 순서 자체가 로직의 일부가 되며, 단순히 보기 좋게 정리하는 것과는 다릅니다. 규칙을 작성할 때는 항상 이렇게 생각해야 합니다: 앞쪽에 있을수록 우선순위가 높고, 더 구체적이고 예외적인 판단은 앞쪽에, 포괄적이고 마지막 처리용 규칙은 뒤쪽에 배치해야 합니다.

자주 쓰는 규칙 유형 하나씩 살펴보기

아래에서는 사용 빈도가 높은 순서로 가장 많이 쓰이는 규칙 유형들의 문법과 매칭 로직을 설명합니다.

DOMAIN: 정확한 도메인 매칭

DOMAIN은 완전히 일치하는 도메인만 매칭하며, 모호한 매칭이나 서브도메인 확장은 하지 않습니다.

DOMAIN,ads.example.com,REJECT
DOMAIN,api.example.com,Proxy

위 첫 번째 규칙은 ads.example.com이라는 정확한 주소만 차단하며, cdn.ads.example.com이나 example.com은 이 규칙에 매칭되지 않습니다. 특정 인터페이스 주소를 정확히 차단하거나 허용할 때 적합합니다.

DOMAIN-SUFFIX: 도메인 접미사 매칭

DOMAIN-SUFFIX는 지정한 접미사와 그 모든 서브도메인을 매칭하며, 분류 규칙을 작성할 때 가장 많이 쓰이는 유형입니다.

DOMAIN-SUFFIX,youtube.com,Proxy
DOMAIN-SUFFIX,cn,DIRECT

첫 번째 규칙은 youtube.com, www.youtube.com, music.youtube.com 등 이 접미사로 끝나는 모든 도메인에 매칭됩니다. 두 번째는 .cn으로 끝나는 모든 도메인을 프록시를 거치지 않고 직접 연결하게 만듭니다. 이 유형은 커버 범위가 넓어 커스텀 규칙을 작성할 때 가장 먼저 떠오르는 유형입니다.

DOMAIN-KEYWORD: 도메인 키워드 매칭

DOMAIN-KEYWORD는 도메인 문자열에 지정한 키워드가 포함되어 있으면 매칭되며, 키워드가 어느 위치에 있는지는 구분하지 않습니다.

DOMAIN-KEYWORD,google,Proxy

이 규칙은 www.google.com은 물론 googleapis.com, googlevideo.com 등 google 문자열을 포함하는 모든 도메인에 매칭됩니다. 이 유형은 매칭 범위가 가장 넓기 때문에 작성 시 오탐에 주의해야 합니다—예를 들어 키워드 ad는 광고와 무관하지만 도메인에 우연히 ad 문자 조합이 포함된 정상 사이트까지 함께 매칭될 수 있으므로, 가능하면 더 완전한 키워드를 쓰거나 DOMAIN-SUFFIX로 바꾸는 것을 권장합니다.

IP-CIDR 및 IP-CIDR6: IP 대역 매칭

IP-CIDR은 CIDR 표기법으로 IPv4 대역을 매칭하고, IP-CIDR6은 IPv6에 대응합니다.

IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
IP-CIDR,10.0.0.0/8,DIRECT,no-resolve

이 두 규칙은 주로 로컬 네트워크 대역을 허용하여 라우터, NAS, LAN 기기 등에 대한 접근이 프록시를 거치지 않도록 하는 데 사용됩니다. 끝에 있는 no-resolve 파라미터가 중요한데, 이는 Clash에게 이 규칙에 대해 역방향 DNS 해석을 시도하지 말고 목적지 IP로 바로 판단하라고 알려주는 것으로, 도메인 규칙에 대한 불필요한 해석 부담을 줄이고 일부 경계 상황에서의 오판을 방지할 수 있습니다.

주의할 점은 IP 유형 규칙은 기본적으로 연결의 목적지 주소가 IP인 경우에만 적용된다는 것입니다. 연결이 도메인을 통해 시작되고 Clash가 아직 목적지 IP를 해석하지 못한 경우, 이런 규칙은 도메인 단계에서는 보통 매칭되지 않고 DNS 해석이 끝난 후에야 매칭에 참여할 수 있습니다. 이것이 많은 사람들이 도메인 규칙을 앞쪽에 배치하도록 권장하는 이유이기도 합니다.

GEOIP: 국가/지역 IP 데이터베이스 매칭

GEOIP는 내장되거나 외부에서 불러온 IP 지리 위치 데이터베이스를 기준으로 목적지 IP가 속한 국가나 지역을 판단합니다.

GEOIP,CN,DIRECT
GEOIP,JP,Proxy

첫 번째 규칙은 중국 본토로 판별되는 모든 IP를 직접 연결하게 하고, 두 번째는 일본으로 판별되는 IP를 Proxy라는 이름의 프록시 그룹으로 보냅니다. GEOIP 규칙이 참조하는 지리 데이터베이스에는 업데이트 주기가 있어서, 극히 일부 경계 IP 대역은 판별이 지연될 수 있습니다. 명백한 오판이 발견되면 구체적인 IP-CIDR 규칙으로 별도 수정할 수 있습니다.

GEOSITE: 도메인 분류 세트 매칭

GEOSITE(mihomo 등 일부 코어에서 지원)는 미리 분류된 도메인 규칙 세트를 사용하는 방식으로, 하나의 규칙만으로 스트리밍, 소셜 플랫폼 등 특정 서비스군에 속한 수많은 도메인을 한꺼번에 커버할 수 있어 수백~수천 줄의 DOMAIN-SUFFIX를 직접 작성할 필요가 없습니다.

GEOSITE,netflix,Proxy
GEOSITE,cn,DIRECT

이런 규칙을 사용하기 전에는 클라이언트가 해당 규칙 세트 파일을 이미 다운로드하고 로드했는지 확인해야 하며, 그렇지 않으면 분류 데이터를 찾지 못해 규칙이 적용되지 않습니다.

PROCESS-NAME과 MATCH

PROCESS-NAME은 연결을 시작한 프로세스 이름으로 매칭하며, 특정 애플리케이션에 개별 프록시 전략을 지정할 때 적합하고 데스크톱 환경에서 자주 쓰입니다. MATCH는 매칭 값이 없으며 "위 조건에 모두 해당하지 않을 때 통일적으로 이렇게 처리한다"를 의미하고, 항상 규칙 리스트의 마지막 줄로 사용됩니다.

PROCESS-NAME,Steam.exe,Proxy
MATCH,DIRECT

매칭 우선순위와 즉시 멈춤 원칙

위에서 설명한 여러 유형의 규칙을 같은 설정 안에 넣으면, 실제 동작을 결정하는 것은 그것들의 배열 순서이며 유형 자체의 "가중치"가 아닙니다. Clash는 어떤 규칙이 DOMAIN이라는 이유만으로 그보다 앞에 있는 DOMAIN-KEYWORD보다 자동으로 우선시하지 않습니다—순서는 오직 리스트 안의 물리적 위치로 결정됩니다.

실수하기 쉬운 예시를 보겠습니다:

DOMAIN-KEYWORD,youtube,Proxy
DOMAIN-SUFFIX,youtube.com,DIRECT

의도는 YouTube를 프록시로 보내되, 특정 서브도메인(예: 직접 연결로도 되는 정적 리소스 도메인)은 직접 연결하려는 것일 수 있습니다. 하지만 DOMAIN-KEYWORD 규칙이 앞에 있기 때문에, 도메인에 youtube 문자열이 포함되기만 하면 먼저 이 규칙에 매칭되어 프록시로 보내지고, 뒤에 있는 더 정밀한 DOMAIN-SUFFIX 규칙은 영원히 실행될 기회가 없습니다. 예외 규칙이 실제로 적용되게 하려면, 더 포괄적인 규칙보다 앞으로 옮겨야 합니다:

DOMAIN-SUFFIX,youtube.com,DIRECT
DOMAIN-KEYWORD,youtube,Proxy

조정한 후에는 정밀한 도메인 접미사 규칙이 먼저 검사되어 매칭되면 직접 연결하고 검사를 멈춥니다. 이 정밀 규칙에 해당하지 않는 나머지 youtube 키워드를 포함한 도메인만 계속 아래로 내려가 키워드 규칙에 도달해 프록시를 사용하게 됩니다.

커스텀 규칙 작성 시 정렬 방법

위 원칙을 바탕으로 실용적인 정렬 방법을 정리하면, 규칙 간 충돌로 인한 디버깅 비용을 크게 줄일 수 있습니다.

1. LAN 및 내부 네트워크 주소를 가장 앞에: IP-CIDR과 no-resolve를 함께 사용해 사설 네트워크 대역을 허용하고, 이후 어떤 규칙도 내부 네트워크 트래픽을 프록시로 잘못 보내지 않게 합니다.
2. 정밀 예외 규칙을 그다음에: "큰 분류는 프록시로, 개별 항목은 직접 연결" 또는 그 반대 상황이 필요할 때는, 구체적인 도메인을 대상으로 한 DOMAIN, DOMAIN-SUFFIX 예외 규칙을 해당 큰 분류 규칙보다 앞에 배치합니다.
3. 분류 규칙 세트는 중간에: GEOSITE나 일반적인 광고·개인정보 차단 규칙 세트는 예외 규칙 뒤, 포괄적인 키워드 규칙 앞에 배치해 분류 라이브러리가 대부분의 일반 도메인을 먼저 처리하게 합니다.
4. 포괄적인 키워드 매칭은 뒤쪽으로: DOMAIN-KEYWORD는 매칭 범위가 가장 넓어 오판이 발생하기 쉬우므로, 더 정밀한 규칙들이 모두 검사를 마친 뒤에야 차례가 오도록 배치해야 합니다.
5. 지역 및 IP 소속 규칙은 그다음: GEOIP는 보통 도메인 규칙이 커버하지 못하고 이미 구체적인 IP로 해석된 연결을 처리하는 데 쓰이며, 대개 도메인 규칙 뒤에 배치합니다.
6. MATCH 마지막 처리 규칙은 맨 마지막 줄에: 앞의 규칙에 매칭되지 않은 모든 연결은 최종적으로 이 규칙이 처리하며, 네트워크 정책에 따라 기본 프록시 그룹이나 직접 연결을 지정합니다.

이 순서대로 정리한 간단한 예시입니다:

IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
IP-CIDR,10.0.0.0/8,DIRECT,no-resolve
DOMAIN-SUFFIX,cn-cdn.example.com,DIRECT
GEOSITE,cn,DIRECT
GEOSITE,geolocation-!cn,Proxy
DOMAIN-KEYWORD,ads,REJECT
GEOIP,CN,DIRECT
MATCH,Proxy

이 예시의 로직은 매끄럽게 읽힙니다: 먼저 내부 네트워크를 처리하고, 명확히 직접 연결해야 할 특정 CDN 도메인을 처리한 다음, 분류 규칙 세트가 국내와 해외 대부분의 도메인을 각각 처리하게 하고, 키워드 규칙으로 흩어져 있는 광고 도메인을 차단하며, GEOIP가 앞의 도메인 규칙에서 처리하지 못했지만 이미 소속을 판별할 수 있는 IP를 처리하고, 마지막으로 MATCH가 남은 모든 연결을 프록시 그룹으로 보냅니다.

흔한 오류와 점검 방법

실제로 규칙을 디버깅할 때 가장 자주 마주치는 상황들을 정리해, 문제를 빠르게 찾을 수 있도록 돕습니다.

• 규칙이 전혀 적용되지 않음: 먼저 앞쪽에 더 범위가 넓은 규칙이 먼저 매칭되고 있는지 확인합니다. 해당 규칙을 리스트 맨 위로 임시로 옮겨 테스트해서 문법 자체에 문제가 없는지 확인한 뒤 정렬 조정을 고려하세요.
• MATCH 뒤에도 규칙이 있음: 이런 규칙들은 절대 실행되지 않으므로 MATCH 앞으로 옮겨야 합니다.
• IP 유형 규칙이 도메인 연결에서 적용되지 않음: 클라이언트의 DNS 및 해석 모드 설정을 확인하고, 연결이 매칭 단계에서 이미 목적지 IP를 얻었는지 확인합니다. 필요하면 대응하는 도메인 유형 규칙으로 대체하세요.
• 키워드 규칙이 너무 많은 도메인에 오탐함: 키워드를 더 완전한 문자열로 바꾸거나 DOMAIN-SUFFIX로 특정 접미사를 지정해 무관한 매칭을 줄이세요.
• 규칙 세트 로드 실패로 분류 규칙 전체가 적용되지 않음: 대응하는 규칙 세트 파일이 로컬에 정상적으로 다운로드되어 있는지, 설정에서 경로가 올바르게 참조되어 있는지 확인합니다. 네트워크 문제나 경로 오류는 이 규칙 전체를 무효화시킬 수 있습니다.

규칙을 수정한 후에는 새로 추가하거나 조정한 규칙 하나씩 소규모로 테스트해 매칭 결과가 예상과 맞는지 확인한 다음 다음 규칙을 추가하는 것을 권장합니다. 한 번에 너무 많은 것을 바꾸면 문제를 찾기 어려워집니다. 대부분의 클라이언트는 설정을 저장하면 자동으로 규칙을 다시 불러오는데, 예상한 효과가 보이지 않으면 수동으로 설정을 다시 불러와 캐시 문제를 배제해볼 수 있습니다.