Clash 사용자 규칙 문법 완벽 가이드: 매칭 유형·순서·우선순위

Clash 규칙 매칭 모델

Clash의 규칙 시스템은 현재 연결을 어떤 정책 그룹, 프록시 노드 또는 내장 동작으로 처리할지 결정합니다. 연결이 코어에 들어오면 규칙은 설정 파일에 나온 순서대로 위에서 아래로 확인됩니다. 조건에 맞는 첫 번째 규칙이 즉시 적용되며, 이후 규칙은 해당 연결에 더 이상 적용되지 않습니다. 모든 매칭 결과를 모아 ‘정확도’를 비교하는 방식이 아니며, 도메인 규칙이 IP 규칙보다 자동으로 우선되는 것도 아닙니다.

일반적인 규칙은 규칙 유형, 매칭 대상, 대상 정책의 세 부분으로 구성되며 각 필드는 영문 쉼표로 구분합니다. 예를 들면 다음과 같습니다.

rules:
  - DOMAIN,api.example.com,DIRECT
  - DOMAIN-SUFFIX,example.org,Proxy
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - MATCH,Final

DOMAIN, DOMAIN-SUFFIX, IP-CIDR은 규칙 유형입니다. 도메인 또는 네트워크 대역은 매칭 대상이고, DIRECT, Proxy, Final은 처리 대상입니다. 대상 이름은 대소문자, 공백, 기호를 포함해 설정에 있는 프록시 그룹 이름과 완전히 일치해야 합니다. DIRECT는 직접 연결, REJECT는 연결 거부를 뜻하며, 프록시 그룹 이름은 해당 그룹이 최종 사용할 노드를 결정하도록 합니다.

규칙은 일반적으로 대상 도메인, 대상 IP, 포트, 네트워크 유형, 연결을 시작한 프로세스 같은 연결 메타데이터를 처리합니다. 웹페이지 본문을 읽어 사이트 유형을 판단하지는 않습니다. 하나의 앱이 같은 페이지에서 여러 도메인에 접근하면 기본 페이지, 이미지, 동영상, API, 통계 요청이 각각 다른 규칙에 매칭될 수 있습니다. 따라서 규칙 적용 여부를 확인할 때는 주소 표시줄의 대표 도메인만 보지 말고 실제 연결 정보를 확인해야 합니다.

도메인 매칭 문법: 정확한 일치·접미사·키워드

DOMAIN: 전체 도메인만 매칭

DOMAIN은 특정 호스트 이름 하나를 처리할 때 적합합니다. 다음 규칙은 api.example.com과 매칭되지만 www.example.com, v2.api.example.com 또는 다른 서브도메인과는 매칭되지 않습니다.

- DOMAIN,api.example.com,Proxy

특정 API만 별도로 라우팅하고 같은 주 도메인의 다른 서비스는 기존 정책을 유지해야 할 때 정확한 도메인 규칙이 가장 적합합니다. 실제 연결에서 도메인을 비교할 때는 일반적으로 영문 대소문자를 구분하지 않지만, 검토·검색·중복 제거를 쉽게 하려면 소문자로 통일하는 것이 좋습니다.

DOMAIN-SUFFIX: 주 도메인과 서브도메인 매칭

DOMAIN-SUFFIX는 사용자 규칙에서 자주 사용하는 유형입니다. 다음 규칙은 example.com, www.example.com, cdn.media.example.com에 모두 적용됩니다.

- DOMAIN-SUFFIX,example.com,Proxy

접미사 값에는 보통 도메인만 입력하며 앞에 점이나 와일드카드를 붙일 필요가 없습니다. *.example.com으로 작성하면 기대한 결과를 얻지 못할 수 있습니다. 규칙 유형 자체가 이미 접미사 매칭을 의미하기 때문입니다. 특정 서브도메인을 제외하려면 예외 규칙을 일반 접미사 규칙보다 앞에 배치해야 합니다.

- DOMAIN,internal.example.com,DIRECT
- DOMAIN-SUFFIX,example.com,Proxy

DOMAIN-KEYWORD: 도메인에 포함된 문자열 매칭

DOMAIN-KEYWORD는 도메인에 지정한 텍스트가 포함되어 있는지 확인합니다. 예를 들어 DOMAIN-KEYWORD,example,Proxy는 example.com뿐 아니라 example-cdn.net과 notexample.org에도 매칭될 수 있습니다. 적용 범위가 넓으므로 도메인 구조는 자주 바뀌지만 일정한 이름 조각을 유지하는 서비스에 적합하며, 모든 접미사 규칙을 대신하는 용도로는 적합하지 않습니다.

키워드가 짧을수록 오매칭 가능성이 높아집니다. 문제를 확인할 때 관련 없는 사이트가 프록시를 사용한다면 앞쪽에 배치된 DOMAIN-KEYWORD 규칙부터 확인하세요. 완전한 주 도메인을 알고 있다면 DOMAIN 또는 DOMAIN-SUFFIX를 우선 사용하는 것이 좋습니다.

GEOSITE: 도메인 분류 집합으로 매칭

Clash Meta, 즉 현재 널리 사용되는 mihomo 코어는 GEOSITE를 통해 미리 정리된 도메인 분류 데이터를 사용할 수 있습니다. 예시는 다음과 같습니다.

- GEOSITE,category-ads-all,REJECT
- GEOSITE,cn,DIRECT

GEOSITE에서 사용할 수 있는 분류는 클라이언트에 포함되었거나 다운로드된 GeoSite 데이터 파일에 따라 달라집니다. 분류 이름이 없거나 데이터베이스가 최신 상태가 아니거나 클라이언트의 코어가 해당 규칙을 지원하지 않으면 설정 오류가 발생하거나 예상대로 매칭되지 않을 수 있습니다. 따라서 다른 설정에서 규칙을 복사하기 전에 현재 클라이언트의 코어 유형과 데이터 파일 출처를 먼저 확인해야 합니다.

IP·포트·네트워크 유형 규칙

IP-CIDR 및 IP-CIDR6

IP-CIDR는 CIDR 네트워크 대역으로 IPv4 대상 주소를 매칭하고, IP-CIDR6는 IPv6에 사용합니다. 슬래시 뒤 숫자는 네트워크 프리픽스 길이를 뜻합니다. 단일 IPv4 주소는 /32, 단일 IPv6 주소는 /128로 작성할 수 있습니다.

- IP-CIDR,203.0.113.8/32,Proxy,no-resolve
- IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
- IP-CIDR6,2001:db8::/32,Proxy,no-resolve

연결이 처음부터 도메인으로 제공되는 경우 일부 IP 규칙은 대상 IP를 얻은 뒤 계속 판단하기 위해 도메인 해석을 수행할 수 있습니다. 규칙 끝의 no-resolve는 이 IP 규칙을 확인하기 위해 도메인을 추가로 해석하지 말라는 뜻입니다. 사설 네트워크 예약 주소나 이미 알고 있는 서버 주소처럼 도메인 해석이 필요 없는 규칙에는 보통 이 매개변수를 추가해 불필요한 DNS 조회를 줄일 수 있습니다.

no-resolve는 Clash 전체의 DNS 기능을 끄는 설정이 아니며 앱 자체에서 발생하는 DNS 요청도 차단하지 않습니다. 현재 규칙의 매칭 과정에서 도메인을 IP로 능동적으로 해석할지 여부만 제어합니다. 해석된 주소 대역에 의존하는 규칙이라면 이 매개변수를 무조건 추가해서는 안 됩니다.

GEOIP: IP 데이터베이스 분류로 매칭

GEOIP는 대상 IP의 지리 데이터베이스 분류를 기준으로 매칭합니다. 일반적인 작성 형식은 다음과 같습니다.

- GEOIP,CN,DIRECT,no-resolve

이 규칙의 결과는 GeoIP 또는 GeoData 데이터베이스의 내용에 따라 달라집니다. IP 주소의 지역 정보는 변할 수 있고, 클라우드 서비스와 콘텐츠 전송 네트워크는 여러 지역으로 트래픽을 분산할 수 있습니다. 따라서 GEOIP는 모든 정확한 도메인 예외를 덮는 규칙보다 목록 후반의 범위 규칙으로 사용하는 편이 적합합니다. 처리 방식을 고정해야 하는 서비스는 명확한 도메인 또는 IP 규칙을 앞에 배치해야 합니다.

포트 및 프로토콜

mihomo는 DST-PORT, SRC-PORT, NETWORK 등의 유형으로 연결 조건을 더 제한할 수 있습니다. 대상 포트 규칙은 서버 포트를, 소스 포트 규칙은 로컬 연결에 사용되는 포트를 대상으로 합니다. 네트워크 유형은 보통 tcp 또는 udp로 작성합니다.

- DST-PORT,22,SSH
- DST-PORT,3478-3481,Realtime
- NETWORK,udp,UDP-Policy

포트만 기준으로 라우팅하면 같은 포트를 사용하는 다른 프로그램에도 영향을 줄 수 있습니다. 예를 들어 HTTPS는 일반적으로 443 포트를 사용하므로 모든 443 트래픽을 특정 정책으로 보내는 것은 지나치게 포괄적입니다. 도메인, 프로세스 또는 논리 규칙을 함께 사용해 범위를 좁히고, 변경 후 연결 목록을 확인하는 편이 안전합니다.

프로세스 규칙 및 논리 조합

PROCESS-NAME 및 PROCESS-PATH

PROCESS-NAME은 연결을 시작한 실행 파일 이름으로 매칭하며, 특정 앱 전체에 하나의 정책을 적용할 때 적합합니다. 예를 들어 Windows 프로그램 이름에는 보통 확장자가 포함됩니다.

- PROCESS-NAME,example.exe,Application-Proxy
- PROCESS-NAME,curl,DIRECT

PROCESS-PATH는 프로그램의 전체 경로로 매칭할 수 있어 같은 이름의 실행 파일이 여러 개일 때 더 정확합니다. 다만 경로 형식은 운영체제와 코어 구현의 영향을 받습니다. Windows 경로의 백슬래시와 공백, YAML 따옴표를 올바르게 처리해야 합니다. 앱 업데이트로 설치 디렉터리가 바뀌면 기존 경로 규칙이 작동하지 않을 수도 있습니다.

프로세스 식별 기능은 플랫폼, 실행 권한, 트래픽 가로채기 방식에 따라 달라집니다. 일부 시스템에서는 특정 권한이 있어야 프로세스 정보를 얻을 수 있고, 일부 전달 경로에서는 원래 프로세스를 확인하지 못할 수도 있습니다. 프로세스 규칙이 적용되지 않을 때는 규칙 문구를 계속 수정하기보다 먼저 클라이언트 연결 상세에 프로세스 이름이 표시되는지 확인해야 합니다.

AND·OR·NOT

mihomo는 여러 조건을 조합하는 논리 규칙을 지원합니다. 예를 들어 특정 앱이 특정 도메인에 접근할 때만 프록시를 사용하도록 설정할 수 있습니다.

- AND,((PROCESS-NAME,example.exe),(DOMAIN-SUFFIX,example.com)),Proxy
- OR,((DST-PORT,80),(DST-PORT,443)),Web
- NOT,((NETWORK,udp)),TCP-Policy

논리 규칙은 명확한 교집합, 합집합, 제외 조건을 표현하는 데 적합하지만 괄호 중첩이 많아지면 유지 관리 비용이 빠르게 늘어납니다. 코어 버전에 따라 논리 규칙과 하위 규칙 유형의 지원 범위가 다를 수 있습니다. 저장 후 클라이언트에서 파싱 오류가 표시되면 현재 mihomo 문서를 기준으로 괄호, 쉼표, 지원되는 규칙 유형을 확인하세요.

규칙 순서 및 우선순위

Clash의 핵심 우선순위 원칙은 ‘먼저 매칭되면 중지’입니다. 규칙 유형 자체에 공통으로 적용되는 숨은 가중치는 없습니다. 뒤에 더 정확한 DOMAIN이 있더라도 앞의 DOMAIN-SUFFIX, GEOSITE 또는 다른 광범위한 규칙이 먼저 매칭되면 뒤의 정확한 규칙은 실행되지 않습니다.

실용적인 배치 방법은 예외를 앞에, 범위 규칙을 중간에, 최종 규칙을 마지막에 두는 것입니다.

1. 로컬 네트워크 주소, 내부 도메인, 반드시 직접 연결해야 하는 예외입니다.
2. 고정 프록시 또는 고정 거부가 필요한 정확한 도메인입니다.
3. 특정 앱, 포트 및 논리 조합 규칙입니다.
4. 도메인 접미사, 규칙 집합, GEOSITE, GEOIP 등의 범위 규칙입니다.
5. MATCH 최종 규칙입니다.

rules:
  - DOMAIN,login.internal.example,DIRECT
  - DOMAIN,api.example.com,Service-Proxy
  - PROCESS-NAME,example.exe,Application-Proxy
  - DOMAIN-SUFFIX,example.com,Proxy
  - GEOSITE,cn,DIRECT
  - GEOIP,CN,DIRECT,no-resolve
  - MATCH,Final

이 설정에서는 api.example.com이 정확한 도메인 규칙에 먼저 매칭되므로 뒤의 example.com 접미사 규칙으로 넘어가지 않습니다. 해당 접미사에 속한 다른 도메인은 Proxy로 전달됩니다. 앞의 규칙으로 처리되지 않은 연결은 최종적으로 Final에 전달됩니다.

MATCH는 조건 없는 최종 규칙이므로 규칙 목록의 마지막에 배치해야 합니다. 일부 오래된 설정에서는 비슷한 목적으로 FINAL을 사용하지만 실제 지원 여부는 코어에 따라 다릅니다. mihomo 설정에서는 현재 코어 문서에 따라 MATCH를 우선 사용하세요. 최종 규칙을 중간에 두면 그 뒤의 규칙은 매칭될 기회를 얻지 못합니다.

규칙 대상이 프록시 그룹이면 규칙은 ‘어느 그룹으로 보낼지’만 결정하고, 노드 선택은 프록시 그룹 유형이 결정합니다. 예를 들어 수동 선택 그룹은 사용자가 현재 선택한 노드를 사용하고, 자동 테스트 그룹은 그룹 내 테스트 결과에 따라 노드를 선택합니다. 경로를 점검할 때는 ‘규칙이 잘못된 그룹에 매칭된 문제’와 ‘그룹 안에서 적절하지 않은 노드가 선택된 문제’를 구분해야 합니다.

구독 규칙 덮어쓰기 및 변경 사항 유지

구독 설정은 일반적으로 서버에서 생성됩니다. 클라이언트에서 구독을 펼친 YAML을 직접 편집하면 단기간에는 적용되지만 다음 구독 업데이트 때 변경 사항이 새 설정으로 대체될 수 있습니다. 장기간 유지할 사용자 규칙은 클라이언트가 제공하는 오버라이드, 설정 병합, 확장 스크립트 또는 로컬 설정 기능을 사용해야 합니다.

클라이언트마다 병합 기능의 이름은 다르지만 목적은 대체로 다음 세 가지로 나뉩니다.

• 앞에 추가: 구독 규칙 목록의 시작 부분에 삽입하며, 우선순위가 높은 예외를 추가할 때 적합합니다.
• 뒤에 추가: 목록 끝에 덧붙입니다. 단, 구독에 이미 MATCH가 포함되어 있으면 추가한 내용이 영원히 매칭되지 않을 수 있습니다.
• 전체 교체: 사용자 지정 목록으로 구독의 모든 규칙을 교체합니다. 필요한 로컬 네트워크, DNS, 직접 연결 및 최종 처리 로직을 직접 보존해야 합니다.

따라서 ‘규칙 하나를 추가한다’고 해서 반드시 ‘우선순위가 높아지는’ 것은 아닙니다. 구독의 기존 결과를 덮어쓰려면 새 규칙을 관련 광범위한 규칙과 최종 규칙보다 앞에 배치해야 합니다. 그래픽 클라이언트를 사용할 때는 오버라이드 편집창의 순서만 보지 말고 병합된 실제 설정 또는 실행 중인 설정을 확인하세요.

RULE-SET 및 rule-providers

규칙이 많을 때는 rule-providers로 규칙 집합을 참조한 다음 주 규칙 목록에서 RULE-SET을 사용할 수 있습니다. 규칙 제공자는 규칙 내용을 불러오지만, RULE-SET이 주 목록에서 배치된 위치가 여전히 우선순위를 결정합니다.

rule-providers:
  private-services:
    type: http
    behavior: domain
    format: yaml
    path: ./ruleset/private-services.yaml
    url: https://rules.example.com/private-services.yaml
    interval: 86400

rules:
  - DOMAIN,exception.example.com,DIRECT
  - RULE-SET,private-services,Proxy
  - MATCH,Final

behavior는 규칙 집합의 내용과 일치해야 합니다. 일반적인 동작에는 domain, ipcidr, classical이 있습니다. 도메인 동작은 도메인 집합에, IP 동작은 네트워크 대역 집합에 적합하며, 클래식 동작은 유형이 포함된 완전한 규칙 페이로드를 담을 수 있습니다. 규칙 파일의 구체적인 형식은 format과 코어 버전에도 영향을 받으므로, 주 설정의 rules 섹션 전체를 임의 형식의 규칙 제공자 파일로 사용할 수는 없습니다.

원격 규칙 집합을 불러오지 못하면 URL에 접근할 수 있는지, 파일 형식이 올바른지, 저장 경로에 쓸 수 있는지 확인하고 클라이언트 로그도 살펴보세요. 중요한 라우팅이 원격 규칙 집합에 의존한다면, 규칙 집합을 일시적으로 사용할 수 없을 때 연결 방향이 불명확해지지 않도록 적절한 최종 규칙을 유지하는 것이 좋습니다.

규칙이 적용되지 않을 때의 점검 순서

규칙 문제는 한 번에 많은 내용을 바꾸기보다 실행 결과를 바탕으로 원인을 역추적하는 방식이 적합합니다. 다음 순서로 문법, 순서, 해석, 클라이언트 기능 문제를 구분할 수 있습니다.

1. 현재 설정이 활성화되었는지 확인합니다. 클라이언트에 여러 설정 파일이 저장되어 있을 수 있습니다. 수정 후 저장, 다시 불러오기 또는 설정 전환을 실행하고 현재 실행 중인 설정이 방금 편집한 버전인지 확인하세요.
2. 연결 상세를 확인합니다. 대상 도메인, 대상 IP, 네트워크 유형, 프로세스 이름, 매칭된 규칙, 최종 정책 그룹을 기록하세요. 연결 목록은 코어가 실제로 판단한 결과를 보여주므로 웹페이지 도메인만 보고 추측하는 것보다 신뢰할 수 있습니다.
3. 앞에 있는 광범위한 규칙을 확인합니다. DOMAIN-KEYWORD, DOMAIN-SUFFIX, GEOSITE, GEOIP, RULE-SET, MATCH를 중점적으로 검색하세요.
4. 정책 이름을 확인합니다. 규칙 끝의 대상은 실제로 존재해야 합니다. 그룹 이름을 변경한 뒤 기존 규칙이 이미 삭제된 이름을 계속 가리킬 수 있습니다.
5. DNS 관찰 결과를 확인합니다. 앱은 IP에 직접 연결할 수도 있고 캐시, 암호화 DNS 또는 자체 해석 방식을 사용할 수도 있습니다. 도메인 정보를 얻지 못하면 도메인 규칙이 매칭에 참여하지 못할 수 있습니다.
6. 코어 지원 여부를 확인합니다. 프로세스, 논리, GEOSITE, 일부 포트 규칙은 코어와 플랫폼 기능에 의존합니다. 시작 로그에서 알 수 없는 규칙이나 설정 파싱 관련 메시지를 확인하세요.
7. 기존 연결을 정리한 뒤 다시 시도합니다. 이미 연결된 장시간 연결은 규칙을 수정해도 즉시 다시 매칭되지 않는 경우가 많습니다. 해당 앱의 연결을 종료하거나 클라이언트 연결 기록을 지우고 앱을 재시작한 후 테스트하세요.

정확한 도메인인데도 매칭되지 않는 이유

실제 요청이 다른 서브도메인에 접근했거나, 연결 상세에 IP만 표시되거나, 정확한 규칙이 광범위한 규칙 뒤에 있거나, 구독 업데이트로 변경 사항이 덮어써진 경우가 흔한 원인입니다. 최신 웹사이트는 로그인, API, 정적 리소스, 동영상을 서로 다른 도메인에 배정하는 경우가 많습니다. 먼저 연결 목록에서 앱 프로세스로 필터링한 다음 대상 호스트를 하나씩 확인해 보세요.

규칙은 매칭되었다고 표시되는데 접속 결과가 바뀌지 않는 이유

정확히 매칭되었다는 것은 연결이 지정한 정책으로 들어갔다는 뜻일 뿐입니다. 정책 그룹의 현재 선택, 노드 연결 상태, DNS 응답, 앱 캐시, 별도로 발생하는 IPv6 연결도 확인해야 합니다. 정책 그룹이 자동 선택 유형이면 테스트 후 그룹 내 노드가 바뀔 수 있습니다. 도메인이 IPv4와 IPv6를 함께 반환하면 두 연결이 서로 다른 유형의 규칙에 매칭될 수도 있습니다.

최소 테스트 설정

복잡한 설정에서 충돌 원인을 파악하기 어려울 때는 충분히 정확한 규칙 하나를 임시로 추가해 목록 맨 앞에 배치하고, 쉽게 식별할 수 있는 정책 그룹을 가리키도록 하세요. 테스트가 성공하면 규칙 순서를 단계적으로 원래대로 되돌립니다. DNS, TUN, 프록시 그룹, 많은 규칙을 동시에 수정하지 마세요. 변경이 발생했을 때 실제 원인을 파악하기 어려워집니다.

클라이언트가 TUN 모드로 시스템 프록시를 따르지 않는 앱까지 가로채야 한다면, 먼저 TUN이 정상적으로 시작되었는지와 라우팅 및 DNS 하이재킹 설정이 현재 플랫폼 요구 사항에 맞는지 확인해야 합니다. TUN은 트래픽을 코어로 전달하고, 규칙은 코어에 들어온 트래픽을 어떻게 처리할지 결정하므로 서로 다른 단계에 해당합니다. TUN이 가로채지 못한 연결은 당연히 규칙 매칭 기록에 나타나지 않습니다.