Clash 사용자 규칙 설정법: 규칙 유형, 매칭 순서와 MATCH 기본 규칙

1. 규칙 문법: 매칭 조건과 트래픽 처리 정책

Clash 사용자 규칙은 각 연결을 어떤 출구로 보낼지 지정합니다. 클라이언트에서 규칙을 편집하고 실제 매칭은 코어가 처리합니다. 오리지널 Clash와 Clash Meta(현 mihomo)는 지원하는 규칙 기능이 완전히 같지 않습니다. 이 글에서는 두 코어에서 흔히 쓰는 기본 문법을 먼저 살펴보고, 규칙 세트의 호환 조건은 별도로 설명합니다.

일반적인 규칙은 YAML 최상위의 rules: 목록에 작성합니다. 한 줄은 보통 규칙 유형, 매칭 대상, 정책으로 구성되며, 일부 유형에는 추가 매개변수를 지정할 수 있습니다. MATCH에는 매칭 대상이 없으므로 출구 정책만 적으면 됩니다.

rules:
  - DOMAIN,example.com,DIRECT
  - DOMAIN-SUFFIX,example.org,REJECT
  - IP-CIDR,192.168.50.0/24,DIRECT,no-resolve
  - MATCH,DIRECT

아래는 규칙 설정 예시이며 전체 구독 설정 파일이 아닙니다. DIRECT는 직접 연결, REJECT는 연결 거부를 뜻합니다. 정책에 프록시 출구를 지정하려면 현재 설정에 해당 이름의 노드나 정책 그룹이 이미 있어야 합니다. 이름은 정확히 일치해야 하며, 한국어 의미에 따라 출구가 자동으로 만들어지지는 않습니다.

2. DOMAIN과 DOMAIN-SUFFIX: 정확한 도메인과 하위 도메인 매칭

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

도메인 규칙에는 URL 경로를 입력하지 않음

https://api.example.com/v1/status를 처리하려면 URL 전체가 아니라 도메인인 api.example.com을 입력하세요. https://, /v1/status 또는 포트 번호를 함께 넣으면 안 됩니다. 일반 도메인 규칙으로는 HTTPS 페이지 경로별로 트래픽을 나눌 수 없으므로, 같은 도메인의 두 경로가 서로 다른 출구를 사용하게 할 수 없습니다.

특정 API 하나에만 예외를 적용하려면 DOMAIN을 사용하세요.
기본 도메인과 모든 하위 도메인에 같은 정책을 적용하려면 DOMAIN-SUFFIX를 사용하세요.
키워드 규칙은 관련 없는 도메인까지 매칭할 수 있습니다. 연결 기록에서 범위를 확인한 뒤 장기적으로 사용하세요.

도메인 매칭은 코어가 대상 도메인을 확인할 수 있어야 작동합니다. 앱이 IP에 직접 연결하거나 DNS 요청이 예상대로 코어를 거치지 않는 경우, 또는 연결 메타데이터에 도메인이 없는 경우에는 DOMAIN 규칙이 반드시 적용된다고 볼 수 없습니다. mihomo의 도메인 스니핑이 일부 상황에서 정보를 보완할 수 있지만, 모든 프로토콜에 통하는 해결책은 아닙니다.

3. 규칙 순서: 위에서부터 확인하고 첫 번째 매칭에서 종료

Clash는 일치하는 규칙을 모두 모은 뒤 가장 정확해 보이는 규칙을 고르지 않습니다. 일반 규칙 목록은 순서대로 확인하며, 조건에 처음으로 맞는 규칙이 출구를 결정합니다. 그 뒤의 규칙은 해당 연결에 적용되지 않습니다. 따라서 정확한 예외는 앞에, 범위가 넓은 분류 규칙은 뒤에 두는 것이 일반적입니다.

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

이 예시에서는 api.example.com에 직접 연결하고 www.example.com은 거부합니다. 앞의 두 줄 순서를 바꾸면 api.example.com이 먼저 도메인 접미사 규칙과 일치해 뒤에 있는 직접 연결 규칙은 적용되지 않습니다. DOMAIN의 우선순위가 낮아진 것이 아니라, 이미 앞선 규칙에서 매칭이 끝난 것입니다.

관리하기 편한 규칙 순서

특정 사이트 예외: 별도로 허용하거나 차단할 도메인, 또는 특정 출구를 지정할 도메인.
로컬 네트워크 및 내부 서비스: 로컬 네트워크에 속하는 주소 대역과 내부 도메인.
서비스 분류 및 규칙 세트: 용도별로 구성한 광범위한 트래픽 분기 규칙.
지역 기반의 광범위한 판별: 지리 데이터베이스를 사용하는 IP 규칙 등.
MATCH: 앞선 규칙에 매칭되지 않은 연결을 처리합니다.

이는 규칙을 관리하는 한 가지 방법일 뿐, 반드시 그대로 따라야 하는 고정 템플릿은 아닙니다. 보안 요구사항상 특정 연결을 먼저 차단해야 한다면 해당 허용 규칙보다 차단 규칙을 앞에 배치하고 충돌이 없는지 확인하세요. 중요한 원칙은 앞에 있는 규칙이 뒤의 규칙보다 우선 적용되어도 의도에 맞아야 한다는 것입니다.

4. IP-CIDR과 GEOIP: 대상 IP, DNS 해석과 no-resolve

IP-CIDR은 대상 IPv4 주소 범위에 매칭하고, IP-CIDR6은 IPv6에 사용합니다. 예를 들어 192.168.50.0/24는 해당 네트워크 대역의 주소를 포함하므로 가정용 NAS, 프린터, 내부 서비스에 직접 연결 규칙을 적용할 때 유용합니다. 이는 ‘접속 기기’의 IP를 필터링하는 조건이 아닙니다.

rules:
  - IP-CIDR,192.168.50.0/24,DIRECT,no-resolve
  - IP-CIDR6,fd00::/8,DIRECT,no-resolve
  - GEOIP,CN,DIRECT
  - MATCH,DIRECT

GEOIP,CN,DIRECT는 현재 IP 지리 데이터베이스를 기준으로 대상 IP가 CN에 속하는지 판단합니다. ‘중국 웹사이트’ 전체 목록을 뜻하는 것은 아닙니다. 웹사이트가 여러 지역의 CDN을 사용할 수 있고, 같은 도메인도 서로 다른 IP로 해석될 수 있습니다. 데이터베이스 내용과 갱신 시점, DNS 결과가 모두 판정에 영향을 주므로 실제로 해석된 대상 IP와 데이터베이스 분류를 기준으로 매칭되는 GEOIP 규칙을 확인해야 합니다.

no-resolve의 적용 범위

연결에 도메인만 있고 사용할 수 있는 대상 IP가 없으면 IP 규칙이 DNS 조회를 유발할 수 있습니다. no-resolve를 추가하면 해당 규칙에 매칭하기 위해 도메인을 능동적으로 조회하지 않습니다. 연결 메타데이터에 사용 가능한 IP가 이미 있다면 주소 매칭은 계속할 수 있습니다. 이는 DNS를 끄거나 모든 도메인 요청이 IP 판별을 건너뛰게 한다는 뜻이 아닙니다.

로컬 네트워크 IP를 직접 연결하는 규칙에는 no-resolve를 자주 추가합니다. 내부 네트워크 대역을 확인하기 위해 다른 도메인을 미리 조회하는 일을 방지할 수 있습니다.
아직 해석되지 않은 도메인에도 GEOIP 판정을 적용하려면 no-resolve를 무조건 추가하지 마세요.
연결을 시작한 기기의 주소를 기준으로 트래픽을 분기하려면 IP-CIDR에 출발지 IP를 입력하지 말고, 코어가 지원하는 출발지 주소 규칙을 확인하세요.

위의 fd00::/8은 IPv6 로컬 주소 대역의 한 가지 예시일 뿐, 모든 로컬 네트워크 상황을 포함하지 않습니다. 실제 설정에서는 기기의 주소 계획에 맞춰 대역을 선택하고, DNS가 IPv6 주소를 반환한 뒤에도 예상한 정책이 적용되는지 확인하세요.

5. MATCH 기본 규칙: 마지막 규칙의 출구 선택

MATCH는 조건 없이 매칭됩니다. 목록 중간에 놓으면 일반적인 매칭 절차에서 그 아래의 규칙에 도달할 수 없습니다. 따라서 보통 하나만 두고 목록의 마지막에 배치합니다. MATCH 뒤에 사용자 규칙을 추가하면 ‘설정은 불러와지지만 실제로 적용되지 않는’ 문제가 흔히 발생합니다.

rules:
  - DOMAIN,api.example.com,DIRECT
  - DOMAIN-SUFFIX,example.org,REJECT
  - IP-CIDR,192.168.50.0/24,DIRECT,no-resolve
  - MATCH,프록시 출구

이 예시에서는 설정에 프록시 출구라는 정책 그룹이 이미 있다고 가정합니다. 앞의 세 규칙에 해당하지 않는 연결은 이 그룹으로 전달되지만, 실제 출구는 그룹에서 현재 선택한 항목에 따라 달라집니다. 그룹에서 DIRECT를 선택했다면 연결은 직접 연결됩니다. 규칙이 특정 그룹에 매칭되는 것과 최종적으로 특정 프록시 노드를 사용하는 것은 서로 다른 단계입니다.

6. 구독 설정 덮어쓰기: 앞에 삽입, 뒤에 추가, 전체 교체

구독은 보통 정기적으로 갱신되므로 다운로드된 설정 파일을 직접 수정하면 다음 갱신 때 변경 사항이 덮어써질 수 있습니다. 클라이언트에서 제공하는 로컬 덮어쓰기, 설정 병합 또는 규칙 편집 기능을 사용하는 편이 안전합니다. 클라이언트와 버전에 따라 메뉴 위치, 필드, 병합 방식이 다르므로 특정 클라이언트의 덮어쓰기 문법을 모든 Clash YAML에 적용할 수는 없습니다.

저장 여부를 판단하기 전에 최종 설정 확인

현재 정상 작동하는 설정을 백업하고 기존 정책 그룹 이름과 마지막 기본 규칙을 기록해 둡니다.
현재 구독에 연결된 로컬 덮어쓰기에서 사용자 규칙을 앞에 삽입하도록 설정합니다. 추가 기능만 있다면 MATCH 뒤에 삽입되지 않는지 확인하세요.
병합 후 실제 적용되는 설정을 확인하고 테스트 도메인을 검색합니다. 해당 도메인이 rules에 있고 범위가 넓은 규칙보다 앞에 있는지 살펴보세요.
설정을 다시 불러온 뒤 새 연결을 만들고 어떤 규칙에 매칭됐는지 확인하세요. 편집기의 원본 설정 조각만 확인해서는 안 됩니다.

‘rules 교체’는 기존 규칙 목록을 지우므로 구독에 포함된 규칙 세트 참조, 로컬 네트워크 예외, 기본 정책까지 함께 삭제될 수 있습니다. 도메인 하나만 수정한다면 구독 전체를 복사해 관리하기보다 정확한 규칙 하나를 앞에 추가하는 방식을 먼저 고려하세요.

RULE-SET도 목록 순서에 따라 적용

rule-providers를 지원하는 코어는 RULE-SET으로 규칙 세트를 참조할 수 있습니다. 지원 범위는 코어와 버전을 확인해야 하며, 오리지널 Clash의 모든 빌드가 지원한다고 단정할 수 없습니다. 아래 예시는 work-domains라는 provider와 프록시 출구라는 정책 그룹이 이미 정의되어 있다고 가정합니다.

rules:
  - DOMAIN,status.example.com,DIRECT
  - RULE-SET,work-domains,프록시 출구
  - MATCH,DIRECT

규칙 세트에 status.example.com이 포함되어 있더라도 앞에 있는 DOMAIN 예외가 먼저 매칭됩니다. 규칙 세트에 rules 목록과 별도의 우선순위가 부여되는 것은 아닙니다. provider의 behavior와 파일 형식도 확인하세요. domain, ipcidr, classical은 서로 다른 형식의 데이터를 사용하므로 임의로 섞을 수 없습니다.

7. 사용자 규칙이 적용되지 않을 때: 연결 기록으로 단계별 확인

규칙을 검증할 때는 한 번에 한 항목만 변경하는 것이 좋습니다. 먼저 테스트용 도메인에 임시 REJECT 규칙을 추가해 목록 맨 위에 놓고, 설정을 다시 불러온 뒤 새 요청을 보내세요. 연결 기록에서 해당 규칙에 매칭되는지 확인한 다음 실제로 필요한 출구로 변경합니다. 테스트가 끝나면 임시 차단 규칙을 삭제해 이후 사용에 영향을 주지 않도록 하세요.

증상	우선 확인할 항목	다음 단계
새 규칙이 전혀 보이지 않음	현재 활성화된 구독, 덮어쓰기 연결 상태, 적용 중인 설정	편집 중인 설정이 코어에서 실제로 불러온 설정인지 확인하세요.
다른 규칙에 매칭됨	목록 앞부분의 DOMAIN-SUFFIX, RULE-SET, MATCH	정확한 예외 규칙을 관련된 광범위 규칙보다 앞에 옮기세요.
정책 그룹에는 매칭되지만 출구가 다름	그룹에서 현재 선택한 항목과 중첩된 정책 그룹	정책 그룹 연결을 따라가 최종 노드 또는 DIRECT를 확인하세요.
일부 요청만 예상대로 처리됨	리디렉션된 도메인, 리소스 도메인, IPv6, 기존 연결	브라우저 주소창만 보지 말고 새 연결을 하나씩 확인하세요.
설정을 다시 불러올 때 오류 발생	YAML 들여쓰기, 규칙 철자, 정책 및 provider 이름	먼저 설정 검사를 통과한 뒤 다시 불러오세요.

코어로 설정 문법 확인

mihomo 명령줄을 직접 사용하는 경우 설정 파일이 있는 디렉터리에서 다음 검사를 실행할 수 있습니다. 실행 파일이 명령 검색 경로에 있어야 하며, 설정에서 참조하는 리소스도 정상적으로 찾을 수 있어야 합니다.

mihomo -t -f config.yaml

검사가 통과되면 설정이 해당 코어의 로드 조건을 충족한다는 뜻일 뿐, 트래픽 분기가 예상대로 작동한다는 의미는 아닙니다. 클라이언트의 연결 기록이나 로그를 열어 대상 도메인, 대상 IP, 매칭된 규칙과 정책 그룹 경로를 확인하세요. 그래픽 클라이언트를 사용할 때는 손에 있는 백업 파일만 검사하지 말고 실제로 불러온 생성 설정이 무엇인지도 확인해야 합니다.

규칙을 수정해도 이미 연결된 장시간 연결이 새 출구로 즉시 옮겨가지는 않습니다. 브라우저의 HTTP/2 연결, 다운로드 작업, 메신저 연결은 기존 경로를 계속 재사용할 수 있습니다. 저장 후 설정을 다시 불러오고 새 연결로 테스트하세요. 필요한 경우 해당 연결을 종료한 뒤 다시 확인해 연결 재사용을 규칙 미적용으로 오해하지 않도록 합니다.

규칙을 관리할 때는 목적이 분명한 예외만 남기고, 해당 위치에 배치한 이유를 기록하세요. 문제가 생기면 ‘트래픽이 코어에 들어오는지, 규칙 모드인지, 적용 목록의 순서, 매칭된 정책, 최종 출구’를 차례로 확인하는 편이 노드를 계속 바꾸는 것보다 원인을 찾기 쉽습니다.