규칙 실행 순서: 매칭되면 즉시 중단
규칙에서 rules는 위에서 아래로 순서대로 실행되는 목록이며, 각 줄의 대략적인 형식은 타입,매칭 내용,정책입니다. 클라이언트가 네트워크 요청을 받으면 첫 번째 규칙부터 하나씩 비교하며, 매칭되는 즉시 해당 정책을 적용하고 더 이상 아래로 매칭을 계속하지 않습니다. 이는 규칙 파일을 이해하는 데 가장 중요한 전제이며, "규칙을 분명히 제대로 썼는데 작동하지 않는다"는 문제의 대부분은 이 점을 간과했기 때문입니다.
예를 들어 규칙 파일에 다음 네 줄이 있다고 가정해 보겠습니다:
- DOMAIN-SUFFIX,example.com,DIRECT
- DOMAIN-SUFFIX,google.com,PROXY
- GEOIP,CN,DIRECT
- MATCH,PROXY
www.google.com에 대한 요청은 먼저 첫 번째 줄을 확인합니다——example.com과 매칭되지 않아 건너뜁니다. 그다음 두 번째 줄을 확인합니다——google.com의 서브도메인으로 매칭되어 적중하므로 즉시 PROXY 정책이 적용되고 멈춥니다. 그 뒤의 GEOIP와 MATCH 규칙은 전혀 실행되지 않습니다.
자주 쓰는 규칙 타입 전체 목록
가이드 페이지의 빠른 참조표에 있는 가장 흔한 6가지 외에도 Clash가 실제로 지원하는 규칙 타입은 훨씬 다양합니다. 용도별로 정리하면 다음과 같습니다:
- DOMAIN: 하나의 완전한 도메인을 정확히 매칭합니다(서브도메인은 포함하지 않음).
- DOMAIN-SUFFIX: 도메인과 그 모든 서브도메인을 매칭하는, 가장 흔히 쓰이는 방식입니다.
- DOMAIN-KEYWORD: 도메인에 지정한 키워드가 포함되어 있으면 매칭되어, 한 번에 여러 변형 도메인을 커버합니다.
- DOMAIN-REGEX: 정규 표현식으로 도메인을 매칭합니다. 규칙성은 있지만 하나씩 나열하기 어려운 도메인 처리에 적합합니다.
- IP-CIDR / IP-CIDR6: IPv4/IPv6 주소 범위로 매칭하며, 사내망 직접 연결에 자주 사용됩니다.
- GEOIP: 요청 대상 IP가 속한 국가/지역에 따라 분기합니다. 예:
GEOIP,CN,DIRECT. - SRC-IP-CIDR: 요청을 보낸 로컬 소스 IP로 매칭합니다. 다중 네트워크 카드나 LAN 내 여러 기기 환경에서 소스별로 분기하는 데 적합합니다.
- PROCESS-NAME: 요청을 보낸 프로세스 이름으로 매칭하며, 특정 앱에만 개별 정책을 지정할 수 있습니다(데스크톱에서 지원이 더 좋음).
- MATCH: 최종 규칙으로, 앞의 규칙에 매칭되지 않은 모든 트래픽에 매칭됩니다. 반드시 목록의 마지막 줄에 있어야 합니다.
Rule Provider: 직접 작성할 필요 없이 원격 소스를 따라 자동 업데이트
규칙을 하나씩 직접 작성하는 것은 명백히 비현실적입니다——중국 본토 사이트만 해도 수천 개의 도메인을 일일이 나열할 수는 없습니다. rule-providers의 역할은 커뮤니티나 서비스 제공업체가 관리하는 원격 호스팅 규칙 모음을 참조하는 것으로, 규칙 내용은 원격 소스를 따라 자동으로 업데이트되며, 규칙 목록에 한 줄만 추가하면 참조할 수 있습니다:
rule-providers:
reject:
type: http
behavior: domain
url: "https://example.com/rules/reject.txt"
path: ./ruleset/reject.yaml
interval: 86400
rules:
- RULE-SET,reject,REJECT
- GEOIP,CN,DIRECT
- MATCH,PROXY
대부분의 구독 제공업체는 이미 이 레이어를 설정해두었으므로 일반 사용자는 바로 사용할 수 있습니다. 기본 규칙 세트가 요구를 충족하지 못할 때(예를 들어 새로 발견된 광고 도메인을 추가로 차단하고 싶을 때)만 그 앞에 자신의 규칙을 삽입해야 합니다——순서가 앞선 규칙이 먼저 매칭되기 때문입니다.
초보자가 가장 자주 하는 3가지 규칙 실수
1. MATCH를 마지막이 아니라 중간에 씀
MATCH는 최종 규칙입니다. 목록 중간에 쓰면 그 뒤의 모든 규칙이 실행되지 않습니다. MATCH 자체가 모든 트래픽에 매칭되기 때문입니다. 항상 전체 rules 목록의 맨 마지막 줄에 두세요.
2. 커스텀 규칙을 Rule Provider 참조 뒤에 씀
직접 작성한 규칙이 구독에 내장된 규칙 세트보다 우선 적용되게 하려면 반드시 RULE-SET 참조 줄 앞에 두어야 합니다. 그렇지 않으면 구독 규칙 세트가 먼저 매칭되어 커스텀 규칙에는 영원히 차례가 오지 않습니다.
3. IP-CIDR에 no-resolve를 빠뜨림
사내망 IP 대역을 매칭할 때는 no-resolve 파라미터(예: IP-CIDR,192.168.0.0/16,DIRECT,no-resolve)를 추가하는 것이 좋습니다. 이는 도메인을 미리 해석하지 않는다는 의미로, 해석 동작으로 인한 불필요한 DNS 조회를 방지할 수 있습니다.
실전 예제: 특정 도메인에만 개별 정책 지정하기
특정 사이트를 구독 규칙 세트의 판단과 무관하게 항상 프록시를 경유하게 하고 싶다면, 규칙 목록 맨 위에 한 줄만 추가하면 됩니다:
rules:
- DOMAIN-SUFFIX,example.com,PROXY # 커스텀 규칙은 맨 앞에
- RULE-SET,reject,REJECT
- RULE-SET,direct,DIRECT
- RULE-SET,proxy,PROXY
- MATCH,PROXY
모든 RULE-SET 참조보다 앞에 있으므로 가장 먼저 매칭되며, 구독 규칙 세트에 "선점"되어 직접 연결이나 다른 정책으로 판정되는 일이 없습니다.
마지막으로
"순서대로 매칭하고, 매칭되면 즉시 중단"이라는 핵심 로직을 이해하면, 나머지 규칙 타입은 단지 어휘를 쌓아가는 것일 뿐입니다. 어떤 용어의 의미가 궁금하면 언제든 용어집에서 확인할 수 있습니다. 특정 사이트가 왜 열리지 않는지 알고 싶을 뿐이라면, 가이드의 문제 해결 방법이 규칙을 직접 작성하는 것보다 더 빠르게 문제를 해결할 수도 있습니다.