Clash 사용자 지정 규칙 작성법: DOMAIN 계열 문법과 매칭 우선순위 완벽 가이드

Clash 규칙 한 줄의 구조부터 이해하기

Clash의 규칙 시스템은 연결 특성에 따라 트래픽의 처리 경로를 결정합니다. 가장 일반적인 규칙은 규칙 유형, 매칭 대상, 정책의 세 부분으로 구성되며 각 필드는 영문 쉼표로 구분합니다. 도메인 규칙을 예로 들면, 다음 줄은 api.example.com에 접속할 때 DIRECT 정책을 사용한다는 뜻입니다:

DOMAIN,api.example.com,DIRECT

DOMAIN은 규칙 유형이고, api.example.com은 매칭 대상, DIRECT는 대상 정책입니다. 대상 정책은 내장 동작일 수도 있고, 설정에 이미 정의된 프록시나 정책 그룹 이름일 수도 있습니다. 대표적인 내장 동작으로는 DIRECT와 REJECT가 있습니다. 설정에 ‘노드 선택’이라는 정책 그룹이 있다면 규칙 끝에 ‘노드 선택’을 그대로 적을 수도 있습니다. 이름은 한 글자도 다르지 않아야 하며, 공백·대소문자·기호도 모두 이름의 일부입니다.

전체 규칙 목록은 어디에 둘까

기존 Clash YAML에서는 인라인 규칙을 최상위 rules 필드 아래에 작성합니다. 각 항목은 앞에 하이픈을 붙이며, 나열 순서가 실제 매칭 순서가 됩니다:

rules:
  - DOMAIN,api.example.com,DIRECT
  - DOMAIN-SUFFIX,example.com,노드 선택
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - GEOIP,CN,DIRECT
  - MATCH,노드 선택

설정 편집을 지원하는 GUI 클라이언트에서는 보통 「설정」→현재 설정 선택→「편집」 순서로 YAML을 엽니다. 클라이언트에 따라 버튼 이름이 ‘파일 편집’, ‘설정 보기’ 또는 ‘확장 설정’으로 표시될 수 있습니다. 저장한 뒤에는 설정을 다시 불러와야 합니다. 디스크의 파일만 수정하고 다시 로드하지 않으면 현재 실행 중인 커널은 이전 규칙을 계속 사용합니다.

DOMAIN, DOMAIN-SUFFIX, DOMAIN-KEYWORD의 차이

웹사이트 트래픽 분기에는 도메인 규칙을 우선 사용하는 것이 좋습니다. 요청 도메인을 바로 활용하므로 먼저 IP로 해석할 필요가 없기 때문입니다. 자주 쓰는 DOMAIN 계열 규칙 세 가지는 적용 범위가 서로 다르므로 이름이 비슷하다는 이유만으로 바꿔 쓸 수 없습니다.

규칙 유형	예시	매칭되는 대상	매칭되지 않는 대상
`DOMAIN`	`DOMAIN,api.example.com,DIRECT`	`api.example.com`	`www.example.com`、`v2.api.example.com`
`DOMAIN-SUFFIX`	`DOMAIN-SUFFIX,example.com,DIRECT`	`example.com` 및 모든 하위 도메인	`example.com.test`
`DOMAIN-KEYWORD`	`DOMAIN-KEYWORD,example,DIRECT`	도메인에 `example`이 포함된 연결	해당 연속 문자열을 포함하지 않는 도메인

DOMAIN: 완전한 호스트 이름만 매칭

DOMAIN은 하나의 특정 호스트 이름만 처리하고 싶을 때 적합합니다. 예를 들어 소프트웨어 업데이트 서버는 직접 연결하되, 같은 주 도메인의 다른 서비스 경로는 바꾸지 않을 수 있습니다:

DOMAIN,updates.example.com,DIRECT
DOMAIN,telemetry.example.com,REJECT
DOMAIN-SUFFIX,example.com,노드 선택

updates.example.com 요청은 첫 번째 규칙에서 매칭되어 중단되고, telemetry.example.com 요청은 두 번째 규칙에서 매칭됩니다. store.example.com 요청만 세 번째 접미사 규칙까지 내려갑니다. 예외를 유지하려면 정확한 규칙을 더 넓은 규칙보다 위에 배치해야 합니다.

DOMAIN-SUFFIX: 주 도메인과 모든 하위 도메인에 적용

DOMAIN-SUFFIX,example.com,노드 선택은 example.com, www.example.com, cdn.assets.example.com에 적용됩니다. 일반 문자열의 끝부분만 같다고 해서 fakeexample.com에 잘못 매칭되지는 않으며, 도메인 레이블 경계를 기준으로 판단합니다.

하나의 웹사이트는 로그인, API, 이미지, 정적 리소스용 하위 도메인을 함께 사용하는 경우가 많습니다. 이러한 하위 도메인이 모두 같은 정책을 따라야 한다는 점이 확인됐다면, 전체 도메인을 하나씩 적는 것보다 접미사 규칙 하나로 관리하는 편이 쉽습니다. 특정 하위 도메인에 예외가 필요하면 해당 DOMAIN 규칙을 접미사 규칙 위에 배치하세요.

DOMAIN-KEYWORD: 범위가 넓으므로 오매칭을 먼저 점검

DOMAIN-KEYWORD는 도메인에 지정한 문자열이 포함되어 있는지 확인합니다. 도메인이 자주 바뀌지만 일정한 브랜드 문자열을 공유하는 서비스에 적합한 반면, 이름만 비슷한 무관한 도메인까지 함께 포함할 수 있습니다. 키워드가 짧을수록 적용 범위가 넓어집니다. 예를 들어 cdn이라는 키워드는 서로 관련 없는 콘텐츠 전송 도메인 다수를 동시에 매칭할 수 있습니다.

DOMAIN-KEYWORD,company-service,노드 선택

DOMAIN 또는 DOMAIN-SUFFIX로 표현할 수 있다면 범위가 더 명확한 유형을 우선 사용하세요. 키워드 규칙은 정확한 도메인 및 접미사 규칙 뒤, IP 계열 규칙 앞에 배치하는 것이 적절합니다.

규칙 우선순위의 핵심은 하나뿐입니다: 위에서 아래로, 처음 매칭된 규칙

Clash는 모든 매칭 결과를 모은 다음 그중 ‘더 구체적인’ 규칙을 고르지 않습니다. 커널은 rules의 첫 줄부터 확인하고, 처음 매칭되는 규칙을 만나면 즉시 해당 정책을 적용하며 이후 규칙은 더 이상 확인하지 않습니다. 즉 규칙 우선순위는 설정 파일에 적힌 순서 그 자체입니다.

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

이 설정에서는 api.example.com이 첫 번째 DOMAIN-SUFFIX에 먼저 매칭되므로 두 번째 정확한 규칙은 절대 적용되지 않습니다. 올바른 방법은 예외를 더 넓은 규칙보다 앞에 두는 것입니다:

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

관리하기 쉬운 정렬 방식

가장 명확한 차단·직접 연결·지정 노드 예외, 예를 들어 단일 DOMAIN 규칙.
여러 서비스를 포괄하는 DOMAIN-SUFFIX, DOMAIN-KEYWORD 또는 GEOSITE.
로컬 네트워크·예약 주소·확인된 네트워크 대역의 IP-CIDR 및 IP-CIDR6.
국가 또는 지역별로 분류하는 GEOIP.
마지막에 기본 처리 규칙 MATCH 배치.

이는 문법상 강제되는 템플릿이 아니라 규칙이 서로 가려지는 문제를 줄이기 위한 실용적인 순서입니다. 실제로 우선 처리해야 하는 규칙은 더 앞에 둬야 합니다. 예를 들어 특정 IP 대역을 반드시 차단해야 한다면, 먼저 매칭될 수 있는 광범위한 직접 연결 규칙 뒤에 배치해서는 안 됩니다.

IP-CIDR, GEOIP, no-resolve의 실제 역할

IP-CIDR은 대상 IPv4 주소 또는 네트워크 대역을 기준으로 매칭하고, IP-CIDR6은 IPv6을 처리합니다. CIDR 뒤의 숫자는 네트워크 접두사 길이를 뜻합니다. 192.168.1.0/24는 192.168.1.0부터 192.168.1.255까지 포함하며, 10.0.0.0/8은 전체 10.0.0.0 사설 주소 대역을 포함합니다.

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,노드 선택

GEOIP는 대상 IP가 지리 데이터베이스에서 어느 지역으로 분류되는지에 따라 매칭합니다. 예를 들어 GEOIP,CN,DIRECT는 데이터베이스에서 중국 본토 주소로 판정된 연결을 직접 연결한다는 뜻입니다. 판단의 정확도는 커널이 실제로 불러온 GeoIP 데이터에 좌우되며, 클라우드 서비스·Anycast·주소 변경으로 인해 결과가 서버의 물리적 위치와 다를 수 있습니다.

IP 규칙이 DNS 조회를 유발할 수 있는 이유

애플리케이션이 연결을 시작할 때 커널이 받는 대상은 도메인일 수도 있고 이미 IP일 수도 있습니다. IP-CIDR 또는 GEOIP를 확인할 때 현재 도메인만 있다면, 커널은 대상 IP를 얻기 위해 도메인을 조회한 뒤 지정된 네트워크 대역이나 지역에 속하는지 판단해야 할 수 있습니다. 이것이 IP 규칙과 DNS 조회가 연결되는 이유입니다.

해당 매개변수를 지원하는 IP 계열 규칙 끝에 no-resolve를 추가하면 이 규칙을 확인하기 위해 도메인을 별도로 조회하지 않습니다. 연결에 대상 IP가 이미 포함되어 있다면 규칙은 정상적으로 매칭됩니다. 도메인만 있고 사용할 수 있는 대상 IP가 없다면 조회가 필요한 판단을 건너뛰고 뒤의 규칙을 계속 확인합니다.

IP-CIDR,203.0.113.0/24,노드 선택,no-resolve

no-resolve는 모든 상황에 적용하는 성능 향상 옵션이 아니며, DOMAIN·DOMAIN-SUFFIX·MATCH 뒤에 붙여서도 안 됩니다. 주로 IP 계열 규칙에 사용합니다. 적용 여부는 규칙의 목적에 따라 결정하세요. 로컬 네트워크 대역에는 대상이 원래 사설 IP이므로 보통 추가할 수 있지만, 도메인 조회 결과의 주소로 소속을 판단해야 한다면 이 옵션으로 해당 조회를 막아서는 안 됩니다.

Fake-IP 모드에서도 도메인 규칙을 먼저 배치해야 합니다

Fake-IP DNS 모드에서는 클라이언트가 매핑 주소를 먼저 받을 수 있지만, 커널은 도메인과 매핑 관계를 유지하므로 여전히 도메인 규칙으로 트래픽을 분기할 수 있습니다. 명확한 도메인 규칙을 IP 지리 규칙보다 앞에 두면 CDN 주소가 바뀌어 같은 서비스가 다른 정책으로 분류되는 문제를 줄일 수 있습니다. 사용할 수 있는 도메인 정보가 없거나 도메인 규칙이 매칭되지 않을 때만 IP 기반 판단이 더 중요해집니다.

mihomo에서 자주 쓰는 확장 규칙: GEOSITE, 포트, 프로세스

현재 Clash Meta 커널인 mihomo는 초기 Clash보다 더 다양한 규칙 유형을 지원합니다. 여러 커널에서 설정을 함께 사용해야 한다면 먼저 클라이언트가 실제로 어떤 커널을 실행하는지 확인하세요. 지원되지 않는 규칙 유형은 설정 로드 실패로 이어질 수 있습니다.

규칙	용도	예시
`GEOSITE`	도메인 분류 데이터베이스로 사이트 그룹 매칭	`GEOSITE,category-ads-all,REJECT`
`DST-PORT`	대상 포트 기준 매칭	`DST-PORT,22,DIRECT`
`SRC-IP-CIDR`	연결을 시작한 출발지 주소 기준 매칭	`SRC-IP-CIDR,192.168.1.50/32,DIRECT`
`PROCESS-NAME`	프로세스 이름 기준 매칭	`PROCESS-NAME,backup.exe,DIRECT`

GEOSITE는 데이터베이스에 있는 도메인 집합을 매칭하며 서버 IP가 어느 국가에 있는지를 기준으로 판단하지 않습니다. 반면 GEOIP는 IP 데이터베이스를 기반으로 합니다. 이름은 비슷하지만 처리 대상은 완전히 다릅니다. 설정에서 GEOSITE를 사용하기 전에 클라이언트가 해당 GeoSite 데이터를 설정하고 로드할 수 있는지 확인해야 합니다.

프로세스 규칙은 운영체제와 커널이 프로세스 정보를 얻을 수 있는지에 따라 달라집니다. TUN 모드에서는 플랫폼마다 프로세스 식별 지원 수준이 완전히 같지 않습니다. Windows·macOS·Linux에서 설정을 함께 사용해야 한다면 도메인 및 IP 규칙이 일반적으로 더 안정적입니다. 프로세스 규칙은 특정 장치에서 보조 조건으로 사용하는 편이 좋으며, 유일한 판단 기준으로 삼지는 마세요.

사용자 지정 규칙은 어느 줄에 넣어야 할까

사용자 지정 규칙의 적용 여부는 대개 ‘문법이 맞는가’보다 먼저 매칭되는 규칙보다 앞에 배치했는가에 달려 있습니다. 삽입 위치를 찾을 때는 먼저 설정 후반부의 GEOIP, 광범위한 RULE-SET, MATCH를 확인한 다음 새 규칙이 어느 동작을 덮어써야 하는지 판단하세요.

상황 1: 특정 도메인을 프록시에서 제외하기

기존 설정이 이미 DOMAIN-SUFFIX,example.com,노드 선택으로 전체 주 도메인을 처리하고 있다면 새로 추가하는 직접 연결 예외를 그 위에 배치해야 합니다:

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

상황 2: 특정 네트워크 대역을 항상 프록시로 연결하기

해당 네트워크 대역이 GEOIP,CN,DIRECT에 먼저 매칭될 수 있다면 네트워크 대역 규칙을 GEOIP보다 앞에 넣어야 합니다:

rules:
  - IP-CIDR,198.51.100.0/24,노드 선택,no-resolve
  - GEOIP,CN,DIRECT
  - MATCH,노드 선택

상황 3: 구독 설정에서 규칙을 계속 유지하기

구독으로 생성된 YAML을 직접 편집하면 다음 업데이트 전까지만 유지되는 경우가 많습니다. 구독을 새로 고치면 클라이언트가 원격 콘텐츠로 로컬 사본을 덮어쓰는 것이 일반적입니다. 더 안정적인 방법은 클라이언트가 제공하는 설정 오버라이드, 설정 병합 또는 확장 스크립트를 사용해 사용자 지정 규칙을 구독 규칙보다 앞에 삽입하는 것입니다. 구체적인 메뉴 위치는 현재 사용 중인 클라이언트에 따라 다르지만, 흔히 「설정」→「설정 관리」→「오버라이드」로 이동하거나 현재 구독 메뉴에서 「확장 설정」을 선택합니다.

수십 개 이상의 규칙을 관리해야 한다면 rule-providers를 사용할 수 있습니다. 규칙 집합은 별도로 업데이트하고, 주 설정에서는 RULE-SET으로 참조하기만 합니다:

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

rules:
  - RULE-SET,private-sites,DIRECT
  - GEOIP,CN,DIRECT
  - MATCH,노드 선택

behavior: domain은 규칙 집합의 페이로드가 도메인 유형임을 뜻합니다. 규칙 집합에 DOMAIN·IP-CIDR 같은 완전한 규칙이 함께 들어 있다면 전체 규칙에 맞는 classical 동작을 사용해야 합니다. 제공자 유형, 파일 형식, 실제 콘텐츠는 서로 일치해야 하며, 완전한 Clash 규칙을 도메인 페이로드만 받는 집합에 그대로 넣어서는 안 됩니다.

저장 후 규칙이 실제로 매칭됐는지 확인하는 방법

규칙 검증은 웹페이지가 열리는지만 확인해서는 안 됩니다. 페이지가 정상적으로 열리는 이유가 직접 연결, 프록시, 캐시 또는 다른 네트워크 경로일 수 있기 때문입니다. 설정 로드 상태, 연결 기록, 실제로 매칭된 규칙을 함께 확인해야 합니다.

설정을 저장하고 다시 로드한 뒤, 화면에 YAML 파싱 오류나 규칙 유형 오류가 없는지 확인합니다.
대상 애플리케이션의 기존 연결을 정리하고, 필요하면 애플리케이션을 완전히 종료한 후 다시 엽니다.
클라이언트의 「연결」 페이지에서 도메인으로 대상 요청을 필터링합니다.
해당 연결에 표시된 규칙 유형, 규칙 내용, 최종 정책 그룹을 확인합니다.
주 도메인, 하위 도메인, 매칭되면 안 되는 유사 도메인을 각각 테스트해 적용 범위가 예상과 맞는지 확인합니다.

예를 들어 DOMAIN-SUFFIX,example.com,DIRECT를 테스트할 때 example.com, api.example.com, example.com.test를 차례로 확인할 수 있습니다. 앞의 두 주소는 매칭되어야 하고 세 번째는 매칭되면 안 됩니다. 정확한 규칙을 테스트할 때는 v2.api.example.com도 추가하세요. 이 주소는 DOMAIN,api.example.com,DIRECT에서 같은 도메인으로 취급되지 않아야 합니다.

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

먼저 위쪽 규칙에 가로채이지 않았는지 확인: 연결 상세 정보에서 실제로 매칭된 규칙을 찾으세요. 사용자 지정 항목을 목록 끝에서 계속 옮기는 것만으로는 해결되지 않습니다.
다음으로 정책 이름 확인: 규칙 끝의 이름은 정책 그룹 이름과 완전히 일치해야 합니다.
현재 설정 확인: 편집한 파일이 클라이언트에서 실제로 사용 중인 설정이 아닐 수 있습니다.
기존 연결 확인: 규칙을 변경해도 이미 연결된 TCP 연결의 경로가 다시 결정되지는 않는 경우가 많습니다.
DNS와 대상 유형 확인: 애플리케이션이 IP에 직접 연결하거나 다른 하위 도메인을 사용할 수 있으며, QUIC의 UDP 연결일 수도 있습니다.
커널 호환성 확인:GEOSITE, 논리 조합 및 일부 프로세스 규칙은 mihomo 지원이 필요합니다.

순서를 바로 점검할 수 있는 규칙 예시

아래 구조는 ‘단일 도메인 예외, 도메인 집합, 사설 네트워크 대역, 지역 규칙, 최종 기본 처리’ 순서를 보여줍니다. 정책 그룹 이름은 자신의 설정과 일치해야 합니다:

rules:
  - DOMAIN,login.example.com,DIRECT
  - DOMAIN,ads.example.com,REJECT
  - DOMAIN-SUFFIX,example.com,노드 선택
  - GEOSITE,category-ads-all,REJECT
  - IP-CIDR,127.0.0.0/8,DIRECT,no-resolve
  - IP-CIDR,10.0.0.0/8,DIRECT,no-resolve
  - IP-CIDR,172.16.0.0/12,DIRECT,no-resolve
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - IP-CIDR6,::1/128,DIRECT,no-resolve
  - IP-CIDR6,fc00::/7,DIRECT,no-resolve
  - GEOIP,CN,DIRECT
  - MATCH,노드 선택

이 예시에서는 로그인 도메인을 먼저 직접 연결하고, 광고 하위 도메인은 우선 차단하며, 나머지 example.com 서비스는 ‘노드 선택’으로 보냅니다. 그다음 일반 광고 분류, 사설 주소, 지역 IP를 확인합니다. 마지막으로 매칭되지 않은 모든 연결은 MATCH에 전달합니다. 규칙을 추가할 때 ‘기존 규칙 중 어느 규칙을 덮어써야 하는가’를 먼저 정하면 삽입 위치도 대개 바로 결정됩니다.

규칙 관리의 핵심은 개수를 늘리는 것이 아니라 적용 범위를 제어하는 데 있습니다. 먼저 정확한 도메인을 사용하고, 하위 도메인 전체가 같은 정책을 따르는지 확인한 뒤 접미사를 사용하세요. IP 규칙에서는 조회 허용 여부를 명확히 하고, 광범위한 분류와 기본 처리 규칙은 뒤쪽에 배치합니다. 수정이 끝나면 연결 상세 정보에서 매칭 항목을 확인하세요. 단순히 웹페이지 결과만 보는 것보다 문제 위치를 훨씬 빠르게 찾을 수 있습니다.