Clash 규칙 설정 가이드: DOMAIN-SUFFIX·IP-CIDR 매칭 순서와 MATCH 기본 규칙

규칙이 적용되지 않는다면 먼저 규칙 모드인지 확인하세요

웹사이트에 직접 연결 규칙을 추가했는데도 프록시를 거치거나, 특정 IP 대역을 프록시로 설정했는데 접속 결과가 바뀌지 않을 수 있습니다. 이런 문제는 문법 오류 때문만은 아닙니다. 먼저 앱 트래픽이 Clash를 통과하는지, 커널이 규칙 모드인지 확인한 다음 규칙 내용을 점검하세요.

클라이언트의 ‘프록시 모드’에서 ‘규칙(Rule)’을 선택하세요. 클라이언트에 따라 ‘규칙 모드’로 표시될 수도 있습니다. 분할 라우팅 규칙을 확인할 때는 ‘전역(Global)’이나 ‘직접 연결(Direct)’ 모드를 사용하지 마세요.
‘연결(Connections)’ 페이지를 열고 대상 웹사이트에 다시 접속하세요. 새 연결이 보이지 않으면 시스템 프록시, 앱 자체의 프록시 설정 또는 TUN이 트래픽을 처리하는 범위를 먼저 확인하세요.
현재 선택된 설정이 실제로 수정한 파일인지 확인하세요. 파일을 저장한 뒤에는 클라이언트에서 설정을 다시 불러와야 합니다. 저장만으로 실행 중인 커널의 설정이 갱신되지 않을 수 있습니다.
대상 앱의 기존 연결을 끊고 다시 테스트하세요. 규칙은 주로 연결이 만들어질 때 출구를 선택하므로, 이미 연결된 장시간 연결은 파일을 수정해도 자동으로 경로가 바뀌지 않습니다.

규칙의 구성: 유형, 매칭 값, 출구 정책

일반적인 규칙은 YAML의 rules: 목록에 한 줄씩 작성하며, 각 줄은 하이픈으로 시작합니다. 도메인 규칙은 보통 규칙 유형, 매칭 값, 출구 정책의 세 필드로 구성됩니다. MATCH에는 매칭 값이 필요하지 않습니다. no-resolve를 지원하는 IP 규칙은 네 번째 필드를 추가할 수도 있습니다.

rules:
  - DOMAIN,login.example.com,DIRECT
  - DOMAIN-SUFFIX,example.org,REJECT
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - MATCH,DIRECT

이 설정 예시는 구조를 살펴보기 쉽도록 내장 정책만 사용합니다. DIRECT는 직접 연결, REJECT는 연결 거부를 뜻합니다. 실제로 프록시를 사용하려면 마지막 필드에 설정에 이미 등록된 프록시 노드 이름이나 정책 그룹 이름을 입력하세요. PROXY는 모든 설정에 공통으로 포함되는 내장 정책이 아닙니다. 같은 이름의 노드나 정책 그룹이 없으면 그대로 복사했을 때 설정을 불러오지 못할 수 있습니다.

영문 반각 쉼표를 사용하세요. 전각 쉼표를 쓰면 안 됩니다.
YAML 들여쓰기에는 공백을 사용하고 Tab은 쓰지 마세요. 같은 목록의 규칙은 들여쓰기 수준을 동일하게 맞추세요.
정책 이름은 대소문자, 공백, 기호까지 정의된 이름과 정확히 일치해야 합니다.
기존 설정을 수정할 때는 항목을 원래의 rules: 아래에 합치세요. 같은 최상위 키를 다시 추가하지 마세요.

도메인 규칙: DOMAIN, DOMAIN-SUFFIX, DOMAIN-KEYWORD

유형	예시	매칭 범위
`DOMAIN`	`DOMAIN,example.com,DIRECT`	example.com만 매칭하며 www.example.com은 포함하지 않습니다.
`DOMAIN-SUFFIX`	`DOMAIN-SUFFIX,example.com,DIRECT`	example.com 자체와 www.example.com, api.example.com 등 하위 도메인을 매칭합니다.
`DOMAIN-KEYWORD`	`DOMAIN-KEYWORD,example,REJECT`	도메인에 example 문자열이 포함된 연결을 매칭합니다. 접미사 규칙보다 범위가 넓습니다.

접미사는 도메인 경계를 기준으로 매칭하며, 임의의 문자열 끝을 기준으로 하지 않습니다

DOMAIN-SUFFIX,example.com,DIRECT는 a.example.com과 일치하지만 notexample.com이나 example.com.other.org와는 일치하지 않습니다. 보통 *.example.com이라고 쓸 필요가 없습니다. 접미사 규칙에는 이미 하위 도메인 매칭이 포함됩니다.

규칙 값에는 도메인만 입력하세요. https://, 포트, 경로는 넣지 않습니다. https://example.com:8443/account에 접속하더라도 도메인 필드는 example.com입니다. 일반 도메인 규칙으로는 같은 사이트의 /account와 /video 경로를 구분할 수 없습니다.

정확한 예외 규칙을 넓은 범위의 규칙보다 먼저 배치하세요

rules:
  - DOMAIN,login.example.com,DIRECT
  - DOMAIN-SUFFIX,example.com,REJECT
  - MATCH,DIRECT

이 예시에서는 login.example.com은 직접 연결하고, example.com에 속하는 나머지 도메인은 거부합니다. 앞의 두 줄 순서를 바꾸면 로그인 도메인이 접미사 규칙에 먼저 걸려 정확한 규칙은 적용되지 않습니다. 커널은 어느 규칙이 더 정확한지 비교하지 않으며, 일치한 뒤 더 나은 규칙을 찾지도 않습니다.

DOMAIN-KEYWORD는 매칭 범위를 명확히 알고 있을 때 사용하세요. 흔한 짧은 단어 하나로 서비스 전체의 경로를 지정하는 용도에는 적합하지 않습니다. 키워드가 짧을수록 우연히 같은 문자열이 포함된 다른 도메인까지 잘못 매칭될 가능성이 커집니다.

IP-CIDR과 GEOIP: IP 대역과 지역 데이터베이스는 다릅니다

IP-CIDR은 대상 IPv4 주소가 지정된 네트워크 대역에 속하는지 판단합니다. 192.168.0.0/16은 192.168.0.0부터 192.168.255.255까지 포함하고, /32는 IPv4 주소 하나를 나타냅니다. IPv6 대역에는 IP-CIDR6을 사용하며, IPv6 주소 하나는 /128로 지정할 수 있습니다.

rules:
  - 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
  - GEOIP,CN,DIRECT
  - MATCH,프록시 선택

GEOIP,CN,DIRECT는 현재 로드된 IP 지역 데이터베이스를 기준으로 대상 주소가 CN에 속하는지 판단한 뒤 직접 연결합니다. ‘중국어 웹사이트는 모두 직접 연결’하는 규칙이 아니며, 웹페이지 언어나 도메인 접미사로 판단하지도 않습니다. CDN의 IP 할당, 데이터베이스 갱신, IPv4와 IPv6 응답 차이로 같은 웹사이트도 네트워크에 따라 다르게 매칭될 수 있습니다.

특정 서비스를 항상 같은 정책으로 처리해야 한다면 범위가 명확한 도메인 규칙을 우선 사용하세요. 지역 규칙은 뒤쪽에 보조 규칙으로 두는 편이 관리하기 쉽습니다. 필요한 지역 데이터베이스를 불러오지 못했다면 규칙 순서를 바꿔 오류를 숨기지 말고 클라이언트 로그에서 리소스 로드 문제를 먼저 해결하세요.

no-resolve의 역할: 이 규칙을 위해 도메인을 추가로 조회하지 않음

연결에 도메인이 포함되어 있고 규칙이 대상 IP를 필요로 하는 경우, 커널은 IP 매칭을 위해 DNS 조회를 시작할 수 있습니다. no-resolve는 해당 IP 규칙을 위해 도메인 조회를 새로 시작하지 않도록 합니다. 전체 DNS 설정을 끄는 옵션도, 이 IP 규칙을 무시하는 옵션도 아닙니다.

대상이 처음부터 IP인 경우: 주소가 대역에 속하는지 바로 판단할 수 있으므로 no-resolve가 있어도 매칭될 수 있습니다.
연결에 사용할 수 있는 대상 IP가 이미 있는 경우: 여전히 매칭될 수 있습니다. 이 옵션을 ‘도메인 연결은 무조건 건너뜀’으로 이해하면 안 됩니다.
도메인만 있고 사용할 수 있는 대상 IP가 없는 경우: 이 규칙만을 위해 도메인을 추가 조회하지 않으므로, 이후 규칙을 계속 확인할 수 있습니다.

rules:
  - DOMAIN-SUFFIX,example.com,DIRECT
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - GEOIP,CN,DIRECT
  - MATCH,프록시 선택

이 순서는 먼저 명확한 도메인을 처리하고, 다음으로 사설 IP를 확인한 뒤 지역을 판별합니다. 두 번째 규칙에 no-resolve가 있어도 세 번째 규칙에는 없으므로 지역 매칭에 필요한 조회가 발생할 수 있습니다. 한 규칙에 옵션을 추가해도 이후 모든 규칙의 DNS 동작이 제한되지는 않습니다.

세 번째 규칙을 GEOIP,CN,DIRECT,no-resolve로 바꾸면 사용할 수 있는 대상 IP 없이 도메인만 있는 연결은 여기서 지역을 판별하지 못하고 프록시 기본 규칙으로 넘어갈 수 있습니다. 옵션을 추가할지는 예상하는 라우팅 결과와 DNS 경로를 고려해 결정하세요. 조회를 줄이려고 모든 규칙에 일괄 추가하지 마세요.

MATCH 기본 규칙과 위에서 아래로 적용되는 순서

MATCH는 조건 없이 매칭하며, MATCH,정책 이름 형식으로 작성합니다. 보통 규칙 목록의 마지막에 두어 앞에서 처리되지 않은 연결을 모두 받습니다. MATCH,*,정책 이름으로 쓰지 마세요. 유효한 규칙이 남아 있는데 그 앞에 배치해서도 안 됩니다.

rules:
  - DOMAIN,login.example.com,DIRECT
  - DOMAIN-SUFFIX,example.com,프록시 선택
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - GEOIP,CN,DIRECT
  - MATCH,프록시 선택

세 가지 접속으로 규칙 순서를 확인하세요

login.example.com에 접속: 첫 번째 규칙이 일치하면 규칙 검색이 즉시 끝나고 DIRECT가 적용됩니다.
static.example.com에 접속: 첫 번째 규칙은 일치하지 않고 두 번째 규칙이 적용되어 ‘프록시 선택’ 정책 그룹으로 전달됩니다.
위 도메인에 속하지 않고 대상 주소가 IP 규칙이나 지역 규칙에도 걸리지 않는 서비스에 접속: 마지막으로 MATCH가 ‘프록시 선택’으로 전달합니다.

이는 설정에서 도출한 결과일 뿐, 예시 도메인에서 실제로 접속 가능한 서비스가 제공된다는 뜻은 아닙니다. 직접 테스트할 때는 라우팅할 실제 대상을 사용하세요. 또한 정책 그룹에 매칭되어도 원격 노드를 거친다고 단정할 수 없습니다. 해당 그룹에서 현재 DIRECT를 선택했다면 최종 연결은 직접 연결입니다.

일반적으로는 정확한 예외, 명확한 도메인 범위, 기타 서비스 규칙이나 규칙 집합, IP 및 지역 보조 규칙, 최종 기본 규칙 순으로 배치하면 실용적입니다. 이 순서는 커널이 강제하는 것은 아닙니다. 예외보다 특정 차단 규칙을 우선해야 한다면 해당 규칙을 앞에 두세요. 중요한 것은 규칙 유형에 따라 기계적으로 분류하는 것이 아니라 각 규칙이 이후 항목 중 어디까지 적용되는지 파악하는 것입니다.

구독과 규칙 집합: 내용뿐 아니라 위치도 올바르게 설정하세요

구독을 갱신한 뒤 사용자 지정 규칙이 사라졌다면, 다시 다운로드될 때 덮어쓰이는 구독 파일을 수정했을 가능성이 큽니다. 먼저 기존 설정을 보관한 뒤 클라이언트의 덮어쓰기, 병합 또는 확장 설정 기능을 사용하세요. 클라이언트마다 메뉴 위치와 병합 형식이 다릅니다. 특정 클라이언트의 확장 필드를 Clash 커널에서 공통으로 지원하는 설정이라고 간주하지 마세요.

RULE-SET도 배치 위치에 따라 달라집니다

해당 버전의 Clash 지원 커널과 mihomo에서는 규칙 제공자를 보통 rule-providers:에 정의하고 RULE-SET,제공자 이름,정책 이름으로 참조합니다. 참조 항목도 같은 위에서 아래로 내려가는 매칭 순서를 따릅니다. 앞의 넓은 도메인 규칙이 먼저 일치하면 뒤에 있는 규칙 집합은 확인하지 않습니다.

behavior: domain의 데이터는 도메인 목록 형식으로 작성하세요. 출구 규칙의 세 필드를 그대로 넣으면 안 됩니다.
behavior: ipcidr의 데이터는 IP 대역이며, 주소 범위 목록에 적합합니다.
behavior: classical은 규칙 조건 형식을 사용하며, 최종 출구 정책은 이를 참조하는 RULE-SET 항목에서 지정합니다.

원본 Clash와 과거의 여러 포크, mihomo는 지원하는 규칙 유형과 확장 필드가 완전히 같지 않습니다. unsupported rule type과 같은 메시지가 표시되면 클라이언트의 ‘정보’ 또는 커널 정보를 확인해 실제로 실행 중인 커널을 파악한 뒤 해당 문서를 확인하세요. 인터페이스 프로그램을 업그레이드해도 커널까지 바뀌는 것은 아닐 수 있습니다.

규칙 검증: 한 번에 하나씩 변경하고 매칭 규칙과 최종 출구를 확인하세요

백업한 뒤 저장하세요. 정상적으로 시작되는 설정을 따로 보관하고 정확한 도메인 규칙 하나만 추가하세요. 설정을 다시 불러온 뒤 파싱 오류가 있는지 확인합니다.
기존 연결을 정리하세요. 대상 앱을 종료하거나 클라이언트의 ‘연결’ 페이지에서 해당 연결을 끊은 뒤 요청을 다시 보내세요. 브라우저에서 HTTP/2 또는 HTTP/3 연결을 재사용하면 이전 경로가 계속 유지될 수 있습니다.
대상을 확인하세요. 연결 상세 정보에서 도메인, 대상 IP, 매칭 규칙, 정책 경로를 확인합니다. 클라이언트마다 필드 이름이 조금씩 다를 수 있으므로 전체 트래픽 그래프만 확인해서는 안 됩니다.
로그를 확인하세요. 필요한 경우 log-level을 잠시 debug로 바꾸고 문제를 한 번 재현한 뒤 info로 복원하세요. 로그를 공유하기 전에 구독 링크, 토큰, 공개하면 안 되는 주소를 가리세요.

증상	우선 확인할 항목
항상 MATCH에 매칭됨	규칙이 로드되었는지, 도메인 철자가 틀리지 않았는지, 연결에 IP만 포함되는지, 규칙 집합이 정상적으로 로드되었는지 확인하세요.
정확한 규칙이 매칭되지 않음	앞에 해당 규칙을 덮는 접미사 규칙, 키워드 규칙 또는 규칙 집합이 있는지 확인하세요. 테스트 연결이 규칙 수정 전에 만들어졌는지도 살펴보세요.
프록시 그룹에 매칭되는데도 직접 연결됨	정책 그룹에서 현재 DIRECT를 선택했는지, 중첩 그룹의 최종 선택이 무엇인지 확인하세요.
일부 앱에서 도메인 규칙이 적용되지 않음	연결에 도메인 정보가 없는지, 앱이 자체적으로 DNS를 조회하는지, 시스템 프록시나 TUN이 실제로 해당 앱의 트래픽을 처리하는지 확인하세요.
구독 갱신 후 설정이 원래대로 돌아감	수정한 항목이 구독 원본 파일인지 지속적으로 적용되는 덮어쓰기인지 확인하세요. 사용자 지정 규칙이 넓은 범위의 규칙 뒤에 병합되지는 않았는지도 살펴보세요.

트래픽에 대상 IP만 있고 도메인이 포함되지 않으면 도메인 규칙이 매칭할 정보가 부족할 수 있습니다. mihomo의 Fake-IP 매핑, DNS 처리, 스니핑 설정에 따라 도메인 정보를 사용할 수 있는지가 달라집니다. 스니핑이 모든 프로토콜을 식별하거나 암호화된 연결에서 실제 도메인을 항상 복원하는 것은 아닙니다. 먼저 연결 상세 정보를 확인하고 DNS 또는 스니핑 설정을 조정할지 결정하세요. 여러 항목을 동시에 바꾸지 마세요.