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

PROOF / 01

규칙 매칭 모델: 위에서 아래로, 처음 일치하면 중단

Clash의 rules는 행 단위로 정렬된 트래픽 분배 목록입니다. 각 규칙은 일반적으로 ‘유형, 매칭 대상, 적용할 정책’으로 구성되며, 일부 유형에는 추가 매개변수를 지정할 수 있습니다. 코어는 연결을 처리할 때 목록의 맨 위부터 확인하고, 조건에 맞는 첫 번째 규칙을 찾으면 해당 행의 정책을 즉시 적용한 뒤 나머지 규칙은 확인하지 않습니다.

여기서 말하는 ‘우선순위’는 규칙 유형에 따라 자동으로 정해지지 않습니다. DOMAIN이 본질적으로 DOMAIN-SUFFIX보다 우선하는 것도 아니며, IP-CIDR이 앞에 있는 도메인 규칙을 자동으로 덮어쓰는 것도 아닙니다. 실제 우선순위를 결정하는 것은 규칙이 배치된 행의 위치입니다. 따라서 범위가 넓은 규칙을 너무 앞에 두면 뒤에 배치한 더 정확한 예외 규칙이 가려질 수 있습니다.

rules:
  - DOMAIN,api.example.com,DIRECT
  - DOMAIN-SUFFIX,example.com,노드 선택
  - GEOIP,CN,DIRECT
  - MATCH,노드 선택

위 순서에서는 먼저 api.example.com을 직접 연결하고, 해당 도메인의 다른 하위 도메인은 ‘노드 선택’으로 보냅니다. 앞의 두 줄 순서를 바꾸면 정확한 도메인도 접미사 규칙에 먼저 잡히므로 첫 번째 직접 연결 예외가 작동하지 않습니다. 마지막의 MATCH는 앞에서 일치하지 않은 연결을 처리하는 기본 규칙으로, 일반적으로 하나만 목록의 맨 끝에 둡니다.

PROOF / 02

도메인 규칙: 정확한 호스트·접미사·키워드

도메인 규칙은 대상 호스트명이 명확한 요청을 처리할 때 적합하며, 사용자 지정 트래픽 분기에서 가장 자주 사용하는 유형입니다. 연결에 도메인 정보가 남아 있다면 코어가 대상을 IP로 먼저 변환하지 않고 바로 매칭할 수 있습니다. 대표적인 유형은 다음과 같습니다.

rules:
  - DOMAIN,login.example.net,DIRECT
  - DOMAIN-SUFFIX,example.net,업무 서비스
  - DOMAIN-KEYWORD,streaming,미디어 노드
  - GEOSITE,cn,DIRECT
  - MATCH,노드 선택

DOMAIN,login.example.net은 이 완전한 호스트만 매칭하며 static.login.example.net은 매칭하지 않습니다. DOMAIN-SUFFIX,example.net은 일반적으로 example.net과 모든 하위 도메인을 함께 포함하므로 사이트 단위 규칙에 적합합니다. DOMAIN-KEYWORD는 지정한 문자열이 대상 도메인에 포함되기만 해도 일치할 수 있어 범위를 제어하기 어렵습니다. 충분히 구체적인 키워드를 사용하고 정확한 규칙 뒤에 배치하세요.

GEOSITE는 데이터 세트를 기반으로 매칭하는 방식입니다. 사용 가능 여부와 분류명 작성법은 사용하는 코어, 클라이언트 및 지리 데이터 파일에 따라 달라집니다. 설정을 옮길 때 특정 클라이언트가 인식하는 분류를 모든 Clash 파생 코어가 지원한다고 가정해서는 안 됩니다. 먼저 코어 유형과 데이터 파일이 정상적으로 로드되었는지 확인하세요.

PROOF / 03

IP, 출발지 주소 및 네트워크 프로토콜 규칙

서비스를 주소 대역으로만 식별할 수 있거나 LAN 출발지와 대상 지역에 따라 제어해야 한다면 IP 유형 규칙을 사용할 수 있습니다. IPv4 대역에는 일반적으로 IP-CIDR, IPv6 대역에는 IP-CIDR6을 사용하며, GEOIP는 지리 데이터베이스를 기준으로 대상 IP의 분류를 판단합니다.

rules:
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - IP-CIDR,10.0.0.0/8,DIRECT,no-resolve
  - IP-CIDR6,fd00::/8,DIRECT,no-resolve
  - GEOIP,CN,DIRECT
  - MATCH,노드 선택

no-resolve는 IP 규칙이 매칭을 위해 도메인 조회를 직접 실행하지 않도록 합니다. 연결 자체에 대상 IP가 이미 포함되어 있으면 해당 주소를 계속 검사할 수 있습니다. 반대로 대상이 도메인뿐이고 코어가 아직 실제 주소를 얻지 못한 경우에도 이 규칙은 DNS 조회를 강제로 수행하지 않습니다. 일반 도메인을 추가로 조회할 필요가 없는 LAN 예약 주소 규칙에 자주 사용하는 이유입니다.

no-resolve를 추가할지는 대상에 따라 결정해야 합니다. GEOIP가 조회 결과를 바탕으로 직접 연결 또는 프록시 여부를 판단하게 하려면, 조회를 차단할 경우 필요한 주소를 얻지 못할 수 있습니다. 반대로 도메인 규칙이 주요 서비스를 이미 처리하고 IP 규칙은 주소로 직접 접속하는 연결만 담당한다면, 이 옵션으로 불필요한 조회를 줄일 수 있습니다.

Fake-IP 모드에서는 애플리케이션이 코어가 할당한 예약 주소를 먼저 볼 수 있으며, Clash는 도메인과 실제 대상 사이의 매핑을 관리합니다. 도메인 규칙은 일반적으로 원래 호스트명을 기준으로 계속 작동하지만, IP 규칙을 점검할 때는 ‘애플리케이션에 표시된 Fake-IP’, ‘코어가 저장한 도메인 매핑’, ‘상위 DNS가 반환한 실제 IP’를 구분해야 합니다. 브라우저나 애플리케이션에 표시된 대상 주소만 보면 규칙이 일치했는지 잘못 판단하기 쉽습니다.

출발지 주소 및 네트워크 유형

SRC-IP-CIDR은 연결을 시작한 장치의 주소로 매칭하므로 라우터나 LAN 게이트웨이 환경에서 자주 사용합니다. 예를 들어 특정 테스트 장치에 별도 정책을 적용할 수 있습니다. NETWORK는 TCP와 UDP를 기준으로 연결을 구분하며, 더 구체적인 포트 조건과 조합하기 좋습니다. 모든 UDP 트래픽을 앞에서 하나의 정책으로 보내면 영향 범위가 지나치게 넓어질 수 있습니다.

rules:
  - SRC-IP-CIDR,192.168.50.25/32,테스트 정책
  - NETWORK,UDP,노드 선택
  - MATCH,DIRECT

데스크톱 클라이언트가 로컬 트래픽만 프록시하는 경우 출발지 주소는 라우터의 투명 프록시 환경만큼 유용하게 구분되지 않을 수 있습니다. 사용하기 전에 클라이언트 작동 모드, TUN이 가로채는 범위, 코어가 실제로 확보한 연결 메타데이터를 확인하세요.

PROOF / 04

프로세스·경로·포트 매칭

프로세스 규칙을 사용하면 연결을 시작한 애플리케이션별로 트래픽을 분기할 수 있습니다. PROCESS-NAME은 일반적으로 실행 파일 이름을 매칭하고, PROCESS-PATH는 전체 경로를 매칭합니다. 같은 도메인을 여러 애플리케이션이 공유하지만 특정 프로그램만 별도 정책을 적용해야 할 때 유용합니다.

rules:
  - PROCESS-NAME,example-client.exe,업무 서비스
  - PROCESS-PATH,C:\Apps\Example\example-client.exe,업무 서비스
  - DST-PORT,22,개발 노드
  - DST-PORT,123,DIRECT
  - MATCH,노드 선택

프로세스 식별 기능은 운영체제 권한, 클라이언트 구현, 코어 버전 및 트래픽 가로채기 모드의 영향을 받습니다. Windows, macOS, Linux는 프로세스 이름과 경로를 표현하는 방식이 다르며, 모바일 운영체제에는 데스크톱의 실행 파일 규칙을 그대로 적용하기 어렵습니다. 로그에 대상 주소만 있고 프로세스 필드가 없다면 프로세스 이름을 계속 바꿔도 해결되지 않습니다. 현재 플랫폼이 프로세스 메타데이터를 제공할 수 있는지 먼저 확인하세요.

DST-PORT는 대상 포트, SRC-PORT는 로컬 출발지 포트로 매칭합니다. 대상 포트가 출발지 포트보다 안정적이지만, 포트 하나만으로 서비스를 특정할 수는 없습니다. 예를 들어 TCP 443은 수많은 HTTPS 서비스가 공유하므로 이를 앞에서 하나의 프록시 정책으로 지정하면 대부분의 웹 연결을 덮어쓰게 됩니다. 포트 규칙은 용도가 명확한 프로토콜에 사용하거나, mihomo의 논리 조합 규칙에서 도메인 및 네트워크 유형과 함께 범위를 제한하는 편이 좋습니다.

PROOF / 05

규칙 순서와 우선순위를 실용적으로 구성하는 방법

관리하기 쉬운 규칙 목록은 일반적으로 ‘예외는 앞에, 일반 규칙은 중간에, 기본 규칙은 뒤에’ 배치합니다. 반드시 직접 연결하거나 거부해야 하는 정확한 호스트를 먼저 두고, 업무 도메인과 프로세스 규칙을 배치한 뒤 주소 대역과 지역 분류를 처리하고, 마지막에 MATCH로 마무리할 수 있습니다. 다만 고정 템플릿을 기계적으로 적용하지 말고 실제 목적에 맞춰 순서를 조정해야 합니다.

1. 로컬 및 관리 주소: 라우터 관리 페이지, LAN 대역과 로컬 서비스는 일반적으로 먼저 직접 연결하여 광범위한 프록시 규칙에 가로채이지 않도록 합니다.
2. 정확한 예외: DOMAIN, 단일 주소 CIDR 또는 명확한 프로세스 이름으로 특수한 요구 사항을 처리합니다.
3. 업무 규칙: 도메인 접미사, 규칙 모음 또는 애플리케이션 프로세스에 따라 해당 정책 그룹으로 분배합니다.
4. 범위가 넓은 분류: 지리 데이터베이스, 키워드 및 대규모 규칙 모음은 더 정확한 규칙 뒤에 배치합니다.
5. 최종 기본 규칙: MATCH를 예상한 기본 정책으로 지정합니다.

rules:
  # LAN
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - IP-CIDR,10.0.0.0/8,DIRECT,no-resolve

  # 정확한 예외
  - DOMAIN,update.example.org,DIRECT
  - DOMAIN,blocked.example.org,REJECT

  # 일반 업무
  - DOMAIN-SUFFIX,example.org,업무 서비스
  - PROCESS-NAME,media-player.exe,미디어 노드

  # 지역 및 기본 규칙
  - GEOIP,CN,DIRECT
  - MATCH,노드 선택

주석은 규칙 동작을 바꾸지 않지만 이후 검증에 드는 시간을 크게 줄여 줍니다. 단순히 출처만 표시하기보다 각 규칙 그룹의 용도를 적는 것이 좋습니다. 구독을 업데이트하거나 설정을 수동으로 병합한 뒤에도 사용자 지정 구간이 예상한 위치에 남아 있는지 빠르게 확인할 수 있습니다. 특히 클라이언트의 오버라이드 기능을 점검해야 합니다. 어떤 클라이언트는 사용자 지정 규칙을 맨 위에 삽입하고, 어떤 클라이언트는 맨 아래에 추가하며, 구독 업데이트 때 전체 설정을 다시 생성하는 경우도 있습니다.

PROOF / 06

규칙 모음 및 mihomo 논리 규칙

규칙이 많다면 rule-providers를 사용해 규칙 내용을 별도 파일로 분리한 뒤, 기본 규칙 목록에서 RULE-SET으로 참조할 수 있습니다. 모음은 매칭 항목을 저장하고, 기본 설정에서 해당 참조를 배치한 위치가 전체 우선순위를 결정합니다. 설정 상단에 모음을 정의했다고 해서 다른 규칙보다 자동으로 먼저 실행되지는 않습니다.

rule-providers:
  service-domains:
    type: http
    behavior: domain
    format: yaml
    path: ./ruleset/service-domains.yaml
    url: https://rules.example.net/service-domains.yaml
    interval: 86400

rules:
  - DOMAIN,internal.example.net,DIRECT
  - RULE-SET,service-domains,업무 서비스
  - MATCH,노드 선택

behavior는 규칙 파일의 내용과 일치해야 합니다. 도메인 모음에는 domain 동작을, IP 대역 모음에는 ipcidr를 사용할 수 있으며, 여러 고전 규칙 유형이 섞인 모음에는 일반적으로 classical을 사용합니다. 코어 버전에 따라 format, 지원되는 동작 및 데이터 파일 형식이 다를 수 있으므로, 기존 규칙 세트를 가져오기 전에 클라이언트가 실제로 사용하는 코어를 확인해야 합니다. 클라이언트 화면에 표시된 이름만 보고 판단해서는 안 됩니다.

mihomo는 논리 조합 기능도 제공하므로 AND, OR, NOT으로 여러 조건을 하나의 규칙으로 묶을 수 있습니다. 예를 들어 UDP 443만 처리하는 조건은 다음과 같이 작성할 수 있습니다.

rules:
  - AND,((NETWORK,UDP),(DST-PORT,443)),REJECT
  - MATCH,노드 선택

논리 규칙은 ‘모든 조건을 동시에 만족’하거나 ‘조건 중 하나를 만족’하는 복잡한 조건을 표현하는 데 적합하지만, 괄호·쉼표·중첩 단계에서 오류가 나기 쉽습니다. 이는 mihomo와 같은 호환 코어의 확장 기능이므로, 구형 정식 Clash 코어로 옮기면 인식되지 않을 수 있습니다. 설정의 가독성을 유지하려면 명확한 일반 규칙 두세 개로 해결할 수 있는 경우 굳이 깊게 중첩된 표현식으로 바꾸지 마세요.

PROOF / 07

규칙이 적용되지 않을 때 확인할 순서

규칙이 적용되지 않는 원인은 대개 단일 문법 오류가 아닙니다. ‘설정이 로드되었는가, 연결이 코어에 들어왔는가, 메타데이터가 예상과 일치하는가, 앞선 규칙에 가로채였는가’를 차례로 확인하는 방식이 가장 효과적입니다.

1. 현재 사용 중인 Profile 확인: 파일을 편집한 후 설정을 다시 로드하고 클라이언트에서 현재 활성화된 설정 이름을 확인하세요. 활성화되지 않은 사본을 수정해도 실행 결과는 바뀌지 않습니다.
2. 연결 정보 또는 로그에서 일치한 규칙 확인: 대상 도메인, 대상 IP, 프로세스, 네트워크 유형 및 최종 정책을 기록하세요. 더 앞에 있는 규칙이 일치한 것으로 표시되면 순서를 조정하거나 해당 규칙의 범위를 줄여야 합니다.
3. YAML 계층 확인:rules는 올바른 최상위 위치에 있어야 하며 목록 항목에는 하이픈을 사용해야 합니다. 전각 쉼표, 잘못된 들여쓰기 및 보이지 않는 문자도 파싱 실패를 일으킬 수 있습니다.
4. 정책 그룹 이름 확인: 규칙에서 참조하는 이름이 실제로 존재해야 합니다. 프록시 그룹 이름을 바꿨다면 기존 규칙의 대상 이름도 함께 수정하세요.
5. 도메인과 IP 구분: 애플리케이션이 IP로 직접 접속하면 도메인 규칙에 매칭할 호스트명이 없습니다. 암호화 DNS, TUN 또는 Fake-IP를 사용 중이라면 코어 로그를 함께 확인해 실제 메타데이터를 판단하세요.
6. 클라이언트 오버라이드 확인: 구독 업데이트, 스크립트 병합 및 그래픽 인터페이스의 규칙 오버라이드가 최종 순서를 바꿀 수 있으므로 실행 중인 설정을 기준으로 확인해야 합니다.
7. 코어 지원 여부 확인:GEOSITE, 논리 규칙, 일부 프로세스 필드 및 규칙 세트 형식은 모든 코어 버전에서 동일하게 지원되지 않습니다.

최소 규칙 세트로 재현하기

원래 설정에 수천 개의 규칙이 포함되어 있다면 테스트 규칙과 MATCH만 담은 최소 설정을 임시로 만들어 보세요. 먼저 대상 도메인이 정확한 규칙에 일치하는지 확인한 다음 접미사, 규칙 모음, GEOIP 및 프로세스 조건을 단계적으로 추가합니다. 한 번에 한 그룹씩만 추가하면 어떤 줄이 결과를 바꾸었는지 쉽게 찾을 수 있습니다.

rules:
  - DOMAIN,test.example.com,DIRECT
  - MATCH,노드 선택

최소 설정에서는 일치하지만 전체 설정에서는 일치하지 않는다면 대개 앞선 규칙, 오버라이드 순서 또는 규칙 세트 범위가 원인입니다. 최소 설정에서도 일치하지 않는다면 트래픽이 Clash에 들어오는지, 대상에 실제로 해당 도메인이 포함되어 있는지, 클라이언트가 현재 테스트 설정을 로드했는지 확인해야 합니다.

적용 전 검증 체크리스트

• 정확한 예외가 범위가 넓은 접미사, 키워드 및 규칙 모음보다 앞에 있는가.
• 모든 정책 이름이 프록시 그룹 이름과 일치하는가.
• IPv4, IPv6 및 LAN 주소 대역에 적절한 규칙 유형을 각각 사용했는가.
• no-resolve를 직접 조회할 필요가 없는 IP 규칙에만 사용했는가.
• 프로세스 규칙이 현재 운영체제와 코어의 식별 방식에 맞는가.
• 규칙 모음의 동작 유형이 콘텐츠 형식과 일치하는가.
• 목록 끝에 예상한 기본 처리만 하나 남아 있는가.

안정적인 Clash 사용자 지정 규칙은 규칙 수가 아니라 명확한 경계, 설명 가능한 순서와 재현 가능한 실행 결과에 달려 있습니다. 먼저 정확한 규칙으로 예외를 표현하고, 매칭 범위를 단계적으로 넓힌 다음, 로그에서 처음 일치한 규칙을 확인하는 방식이 키워드를 계속 추가하는 것보다 일반적으로 더 안정적입니다.