Clash 사용자 규칙 문법과 우선순위: DOMAIN·IP-CIDR·MATCH

규칙은 위에서 아래로 확인하며, 처음 일치한 규칙이 적용됩니다

Clash 클라이언트가 규칙 모드로 작동하면 코어는 설정 파일의 rules 목록을 순서대로 확인합니다. 조건에 맞는 규칙을 처음 만나면 해당 규칙의 정책에 연결을 넘기고, 더 정확한 규칙을 찾지 않습니다. 따라서 규칙을 적은 순서가 곧 우선순위이며, DOMAIN이 IP-CIDR보다 항상 우선하는 식의 공통 정렬 기준은 없습니다.

아래 예시는 현재 설정에 ‘프록시 선택’이라는 프록시 그룹이 이미 있다고 가정합니다. 이 이름은 proxy-groups의 name과 정확히 일치해야 합니다. 예시 도메인 example.com은 문법을 설명하기 위한 것으로, 해당 사이트에 특정 정책을 적용하라는 뜻은 아닙니다.

mode: rule

rules:
  - DOMAIN,api.example.com,프록시 선택
  - DOMAIN-SUFFIX,example.com,DIRECT
  - MATCH,프록시 선택

api.example.com에 접속하면 첫 번째 규칙이 적용되어 ‘프록시 선택’으로 연결됩니다.
www.example.com에 접속하면 첫 번째 규칙은 일치하지 않고 두 번째 규칙이 적용되어 DIRECT로 연결됩니다.
앞의 두 규칙에 일치하지 않는 다른 대상은 마지막 MATCH 규칙이 처리합니다.

두 번째 규칙을 첫 번째 규칙보다 앞에 두면 api.example.com도 접미사 규칙에 먼저 일치해 직접 연결됩니다. 뒤에 적힌 정확한 도메인 규칙이 올바르더라도 더는 확인하지 않습니다. 규칙을 관리할 때는 먼저 예외를 정한 뒤, 더 넓은 범위를 다루는 규칙을 배치하세요.

DOMAIN 계열: 도메인, 접미사, 키워드 매칭

도메인 규칙은 일반적으로 ‘규칙 유형, 매칭 대상, 정책’의 세 필드로 작성합니다. 여기서 도메인은 전체 URL이 아닙니다. https://, 포트, 경로, 쿼리 매개변수를 붙이지 마세요. https://api.example.com/v1/status를 매칭하려면 전체 주소가 아니라 api.example.com을 적습니다.

자주 쓰는 도메인 규칙 세 가지의 매칭 범위
유형	예시	매칭 결과
DOMAIN	`DOMAIN,example.com,DIRECT`	example.com만 매칭하며 www.example.com은 포함하지 않습니다.
DOMAIN-SUFFIX	`DOMAIN-SUFFIX,example.com,DIRECT`	example.com과 하위 도메인을 매칭하지만 notexample.com은 매칭하지 않습니다.
DOMAIN-KEYWORD	`DOMAIN-KEYWORD,example,프록시 선택`	도메인에 example 문자열이 포함된 대상을 매칭합니다. 접미사 규칙보다 범위가 넓습니다.

예외 도메인은 접미사 규칙보다 앞에 배치

rules:
  - DOMAIN,download.example.com,프록시 선택
  - DOMAIN-SUFFIX,example.com,DIRECT
  - DOMAIN-KEYWORD,telemetry,REJECT
  - MATCH,프록시 선택

이 순서에서는 다운로드 도메인을 별도 경로로 먼저 처리한 다음 전체 도메인 접미사를 적용합니다. 키워드 규칙은 접미사 규칙 뒤에 있으므로 telemetry.example.com에 키워드가 포함되어도 example.com 접미사 규칙이 먼저 적용되어 직접 연결됩니다. 차단하려면 해당 도메인의 정확한 거부 규칙을 앞에 두세요. REJECT가 자동으로 최우선 적용되는 것은 아닙니다.

키워드 규칙은 범위를 신중히 설정하세요

DOMAIN-KEYWORD,ad,REJECT는 정상적인 여러 도메인에 포함된 짧은 문자열까지 매칭할 수 있어 오탐 위험이 큽니다. 전체 도메인을 알고 있다면 DOMAIN을, 하위 도메인 묶음을 처리하려면 DOMAIN-SUFFIX를 우선 사용하세요. 키워드 규칙은 일관된 이름 패턴이 실제로 존재하고 매칭 범위를 확인한 경우에 적합합니다.

도메인 규칙이 적용되려면 연결 메타데이터에 사용할 수 있는 도메인이 있어야 합니다. 앱이 IP에 직접 연결하거나 DNS 경로가 다르거나 도메인 스니핑이 작동하지 않으면 연결 기록에 대상 주소만 표시될 수 있습니다. 브라우저 주소창에 도메인이 보인다는 이유만으로 코어가 해당 DOMAIN 규칙을 반드시 적용한다고 단정할 수는 없습니다.

IP-CIDR와 no-resolve: DNS 조회 제어

IP-CIDR은 대상 IPv4 주소가 속한 네트워크 대역을 매칭하며, IPv6에는 보통 IP-CIDR6을 사용합니다. CIDR 뒤의 숫자는 네트워크 프리픽스 길이입니다. IPv4의 /32는 단일 주소를 뜻하고, 192.168.1.0/24는 192.168.1.0부터 192.168.1.255까지의 주소 범위를 뜻합니다.

rules:
  - IP-CIDR,192.168.1.10/32,DIRECT,no-resolve
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - IP-CIDR,10.0.0.0/8,DIRECT,no-resolve
  - IP-CIDR,172.16.0.0/12,DIRECT,no-resolve
  - IP-CIDR6,fc00::/7,DIRECT,no-resolve
  - MATCH,프록시 선택

no-resolve는 이 IP 규칙을 확인하기 위해 아직 조회되지 않은 대상 도메인을 새로 조회하지 않도록 합니다. ‘DNS를 끄는 옵션’도 아니고 ‘모든 도메인이 이 규칙을 통과하지 못하게 하는 옵션’도 아닙니다. 대상 IP가 이미 있으면 코어가 이를 바탕으로 네트워크 대역을 매칭할 수 있습니다. 사용할 수 있는 대상 IP가 없다면 매칭을 위해 DNS 조회를 새로 실행하지 않습니다.

두 연결 경로의 차이

앱이 192.168.1.10:443에 직접 연결하는 경우: 대상 IP를 알고 있으므로 단일 주소 규칙에 일치할 수 있으며, no-resolve도 이 매칭을 막지 않습니다.
앱이 nas.example.com을 요청하는 경우: 코어에 사용할 수 있는 실제 대상 IP가 아직 없다면 no-resolve가 설정된 네트워크 대역 규칙은 도메인을 새로 조회하지 않습니다. 따라서 연결이 뒤에 있는 다른 규칙으로 넘어갈 수 있습니다.

이 NAS 도메인을 반드시 직접 연결해야 한다면, 실행 여부가 불확실한 IP 판별에 의존하지 말고 보통 DOMAIN,nas.example.com,DIRECT를 추가하는 편이 좋습니다. DNS 조회 결과에 따라 도메인을 분기해야 한다면 DNS 설정을 함께 확인하고 해당 규칙의 no-resolve를 제거할지 결정하세요.

fake-ip 환경에서 클라이언트가 보는 합성 주소도 웹사이트의 실제 서버 주소로 간주할 수 없습니다. 연결 상세 정보, 도메인 매핑, DNS 로그를 함께 확인하세요. 특정 사이트 문제를 해결하려고 fake-ip 주소 풀 전체를 직접 연결 규칙에 넣지 마세요.

정책 대상과 MATCH: 연결 경로 및 기본 규칙

규칙 마지막 필드는 정책을 지정하며, 반드시 개별 프록시 노드를 뜻하지는 않습니다. DIRECT는 직접 연결, REJECT는 연결 거부를 의미합니다. 사용자 지정 이름은 정의된 프록시나 프록시 그룹을 가리킬 수 있습니다. 규칙이 ‘프록시 선택’에 일치하면 실제 연결 경로는 그룹에서 현재 선택된 항목에 따라 결정됩니다.

따라서 연결 상세 정보에 ‘프록시 그룹 일치’라고 표시되더라도 실제로 직접 연결될 수 있으며, 이것만으로 규칙이 작동하지 않는다고 볼 수는 없습니다. 그룹 안에서 DIRECT를 선택했는지, DIRECT가 포함된 다른 그룹을 거치는지, 자동 선택 그룹이 현재 어떤 항목을 선택했는지 확인하세요. 규칙 매칭과 최종 연결 경로는 서로 이어지지만 별개의 판단 단계입니다.

rules:
  - DOMAIN,blocked.example.com,REJECT
  - DOMAIN,intranet.example.com,DIRECT
  - DOMAIN-SUFFIX,example.com,프록시 선택
  - MATCH,프록시 선택

MATCH는 기본 규칙 위치에 두세요

MATCH에는 도메인이나 네트워크 대역 매개변수가 없습니다. 문법은 MATCH,정책뿐입니다. 이 규칙에 도달한 모든 연결을 무조건 매칭합니다. 규칙 목록 첫 줄에 두면 뒤의 모든 규칙은 실행되지 않으며, 두 규칙 세트 사이에 두면 두 번째 규칙 세트도 확인하지 않습니다.

분류되지 않은 트래픽을 프록시 그룹으로 보내려면 MATCH,프록시 선택을 사용하세요.
분류되지 않은 트래픽을 직접 연결하려면 MATCH,DIRECT를 사용하세요.
명시적으로 허용한 연결만 통과시키려면 MATCH,REJECT를 사용할 수 있습니다. 단, 필요한 의존성을 먼저 빠짐없이 허용해야 합니다. 그렇지 않으면 로그인, 업데이트, 리소스 로딩까지 함께 차단될 수 있습니다.

기본 정책을 바꾸면 아직 분류되지 않은 많은 트래픽에 영향을 줍니다. 수정 전에 현재 설정을 저장하고, 수정 후에는 웹사이트 첫 화면만 열어 보지 말고 전체 사용 흐름을 점검하세요.

mihomo 규칙 세트: 배치 위치가 우선순위를 결정합니다

mihomo에서는 rule-providers로 규칙 세트를 관리하고 RULE-SET으로 참조할 수 있습니다. 규칙 세트는 기본 목록과 별도로 우선순위를 부여받는 체계가 아닙니다. RULE-SET이 놓인 줄에서 다른 규칙과 함께 매칭됩니다. 앞에 있는 일반 규칙이 먼저 적용되면 뒤의 규칙 세트는 실행되지 않습니다.

다음은 mihomo의 로컬 파일 규칙 세트 예시입니다. 기존 설정과 병합해야 하며, 기존 노드와 ‘프록시 선택’ 그룹은 유지하세요. ./rules/work.yaml 파일이 코어의 설정 작업 디렉터리를 기준으로 실제 존재해야 합니다. 선언만 추가하고 파일 생성을 빠뜨리지 마세요.

rule-providers:
  work:
    type: file
    behavior: classical
    format: yaml
    path: ./rules/work.yaml

rules:
  - DOMAIN,login.example.com,DIRECT
  - RULE-SET,work,프록시 선택
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - MATCH,프록시 선택

해당하는 work.yaml의 내용은 다음과 같습니다. 정책은 RULE-SET을 참조하는 곳에서 지정하므로 classical 세트의 각 항목에 ‘프록시 선택’을 따로 붙이지 않습니다.

payload:
  - DOMAIN-SUFFIX,example.com
  - IP-CIDR,203.0.113.0/24

203.0.113.0/24는 문서 예시용 네트워크 대역이며 실제 서비스에 사용할 대상 주소가 아닙니다. 실제 설정에는 서비스에서 제공한 네트워크 대역을 사용하세요. 여기서는 login.example.com이 기본 목록의 첫 번째 규칙에 먼저 일치하므로 work 세트의 도메인 접미사에 포함되더라도 직접 연결됩니다.

behavior와 파일 내용이 일치해야 합니다

classical: 항목에 DOMAIN-SUFFIX, IP-CIDR 등의 규칙 유형이 포함됩니다. 여러 유형을 섞은 규칙에 적합합니다.
domain: 항목은 도메인 매칭 대상입니다. 규칙 유형 접두사가 붙은 classical 항목을 그대로 복사하면 안 됩니다.
ipcidr: 항목은 IP 네트워크 대역이며 도메인 목록이 아닙니다.

이 설정은 mihomo 문법에 맞춰 작성했습니다. Clash 코어마다 규칙 세트 형식과 확장 유형 지원 여부가 다르므로 클라이언트에 표시된 코어 정보와 설정 검사 결과를 기준으로 판단하세요. 파일 이름이 같아도 구형 코어가 모든 필드를 읽을 수 있는 것은 아닙니다.

사용자 규칙 정렬과 구독 설정 덮어쓰기

규칙이 많아지면 목록 끝에 계속 추가하기보다 ‘명확한 예외 → 분류 규칙 → 기본 정책’ 순서로 관리하세요. 다음은 검토하기 쉬운 정렬 방식입니다. 차단 규칙을 맨 앞에 둘지는 허용할 예외가 무엇인지에 따라 결정해야 합니다.

다른 분류보다 먼저 적용해야 하는 정확한 규칙. 예를 들어 특정 로그인 도메인을 직접 연결하거나 특정 추적 도메인을 차단하는 규칙입니다. 규칙이 충돌하면 어느 쪽을 먼저 적용할지 명확히 정하세요.
로컬 서비스와 LAN 대상. 도메인을 알고 있다면 도메인 규칙을, 네트워크 대역을 알고 있다면 IP 규칙을 사용하고 DNS 조회가 필요한지 확인하세요.
서비스별 분류와 규칙 세트. 업무, 미디어 등 용도에 따라 나누세요. 범위가 겹치는 세트는 먼저 적용할 분류를 앞에 배치합니다.
범위가 넓은 도메인·지역·IP 분류. 넓은 범위를 다루는 세트는 뒤에 있는 예외 규칙을 가릴 수 있으므로 변경 후 일부 대상을 표본으로 확인하세요.
마지막 줄의 MATCH. 분류되지 않은 연결의 처리 방식을 정하고, 그 뒤에는 실행이 필요한 규칙을 두지 마세요.

구독을 업데이트하면 기본 설정이 다시 생성될 수 있습니다. 구독으로 생성된 YAML을 직접 수정하면 현재는 적용되더라도 다음 업데이트 때 변경 내용이 사라질 수 있습니다. 클라이언트에 덮어쓰기, 병합 또는 사용자 규칙 유지 기능이 있다면 해당 기능을 사용하세요. 메뉴 이름은 클라이언트마다 다르므로 특정 UI의 메뉴 경로를 모든 Clash 클라이언트에 공통으로 적용할 수는 없습니다.

특히 규칙을 ‘뒤에 추가’하는 것과 ‘앞에 배치’하는 것의 차이를 확인하세요. 사용자 규칙이 구독 설정의 MATCH 뒤에 추가되면 내용은 있어도 절대 적용되지 않습니다. 편집기의 일부 설정만 보지 말고 코어가 최종적으로 불러온 규칙 목록에서 병합 후 위치를 확인하세요.

규칙이 적용되지 않을 때: 연결 기록으로 하나씩 확인

문제를 해결할 때는 한 번에 조건 하나만 바꾸세요. 먼저 api.example.com처럼 대상을 명확히 정하고 예상 정책을 기록한 다음, 새 연결에 어떤 규칙이 적용됐고 최종 경로가 어디인지 확인합니다. 브라우저가 기존 장기 연결을 재사용할 수 있으므로 페이지를 새로고침해도 항상 새 연결이 만들어지는 것은 아닙니다.

트래픽이 코어를 통과하는지 확인하세요. 시스템 프록시는 시스템 프록시 설정을 따르는 앱에만 적용됩니다. 코어를 거치지 않는 연결은 rules의 영향을 받지 않습니다. TUN을 사용하는 경우에도 라우팅이 대상 트래픽을 실제로 포함해야 합니다.
실행 중인 설정과 모드를 확인하세요. 수정한 설정이 실제로 불러와졌는지, 작동 모드가 규칙인지, 구독 전환 후 다른 설정이 로드되지는 않았는지 확인하세요.
구문 오류를 확인하세요. YAML은 탭이 아니라 공백으로 들여쓰기해야 합니다. 규칙 유형 철자, 쉼표 개수, 정책 이름을 확인하세요. 최상위 rules 키가 중복되었다면 하나의 목록으로 합쳐야 합니다.
앞에서 먼저 적용된 규칙을 확인하세요. 대상 범위를 포함하는 DOMAIN-SUFFIX, 키워드 규칙, RULE-SET 또는 앞에 배치된 MATCH를 찾아보세요. 예상과 다른 규칙이 로그에 표시됐다면 설정에서 추측하는 것보다 실제 적용 기록을 우선하세요.
대상 메타데이터를 확인하세요. 기록된 대상이 도메인인지 IP인지, IPv6인지, 이미 DNS 조회 결과가 있는지 확인합니다. IPv4 네트워크 대역 규칙만으로 IPv6 대상을 매칭할 수는 없습니다.
새 테스트 연결을 만드세요. 연결을 끊어도 되는 경우 해당 연결을 종료하거나 테스트 앱을 완전히 닫았다가 다시 실행한 뒤 새 규칙 매칭 기록을 확인하세요.

관리하기 쉬운 규칙 설정은 세 가지 질문에 답할 수 있어야 합니다. 대상이 왜 이 규칙에 일치하는가, 이 규칙은 연결을 어떤 정책에 넘기는가, 정책은 최종적으로 어떤 연결 경로를 사용하는가. 이 세 단계를 각각 확인하면 DOMAIN, IP-CIDR, 규칙 세트와 MATCH의 관계를 실제 연결에 적용해 이해할 수 있습니다. 설정 텍스트의 겉보기 순서만으로 판단할 필요가 없습니다.