Clash 사용자 규칙 설정 방법: DOMAIN-SUFFIX·IP-CIDR·RULE-SET 문법과 우선순위

규칙 모드와 실제 적용 중인 설정 확인

특정 도메인을 항상 직접 연결하려면 먼저 클라이언트의 실행 모드를 「규칙 / Rule」로 설정한 다음, 사용자 규칙을 기존 rules: 목록 앞부분에 추가하세요. 저장한 뒤 설정을 다시 불러오고 연결 목록에서 해당 도메인에 적용된 규칙과 최종 아웃바운드를 확인합니다. 전역 모드는 전체 트래픽을 전역 정책으로 전달하고, 직접 연결 모드는 모든 연결을 바로 연결하므로 여기서 설명하는 분류 순서를 확인하기에 적합하지 않습니다.

Clash는 클라이언트와 코어 생태계에서 널리 쓰이는 이름이며, Clash Meta는 이후 mihomo라는 이름을 사용합니다. 이 문서에서 다루는 도메인 규칙, CIDR 규칙, 순서에 따른 매칭은 일반적인 설정 기능입니다. 구체적인 규칙 세트 형식과 추가 규칙 유형은 실제 사용하는 코어에 따라 달라집니다. 클라이언트 인터페이스와 코어는 서로 다른 개념이므로, 문제를 진단할 때는 「정보」 또는 코어 정보 화면에서 현재 실행 중인 코어를 확인하세요.

현재 활성화된 설정을 열고 원본 파일을 백업하거나 설정을 내보내세요.
Proxy 등 이미 존재하는 정책 그룹의 이름을 대소문자, 공백, 한글까지 정확히 확인하세요.
클라이언트에서 제공하는 덮어쓰기, 병합 또는 사용자 규칙 메뉴를 통해 규칙을 몇 개 추가하세요.
설정을 다시 불러온 뒤 적용된 설정을 확인해 새 규칙이 편집기에만 저장된 것이 아니라 실제 rules에 반영됐는지 확인하세요.

기본 문법: 유형, 매칭 대상, 아웃바운드

대부분의 일반 규칙은 유형,매칭 대상,대상 구조를 사용합니다. 대상에는 내장 값인 DIRECT, REJECT 또는 현재 설정에 정의된 프록시 노드나 정책 그룹을 지정할 수 있습니다. MATCH에는 매칭 대상이 필요 없으므로 MATCH,대상으로 작성하며, 보통 마지막에 기본 규칙으로 둡니다.

rules:
  - DOMAIN,api.example.com,DIRECT
  - DOMAIN-SUFFIX,example.org,DIRECT
  - DOMAIN-KEYWORD,telemetry,REJECT
  - IP-CIDR,192.168.50.0/24,DIRECT,no-resolve
  - IP-CIDR6,fd00::/8,DIRECT,no-resolve
  - MATCH,Proxy

이 예시는 기존 규칙 목록을 교체하거나 병합하는 용도이며, 기본 설정에 Proxy 정책 그룹이 이미 정의되어 있다고 가정합니다. 실제 정책 그룹 이름이 Proxy가 아니라면 설정에 있는 이름을 그대로 사용해야 합니다. 이 내용을 단독으로 붙여 넣어도 정책 그룹이나 프록시 노드가 생성되지는 않습니다. 예시의 예약 도메인은 매칭 범위를 설명하기 위한 것이므로 실제 적용할 때는 제어하려는 도메인으로 바꾸세요.

유형	매칭 범위	사용 사례
`DOMAIN`	도메인 전체와 정확히 일치	API나 로그인 주소 하나만 분리할 때
`DOMAIN-SUFFIX`	도메인과 모든 하위 도메인	하나의 도메인 계열을 일괄 처리할 때
`DOMAIN-KEYWORD`	지정한 문자열이 포함된 도메인	넓은 매칭 범위를 허용할 때
`IP-CIDR`	대상 IPv4 주소 대역	로컬 네트워크와 고정 서비스 주소
`RULE-SET`	선언된 규칙 제공자 참조	여러 도메인이나 네트워크 대역을 한곳에서 관리할 때
`MATCH`	앞선 규칙에서 매칭되지 않은 연결	목록 끝에 두는 기본 아웃바운드

DOMAIN-SUFFIX는 임의의 문자열 끝부분과 일치하지 않습니다

DOMAIN-SUFFIX,example.com,DIRECT는 example.com과 img.example.com에 매칭되지만 notexample.com에는 매칭되지 않습니다. *.example.com처럼 작성할 필요가 없으며, 도메인 필드에 https://, 포트 또는 경로를 넣지 마세요. 규칙은 브라우저 주소창의 전체 URL이 아니라 연결 대상 정보를 기준으로 매칭합니다.

api.example.com만 대상으로 하려면 DOMAIN을 사용해 범위를 좁히세요. DOMAIN-KEYWORD,example,DIRECT는 같은 문자열을 포함하는 다른 도메인까지 매칭할 수 있습니다. 로그인, 결제 또는 사내 시스템에는 우선 정확히 매칭하는 규칙을 적용하고 필요할 때 범위를 넓히세요.

매칭 우선순위: 위에서 아래로 확인해 첫 번째로 일치하는 규칙 적용

일반적인 rules 목록은 작성된 순서대로 평가되며, 대개 처음 매칭된 규칙이 아웃바운드를 결정합니다. 모든 결과를 모은 뒤 자동으로 「더 구체적인」 규칙을 고르지 않습니다. 도메인 규칙이 IP 규칙보다 기본적으로 우선하는 것도 아니고, 정확한 도메인 규칙이 접미사 규칙보다 자동으로 먼저 적용되는 것도 아닙니다. 먼저 적용해야 할 예외 규칙은 앞에 배치하세요.

rules:
  - DOMAIN,api.example.com,Proxy
  - DOMAIN-SUFFIX,example.com,DIRECT
  - MATCH,Proxy

이 순서에서는 api.example.com이 Proxy를 사용하고 www.example.com은 직접 연결됩니다. 앞의 두 규칙 순서를 바꾸면 API 도메인이 먼저 접미사 규칙에 매칭되어 아래의 정확한 도메인 규칙은 적용되지 않습니다. 규칙을 추가한 뒤 「설정은 불러왔지만 트래픽이 바뀌지 않는」 흔한 원인입니다.

사용자 규칙은 어디에 배치해야 하나요?

개별 예외는 일반 규칙보다 앞에 배치: 특정 도메인에만 적용되는 아웃바운드 규칙은 도메인 전체를 대상으로 하는 규칙보다 먼저 둡니다.
사용자 수정 규칙은 관련 구독 규칙보다 앞에 배치: 구독 규칙 세트가 대상 도메인을 이미 처리한다면 뒤에 추가한 규칙으로는 결과를 바꾸기 어렵습니다.
기본 규칙은 마지막에 배치: MATCH가 먼저 연결을 처리하면 그 뒤의 일반 규칙은 적용되지 않습니다.
보안 경계를 명확히 유지: 앞에 둔 직접 연결 규칙은 구독의 차단 규칙을 우회할 수도 있으므로, 허용이 필요한 도메인에만 예외를 추가하세요.

따라서 「사용자 규칙을 구독 규칙 앞에 배치」하는 것은 규칙이 서로 덮어쓰는 상황에 대응하는 방법이지, 모든 사용자 규칙을 무조건 맨 위에 두라는 뜻은 아닙니다. 먼저 적용해야 하는 차단 규칙이나 로컬 네트워크 규칙이 있다면 실제 요구에 맞춰 순서를 정하고, 새로 추가한 몇 줄만 볼 것이 아니라 적용된 전체 목록을 확인하세요.

IP-CIDR와 no-resolve: 규칙 매칭을 위한 DNS 조회 제어

IP-CIDR,192.168.50.0/24,DIRECT,no-resolve는 해당 IPv4 대역을 매칭 조건으로 사용하고 직접 연결하도록 지정합니다. /24는 네트워크 프리픽스 길이입니다. 단일 IPv4 주소에는 /32, 단일 IPv6 주소에는 /128을 사용할 수 있습니다. 여기에 입력하는 주소는 대상 주소이며 로컬 기기의 출발지 주소가 아닙니다.

연결 대상이 도메인인 경우 코어는 대상 IP가 필요한 규칙을 평가하면서 매칭 여부를 판단하기 위해 DNS 조회를 수행할 수 있습니다. no-resolve는 이 IP 규칙만을 위해 조회를 시작하지 않도록 합니다. 「DNS 차단」을 뜻하지 않으며, 연결이 반드시 직접 연결된다는 의미도 아닙니다. 이후 규칙이나 실제 연결에 필요한 DNS 조회까지 막지는 않습니다.

대상이 이미 IP 주소이거나 코어에서 사용할 수 있는 실제 대상 IP를 알고 있다면 네트워크 대역 매칭을 계속할 수 있습니다.
대상이 도메인이고 아직 사용할 수 있는 IP가 없다면 no-resolve가 붙은 IP 규칙은 보통 매칭을 위해 주소를 조회하지 않고, 연결은 다음 규칙을 확인합니다.
로컬 네트워크 주소나 명시적인 IP 직접 연결에는 이 옵션이 적합합니다. 도메인 조회 결과를 기준으로 특정 대역을 판별하려면 옵션을 제거했을 때의 DNS 동작도 함께 검토하세요.

사내 네트워크 서비스를 예로 들어 보겠습니다. 앱이 192.168.50.10에 직접 연결한다면 위의 네트워크 대역 규칙으로 쉽게 확인할 수 있습니다. 해당 주소로 해석되는 내부 도메인에 연결한다면 먼저 구체적인 도메인 직접 연결 규칙을 추가하고 사내 DNS가 해당 도메인을 해석할 수 있는지 확인하세요. 라우팅 선택과 DNS 연결 가능성은 별개의 문제입니다. DIRECT만 지정한다고 잘못된 DNS 서버가 바로잡히지는 않습니다.

RULE-SET 작성법: 제공자 선언과 규칙 참조

규칙이 많다면 rule-providers에 규칙 제공자를 선언한 뒤 RULE-SET,제공자 이름,대상으로 참조할 수 있습니다. 프록시 노드를 제공하는 proxy-providers와는 용도가 다릅니다. 아래 예시는 mihomo에서 로컬 YAML 도메인 규칙 세트를 사용하는 방법입니다. 먼저 파일을 준비한 다음 기본 설정에 병합하세요.

1단계: 로컬 도메인 규칙 파일 만들기

코어가 읽을 수 있는 설정 디렉터리에 rules/local-direct.yaml 파일을 만드세요. 제공자가 behavior: domain으로 선언되어 있으므로 파일에는 payload를 사용하고 도메인 매칭 값만 입력합니다. DOMAIN-SUFFIX 유형이나 아웃바운드 대상은 추가하지 마세요.

payload:
  - 'example.com'
  - '+.example.org'

여기서 example.com은 정확한 도메인 매칭에 사용하고, +.example.org는 도메인 자체와 모든 하위 도메인을 의미합니다. 규칙 세트의 도메인 표기법과 기본 설정의 DOMAIN-SUFFIX 문법은 서로 다른 계층에서 사용되므로 그대로 섞어 쓸 수 없습니다.

2단계: 제공자 선언 및 참조

rule-providers:
  local-direct:
    type: file
    behavior: domain
    format: yaml
    path: ./rules/local-direct.yaml

rules:
  - RULE-SET,local-direct,DIRECT
  - MATCH,Proxy

local-direct는 선언과 참조에서 이름이 완전히 같아야 합니다. 상대 경로는 코어의 작업 디렉터리를 기준으로 해석되므로 편집 중인 구독 파일과 같은 디렉터리를 가리키지 않을 수 있습니다. 파일을 읽지 못하면 코어 로그에서 실제 경로와 권한을 확인하세요. 여기서 type: file은 로컬 파일을 읽으며 네트워크에서 자동으로 내려받지 않습니다.

behavior: classical을 사용한다면 규칙 세트의 각 항목에 DOMAIN-SUFFIX,example.org처럼 규칙 유형을 포함해야 합니다. 다만 아웃바운드 대상은 쓰지 않고 바깥쪽 RULE-SET에서 지정합니다. 규칙 세트의 모든 매칭 항목은 기본 목록에서 참조한 위치에 적용되며 별도의 우선순위를 얻지 않습니다. 참조를 MATCH 뒤에 두면 트래픽을 분류할 수 없습니다.

검증 및 문제 해결: 매칭 규칙과 아웃바운드 경로 확인

한 번에 규칙을 한두 개씩 추가하고, 먼저 설정 문법을 검사한 뒤 다시 불러오세요. YAML은 공백으로 들여쓰고 Tab은 사용하지 마세요. 기존에 rules:가 있다면 해당 목록에 병합하고 파일 끝에 같은 최상위 키를 다시 추가하지 마세요. 키가 중복되면 앞선 내용이 덮어써지거나 파싱 오류가 발생할 수 있습니다.

트래픽이 코어에 들어오는지 확인: 브라우저가 시스템 프록시를 사용하거나 앱에서 프록시를 명시적으로 설정해야 합니다. 또는 TUN이 해당 트래픽을 처리해야 합니다. 코어에 들어오지 않은 연결에는 이 규칙이 적용되지 않습니다.
테스트 포트 확인: 현재 적용된 설정의 mixed-port가 7890이라면 아래 명령으로 로컬 HTTP 프록시를 명시해 사용할 수 있습니다. 실제 포트가 다르면 함께 수정하세요.
새 연결 확인: 연결 목록에서 대상 도메인을 검색하고 펼쳐 규칙 유형, 매칭 대상, 아웃바운드 경로를 확인하세요. 기존에 오래 유지된 연결은 이전 경로를 계속 사용할 수 있으므로 해당 연결을 닫고 다시 시도해야 합니다.
정책 그룹과 최종 노드를 구분: Proxy에 매칭됐다는 것은 해당 그룹으로 들어갔다는 뜻일 뿐입니다. 그룹에서 현재 DIRECT를 선택했다면 최종 연결은 직접 연결입니다.

curl --proxy http://127.0.0.1:7890 --head https://example.com

이 명령은 로컬 프록시를 명시적으로 통과하는 테스트 요청을 보냅니다. HTTP 상태 코드만으로 트래픽 분류가 성공했는지 판단하지 마세요. 클라이언트에서도 매칭된 규칙을 확인해야 합니다. 도메인에 따라 리디렉션이 발생할 수 있고 브라우저 페이지가 여러 도메인에 요청을 보낼 수도 있으므로 제어하려는 연결을 각각 확인하세요.

자주 발생하는 문제 3가지와 점검 순서

설정을 불러오지 못함: 들여쓰기, 쉼표, 정책 그룹 이름, RULE-SET에서 참조하는 제공자의 존재 여부를 확인하세요. 로그에 표시된 첫 번째 오류부터 확인하는 것이 좋습니다.
설정은 불러왔지만 규칙이 매칭되지 않음: 실행 모드, 규칙 순서, 실제 요청 도메인, 적용된 설정을 확인하세요. 연결 정보에 IP만 표시된다면 도메인 규칙의 매칭 여부는 코어가 도메인 정보를 가지고 있는지에 따라 달라집니다.
규칙은 매칭됐지만 연결에 실패함: DNS, 선택한 노드, 대상 서비스, 로컬 라우팅을 추가로 확인하세요. 규칙이 매칭됐다는 것은 경로가 선택됐다는 뜻일 뿐, 해당 경로에 실제로 연결할 수 있다는 뜻은 아닙니다.

TUN을 사용할 때는 일부 시스템 트래픽, 로컬 네트워크 접근 또는 설정에서 제외한 경로가 예상한 경로로 들어오지 않을 수 있습니다. 앱 자체 프록시가 연결 진입점을 바꾸기도 합니다. 먼저 프록시를 명시하는 명령으로 규칙 자체를 확인한 다음 브라우저나 대상 앱에서 트래픽이 제대로 전달되는지 점검하면 「규칙 작성 오류」와 「트래픽이 코어에 들어오지 않음」을 구분할 수 있습니다.

검증을 마친 뒤 구독을 한 번 더 업데이트하고 규칙이 유지되는지 확인하세요. 안정적으로 관리하려면 로컬 덮어쓰기에 예외 규칙을 저장하고, 구독에서 일반 규칙을 관리하며, 마지막에는 명확한 기본 규칙을 둡니다. 수정할 때마다 연결 기록으로 결과를 확인하세요. 전체 설정 항목과 트래픽 처리 방법은 고급 설정 또는 고객 지원 센터에서 확인할 수 있습니다.