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

Clash 규칙에서 자주 쓰는 유형과 작성 형식을 체계적으로 정리하고, 위에서 아래로 순서대로 매칭되는 우선순위 원리와 GEOIP·MATCH를 어디에 배치해야 하는지 실전 정렬 기준과 함께 설명합니다.

1. 규칙 항목의 기본 구조

Clash의 분기 처리 능력은 규칙 하나하나 위에 세워집니다. 설정 파일의 rules: 항목 아래 각 줄이 독립된 규칙 하나에 해당하며, 공통 형식은 콤마로 구분되는 세 부분 구조입니다:

TYPE,ARGUMENT,POLICY

TYPE은 매칭 기준이 되는 유형(도메인, IP 대역, 프로세스명 등)을 나타내고, ARGUMENT는 구체적인 매칭 값이며, POLICY는 일치했을 때 적용할 정책으로 특정 프록시 노드명, 정책 그룹명 또는 내장된 DIRECT(직접 연결)·REJECT(차단)를 지정할 수 있습니다. 일부 규칙 유형은 네 번째 선택 인자도 지원하는데, 가장 흔한 것이 no-resolve로, IP 계열 규칙을 매칭할 때 DNS 조회를 먼저 하지 않도록 지시해 불필요한 조회 지연이나 정보 노출을 막아줍니다. 완전한 규칙 예시는 다음과 같습니다:

DOMAIN-SUFFIX,example.com,Proxy
IP-CIDR,192.168.0.0/16,DIRECT,no-resolve

이 세 부분(선택적으로 네 부분) 구조를 이해하는 것이 이후 모든 규칙 유형을 파악하는 전제입니다.

2. 자주 쓰는 규칙 유형 하나씩 살펴보기

Clash 코어(Clash Meta·mihomo 계열 포함)가 지원하는 규칙 유형은 다양하지만, 실제 설정에서 자주 등장하는 것은 매칭 대상 기준으로 도메인 계열, IP 계열, 지역(GEO) 계열, 프로세스·포트 계열 네 그룹으로 정리할 수 있습니다.

1. 도메인 계열 규칙

2. IP·네트워크 대역 계열 규칙

IP 계열 규칙은 no-resolve 인자와 함께 쓰는 경우가 많은데, 특히 직접 연결 규칙에서는 직접 연결 트래픽 자체에 추가 조회 과정이 필요 없기 때문입니다.

3. 지역(GEO) 계열 규칙

4. 프로세스·포트 계열 규칙

5. 규칙 세트와 기본(兜底) 규칙

주의

DOMAIN-KEYWORDDOMAIN-REGEX는 매칭 범위가 넓은 편이라 앞쪽에 배치하면 키워드가 겹칠 때 원하지 않는 트래픽까지 먼저 걸릴 수 있으니, 정확 매칭 규칙 뒤쪽에 두는 것을 권장합니다.

3. 매칭 우선순위: 위에서 아래로, 한 번 걸리면 끝

Clash 규칙에서 가장 핵심적으로 이해해야 할 부분은 다음과 같습니다. 규칙 매칭은 rules: 목록에 적힌 순서 그대로 위에서 아래로 한 줄씩 판단하며, 어떤 규칙이 한 번 매칭되면 곧바로 그 규칙의 정책이 적용되고 그 아래의 규칙은 더 이상 검사하지 않습니다. 즉 규칙이 놓인 위치 자체가 하나의 우선순위이며, 규칙 유형 자체에 타고난 우열은 없습니다. DOMAIN이든 GEOIP이든 위쪽에 적혀 있어 먼저 검사되고 먼저 매칭되면 그것이 먼저 적용됩니다.

실수하기 쉬운 예를 하나 들어보겠습니다:

GEOIP,CN,DIRECT
DOMAIN-SUFFIX,example.com,Proxy

만약 example.com이 위치한 서버의 IP가 지역 데이터베이스에서 마침 중국 본토 IP로 인식된다면, 위 설정에서는 첫 번째 GEOIP 규칙에서 이미 트래픽이 직접 연결로 처리되어 버려서, 해당 도메인을 위해 적어둔 두 번째 프록시 규칙은 영원히 실행되지 않습니다. 특정 도메인을 항상 프록시로 보내고 싶다면 이 도메인 규칙을 GEOIP 앞에 두어야 합니다:

DOMAIN-SUFFIX,example.com,Proxy
GEOIP,CN,DIRECT

이런 순서 문제는 규칙이 많아질수록 매우 흔하게 발생합니다. "프록시를 설정했는데도 프록시로 안 나간다"는 문제를 진단할 때는, 가장 먼저 위쪽에 더 넓은 범위의 규칙이 그 트래픽을 먼저 가로채고 있는지 확인해야 합니다.

4. GEOIP와 MATCH의 배치 원칙

GEOIP 규칙과 MATCH 기본 규칙의 위치는 전체 규칙 목록에서 특히 강조할 만한 두 지점입니다.

GEOIP는 세부 규칙 뒤에 두어야 합니다

GEOIP는 목적지 IP가 어느 국가·지역에 속하는지를 판단하는 규칙이라 매칭 범위가 매우 넓어서, GEOIP,CN,DIRECT 한 줄이 수많은 개별 도메인을 한꺼번에 뒤덮을 수 있습니다. 규칙 목록 앞쪽에 두면 원래 프록시로 보내야 할 특정 서비스까지 함께 직접 연결로 처리될 위험이 큽니다. 안전한 방법은 정밀하게 제어해야 할 도메인·앱·포트 규칙을 먼저 적고, GEOIP 계열 규칙은 이런 세부 규칙 뒤, 기본 규칙 앞에 두어 "별도로 표시되지 않은 대부분의 로컬 트래픽을 직접 연결로 처리"하는 역할을 맡기는 것입니다.

MATCH는 반드시 목록 맨 마지막 줄에 두어야 합니다

MATCH는 이름 그대로 앞선 모든 규칙에 걸리지 않은 트래픽을 받아내는 기본 규칙입니다. 별도 인자가 필요 없고 형식은 항상 MATCH,POLICY이며, 사이트의 분기 정책에 따라 MATCH,Proxy 또는 MATCH,DIRECT로 쓰는 경우가 흔합니다. 이 규칙이 마지막에 있지 않으면 그 뒤에 있는, 원래 세부 규칙으로 처리되어야 할 트래픽이 미리 기본 정책에 가로채여 버리고, 그 아래에 적어둔 세부 규칙은 모두 무의미해집니다. 즉 MATCH가 한 번 등장하면 그 뒤의 규칙은 절대 실행될 수 없으므로, 반드시 마지막 한 줄이어야 합니다.

점검 방법

규칙 목록을 다 작성한 뒤에는 위에서부터 한 번 읊어 보면서, "범위가 더 넓은 규칙"이 "범위는 좁지만 특별히 처리해야 하는 규칙" 앞에 놓여 있지 않은지 확인하고, MATCH가 마지막 줄을 단독으로 차지하고 있는지 다시 확인하는 것을 권장합니다.

5. 그대로 적용할 수 있는 정렬 가이드

위의 원리를 결합하면, 구조가 명확한 규칙 목록은 보통 "정밀한 것 먼저, 넓은 것 나중, 마지막에 기본 규칙"이라는 순서를 따르며 대략 다섯 단계로 나눌 수 있습니다:

  1. 로컬 네트워크와 사설 주소는 직접 연결: IP-CIDR,192.168.0.0/16,DIRECT,no-resolve처럼 작성해, 내부망 트래픽이 프록시를 거치지 않도록 합니다.
  2. 특정 앱·포트 지정 규칙: 별도로 제어가 필요한 PROCESS-NAME, DST-PORT 규칙.
  3. 특별히 신경 써야 할 도메인 규칙: 자주 쓰는 서비스의 DOMAIN-SUFFIX, DOMAIN 규칙으로 프록시 또는 직접 연결을 명확히 지정합니다.
  4. 규칙 세트와 지역 규칙: RULE-SET으로 참조하는 대량 규칙, 그리고 나머지 로컬 트래픽을 처리하는 GEOIP.
  5. 최종 기본 규칙: MATCH 한 줄로 매칭되지 않은 모든 트래픽의 기본 방향을 정합니다.

간단히 정리하면 다음과 같은 예시가 됩니다:

IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
IP-CIDR,10.0.0.0/8,DIRECT,no-resolve
PROCESS-NAME,com.example.updater,DIRECT
DOMAIN-SUFFIX,example.com,Proxy
DOMAIN-KEYWORD,ads,REJECT
RULE-SET,proxy-list,Proxy
GEOIP,CN,DIRECT
MATCH,Proxy

덧붙여, 규칙 세트(RULE-SET) 자체도 내부에 적힌 항목 순서에 따라 전체 매칭에 참여하므로, 목록에 배치하는 위치 역시 "앞쪽에 이미 더 정밀한 규칙이 있어 먼저 걸러내고, 그다음에 이 세트가 검사된다"는 원칙을 따릅니다. 여러 규칙 세트를 동시에 참조한다면, 범위가 좁고 먼저 적용되어야 하는 세트를 범위가 넓은 세트보다 앞에 두는 것이 좋습니다.

6. 자주 하는 정렬 실수 자가 점검

실제 사용에서 규칙이 작동하지 않는 원인은 대부분 문법 오류가 아니라 순서 문제입니다. 가장 흔한 사례를 정리하면 다음과 같습니다:

이런 문제를 진단할 때는 규칙 하나하나의 문법을 반복해서 확인하기보다, rules: 목록 전체를 출력해 놓고 순서대로 매칭 과정을 머릿속으로 시뮬레이션해 보는 편이 훨씬 효율적입니다. 대개 어느 위치의 규칙이 먼저 걸렸는지 금세 찾아낼 수 있습니다.

클라이언트 다운로드