규칙 매칭의 기본 원칙: 위에서 아래로, 매칭되면 즉시 종료
Clash의 분류 엔진은 연결 요청을 처리할 때 rules 필드에 나열된 순서대로 하나씩 비교하며, 어떤 규칙의 조건이 요청과 일치하는 즉시 해당 규칙이 지정한 정책 그룹 또는 노드를 적용하고, 이후의 모든 규칙은 더 이상 판단에 참여하지 않습니다. 즉 규칙 목록의 배열 순서 자체가 우선순위이며 규칙 유형과는 무관합니다. 앞쪽에 적힌 DOMAIN-KEYWORD가 뒤쪽에 적힌 GEOIP를 덮어쓸 수도 있고, 반대의 경우도 마찬가지입니다.
이 메커니즘은 두 가지 직접적인 결과를 낳습니다. 첫째, 규칙 항목이 앞쪽에 있을수록 범위가 좁고 판단 기준이 명확한 상황(예: 특정 도메인의 직접 연결이나 차단)에 적합해야 하고, 뒤쪽으로 갈수록 범위가 넓은 최종 처리 규칙(예: 국가/지역별로 분류하는 GEOIP와 최종 MATCH)이어야 합니다. 둘째, 커스텀 규칙을 새로 추가할 때 삽입 위치에 따라 앞쪽의 기존 규칙에 먼저 차단되어 무효화될 수 있습니다. "규칙을 분명히 작성했는데 적용되지 않는" 문제의 원인은 대부분 문법 오류가 아니라 순서 문제입니다.
Clash Meta(mihomo)의 규칙 엔진 로직은 Clash와 동일하게 위에서 아래로, 매칭되면 즉시 종료하는 방식입니다. 차이점은 지원하는 규칙 유형이 더 풍부하다는 것(예: PROCESS-NAME, RULE-SET, 논리 규칙 AND/OR/NOT)이며, 배열 순서 처리 원칙 자체는 영향을 받지 않습니다.
자주 쓰는 규칙 유형과 작성 형식
규칙 항목의 일반 형식은 유형,매칭 내용,정책이며, 정책은 특정 노드 이름일 수도 있고 정책 그룹 이름(예: PROXY, DIRECT, REJECT)일 수도 있습니다. 다음은 실제 설정에서 가장 자주 쓰이는 몇 가지 유형입니다.
DOMAIN 계열: 도메인 매칭
DOMAIN: 완전한 도메인을 정확히 매칭하며, 해당 도메인 자체만 매칭되고 서브도메인은 포함하지 않습니다.DOMAIN-SUFFIX: 도메인 접미사를 매칭하며 모든 서브도메인을 자동으로 포함합니다. 가장 많이 쓰이는 도메인 규칙입니다.DOMAIN-KEYWORD: 도메인에 포함된 키워드를 매칭합니다. 범위가 가장 넓지만 무관한 도메인을 잘못 매칭할 위험도 가장 큽니다.
DOMAIN,api.example.com,DIRECT
DOMAIN-SUFFIX,example.com,PROXY
DOMAIN-KEYWORD,analytics,REJECT
위 세 줄이 함께 있을 때, api.example.com은 첫 번째와 두 번째 규칙 조건을 동시에 만족하므로 첫 번째 규칙이 앞에 있으면 api.example.com은 DIRECT로 처리되고, example.com의 다른 서브도메인은 두 번째 규칙의 PROXY로 처리됩니다. 이것이 "범위가 좁은 규칙을 앞에 배치한다"는 원칙의 대표적인 예시입니다.
IP-CIDR와 IP-CIDR6: 네트워크 대역별 매칭
목적지 주소가 도메인이 아니라 이미 알고 있는 IP 대역(내부망 주소, CDN 고정 오리진, 이미 알려진 서비스 제공사 대역 등)인 경우 IP-CIDR을 사용합니다. 이 규칙은 기본적으로 연결의 목적지 IP에만 적용되며, 서버에서 해석된 모든 A/AAAA 레코드를 매칭에 포함시켜야 한다면 일부 코어에서 no-resolve 옵션으로 추가 해석 오버헤드를 건너뛸 수 있습니다.
IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
IP-CIDR,10.0.0.0/8,DIRECT,no-resolve
IP-CIDR6,2001:db8::/32,DIRECT,no-resolve
no-resolve를 붙이지 않으면 Clash는 도메인을 먼저 DNS로 해석한 뒤 IP 대역과 비교하며, 이는 매칭마다 해석 오버헤드를 추가합니다. 내부망 주소 대역처럼 해석이 명백히 불필요한 규칙에는 항상 no-resolve를 붙이는 것이 좋습니다.
GEOIP: 국가/지역별 분류
GEOIP는 목적지 IP가 속한 국가/지역 코드에 따라 판단하며, "국내 IP는 직접 연결, 해외 IP는 프록시 경유" 같은 대략적인 분류에 자주 쓰입니다. 판단 기준이 국가/지역 전체의 IP 데이터베이스이므로 매칭 범위가 가장 넓어 보통 규칙 목록의 끝부분에 배치합니다.
GEOIP,CN,DIRECT
GEOIP,PRIVATE,DIRECT
RULE-SET과 규칙 세트: 일괄 관리되는 분류 조각
Clash Meta(mihomo)는 rule-providers 필드로 외부 규칙 세트를 불러올 수 있으며, 설정에서 RULE-SET으로 참조합니다. 특정 카테고리의 사이트(스트리밍, 광고 도메인 목록 등)를 한 곳에서 관리하고 주기적으로 업데이트할 수 있어 하나하나 직접 작성할 필요가 없습니다.
rule-providers:
ads-reject:
type: http
behavior: domain
url: "https://example.com/rules/ads.txt"
path: ./rule-providers/ads-reject.yaml
interval: 86400
rules:
- RULE-SET,ads-reject,REJECT
MATCH: 최종 처리 규칙
MATCH는 앞선 규칙에서 처리되지 않은 모든 연결을 매칭하며, 반드시 규칙 목록의 맨 마지막 줄에 두어 전체 분류표의 최종 출구 역할을 합니다. 이후 손쉽게 전환할 수 있도록 보통 고정 노드가 아니라 정책 그룹을 지정합니다.
MATCH,PROXY
규칙 배열 순서 가이드: 규칙 충돌을 피하는 방법
위의 규칙 유형들을 하나의 설정에 함께 사용할 때는 "매칭 범위가 작은 것에서 큰 것 순"으로 위에서 아래로 배열하는 것이 좋으며, 대략 네 계층으로 나눌 수 있습니다.
- 정확 예외 계층:
DOMAIN과 내부망IP-CIDR로, 개별적으로 정책을 지정해야 하는 구체적인 주소를 처리합니다. 예를 들어 내부망 관리 페이지는 직접 연결, 이미 알려진 악성 도메인은 즉시 차단. - 도메인 분류 계층:
DOMAIN-SUFFIX를 위주로 서비스 그룹(소셜, 동영상, 개발 도구 등)별로 일괄 정책 그룹에 분류합니다. - 규칙 세트 및 키워드 계층:
RULE-SET,DOMAIN-KEYWORD는 매칭 범위가 넓으므로 도메인 분류 계층 뒤에 배치해, 원래 정확히 매칭되어야 할 도메인을 키워드 규칙이 먼저 가로채는 것을 방지합니다. - 지역 및 최종 처리 계층:
GEOIP로 남은 국가/지역 분류를 처리하고, 마지막 줄에MATCH로 마무리합니다.
아래 표는 상태 배지로 몇 가지 대표적인 규칙이 이 배열 순서에서 보통 어떤 출구 방향으로 이어지는지 표시하여 설정이 예상과 일치하는지 확인하기 쉽게 정리했습니다.
- DOMAIN-SUFFIX,cn
- DIRECT
- DOMAIN-SUFFIX,googlevideo.com
- PROXY
- DOMAIN-KEYWORD,ad
- REJECT
- GEOIP,CN
- DIRECT
- MATCH
- PROXY
새로 추가한 규칙이 적용되지 않는다면, 그 위쪽에 이미 같은 대상을 먼저 매칭하는 더 넓은 범위의 규칙이 있는지 먼저 확인하세요. 문법을 반복해서 검토하는 것보다 순서 문제를 확인하는 것이 훨씬 빠른 해결법입니다.
실전 예시: 커스텀 분류 조각과 배치 위치
"특정 개발 환경 도메인만 직접 연결로 처리하면서 기존 광고 차단 및 지역 분류는 유지"하는 경우를 예로 들면, 새 규칙은 광고 차단 규칙 앞, 도메인 분류 계층 뒤에 삽입해야 합니다. 이 예외 규칙의 매칭 범위가 DOMAIN-KEYWORD보다 정확하므로 먼저 판단되어야 하기 때문입니다.
rules:
# 정확 예외 계층
- DOMAIN,192-168-1-1.local,DIRECT
- IP-CIDR,172.16.0.0/12,DIRECT,no-resolve
# 신규: 개발 환경 도메인 직접 연결 (키워드 규칙 앞에 삽입)
- DOMAIN-SUFFIX,dev.internal-project.com,DIRECT
# 도메인 분류 계층
- DOMAIN-SUFFIX,github.com,PROXY
- DOMAIN-SUFFIX,googlevideo.com,PROXY
# 규칙 세트 및 키워드 계층
- RULE-SET,ads-reject,REJECT
- DOMAIN-KEYWORD,analytics,REJECT
# 지역 및 최종 처리 계층
- GEOIP,CN,DIRECT
- MATCH,PROXY
만약 이 신규 규칙을 MATCH 근처에 잘못 배치하면, 이미 앞쪽에 범위가 더 넓은 키워드 규칙이나 지역 규칙이 있으므로 새 규칙은 거의 실행되지 못하며, "설정은 저장됐지만 트래픽 경로는 그대로"인 현상으로 나타납니다.
또 다른 흔한 요구는 특정 IP 대역을 직접 연결이 아니라 차단으로 처리하는 것입니다. 예를 들어 이미 알려진 탐지 서버 목록을 차단하는 경우입니다.
rules:
- IP-CIDR,203.0.113.0/24,REJECT,no-resolve
- GEOIP,CN,DIRECT
- MATCH,PROXY
이 IP-CIDR,REJECT는 반드시 GEOIP,CN,DIRECT보다 앞에 두어야 합니다. 그렇지 않으면 해당 대역이 국내 IP로 판정될 경우 GEOIP 규칙에 먼저 매칭되어 직접 연결로 처리되며, 차단 규칙은 영원히 실행되지 않습니다.
규칙이 적용되지 않을 때의 점검 순서
커스텀 규칙이 예상대로 적용되지 않을 때는 문법 오류를 먼저 의심하기보다 다음 순서로 점검하는 것이 좋습니다.
- 배열 위치 확인: 새 규칙 위쪽에 범위가 더 넓으면서 더 먼저 매칭되는 규칙이 없는지 확인합니다. 가장 흔한 원인입니다.
- 규칙 유형과 내용 형식 확인:
DOMAIN-SUFFIX는 와일드카드 접두사가 필요 없습니다(*.example.com처럼 쓰지 않음). 순수 도메인 접미사 형태인example.com으로 작성해야 합니다. - 정책 그룹 이름 존재 여부 확인: 규칙 끝의 정책 이름은
proxy-groups에 정의된 그룹 이름이나 특정 노드 이름과 정확히 일치해야 합니다. 오타가 있으면 코어가 설정을 로드하는 단계에서 오류를 내거나 해당 줄을 무시할 수 있습니다. - DNS 계층의 분류 여부 확인:
fake-ip나 커스텀nameserver-policy가 켜져 있다면, 도메인이 규칙 엔진에 도달하기 전에 이미 DNS 분류에 영향을 받았을 수 있습니다.rules만 보지 말고 DNS 설정 섹션도 함께 확인해야 합니다.
DOMAIN-KEYWORD를 DOMAIN-SUFFIX의 대체품처럼 남용하지 마세요. 키워드 규칙은 도메인 구조를 구분하지 않으므로 같은 문자열을 포함하는 무관한 도메인을 잘못 매칭하기 쉽습니다(예: 키워드 ad는 adobe.com도 매칭됩니다). 이상한 연결을 점검할 때는 이런 광범위한 규칙이 너무 앞쪽에 배치되어 있는지부터 확인해야 합니다.