Clash 사용자 규칙 설정법: DOMAIN-SUFFIX·IP-CIDR 매칭 순서와 우선순위

규칙 우선순위의 기본: 위에서부터 확인해 처음 일치하는 규칙 적용

Clash 사용자 규칙은 “더 정확하게 쓰면 자동으로 우선 적용”되는 방식이 아닙니다. 규칙 모드에서는 목록을 위에서부터 확인하고, 처음 일치한 규칙에 따라 연결의 아웃바운드 정책을 정합니다. 이후 규칙은 더 이상 확인하지 않습니다. 따라서 특정 도메인 예외를 위에, 도메인 접미사 규칙을 그 아래에 두고 MATCH는 목록 맨 마지막에 배치하세요. 노드를 계속 바꾸기보다 규칙 순서를 조정하는 편이 트래픽 분기 오류를 바로잡는 데 효과적일 때가 많습니다.

이 글은 Clash에서 널리 사용하는 규칙 문법을 바탕으로 설명하며, 규칙 모음은 mihomo(Clash Meta) 사용법을 다룹니다. 클라이언트마다 설정 편집 위치와 덮어쓰기 방식, 코어 버전이 다르므로 클라이언트 이름만으로 확장 옵션의 지원 여부를 판단할 수는 없습니다. 먼저 DOMAIN, DOMAIN-SUFFIX, IP-CIDR, MATCH로 기본 분기를 구성하고 매칭 결과를 확인한 뒤 확장하세요.

시스템 프록시와 TUN 모드는 트래픽이 코어로 들어오는 경로를 정하고, 규칙은 들어온 트래픽의 아웃바운드를 선택합니다. TUN을 켠다고 특정 규칙의 우선순위가 높아지는 것은 아닙니다. 앱 트래픽이 Clash에 전달되지 않으면 규칙이 올바르더라도 연결 기록에 표시되지 않습니다.

규칙 기본 형식: 유형, 매칭 값, 아웃바운드 정책

규칙은 일반적으로 YAML 설정의 rules: 목록에 작성합니다. 기본 형식은 유형,매칭 값,아웃바운드 정책이며, 일부 유형은 옵션을 추가할 수 있습니다. 목록 항목 앞에는 하이픈을 쓰고, 들여쓰기는 공백으로 합니다. Tab은 사용하지 마세요. 아래는 기존 설정에 추가할 수 있는 규칙 예시이며, 노드·포트·DNS 설정을 포함한 완성된 설정 파일은 아닙니다.

rules:
  - DOMAIN,login.example.org,DIRECT
  - DOMAIN-SUFFIX,example.org,REJECT
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - MATCH,DIRECT

여기서 DIRECT는 직접 연결, REJECT는 연결 거부를 뜻하는 기본 아웃바운드 정책입니다. 예시에는 예약된 테스트용 도메인을 사용했습니다. login.example.org는 직접 연결하고, 그 밖의 example.org 도메인은 거부합니다. 앞선 규칙에 일치하지 않은 연결은 마지막 규칙에 따라 직접 연결됩니다.

프록시 그룹을 지정할 때는 설정에 실제로 있는 이름을 사용하세요

기존 proxy-groups에 “노드 선택”이라는 프록시 그룹이 있다면, 규칙의 아웃바운드 정책에 해당 이름을 지정할 수 있습니다. 예: DOMAIN,api.example.org,노드 선택. 하지만 이 이름은 기본 제공 이름이 아닙니다. 설정에 해당 그룹이 없으면 그대로 복사할 경우 설정 검증이나 로드에 실패할 수 있습니다.

설정 파일에는 최상위 rules: 키를 하나만 두세요. 기존 목록에 규칙을 추가하고, 파일 끝에 같은 이름의 키를 반복해서 작성하지 마세요.
규칙을 복사할 때는 영문 쉼표를 사용하세요. 쉼표를 전각 쉼표로 입력하면 해당 줄을 인식하지 못할 수 있습니다.
규칙이 프록시 그룹을 가리키더라도 최종 노드는 그룹의 선택 또는 지연 시간 측정 방식에 따라 결정됩니다. 규칙 매칭과 노드 연결 가능 여부는 별도로 확인해야 합니다.

DOMAIN과 DOMAIN-SUFFIX: 예외를 먼저, 범위 규칙은 나중에

유형	규칙 예시	매칭 범위
DOMAIN	`DOMAIN,api.example.org,DIRECT`	정확히 이 도메인만 매칭
DOMAIN-SUFFIX	`DOMAIN-SUFFIX,example.org,DIRECT`	루트 도메인과 모든 하위 도메인 매칭
DOMAIN-KEYWORD	`DOMAIN-KEYWORD,example,REJECT`	도메인에 해당 문자열이 포함된 연결 매칭

접미사는 임의의 문자열 끝부분과 일치하지 않습니다

DOMAIN-SUFFIX,example.org,DIRECT는 example.org, www.example.org, a.b.example.org와 일치하지만, notexample.org를 하위 도메인으로 취급해서는 안 됩니다. 도메인 하나와 모든 하위 도메인을 처리하려면 루트 도메인만 입력하세요. https://, 경로, *.는 붙이지 마세요.

규칙에 입력하는 도메인은 전체 URL이 아닙니다. https://example.org/account에는 프로토콜과 경로가 포함되어 있어 DOMAIN에 그대로 넣을 수 없습니다. 일반 도메인 규칙으로는 같은 사이트의 /account와 /images 경로를 구분할 수도 없습니다. HTTPS 경로는 암호화된 애플리케이션 계층의 정보이므로 도메인별 분기를 웹 페이지 경로 필터링처럼 사용할 수 없습니다.

키워드 규칙은 의도치 않은 매칭에 주의하세요

DOMAIN-KEYWORD는 편리하지만 예상보다 넓은 범위를 매칭하는 경우가 많습니다. “example”은 example.org와 관계없는 다른 도메인에도 포함될 수 있습니다. 전체 도메인을 알고 있다면 DOMAIN을, 사이트 전체 도메인을 포함하려면 DOMAIN-SUFFIX를 우선 사용하세요. 범위를 명확히 지정하는 대신 짧은 키워드를 사용하지 마세요.

rules:
  - DOMAIN,download.example.org,DIRECT
  - DOMAIN-SUFFIX,example.org,REJECT
  - MATCH,DIRECT

이 순서에서는 다운로드 하위 도메인이 예외로 처리됩니다. 접미사 규칙을 첫 줄로 옮기면 다운로드 도메인도 먼저 거부 규칙에 매칭되어, 아래에 있는 더 구체적인 DOMAIN 규칙은 다시 확인되지 않습니다. Clash는 구체적인 도메인 규칙을 포괄적인 규칙보다 자동으로 앞에 배치하지 않습니다.

IP-CIDR와 no-resolve: 대상 주소와 DNS 조회 동작 구분하기

IP-CIDR은 대상 IPv4 주소가 속한 네트워크 대역을 기준으로 매칭합니다. 예: IP-CIDR,192.168.1.0/24,DIRECT,no-resolve. 여기서 /24는 네트워크 프리픽스 길이로, 주소 범위는 192.168.1.0부터 192.168.1.255까지입니다. IPv4 주소 하나만 매칭하려면 /32를 사용합니다. IPv6에는 IP-CIDR6을, IPv6 주소 하나에는 /128을 사용하세요.

rules:
  - 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
  - MATCH,DIRECT

다음은 흔히 사용하는 사설 IP 주소 대역의 예이며, 모든 특수 주소를 처리하는 완전한 목록은 아닙니다. 기업 네트워크, 자체 구축 라우터, VPN에는 추가 대역이 있을 수 있습니다. 대상 대역에 회사 터널로 접속해야 한다면 사설 주소라는 이유만으로 일반 직접 연결이 가능하다고 단정하지 마세요.

no-resolve는 DNS를 비활성화하는 옵션이 아닙니다

연결에 도메인이 포함되어 있지만 매칭에 사용할 대상 IP가 아직 없는 경우, IP 규칙은 주소가 해당 대역에 속하는지 확인하기 위해 DNS 조회를 수행할 수 있습니다. no-resolve를 추가하면 해당 규칙을 적용하기 위한 별도의 도메인 조회를 하지 않습니다. 사용 가능한 대상 IP가 이미 있거나 앱이 IP 주소로 직접 연결하는 경우에는 이 규칙이 매칭될 수 있습니다.

반대로 이미 알고 있는 사설 IP 트래픽을 직접 연결하려면 no-resolve를 사용해 해당 대역 규칙 때문에 추가 조회가 발생하지 않도록 할 수 있습니다. 이 옵션은 앱 자체의 DNS 조회를 막지 않으며, 연결을 설정할 때 DNS 조회가 절대 필요하지 않다는 뜻도 아닙니다. Fake-IP, DNS 매핑, 도메인 스니핑 설정에 따라 코어가 확인할 수 있는 정보가 달라지므로 문제 해결 시 실제 연결 기록을 확인하세요.

MATCH와 규칙 모음: 기본 규칙은 마지막에 배치

MATCH는 아직 다른 규칙에 매칭되지 않은 모든 연결에 적용되므로 주요 필드는 MATCH,아웃바운드 정책 두 개뿐입니다. 목록 맨 앞에 두면 이후의 도메인 규칙, IP 규칙, 규칙 모음은 모두 적용되지 않습니다. 일반적으로 “정확한 예외 → 분류 규칙 → 필요한 주소 규칙 → MATCH” 순서로 배치하지만, 서로 다른 유형 사이의 우선순위도 실제 목록 순서에 따라 결정됩니다.

규칙 모음도 별도의 우선순위를 갖지 않습니다

mihomo에서는 rule-providers로 규칙 모음을 관리한 뒤 RULE-SET으로 참조할 수 있습니다. 참조가 rules에 배치된 위치가 바로 매칭 순서입니다. 규칙 모음 파일에 항목이 아무리 많아도 그 앞에 작성된 개별 규칙보다 자동으로 우선 적용되지는 않습니다.

특정 도메인을 규칙 모음에서 제외하려면 해당 도메인의 정확한 매칭 규칙을 RULE-SET 참조보다 앞에 배치하세요.
사용 전 provider 이름이 정의되어 있는지 확인하고, behavior가 실제 규칙 데이터 형식과 일치하는지 점검하세요. 도메인 목록과 CIDR 목록은 데이터 형식이 서로 다릅니다.
규칙 모음 업데이트 실패와 “일치하는 항목이 없음”은 서로 다른 문제입니다. 먼저 로드 로그를 확인한 다음 규칙 순서를 점검하세요.

원본 Clash의 각 분기와 mihomo는 규칙 모음 형식, 논리 규칙 및 기타 확장 기능이 서로 다를 수 있습니다. 코어를 바꿀 때 RULE-SET 한 줄만 복사하지 마세요. provider 정의도 함께 확인하고, 현재 코어의 설정 검증 기능으로 지원 여부를 점검해야 합니다.

기본 동작을 직접 연결로 할지 프록시로 할지는 사용 목적에 따라 다릅니다

이 글의 예시에서는 외부 프록시 그룹에 의존하지 않도록 MATCH,DIRECT를 사용했으며, 모든 구독에서 기본 동작을 직접 연결로 설정해야 한다는 뜻은 아닙니다. 분류되지 않은 연결을 프록시로 보내려면 마지막 규칙을 실제로 존재하는 프록시 그룹 이름으로 바꾸세요. 먼저 구독의 기본 분기 의도를 유지한 뒤 필요한 예외를 하나씩 추가하면 변경 원인을 파악하기 쉽습니다.

구독 업데이트 후 규칙이 사라진다면 덮어쓰기 위치와 병합 순서를 확인하세요

클라이언트가 다운로드한 구독 YAML을 직접 수정하면 다음 업데이트 때 원격 설정으로 덮어써질 수 있습니다. 장기간 유지하려면 클라이언트에서 제공하는 로컬 덮어쓰기, 설정 병합 또는 스크립트 기능을 사용하는 편이 좋습니다. 클라이언트마다 메뉴와 병합 방식이 다르므로 현재 구독의 작업 메뉴에서 로컬 확장 기능을 확인하세요. 모든 “편집” 버튼이 영구 덮어쓰기로 저장된다고 가정해서는 안 됩니다.

현재 정상 작동하는 설정을 먼저 백업하세요. 활성 구독, 현재 모드, 기존 마지막 규칙을 기록해 두면 테스트 후 원래 상태로 되돌릴 수 있습니다.
결과를 확인할 수 있는 정확한 규칙 하나부터 추가하세요. 예를 들어 테스트용 도메인에 임시 거부 규칙을 적용하고, 처음부터 수백 개의 규칙을 한꺼번에 추가하지 마세요.
최종 적용 설정을 확인하세요. 병합 후 사용자 규칙이 기존 MATCH 뒤에 추가되었다면, 파일에 규칙이 있어도 매칭되지 않습니다.
다시 불러온 다음 구독도 한 번 업데이트하세요. 로컬 규칙이 유지되고 올바른 위치에 있는지 확인해야 저장 상태 검증이 끝납니다.

덮어쓰기 도구는 목록을 교체하거나, 앞에 넣거나, 뒤에 붙일 수 있으며 각각 결과가 다릅니다. rules를 통째로 교체하면 구독에 있던 분기 로직이 사라지고, 단순히 뒤에 붙이면 기본 규칙 뒤에 놓일 수 있습니다. “저장 완료” 여부만 확인하는 것보다 클라이언트의 병합 방식을 파악하는 것이 중요합니다.

규칙이 적용되지 않을 때 확인할 순서: 모드, 연결, 매칭, 아웃바운드

변경이 적용됐는지 확인할 때 웹사이트가 열리는지만 보지 마세요. 캐시, 기존 장기 연결, 브라우저의 연결 재사용이 확인 결과를 흐릴 수 있습니다. 규칙을 다시 불러온 뒤 대상 사이트의 기존 연결을 닫고 새 요청을 보내세요. 필요한 경우 클라이언트의 연결 목록에서 해당 연결만 종료하면 됩니다. 정상 작동 중인 앱의 연결까지 모두 끊을 필요는 없습니다.

증상	먼저 확인할 항목	해결 방법
대상 연결 기록이 없음	앱이 시스템 프록시를 사용하는지, TUN이 실제로 트래픽을 가로채는지	먼저 트래픽 유입 경로를 해결하세요. 매칭 규칙을 계속 수정하지 마세요.
연결에 Global 또는 직접 연결 모드 정책이 표시됨	현재 프록시 모드	규칙 모드로 전환한 뒤 새 연결을 생성하세요
MATCH에 매칭됨	도메인이 일치하는지, IP를 사용할 수 있는지, 규칙이 로드되었는지	연결 세부 정보와 최종 규칙 목록을 확인하세요
더 넓은 접미사 규칙에 매칭됨	정확한 예외 규칙이 뒤에 있는지	예외 규칙을 포괄적인 규칙보다 앞으로 옮기세요
원하는 정책에 매칭됐지만 요청이 실패함	프록시 그룹에서 선택된 노드와 대상 연결 상태	트래픽 분기에 성공했는지와 아웃바운드 연결이 실패했는지를 구분하세요

같은 대상으로 변경 전후를 비교하세요

현재 혼합 포트가 실제로 7890으로 설정되어 있다면 아래 명령으로 요청 하나를 로컬 HTTP 프록시를 통해 보낼 수 있습니다. 포트가 다르면 클라이언트에 표시된 값을 사용하세요. Windows에서는 같은 이름의 별칭이 있는 구버전 PowerShell과 혼동하지 않도록 curl.exe를 사용할 수 있습니다. 이 명령은 요청 테스트용이며, 특정 지연 시간이나 성공률을 보장하지 않습니다.

curl --proxy http://127.0.0.1:7890 --connect-timeout 10 --max-time 20 -I https://example.org/

그런 다음 연결 세부 정보에서 대상 도메인, 매칭된 규칙, 프록시 그룹, 최종 아웃바운드를 확인하세요. 이 테스트는 명시적 HTTP 프록시 경로를 검증할 뿐, TUN의 트래픽 가로채기나 UDP 전달을 검증하지는 않습니다. 앱이 IP에 직접 연결하면 도메인 규칙에 필요한 정보가 없을 수 있습니다. mihomo의 스니핑 기능은 지원되는 프로토콜과 설정에서 정보를 보완할 수 있지만 모든 암호화 트래픽의 도메인을 알아낼 수 있는 것은 아닙니다.

안정적으로 관리하려면 정상 작동하는 설정을 보존하고, 규칙을 조금씩 수정한 뒤 새 연결의 매칭 기록을 확인하고, 구독 업데이트 후에도 변경이 유지되는지 점검하세요. 구독, DNS 또는 TUN 모드를 더 설정하려면 Clash 전체 가이드를 참고하세요. 연결 문제는 먼저 자주 묻는 질문에서 확인해 네트워크 오류를 모두 규칙 문법 탓으로 돌리지 않도록 하세요.