Clash 사용자 정의 규칙 작성법: DOMAIN·IP-CIDR 문법과 매칭 우선순위 완벽 정리
Clash 규칙에서 자주 쓰는 유형과 작성 형식을 체계적으로 정리하고, 위에서 아래로 순서대로 매칭되는 우선순위 원리와 GEOIP·MATCH를 어디에 배치해야 하는지 실전 정렬 기준과 함께 설명합니다.
Clash 규칙에서 자주 쓰는 유형과 작성 형식을 체계적으로 정리하고, 위에서 아래로 순서대로 매칭되는 우선순위 원리와 GEOIP·MATCH를 어디에 배치해야 하는지 실전 정렬 기준과 함께 설명합니다.
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
이 세 부분(선택적으로 네 부분) 구조를 이해하는 것이 이후 모든 규칙 유형을 파악하는 전제입니다.
Clash 코어(Clash Meta·mihomo 계열 포함)가 지원하는 규칙 유형은 다양하지만, 실제 설정에서 자주 등장하는 것은 매칭 대상 기준으로 도메인 계열, IP 계열, 지역(GEO) 계열, 프로세스·포트 계열 네 그룹으로 정리할 수 있습니다.
DOMAIN: 완전히 일치하는 전체 도메인만 매칭합니다. 예를 들어 DOMAIN,www.example.com,Proxy는 이 도메인 하나에만 적용되며 서브도메인이나 다른 접두사는 대상이 되지 않습니다.DOMAIN-SUFFIX: 도메인 접미사를 매칭합니다. DOMAIN-SUFFIX,example.com,Proxy라고 쓰면 example.com 자체는 물론 www.example.com, api.example.com 등 모든 서브도메인이 함께 매칭되어, 가장 널리 쓰이는 도메인 규칙입니다.DOMAIN-KEYWORD: 도메인에 지정한 키워드가 포함되어 있으면 매칭됩니다. 예를 들어 DOMAIN-KEYWORD,google,Proxy는 "google"이라는 문자열이 들어간 모든 도메인을 매칭하므로 범위가 넓은 편이라, 같은 문자열을 포함한 다른 도메인이 잘못 걸리지 않도록 주의해야 합니다.DOMAIN-REGEX: 정규표현식으로 도메인을 매칭합니다. 세밀한 제어가 필요하면서 일일이 나열하고 싶지 않은 경우에 적합하지만, 작성과 디버깅 부담이 커서 앞의 세 유형으로 해결되지 않을 때만 사용하는 것이 좋습니다.IP-CIDR: IPv4 CIDR 대역으로 매칭합니다. 예를 들어 IP-CIDR,10.0.0.0/8,DIRECT는 이 사설 네트워크 전체를 직접 연결로 처리한다는 뜻입니다.IP-CIDR6: 문법은 IP-CIDR과 동일하며 IPv6 대역 전용입니다.IP-SUFFIX: IP 주소의 뒷부분 조각으로 매칭하며, 특정 내부망 구성 등 비교적 특수한 상황에서 쓰입니다.SRC-IP-CIDR: 요청을 보낸 출발지 IP 대역으로 매칭합니다. 목적지 주소가 아니라 로컬 네트워크 내 특정 기기에 별도 정책을 지정할 때 주로 사용합니다.IP 계열 규칙은 no-resolve 인자와 함께 쓰는 경우가 많은데, 특히 직접 연결 규칙에서는 직접 연결 트래픽 자체에 추가 조회 과정이 필요 없기 때문입니다.
GEOIP: 목적지 IP가 속한 국가·지역을 기준으로 판단합니다. 예를 들어 GEOIP,CN,DIRECT는 중국 본토 IP로 인식된 트래픽을 직접 연결로 처리한다는 의미입니다. 이 규칙은 IP 지역 데이터베이스에 의존하므로 판별 정확도는 데이터베이스 갱신 상태에 따라 달라집니다.SRC-GEOIP: GEOIP와 비슷하지만 목적지 대신 요청을 보낸 쪽의 지역 정보를 기준으로 판단합니다.PROCESS-NAME: 연결을 시작한 프로세스명으로 매칭합니다. 예를 들어 PROCESS-NAME,com.example.app,Proxy처럼 특정 앱에만 별도 정책을 적용하기 좋아 모바일 설정에서 자주 쓰입니다.PROCESS-PATH: 프로세스의 전체 실행 파일 경로로 매칭합니다. PROCESS-NAME보다 정확도는 높지만 설정이 더 복잡해집니다.DST-PORT / SRC-PORT: 목적지 포트 또는 출발지 포트로 매칭하며, 메일이나 게임 전용 포트처럼 특정 포트를 고정된 경로로 보내고 싶을 때 사용합니다.RULE-SET: 외부 규칙 파일을 참조해 같은 계열의 규칙을 한꺼번에 묶어 관리합니다. 구독 방식으로 갱신할 수 있어 수백, 수천 줄의 세부 규칙을 일일이 관리할 필요가 없어집니다.MATCH: 기본(兜底) 규칙으로 별도 인자가 필요 없으며, 앞선 규칙에 하나도 걸리지 않은 트래픽이 최종적으로 이 규칙에 도달합니다. 형식은 MATCH,POLICY입니다.DOMAIN-KEYWORD와 DOMAIN-REGEX는 매칭 범위가 넓은 편이라 앞쪽에 배치하면 키워드가 겹칠 때 원하지 않는 트래픽까지 먼저 걸릴 수 있으니, 정확 매칭 규칙 뒤쪽에 두는 것을 권장합니다.
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
이런 순서 문제는 규칙이 많아질수록 매우 흔하게 발생합니다. "프록시를 설정했는데도 프록시로 안 나간다"는 문제를 진단할 때는, 가장 먼저 위쪽에 더 넓은 범위의 규칙이 그 트래픽을 먼저 가로채고 있는지 확인해야 합니다.
GEOIP 규칙과 MATCH 기본 규칙의 위치는 전체 규칙 목록에서 특히 강조할 만한 두 지점입니다.
GEOIP는 목적지 IP가 어느 국가·지역에 속하는지를 판단하는 규칙이라 매칭 범위가 매우 넓어서, GEOIP,CN,DIRECT 한 줄이 수많은 개별 도메인을 한꺼번에 뒤덮을 수 있습니다. 규칙 목록 앞쪽에 두면 원래 프록시로 보내야 할 특정 서비스까지 함께 직접 연결로 처리될 위험이 큽니다. 안전한 방법은 정밀하게 제어해야 할 도메인·앱·포트 규칙을 먼저 적고, GEOIP 계열 규칙은 이런 세부 규칙 뒤, 기본 규칙 앞에 두어 "별도로 표시되지 않은 대부분의 로컬 트래픽을 직접 연결로 처리"하는 역할을 맡기는 것입니다.
MATCH는 이름 그대로 앞선 모든 규칙에 걸리지 않은 트래픽을 받아내는 기본 규칙입니다. 별도 인자가 필요 없고 형식은 항상 MATCH,POLICY이며, 사이트의 분기 정책에 따라 MATCH,Proxy 또는 MATCH,DIRECT로 쓰는 경우가 흔합니다. 이 규칙이 마지막에 있지 않으면 그 뒤에 있는, 원래 세부 규칙으로 처리되어야 할 트래픽이 미리 기본 정책에 가로채여 버리고, 그 아래에 적어둔 세부 규칙은 모두 무의미해집니다. 즉 MATCH가 한 번 등장하면 그 뒤의 규칙은 절대 실행될 수 없으므로, 반드시 마지막 한 줄이어야 합니다.
규칙 목록을 다 작성한 뒤에는 위에서부터 한 번 읊어 보면서, "범위가 더 넓은 규칙"이 "범위는 좁지만 특별히 처리해야 하는 규칙" 앞에 놓여 있지 않은지 확인하고, MATCH가 마지막 줄을 단독으로 차지하고 있는지 다시 확인하는 것을 권장합니다.
위의 원리를 결합하면, 구조가 명확한 규칙 목록은 보통 "정밀한 것 먼저, 넓은 것 나중, 마지막에 기본 규칙"이라는 순서를 따르며 대략 다섯 단계로 나눌 수 있습니다:
IP-CIDR,192.168.0.0/16,DIRECT,no-resolve처럼 작성해, 내부망 트래픽이 프록시를 거치지 않도록 합니다.PROCESS-NAME, DST-PORT 규칙.DOMAIN-SUFFIX, DOMAIN 규칙으로 프록시 또는 직접 연결을 명확히 지정합니다.RULE-SET으로 참조하는 대량 규칙, 그리고 나머지 로컬 트래픽을 처리하는 GEOIP.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) 자체도 내부에 적힌 항목 순서에 따라 전체 매칭에 참여하므로, 목록에 배치하는 위치 역시 "앞쪽에 이미 더 정밀한 규칙이 있어 먼저 걸러내고, 그다음에 이 세트가 검사된다"는 원칙을 따릅니다. 여러 규칙 세트를 동시에 참조한다면, 범위가 좁고 먼저 적용되어야 하는 세트를 범위가 넓은 세트보다 앞에 두는 것이 좋습니다.
실제 사용에서 규칙이 작동하지 않는 원인은 대부분 문법 오류가 아니라 순서 문제입니다. 가장 흔한 사례를 정리하면 다음과 같습니다:
GEOIP,CN,DIRECT를 모든 도메인 규칙보다 앞에 적어서, 중국 본토 IP 대역에 속한 목적지 서비스가 모두 직접 연결로 가로채이는 경우.DOMAIN-KEYWORD의 키워드가 너무 넓은데 앞쪽에 배치되어, 원래 프록시로 나가야 할 다른 도메인까지 잘못 걸리는 경우.MATCH 뒤에 규칙을 몇 줄 더 추가했지만, 이 규칙들은 절대 실행되지 않는 무효 설정이 되는 경우.이런 문제를 진단할 때는 규칙 하나하나의 문법을 반복해서 확인하기보다, rules: 목록 전체를 출력해 놓고 순서대로 매칭 과정을 머릿속으로 시뮬레이션해 보는 편이 훨씬 효율적입니다. 대개 어느 위치의 규칙이 먼저 걸렸는지 금세 찾아낼 수 있습니다.