사용자 지정 규칙 작성법: DOMAIN·IP-CIDR 문법과 매칭 우선순위 총정리

Clash 규칙의 구성부터 이해하기

Clash와 mihomo의 기본 규칙은 일반적으로 쉼표로 구분되며, 가장 흔한 구조는 “규칙 유형, 매칭 대상, 대상 정책”입니다. 예를 들어 DOMAIN-SUFFIX,github.com,PROXY는 대상 도메인이 github.com으로 끝날 때 연결을 PROXY라는 정책 그룹에 맡긴다는 뜻입니다. 정책 이름은 대소문자를 구분하므로 proxy-groups에 지정한 이름과 정확히 일치해야 합니다.

rules:
  - DOMAIN,api.example.com,DIRECT
  - DOMAIN-SUFFIX,github.com,PROXY
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - GEOIP,CN,DIRECT
  - MATCH,FINAL

여기서 DIRECT와 REJECT는 내장 동작이고, PROXY와 FINAL은 사용자가 정의한 정책 그룹일 수 있습니다. 규칙이 특정 서버를 직접 지정해야 유효한 것은 아닙니다. 일반적으로 규칙은 정책 그룹을 가리키고, 정책 그룹이 수동 선택, 지연 시간 테스트 또는 장애 조치를 통해 실제 노드를 결정하도록 구성합니다.

YAML 들여쓰기와 규칙 위치

rules는 설정 파일의 최상위 필드이며, 목록 항목은 보통 공백 두 칸으로 들여씁니다. Tab 문자는 사용하지 말고, 규칙을 proxy-groups나 rule-providers 내부에 넣지도 마세요. 수정 후에는 클라이언트에서 설정을 다시 불러와야 합니다. 파일만 저장하고 다시 불러오지 않으면 실행 중인 코어가 이전 내용을 계속 사용할 수 있습니다.

일반적인 데스크톱 클라이언트를 예로 들면, 먼저 설정 화면에서 현재 활성화된 설정을 열고 편집을 마친 뒤 “저장” 또는 “다시 불러오기”를 실행합니다. 그런 다음 “연결” 화면에서 대상 도메인에 접속해 해당 연결에 표시된 규칙 유형과 정책 경로를 확인하세요. 클라이언트마다 메뉴 이름은 조금씩 다르지만, 현재 설정 파일·코어 실행 상태·연결 로그가 서로 일치하는지 확인하는 것이 핵심입니다.

DOMAIN·DOMAIN-SUFFIX·DOMAIN-KEYWORD 선택 기준

DOMAIN: 전체 도메인만 정확히 매칭

DOMAIN은 단일 호스트 이름에 적합합니다. 아래 규칙은 api.example.com만 매칭하며 www.example.com에는 적용되지 않고, v2.api.example.com까지 자동으로 포함하지도 않습니다.

rules:
  - DOMAIN,api.example.com,PROXY

로그인 API, 업데이트 서버 또는 특정 고정 API에 별도의 정책을 지정해야 한다면 DOMAIN을 우선 사용하세요. 적용 범위가 분명해 동일한 주 도메인 아래의 다른 서비스에 의도치 않게 적용될 가능성이 낮습니다.

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

DOMAIN-SUFFIX,example.com,PROXY는 일반적으로 example.com, www.example.com, a.b.example.com을 모두 매칭합니다. 사용자 지정 도메인 라우팅에서 가장 자주 쓰이는 유형으로, 한 사이트의 여러 하위 도메인에 같은 정책을 적용할 때 적합합니다.

rules:
  - DOMAIN-SUFFIX,example.com,PROXY
  - DOMAIN-SUFFIX,example.net,DIRECT

접미사에는 도메인 자체만 입력하고 https://, 경로, 포트 또는 와일드카드를 붙이지 마세요. 올바른 값은 example.com이며 https://example.com/path이나 *.example.com은 올바르지 않습니다. Clash 규칙은 연결 대상과 매칭할 뿐 웹 URL의 전체 경로를 해석하지 않습니다.

DOMAIN-KEYWORD: 도메인 문자열 기준 매칭

DOMAIN-KEYWORD는 도메인에 지정한 문자열이 포함되어 있는지 확인합니다. 예를 들어 DOMAIN-KEYWORD,google,PROXY는 google이 들어간 여러 도메인을 매칭할 수 있습니다. 작성은 간단하지만 접미사 규칙보다 범위가 넓어 대상 서비스와 관계없는 도메인까지 함께 매칭될 수 있습니다.

규칙 유형	예시 대상	매칭 여부	활용 사례
`DOMAIN,api.example.com`	`api.example.com`	예	고정 API 또는 단일 호스트
`DOMAIN,api.example.com`	`v2.api.example.com`	아니요	하위 도메인까지 적용되지 않음
`DOMAIN-SUFFIX,example.com`	`img.example.com`	예	사이트 전체와 하위 도메인에 동일한 라우팅 적용
`DOMAIN-KEYWORD,example`	`example-cdn.net`	예	도메인이 분산되어 있고 안정적인 키워드가 있을 때

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

CIDR은 주소 범위를 나타냅니다

IP-CIDR은 IPv4 주소 또는 네트워크 대역을 매칭합니다. 192.168.1.0/24는 192.168.1.0부터 192.168.1.255까지를 포함하고, 1.1.1.1/32는 단일 IPv4 주소만 매칭합니다. IPv6에는 IP-CIDR6을 사용하며, 예시는 2001:db8::/32입니다.

rules:
  - 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,fc00::/7,DIRECT,no-resolve

이 규칙은 로컬 루프백, 가정용 LAN, 기업 내부망을 직접 연결할 때 자주 사용합니다. 컴퓨터가 HTTP 또는 mixed 포트를 통해 같은 네트워크 대역의 기기에 프록시를 공유한다면, 내부망 규칙을 넓은 범위의 프록시 규칙보다 앞에 두는 것이 좋습니다. 그래야 공유기 관리 페이지, NAS 또는 프린터 접속이 프록시 노드로 우회되지 않습니다.

no-resolve는 “DNS 비활성화”가 아닙니다

연결 대상이 아직 도메인 이름일 때, 코어는 특정 IP 규칙의 매칭 여부를 판단하기 위해 해당 도메인에 대응하는 IP를 먼저 조회할 수 있습니다. IP-CIDR 또는 GEOIP 규칙 끝에 no-resolve를 추가하면 해당 규칙을 확인하기 위해 도메인 조회를 능동적으로 실행하지 않는다는 뜻입니다. 현재 연결 대상이 원래 IP라면 규칙은 정상적으로 비교됩니다.

rules:
  - DOMAIN-SUFFIX,internal.example,DIRECT
  - IP-CIDR,10.20.0.0/16,DIRECT,no-resolve
  - GEOIP,CN,DIRECT,no-resolve
  - MATCH,PROXY

이 규칙 세트에서는 internal.example을 먼저 도메인 규칙으로 판단하고, 대상이 10.20.3.8처럼 직접 IP로 지정되면 IP-CIDR 규칙으로 판단합니다. no-resolve는 설정의 DNS 모듈을 끄지 않으며, 애플리케이션 자체의 DNS 조회를 막지도 않습니다. 또한 도메인 규칙을 IP 규칙으로 바꾸지도 않습니다.

IP 규칙이 불안정할 수 있는 이유

대형 사이트는 CDN을 자주 사용하므로 같은 도메인도 네트워크, 시간, DNS 서버에 따라 서로 다른 IP를 받을 수 있습니다. 일시적인 조회 결과를 /32 규칙으로 등록하면 단기간에는 매칭되지만 주소가 바뀌는 순간 작동하지 않습니다. 안정적인 도메인으로 설명할 수 있는 서비스에는 도메인 규칙을 우선 사용하세요. 대상 자체가 고정 주소이거나 내부망 대역인 경우, 또는 주소의 지역 정보를 기준으로 판단해야 할 때만 IP 규칙을 사용하는 것이 좋습니다.

규칙 우선순위: 유형이 아니라 위에서 아래로 처음 매칭된 규칙

Clash 규칙의 핵심은 순서에 따른 매칭입니다. 연결은 rules 목록의 첫 항목부터 확인하며, 한 규칙에 매칭되는 즉시 해당 규칙의 정책을 적용하고 뒤의 규칙은 더 이상 확인하지 않습니다. “DOMAIN이 원래 IP-CIDR보다 우선한다”거나 “REJECT가 자동으로 DIRECT보다 우선한다”와 같은 고정된 유형별 우선순위는 없습니다.

rules:
  - DOMAIN,download.example.com,DIRECT
  - DOMAIN-SUFFIX,example.com,PROXY
  - MATCH,FINAL

download.example.com에 접속하면 첫 번째 규칙이 이미 매칭되므로 결과는 DIRECT입니다. www.example.com에 접속했을 때는 첫 번째 규칙이 일치하지 않아 두 번째 규칙이 매칭되고 결과는 PROXY가 됩니다. 두 규칙의 순서를 바꾸면 다운로드 도메인이 먼저 접미사 규칙에 걸려 원래의 정확한 직접 연결 규칙은 실행되지 않습니다.

권장 규칙 배치 순서

로컬 장치, LAN, 그리고 직접 연결이 명시된 고정 대상.
일반 규칙보다 우선 적용해야 하는 정확한 DOMAIN, DOMAIN-SUFFIX 또는 IP-CIDR.
광고 차단, 서비스 분류, GEOSITE 또는 외부 규칙 세트.
지역 기준 GEOIP 규칙과 그 밖의 넓은 범위 판단.
마지막에는 MATCH로 앞에서 매칭되지 않은 연결을 처리합니다.

이는 코어가 강제하는 형식이 아니라 유지보수하기 편한 구성 방식입니다. 원칙은 “범위가 구체적일수록, 예외의 우선순위가 높을수록 앞에 배치한다”입니다. 구독에서 제공하는 대형 규칙 세트를 덮어써야 하는 예외 규칙은 해당 RULE-SET보다 앞에 있어야 합니다.

MATCH는 마지막에 배치하세요

MATCH에는 매칭 대상이 없으며, 아직 매칭되지 않은 모든 연결을 처리합니다. 기존 설정에서는 마지막 규칙 유형으로 FINAL이 보이기도 하지만, 현재 mihomo 설정에서는 일반적으로 MATCH를 사용합니다. 어느 쪽이든 목록 중간에 배치하면 뒤의 규칙은 실행될 기회를 얻지 못합니다.

rules:
  - DOMAIN-SUFFIX,example.org,DIRECT
  - RULE-SET,private,DIRECT
  - RULE-SET,streaming,MEDIA
  - GEOIP,CN,DIRECT,no-resolve
  - MATCH,PROXY

GEOIP·GEOSITE·RULE-SET의 구분

GEOIP는 대상 IP의 지역 정보를 기준으로 판단합니다

GEOIP,CN,DIRECT가 판단하는 대상은 대상 IP이지, 도메인 등록 국가나 서버 운영 회사 또는 웹페이지 언어가 아닙니다. 데이터베이스 내용에 따라 결과가 달라지므로 클라이언트 코어와 지리 데이터베이스를 정상적으로 사용할 수 있어야 합니다. CDN 엣지 노드, Anycast 주소, 데이터베이스 업데이트 지연 때문에 예상과 다른 분류가 발생할 수도 있습니다.

Fake-IP DNS 모드를 사용하면 도메인 연결에 도메인 정보가 남아 규칙 시스템이 이를 판단할 수 있으며, 실제 조회와 매핑은 코어가 처리합니다. 연결 목록에 198.18.0.0/16 범위의 Fake-IP가 보인다고 해서 이 전체 대역을 프록시 규칙으로 등록하지 마세요. 이 예약 대역은 Fake-IP 매핑용이며 실제 웹사이트 서버 주소를 의미하지 않습니다.

GEOSITE는 도메인 분류를 기준으로 합니다

mihomo는 지리 데이터 파일의 도메인 분류에 따라 매칭하는 GEOSITE 규칙을 지원합니다. 예를 들어 GEOSITE,cn,DIRECT는 도메인 집합을 사용하고, GEOIP,CN,DIRECT는 IP 지역 데이터를 사용합니다. 이름은 비슷하지만 판단 단계와 데이터 출처가 다릅니다.

rules:
  - GEOSITE,category-ads-all,REJECT
  - GEOSITE,cn,DIRECT
  - GEOIP,CN,DIRECT,no-resolve
  - MATCH,PROXY

GEOSITE 분류 이름은 현재 사용하는 데이터 세트에 따라 달라지며, 모든 구버전 Clash 코어가 지원하는 것은 아닙니다. 여러 클라이언트 사이에서 설정을 옮길 때는 먼저 코어 유형과 규칙 지원 여부를 확인하세요. 클라이언트의 “설정”에 있는 코어 정보 페이지에서 실제 실행 중인 코어를 확인하거나 명령줄에서 mihomo -v를 실행해 버전 출력을 확인할 수 있습니다.

RULE-SET으로 규칙 제공자 참조하기

RULE-SET에는 도메인을 직접 입력하는 것이 아니라 rule-providers에 정의된 규칙 모음을 참조합니다. 아래의 private는 제공자 키 이름과 일치해야 합니다. 제공자의 behavior는 domain, ipcidr, classical 중 하나일 수 있으며, 파일 내용도 해당 동작 유형에 맞아야 합니다.

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

rules:
  - RULE-SET,private,DIRECT
  - MATCH,PROXY

interval: 86400은 86400초, 즉 24시간마다 업데이트를 확인한다는 뜻입니다. 규칙 제공자 다운로드에 실패하면 먼저 URL에 접속할 수 있는지와 파일 형식이 behavior에 맞는지 확인한 뒤, 클라이언트가 ./ruleset/에 쓰기를 허용하는지 살펴보세요. 원격 주소를 rules에 붙여넣는 것만으로는 자동으로 규칙 세트가 만들어지지 않습니다.

포트·프로세스·네트워크 진입점 규칙

DST-PORT와 SRC-PORT

DST-PORT는 대상 포트를 기준으로 매칭합니다. 예를 들어 DST-PORT,443,PROXY는 HTTPS를 비롯해 443 포트를 사용하는 많은 연결에 적용되므로 범위가 매우 넓습니다. SRC-PORT는 로컬 소스 포트를 기준으로 판단하지만 애플리케이션의 임시 소스 포트는 자주 바뀌기 때문에 장기적인 라우팅 기준으로는 잘 사용하지 않습니다.

rules:
  - DST-PORT,22,DIRECT
  - DST-PORT,853,PROXY
  - MATCH,FINAL

포트 규칙에서 말하는 포트는 대상 서비스의 포트이지 Clash의 수신 포트가 아닙니다. 설정의 mixed-port: 7890은 로컬 프록시 진입점이 7890에서 수신 대기한다는 뜻이며, 웹사이트 접속 시 대상 포트인 80 또는 443과는 다른 개념입니다. mixed-port를 통과하는 모든 트래픽을 매칭하려고 DST-PORT,7890을 사용하지 마세요.

PROCESS-NAME 지원 여부는 플랫폼과 트래픽 가로채기 방식에 따라 달라집니다

mihomo는 일부 데스크톱 플랫폼에서 프로세스 이름이나 경로를 기준으로 라우팅할 수 있습니다. 예를 들어 PROCESS-NAME,curl,DIRECT와 같이 작성합니다. 프로세스 규칙은 운영체제가 제공하는 연결 및 프로세스 정보에 의존하므로 Android, iOS, 컨테이너 또는 권한이 제한된 환경에서는 사용하지 못할 수 있습니다. 실행 파일 이름도 운영체제마다 다릅니다. Windows에서는 .exe가 붙는 경우가 많으므로 설정을 옮길 때 다시 확인해야 합니다.

rules:
  - PROCESS-NAME,curl,DIRECT
  - PROCESS-NAME,backup-client.exe,DIRECT
  - DOMAIN-SUFFIX,example.com,PROXY
  - MATCH,FINAL

시스템 프록시 모드는 HTTP 또는 SOCKS 프록시 설정을 따르는 애플리케이션 트래픽을 주로 받으며, TUN 모드는 가상 네트워크 인터페이스를 통해 더 넓은 범위의 IP 트래픽을 가로챕니다. 두 모드에서도 규칙 순서는 변하지 않지만 코어가 확인할 수 있는 대상 정보는 달라질 수 있습니다. 프로세스 규칙을 점검하기 전에 해당 연결이 실제로 Clash에 들어왔는지 확인하고 연결 상세 정보에 프로세스 이름이 표시되는지 살펴보세요.

규칙이 적용되지 않을 때: 이 순서로 확인하세요

1단계: 현재 활성화된 설정을 편집했는지 확인

클라이언트에는 구독 설정, 로컬 설정, 오버라이드 설정이 동시에 저장되어 있을 수 있습니다. 먼저 현재 활성 항목의 이름과 업데이트 시간을 확인한 다음, 규칙이 최종 실행 설정에 반영됐는지 확인하세요. 일부 클라이언트는 구독을 업데이트할 때 원본 설정을 교체하므로 사용자 지정 내용은 클라이언트가 지원하는 오버라이드, 병합 설정 또는 별도 로컬 설정에 넣어야 합니다.

현재 설정을 방금 다시 불러왔는지 확인합니다.
설정 파싱 과정에서 YAML 들여쓰기 또는 필드 오류가 발생하지 않았는지 확인합니다.
대상 정책 그룹이 존재하며 이름과 대소문자가 정확히 일치하는지 확인합니다.
구독 업데이트 후 사용자 지정 규칙이 최종 설정에 여전히 남아 있는지 다시 확인합니다.

2단계: 연결 로그에서 실제 매칭 항목 확인

클라이언트의 “연결” 또는 “로그” 화면을 열고 요청을 다시 한 번 실행하세요. 브라우저는 기존 TCP, QUIC 또는 HTTP/2 연결을 재사용할 수 있으므로 규칙을 수정한 뒤 페이지를 새로고침하는 것만으로는 새 연결이 만들어지지 않을 수 있습니다. 해당 탭을 닫고 몇 초 후 다시 시도하거나 연결 목록에서 기존 연결을 종료해 보세요.

api.example.com을 직접 연결하고 싶은데 로그에 DOMAIN-SUFFIX,example.com이 매칭되어 프록시 그룹으로 들어간다면, 더 넓은 규칙이 앞에 배치된 것입니다. 로그에 바로 MATCH가 표시된다면 도메인 철자, 규칙 형식 또는 규칙 세트 로딩에 문제가 있을 가능성이 큽니다.

3단계: 도메인과 IP 중 무엇을 확인하는지 점검

애플리케이션이 IP에 직접 접속하면 DOMAIN 유형 규칙은 당연히 매칭되지 않습니다. 애플리케이션이 자체 암호화 DNS, 내부 캐시 또는 QUIC으로 연결을 설정하면 코어가 확인하는 정보가 브라우저 주소 표시줄과 다를 수도 있습니다. 연결 상세 정보의 Host, 대상 주소, 네트워크 유형, 프로세스 필드가 웹페이지 도메인만 보고 추측하는 것보다 정확합니다.

설정에서 TUN을 사용한다면 시스템 프록시 모드와 TUN 모드의 연결 기록을 일시적으로 비교할 수 있습니다. 다만 DNS, 규칙, 노드를 동시에 계속 변경하지는 마세요. 한 번에 변수 하나만 바꾸고, 먼저 트래픽이 코어로 들어오는지 확인한 다음 대상 정보와 규칙 순서를 차례로 확인하세요.

4단계: 규칙 이름만 보지 말고 정책 그룹 확인

규칙이 PROXY에 매칭됐다는 것은 연결이 해당 정책 그룹으로 전달됐다는 뜻일 뿐입니다. PROXY에서 현재 수동으로 DIRECT를 선택했다면 실제 출구는 직접 연결입니다. 지연 시간 테스트 그룹을 선택했다면 실제 노드는 그룹 내부의 테스트 결과로 결정됩니다. 연결 상세 정보에는 보통 “규칙 → 정책 그룹 → 노드”와 같은 전체 경로가 표시됩니다.

5단계: 최소 규칙 세트로 재현

대형 구독에는 수만 개의 규칙이 포함될 수 있어 전체 설정에서 항목을 직접 옮기면 충돌 원인을 판단하기 어렵습니다. 임시 로컬 설정을 만들고 필요한 프록시, 정책 그룹 하나, 테스트 규칙 두세 개, 마지막 MATCH만 남겨 보세요. 테스트가 성공하면 정확한 규칙을 정식 설정의 해당 규칙 세트 앞에 다시 추가합니다.

rules:
  - DOMAIN,test.example.com,DIRECT
  - DOMAIN-SUFFIX,example.com,PROXY
  - MATCH,DIRECT

테스트할 때 대상 도메인, 연결 시간, 매칭된 규칙, 최종 정책을 기록하세요. 매번 기존 연결을 먼저 종료하고 3회 연속 테스트합니다. 세 번 결과가 같아야 규칙 순서가 안정적으로 적용됐다고 볼 수 있습니다. 첫 번째에는 이전 정책이 매칭되고 뒤의 두 번에는 새 규칙이 매칭됐다면, 대개 매칭 알고리즘이 무작위로 바뀐 것이 아니라 연결 재사용이나 DNS 캐시 때문입니다.

유지보수하기 쉬운 전체 규칙 예시

아래 구조는 내부망과 명확한 예외를 먼저 처리한 뒤 광고, 서비스 분류, 중국 본토 도메인과 중국 본토 IP를 처리하고, 마지막에 나머지 연결을 프록시 그룹으로 보냅니다. 이는 배치 방식의 예시이며 정책 그룹 이름과 규칙 세트 주소는 실제 설정에 맞게 조정해야 합니다.

rules:
  # 로컬 장치 및 LAN
  - 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,fc00::/7,DIRECT,no-resolve

  # 명확한 예외
  - DOMAIN,updates.example.com,DIRECT
  - DOMAIN-SUFFIX,work.example,WORK
  - DOMAIN-SUFFIX,github.com,PROXY

  # 분류 규칙
  - GEOSITE,category-ads-all,REJECT
  - RULE-SET,private,DIRECT
  - RULE-SET,streaming,MEDIA

  # 광범위한 규칙
  - GEOSITE,cn,DIRECT
  - GEOIP,CN,DIRECT,no-resolve

  # 최종 처리
  - MATCH,PROXY

유지보수할 때 규칙 그룹에 주석을 달고 수동 예외는 대형 규칙 세트 앞에 모아 두세요. 수정할 때마다 먼저 명확한 도메인 하나, 중국 본토 사이트 하나, 프록시 사이트 하나, LAN 주소 하나(예: 라우터의 192.168.1.1)를 확인합니다. 네 가지 연결이 모두 예상대로 작동한 뒤 규칙 범위를 넓히세요.

규칙과 라우팅의 핵심은 항목을 무작정 늘리는 데 있지 않습니다. 각 규칙의 범위를 설명할 수 있고, 순서를 검증할 수 있으며, 매칭 결과를 로그로 재현할 수 있어야 합니다. 문제가 생기면 현재 설정, 연결 대상, 최초 매칭 규칙, 정책 경로, 실제 출구를 차례로 확인하면 대부분 원인을 빠르게 찾을 수 있습니다.