규칙 설정 예상 읽기 시간 13분

Clash 사용자 규칙 작성법: DOMAIN, IP-CIDR, GEOSITE 문법과 매칭 순서

Clash 규칙 필드별 작성법과 활용 사례를 정리하고, 규칙이 위에서부터 순서대로 매칭되며 첫 일치에서 멈추는 원칙과 no-resolve, MATCH, 규칙 집합 순서가 트래픽 분기에 미치는 영향을 설명합니다.

먼저 Clash 규칙의 실행 방식 이해하기

Clash, Clash Meta와 이후의 mihomo 코어는 연결 정보를 규칙 모듈에 전달합니다. 규칙 모듈은 대상 도메인, 대상 IP, 포트, 네트워크 유형, 프로세스 등의 정보를 확인한 뒤 프록시 그룹, 특정 노드, DIRECT 또는 REJECT를 선택합니다. 핵심은 규칙의 개수가 아니라 배치 순서입니다.

규칙은 위에서 아래로 하나씩 확인됩니다. 조건에 맞는 첫 번째 규칙이 발견되면 해당 연결에 대한 뒤의 규칙은 더 이상 검사하지 않습니다. 따라서 범위가 좁고 의도가 분명한 규칙은 앞에, 범위가 넓은 규칙은 뒤에 배치하고, 마지막에는 MATCH로 어디에도 해당하지 않는 연결을 처리하는 방식이 일반적입니다.

rules:
  - DOMAIN,api.example.com,개발 인터페이스
  - DOMAIN-SUFFIX,example.com,해외 사이트
  - GEOSITE,cn,DIRECT
  - GEOIP,CN,DIRECT,no-resolve
  - MATCH,기본 프록시

이 설정에서는 api.example.com에 접속할 때 첫 번째 규칙이 먼저 적용되어 “개발 인터페이스” 정책 그룹을 사용합니다. DOMAIN-SUFFIX,example.com 조건에도 맞지만 두 번째 규칙까지 실행되지는 않습니다. www.example.com에 접속하면 첫 번째 규칙을 건너뛰고 두 번째 규칙에서 매칭됩니다.

하나의 규칙에는 보통 어떤 필드가 들어갈까

일반적인 규칙은 쉼표로 구분하며 기본 구조는 “규칙 유형, 매칭 대상, 정책”입니다. 일부 규칙은 끝에 no-resolve 같은 옵션을 추가할 수 있습니다.

규칙 유형,매칭 대상,정책
IP-CIDR,203.0.113.0/24,노드 선택,no-resolve

정책 이름은 대소문자와 공백을 구분합니다. 규칙에 입력한 이름은 proxy-groups의 name과 완전히 같아야 합니다. 설정에는 “노드 선택”으로 정의되어 있는데 규칙에 “노드 선택 ” 또는 “프록시 선택”이라고 쓰면 설정 로드에 실패하거나 정책을 찾지 못할 수 있습니다.

DOMAIN, DOMAIN-SUFFIX, DOMAIN-KEYWORD는 어떻게 선택할까

도메인 규칙은 웹사이트와 API 트래픽을 분기할 때 적합합니다. 연결에 포함된 호스트 이름을 직접 기준으로 삼으므로 대상 서버가 현재 어떤 IP로 해석되는지에 의존하지 않습니다. CDN을 사용하거나 주소를 자주 바꾸거나 여러 네트워크 대역에 분산된 서비스라면 도메인 규칙이 고정 IP보다 안정적인 경우가 많습니다.

DOMAIN: 하나의 완전한 도메인만 매칭

rules:
  - DOMAIN,login.example.com,로그인 서비스
  - DOMAIN,cdn.example.net,정적 리소스

DOMAIN은 대상 도메인이 완전히 일치해야 합니다. 첫 번째 규칙은 login.example.com과 일치하지만 www.example.com, api.login.example.com, 루트 도메인 example.com과는 일치하지 않습니다. 단일 API, 로그인 도메인, 다운로드 도메인처럼 범위가 명확한 대상에 적합합니다.

DOMAIN-SUFFIX: 루트 도메인과 하위 도메인 매칭

rules:
  - DOMAIN-SUFFIX,example.com,해외 사이트
  - DOMAIN-SUFFIX,example.org,DIRECT

DOMAIN-SUFFIX,example.com은 example.com, www.example.com, a.b.example.com에 모두 적용됩니다. 앞에 별표를 붙일 필요가 없으며 *.example.com처럼 작성해서도 안 됩니다. 한 사이트의 웹페이지, 이미지, API가 같은 주 도메인의 여러 하위 도메인에 있다면 DOMAIN-SUFFIX가 더 간결합니다.

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

rules:
  - DOMAIN-KEYWORD,example,테스트 정책

이 규칙은 도메인에 example이 포함된 연결을 매칭하며, 문자열이 도메인 끝에 있을 필요는 없습니다. example.com뿐 아니라 example-cdn.net과 notexample.org도 일치할 수 있습니다. 적용 범위가 넓어 관련 없는 도메인까지 포함하기 쉬우므로 정확한 규칙 뒤에 배치하고, 가능한 한 고유한 키워드를 사용해야 합니다.

규칙 적합한 상황 주요 범위
DOMAIN 단일 API, 로그인 또는 다운로드 도메인 다른 하위 도메인은 포함하지 않음
DOMAIN-SUFFIX 전체 주 도메인과 모든 하위 도메인 같은 도메인에서 용도가 다른 서비스까지 포함할 수 있음
DOMAIN-KEYWORD 도메인 구조는 바뀌지만 키워드는 일정함 오매칭 가능성이 높음

IP-CIDR, IP-CIDR6와 no-resolve의 역할

IP-CIDR은 IPv4 주소 또는 네트워크 대역을 기준으로 매칭하고, IP-CIDR6은 IPv6에 사용합니다. CIDR 뒤의 숫자는 네트워크 프리픽스 길이를 뜻합니다. 예를 들어 /32는 단일 IPv4 주소, /24는 일반적으로 연속된 IPv4 주소 256개를 포함하며, 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,203.0.113.8/32,전용 노드,no-resolve
  - IP-CIDR6,2001:db8::/32,전용 노드,no-resolve

앞의 두 규칙은 사설 네트워크를 직접 연결할 때 자주 사용됩니다. 세 번째 예시는 하나의 IPv4 주소만 매칭합니다. 예시에 나온 203.0.113.0/24와 2001:db8::/32는 문서용 테스트 주소이므로 실제 서비스 네트워크 대역으로 바로 사용해서는 안 됩니다.

no-resolve는 “DNS를 사용하지 않음”이 아니다

연결에 도메인 정보만 있을 때 IP 규칙이 판단하려면 대상 IP가 필요합니다. no-resolve가 없으면 코어가 규칙 매칭을 위해 도메인 조회를 한 번 수행할 수 있습니다. no-resolve를 추가하면 해당 IP 규칙은 규칙 판단만을 위해 도메인을 IP로 능동적으로 해석하지 않습니다. 연결 자체에 대상 IP가 이미 포함되어 있다면 규칙은 정상적으로 매칭됩니다.

- DOMAIN-SUFFIX,example.com,해외 사이트
- IP-CIDR,203.0.113.0/24,전용 노드,no-resolve
- GEOIP,CN,DIRECT,no-resolve
- MATCH,기본 프록시

이 순서는 먼저 기존 도메인 정보로 판단한 다음 이미 확인된 IP를 검사하고, 마지막에 기본 정책으로 처리합니다. 규칙 단계에서 발생하는 추가 조회에 따른 지연과 DNS 의존성을 줄일 수 있습니다. 다만 no-resolve는 Clash의 DNS 모듈을 끄지 않으며, 애플리케이션이 직접 보내는 DNS 요청도 바꾸지 않습니다.

GEOIP와 고정 네트워크 대역의 차이

GEOIP,CN,DIRECT는 GeoIP 데이터베이스를 사용해 대상 IP의 지역을 판단합니다. 넓은 범위의 지역별 트래픽 분기에 적합하지만, 데이터베이스의 분류가 서비스의 실제 소속과 같은 것은 아닙니다. 해외 브랜드가 중국 본토 CDN을 사용할 수도 있고, 중국 내 서비스가 해외 노드에 연결될 수도 있습니다. 따라서 중요한 서비스는 DOMAIN 또는 DOMAIN-SUFFIX를 먼저 작성하고, GEOIP는 뒤에서 넓은 지역 판단을 담당하게 하는 편이 좋습니다.

GEOSITE, GEOIP와 규칙 집합을 함께 사용하는 방법

mihomo는 GEOSITE 규칙을 지원합니다. GEosite 데이터는 지역, 서비스, 용도 같은 범주별로 도메인을 정리합니다. 수많은 DOMAIN-SUFFIX를 직접 작성하는 수고를 줄여 주지만, 실제로 사용할 수 있는 분류는 클라이언트에 포함되었거나 내려받은 geosite 데이터 파일에 따라 달라집니다.

rules:
  - GEOSITE,category-ads-all,REJECT
  - GEOSITE,private,DIRECT
  - GEOSITE,cn,DIRECT
  - GEOIP,private,DIRECT,no-resolve
  - GEOIP,CN,DIRECT,no-resolve
  - MATCH,노드 선택

위 순서는 먼저 광고 범주를 처리한 뒤 사설 도메인과 중국 본토 도메인을 처리하고, 이어서 이미 확인된 사설 IP와 중국 본토 IP를 처리합니다. 매칭되지 않은 연결은 “노드 선택”으로 전달됩니다. GEOSITE,cn,DIRECT를 사용자 지정 프록시 도메인보다 앞에 두면 해당 도메인이 cn 분류에 포함된 경우 먼저 직접 연결됩니다.

규칙 집합은 RULE-SET으로 실행 대기열에 삽입된다

rule-providers는 규칙 집합의 출처, 형식, 업데이트 주기와 로컬 저장 위치를 정의하고, RULE-SET은 해당 규칙 집합이 기본 규칙 대기열에서 실행될 위치를 결정합니다. provider를 선언했다고 규칙이 자동으로 실행되는 것은 아니며, rules에서 반드시 참조해야 합니다.

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

  service-rules:
    type: http
    behavior: classical
    format: yaml
    path: ./ruleset/service-rules.yaml
    url: https://rules.example.net/service-rules.yaml
    interval: 86400

rules:
  - DOMAIN,api.example.com,전용 노드
  - RULE-SET,service-rules,노드 선택
  - RULE-SET,direct-sites,DIRECT
  - GEOIP,CN,DIRECT,no-resolve
  - MATCH,노드 선택

interval: 86400은 86400초, 즉 24시간마다 업데이트를 확인한다는 뜻입니다. behavior: domain에는 도메인 항목이, behavior: ipcidr에는 네트워크 대역이 들어갑니다. behavior: classical은 규칙 유형이 포함된 클래식 규칙을 담을 수 있습니다. provider의 실제 형식은 파일 내용과 일치해야 합니다.

payload:
  - example.com
  - api.example.net
  - +.service.example.org

다음은 domain 동작 규칙 집합에서 흔히 사용하는 YAML 구조입니다. classical 동작을 사용하면 항목에 보통 규칙 유형이 포함됩니다. 예를 들어 DOMAIN-SUFFIX,example.com 또는 IP-CIDR,203.0.113.0/24,no-resolve와 같이 작성합니다. 정책은 provider의 각 항목에 넣지 않고, 기본 설정의 RULE-SET,규칙 집합 이름,정책에서 일괄 지정합니다.

MATCH 기본 처리와 자주 발생하는 순서 오류

MATCH에는 매칭 대상이 없으므로 여기까지 도달한 모든 연결이 일치합니다. 따라서 일반적으로 규칙 목록의 마지막에만 배치해야 합니다. MATCH는 분류되지 않은 트래픽의 기본 경로를 결정합니다. 고정 노드보다 수동 전환이 가능한 프록시 그룹을 선택하는 경우가 많아 노드를 사용할 수 없을 때 조정하기 쉽습니다.

proxy-groups:
  - name: 노드 선택
    type: select
    proxies:
      - 자동 선택
      - DIRECT

rules:
  - DOMAIN-SUFFIX,intranet.example,DIRECT
  - GEOSITE,cn,DIRECT
  - GEOIP,CN,DIRECT,no-resolve
  - MATCH,노드 선택

오류 1: MATCH를 너무 앞에 배치

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

두 번째 규칙은 실행될 기회를 영원히 얻지 못합니다. 모든 연결이 첫 번째 규칙에서 이미 매칭되기 때문입니다. 설정은 정상적으로 로드될 수 있지만 트래픽 분배 결과는 “모두 같은 정책을 사용하는” 것처럼 나타납니다.

오류 2: 포괄적인 접미사 규칙이 정확한 예외를 덮어씀

rules:
  - DOMAIN-SUFFIX,example.com,DIRECT
  - DOMAIN,video.example.com,미디어 노드

video.example.com은 두 규칙에 모두 해당하지만 첫 번째 규칙에 먼저 매칭됩니다. 올바른 방법은 정확한 예외를 앞에 배치하는 것입니다:

rules:
  - DOMAIN,video.example.com,미디어 노드
  - DOMAIN-SUFFIX,example.com,DIRECT

오류 3: 정책 이름과 프록시 그룹 이름이 다름

규칙의 “노드 선택”은 proxy-groups에 이미 정의되어 있어야 합니다. 실제 프록시 그룹 이름이 “프록시 선택”이라면 설정을 로드할 때 정책을 찾을 수 없다는 오류가 발생할 수 있습니다. 이름, 공백, 대소문자를 하나씩 정확히 확인해야 합니다.

오류 4: 포트를 서비스 식별자로 사용

DST-PORT,443,노드 선택은 특정 웹사이트가 아니라 대상 포트가 443인 모든 연결에 적용됩니다. 최신 HTTPS, 애플리케이션 API, 일부 암호화 DNS 서비스도 443을 사용합니다. 포트 규칙은 프로토콜 범위가 명확할 때 적합하며 도메인 규칙을 대신하기에는 적절하지 않습니다.

rules:
  - DST-PORT,22,개발 네트워크
  - NETWORK,udp,UDP 정책
  - MATCH,노드 선택

포트 22도 SSH가 아닌 서비스에 사용될 수 있으며, 반대로 SSH가 다른 포트에서 실행될 수도 있습니다. 업무 네트워크를 다룰 때는 단일 필드만 보지 말고 대상 도메인, 대상 네트워크 대역, 포트를 함께 확인해야 합니다.

유지 관리하기 쉬운 규칙 정렬 템플릿

실제 설정에 정답인 순서가 하나뿐인 것은 아니지만, “로컬 예외, 정확한 서비스, 도메인 일괄 규칙, IP 및 지역, 기본 정책” 순으로 구성할 수 있습니다. 다음 템플릿은 일반적인 데스크톱 환경에 적합하며, 이름은 설정에 이미 존재하는 프록시 그룹으로 바꿔야 합니다.

rules:
  # 1. 로컬 네트워크 및 명확한 예외
  - DOMAIN,router.lan,DIRECT
  - DOMAIN-SUFFIX,home.arpa,DIRECT
  - 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

  # 2. 단일 서비스의 정확한 정책
  - DOMAIN,api.example.com,전용 노드
  - DOMAIN-SUFFIX,example.net,미디어 노드

  # 3. 외부 규칙 집합
  - RULE-SET,work-services,업무 네트워크
  - RULE-SET,streaming-services,미디어 노드
  - RULE-SET,direct-sites,DIRECT

  # 4. 넓은 범위의 도메인 및 지역 판단
  - GEOSITE,private,DIRECT
  - GEOSITE,cn,DIRECT
  - GEOIP,private,DIRECT,no-resolve
  - GEOIP,CN,DIRECT,no-resolve

  # 5. 최종 기본 처리
  - MATCH,노드 선택

사설 IPv4 네트워크 대역에는 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16이 포함됩니다. 루프백 주소인 127.0.0.0/8도 일반적으로 직접 연결해야 합니다. 이러한 규칙을 명시적으로 추가할지는 기존 설정의 사설 네트워크 규칙 집합과 클라이언트 설정에 따라 다르며, 중복 규칙이 매칭 능력을 높여 주지는 않습니다.

규칙 수와 업데이트 범위 관리

설정 변경 후 규칙 적용 여부 확인 방법

YAML을 수정한 뒤 첫 단계는 설정을 다시 로드할 수 있는지 확인하는 것입니다. 데스크톱 클라이언트는 보통 설정 편집 및 재로드 메뉴를 제공합니다. 예를 들어 설정 관리 화면에서 현재 설정을 열고 파일을 편집해 저장한 다음 “다시 로드”를 실행하거나 해당 설정을 다시 선택합니다. 클라이언트마다 메뉴 이름은 다를 수 있지만 파일만 저장하고 재로드를 건너뛰어서는 안 됩니다.

mihomo 외부 컨트롤러를 사용하는 경우 일반적인 수신 주소는 127.0.0.1:9090입니다. HTTP와 SOCKS 혼합 포트는 보통 7890, DNS 수신 포트는 보통 1053입니다. 이 숫자들은 흔한 기본값일 뿐이므로 현재 설정의 external-controller, mixed-port, dns.listen 값을 기준으로 확인해야 합니다.

네 단계로 매칭 결과 확인하기

  1. 설정 재로드: YAML 들여쓰기 오류, 알 수 없는 규칙 유형, 존재하지 않는 정책에 대한 오류가 없는지 확인합니다.
  2. 기존 연결 정리: 대상 애플리케이션의 기존 연결을 닫고 필요하면 종료한 뒤 다시 실행합니다. 이미 연결된 장시간 연결은 새 규칙이 추가되어도 자동으로 다시 분기되지 않습니다.
  3. 단일 테스트 실행: 백그라운드 동기화, 업데이트, 푸시 연결의 영향을 줄이기 위해 대상 도메인 하나만 접속합니다.
  4. 연결 상세 정보 확인: 클라이언트의 “연결” 화면에서 Host, 대상 IP, 매칭된 규칙, 사용한 프록시 체인을 확인합니다.

DOMAIN,api.example.com,전용 노드를 추가했는데 연결 상세 정보에 DOMAIN-SUFFIX,example.com이 매칭된 것으로 표시된다면, 먼저 정확한 규칙이 접미사 규칙보다 앞에 있는지 확인해야 합니다. IP-CIDR이 표시된다면 애플리케이션이 IP에 직접 연결했거나 도메인 정보가 코어에 전달되지 않았을 가능성이 있습니다.

TUN 모드에서도 같은 규칙 순서를 따른다

TUN 모드는 트래픽이 코어로 들어오는 방식을 바꿀 뿐, 규칙을 병렬로 매칭하도록 바꾸지는 않습니다. 시스템 프록시는 일반적으로 프록시 설정을 따르는 애플리케이션에 적용되고, TUN 모드는 더 많은 TCP, UDP 트래픽과 시스템 프록시를 읽지 않는 프로그램까지 인계할 수 있습니다. 트래픽이 코어에 들어온 뒤에는 여전히 첫 번째 규칙부터 아래로 검사합니다.

Fake-IP DNS 강화 모드를 사용하면 애플리케이션이 먼저 예약 주소를 받을 수 있으며, 코어는 매핑 정보를 이용해 도메인을 복원한 뒤 규칙 판단에 활용합니다. 따라서 연결 화면에 Fake-IP가 표시된다고 DOMAIN 규칙이 작동하지 않는 것은 아닙니다. 애플리케이션이 하드코딩된 IP에만 연결한다면 IP-CIDR, GEOIP 또는 프로세스 규칙을 사용해야 합니다.

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

규칙 문제는 설정 로드, 트래픽 진입 경로, 연결 정보, 규칙 위치의 네 단계로 나누어 확인하는 것이 좋습니다. 먼저 코어가 새 설정을 사용하고 있는지 확인한 다음 대상 트래픽이 Clash로 들어오는지 판단하고, 마지막으로 규칙 자체를 점검합니다. 문법만 계속 수정하면 시스템 프록시가 켜져 있지 않거나 설정이 재로드되지 않은 문제를 놓치기 쉽습니다.

설정을 로드할 수 있는가

대상 트래픽이 코어로 들어오는가

시스템 프록시 모드에서는 애플리케이션이 시스템 프록시 설정을 무시할 수 있습니다. TUN 모드에서도 라우팅 제외, 인터페이스 충돌, 권한 문제가 발생할 수 있습니다. 연결 목록에 대상 애플리케이션이 전혀 보이지 않는다면 규칙을 계속 수정하기보다 먼저 진입 경로를 확인해야 합니다. 브라우저의 기존 연결은 연결 재사용으로 계속 작동할 수 있어 탭을 닫는 것만으로 하위 연결이 즉시 끊기지 않을 수 있습니다.

코어가 받은 정보는 도메인인가 IP인가

DOMAIN 계열 규칙에는 도메인 정보가 필요합니다. 애플리케이션이 IP에 직접 접속한다면 IP-CIDR, GEOIP, 포트, 네트워크 유형 또는 프로세스 정보에 의존해야 합니다. 반대로 IP-CIDR에 no-resolve를 추가했을 때 현재 연결에 도메인만 있다면 해당 규칙은 건너뛰며, 능동적으로 조회한 뒤 비교하지 않습니다.

앞에 더 넓은 범위의 규칙이 있는가

대상 규칙 위에서 DOMAIN-SUFFIX, DOMAIN-KEYWORD, RULE-SET, GEOSITE, GEOIP, MATCH를 차례로 확인하세요. 어느 하나라도 먼저 매칭되면 대상 규칙은 실행되지 않습니다. 점검할 때는 정확한 규칙을 잠시 규칙 목록 맨 앞에 옮겨 볼 수 있습니다. 검증이 끝나면 다시 합리적인 구조의 위치로 돌려놓습니다.

규칙 작성 시 바로 적용할 결론

유지 관리하기 좋은 규칙은 항목 수가 많은 설정이 아니라 각 규칙의 범위와 위치를 설명할 수 있는 설정입니다. 정확한 예외를 먼저 작성하고 일괄 규칙 집합을 배치한 뒤 지역 판단과 MATCH 기본 처리를 추가하면, 문제가 생겨도 실행 순서를 따라 빠르게 원인을 찾을 수 있습니다.

Clash 클라이언트 다운로드 Windows, macOS 및 모바일 버전 확인