2026-07-02 고급 설정 예상 읽기 시간 9분

Clash 커스텀 규칙 작성법: 매칭 유형, 문법 형식, 우선순위 정리

DOMAIN-SUFFIX, IP-CIDR부터 GEOSITE까지 규칙 작성 형식과 활용 상황을 유형별로 정리하고, 위에서 아래로 순차 매칭되는 우선순위 로직과 커스텀 규칙을 구독 규칙 앞뒤 중 어디에 넣을지 설명합니다.

SEC-01

규칙의 기본 구조와 작성 위치

Clash와 mihomo 코어의 분기 기능은 모두 설정 파일의 rules 필드를 기반으로 동작합니다. 규칙 한 줄은 본질적으로 「매칭 유형,매칭 값,대상 정책」의 3단 구조로 되어 있으며, 각 항목은 쉼표로 구분합니다. 가장 흔한 규칙 예시는 다음과 같습니다.

rules:
  - DOMAIN-SUFFIX,google.com,PROXY
  - DOMAIN-SUFFIX,cn,DIRECT
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - GEOIP,CN,DIRECT
  - MATCH,PROXY

첫 번째 항목은 매칭 유형으로 트래픽을 어떤 기준으로 판단할지를 결정하며, 두 번째 항목은 구체적인 매칭 값(도메인 접미사나 IP 대역 등)입니다. 세 번째 항목은 매칭이 성사되었을 때 넘길 정책 그룹이나 정책으로, 흔히 쓰는 값으로 DIRECT(다이렉트 연결), PROXY(특정 정책 그룹 경유), REJECT(차단)가 있습니다. 일부 매칭 유형은 네 번째 선택 매개변수도 지원하는데, 예를 들어 IP-CIDR 뒤에 붙는 no-resolve는 DNS 해석을 건너뛰고 목적지 IP 그대로 판단하겠다는 뜻으로, 불필요한 도메인 해석 요청을 줄이는 데 자주 쓰입니다.

규칙 필드는 보통 설정 파일 끝부분, proxy-groups 바로 뒤에 위치합니다. 커스텀 규칙과 구독에서 받아온 규칙은 하나의 목록으로 합쳐지며, 합쳐진 순서가 분기 결과를 그대로 좌우합니다. 이 부분은 3절에서 자세히 다룹니다.

SEC-02

자주 쓰는 매칭 유형 하나씩 살펴보기

도메인 관련 매칭

DOMAIN은 완전한 도메인을 정확히 매칭하며, 완전히 동일한 도메인에만 적용됩니다. 예를 들어 DOMAIN,api.example.com,PROXY는 이 서브도메인만 처리하고 www.example.com에는 영향을 주지 않습니다.

DOMAIN-SUFFIX는 도메인 접미사를 매칭하는, 가장 많이 쓰이는 유형입니다. DOMAIN-SUFFIX,google.com,PROXY는 google.com, www.google.com, mail.google.com 등 해당 접미사로 끝나는 모든 도메인에 동시에 적용되어, 사이트 전체 단위로 정책을 나누기에 적합합니다.

DOMAIN-KEYWORD는 도메인에 포함된 키워드를 위치와 무관하게 매칭하며, 작성법은 DOMAIN-KEYWORD,youtube,PROXY입니다. 매칭 범위가 넓어 무관한 도메인까지 걸릴 수 있으므로, 키워드가 충분히 특이할 때만 사용하는 것이 좋습니다.

DOMAIN-REGEX는 정규식으로 도메인을 매칭할 수 있어, 규칙성은 있지만 접미사나 키워드로 처리하기 어려운 도메인 집합에 적합합니다. 작성과 디버깅 비용이 높아 일반적인 설정에서는 잘 쓰이지 않습니다.

IP 및 네트워크 대역 매칭

IP-CIDR은 IPv4 대역으로 매칭하며 형식은 IP-CIDR,시작 주소/서브넷 마스크,정책입니다. 사내망 대역을 그대로 허용할 때 자주 쓰이며, 예를 들면 IP-CIDR,10.0.0.0/8,DIRECT,no-resolve 같은 식입니다. IP-CIDR6는 대응하는 IPv6 버전으로 작성 구조는 동일합니다.

GEOIP는 목적지 IP가 속한 국가나 지역으로 판단합니다. 코어에 내장된 IP 지리 데이터베이스를 사용하며 작성법은 GEOIP,CN,DIRECT로, 연결 목적지 IP가 중국 본토에 속하면 다이렉트 연결하라는 뜻입니다. 대역을 일일이 나열할 필요가 없어 IP-CIDR 목록을 직접 작성하는 것보다 유지보수 비용이 훨�다 낮습니다.

지역 및 규칙셋 매칭

GEOSITE는 mihomo 코어가 v2ray 규칙셋 생태계와 호환되도록 지원하는 유형으로, 도메인이 속한 분류로 판단합니다. 예를 들어 GEOSITE,cn,DIRECT 한 줄로 중국 본토에서 자주 쓰는 수백~수천 개 도메인을 커버할 수 있어, 현재 유지보수 비용이 가장 낮은 도메인 분기 방식 중 하나입니다. 사용 전에는 설정 파일에 해당 rule-providers가 선언되어 있는지 확인해야 하며, 그렇지 않으면 코어가 실행 시 규칙셋을 찾지 못했다는 오류를 낼 수 있습니다.

RULE-SET은 자체 제작 또는 구독 제공자가 제공하는 규칙셋 파일을 참조하며, 형식은 RULE-SET,셋 이름,정책입니다. 규칙셋 자체는 다수의 DOMAIN-SUFFIX/IP-CIDR 등 항목을 담은 별도 파일로, rule-providers 필드에서 출처 주소와 갱신 주기를 선언합니다. 규칙 내용을 메인 설정 파일과 별도로 갱신할 수 있어 매번 규칙 목록을 다시 편집할 필요가 없다는 장점이 있습니다.

프로세스 및 포트 매칭

PROCESS-NAME은 연결을 시작한 로컬 프로세스 이름으로 매칭하며, 특정 클라이언트에만 별도의 출구를 지정하기에 적합합니다. 예를 들어 특정 다운로드 도구만 다이렉트 연결하도록 할 수 있습니다. DST-PORT는 목적지 포트로 매칭하며, 흔히 메일이나 게임 관련 포트를 따로 빼내 처리할 때 씁니다. 이 두 유형은 플랫폼 레벨의 프로세스 식별 기능에 의존하기 때문에 일부 모바일 환경이나 샌드박스에서는 동작하지 않을 수 있으므로, 먼저 데스크톱에서 정상 동작을 확인한 뒤 활용하는 것을 권장합니다.

기본 매칭(폴백)

MATCH는 매칭 값이 없는 전체 매칭 규칙으로, 반드시 규칙 목록의 마지막 줄에 두어야 하며, 앞선 규칙이 모두 매칭되지 않았을 때의 기본 처리 경로를 의미합니다. 대다수 설정에서는 MATCH의 대상을 특정 노드로 고정하지 않고 정책 그룹으로 지정해, 설정 파일을 바꾸지 않고도 클라이언트 화면에서 언제든 출구를 전환할 수 있게 합니다.

NOTE

규칙 유형은 대소문자를 크게 구분하지 않지만, 커뮤니티 관례상 모두 대문자로 작성합니다. 이 습관을 유지하면 협업과 이후 검색에 도움이 됩니다.

SEC-03

우선순위 로직: 위에서 아래로, 매칭되면 즉시 종료

Clash와 mihomo 코어는 규칙 목록을 처리할 때 엄격한 순차 매칭 원칙을 따릅니다. rules 목록의 첫 줄부터 시작해 현재 연결과 한 줄씩 대조하다가, 어느 한 줄이라도 매칭에 성공하면 즉시 그 줄에 지정된 정책을 채택하고 그 아래로는 더 이상 대조하지 않습니다. 아래쪽에 더 정확하거나 적합한 규칙이 있어도 검사조차 하지 않습니다. 즉 규칙의 선후 순서 자체가 곧 우선순위이며, 매칭 유형이 얼마나 "정확한지"와는 무관합니다.

흔히 실수하는 예시를 하나 들어보겠습니다.

rules:
  - DOMAIN-KEYWORD,google,DIRECT
  - DOMAIN-SUFFIX,google.com,PROXY
  - MATCH,PROXY

이 설정에서는 첫 줄의 키워드 매칭이 google 문자열이 포함된 모든 도메인을 먼저 잡아 다이렉트 연결시키므로, 원래 프록시로 가야 할 두 번째 줄의 DOMAIN-SUFFIX,google.com,PROXY는 영원히 실행될 기회를 얻지 못합니다. 연결이 두 번째 줄에 도달하기 전에 이미 첫 줄에서 가로채져 처리가 끝나기 때문입니다. 규칙 순서가 뒤바뀌면 결과도 의도와 정반대가 될 수 있는데, 클라이언트 화면은 보통 이런 논리적 충돌을 별도로 알려주지 않으므로 작성자가 직접 검토해야 합니다.

이 동작 원리에 따라, 규칙을 작성할 때는 정확한 것에서 넓은 것 순으로 배치하는 원칙을 지키는 것이 좋습니다. 먼저 DOMAIN, DOMAIN-SUFFIX 같은 정확 매칭을 앞에 두고, 그 다음 DOMAIN-KEYWORD, GEOSITE, GEOIP 같이 범위가 넓은 매칭을 배치하고, 마지막에 MATCH로 마무리합니다. 범위가 넓은 규칙을 앞에 두면 원래 뒤쪽의 정확한 규칙이 처리해야 할 트래픽을 미리 "가로채게" 됩니다.

SEC-04

커스텀 규칙은 구독 규칙 앞에 넣어야 할까, 뒤에 넣어야 할까

대다수 사용자의 설정 파일은 처음부터 직접 작성한 것이 아니라, 구독 노드 제공자가 생성한 완성된 설정 파일로, 그 안에 이미 규칙 목록이 포함되어 있습니다. 이런 상태에서 커스텀 규칙을 추가할 때는 삽입 위치가 실제로 적용되는지를 그대로 좌우합니다.

결론적으로 커스텀 규칙은 구독에 포함된 규칙 목록의 가장 앞쪽에 넣어야 하며, 맨 뒤에 덧붙이면 안 됩니다. 이유는 바로 앞 절에서 설명한 "매칭되면 즉시 종료" 메커니즘 때문입니다. 구독에서 제공하는 규칙 목록은 이미 흔한 도메인과 IP 대역을 대량으로 커버하고 있는 경우가 많아, 커스텀 규칙을 맨 뒤에 두면 연결이 구독 규칙에 먼저 매칭될 확률이 높고, 커스텀 규칙은 영원히 차례가 오지 않게 됩니다. 커스텀 규칙을 가장 앞에 두어야만 구독 규칙보다 실제로 더 높은 우선순위를 가질 수 있습니다.

흔히 쓰는 방법은 규칙 목록 상단에 주석으로 구분선을 만들어, 다음에 구독을 갱신할 때 이 부분을 빠르게 찾아 보존할 수 있게 하는 것입니다.

rules:
  # ↓↓↓ 커스텀 규칙, 구독 갱신 시 수동으로 보존 필요 ↓↓↓
  - DOMAIN-SUFFIX,internal.mycompany.com,DIRECT
  - DOMAIN-KEYWORD,ads,REJECT
  # ↑↑↑ 커스텀 규칙 끝 ↑↑↑
  - DOMAIN-SUFFIX,google.com,PROXY
  - GEOSITE,cn,DIRECT
  - MATCH,PROXY

특히 주의할 점은, 클라이언트에서 구독 자동 갱신을 설정해 두었는데 클라이언트 자체가 "커스텀 규칙을 별도로 저장하고 병합 시 자동으로 앞쪽에 배치"하는 고급 기능을 지원하지 않는다면, 매번 구독을 갱신할 때마다 원격 파일이 로컬 설정 전체를 덮어써 상단에 직접 추가해 둔 규칙까지 함께 사라진다는 점입니다. Clash Verge Rev, FlClash처럼 "설정 병합" 또는 "오버라이드(override)" 기능을 지원하는 클라이언트를 쓸 때는, 커스텀 규칙을 구독으로 생성된 메인 설정에 직접 고치지 말고 별도의 오버라이드 파일에 작성하는 것을 권장합니다. 그러면 구독이 갱신되어도 커스텀 부분이 사라지지 않습니다.

WARN

구독으로 생성된 설정 파일을 직접 수정하는 것은 임시 조치에 불과합니다. 대다수 클라이언트는 다음 구독을 가져올 때 해당 파일을 전체 덮어씁니다. 커스텀 규칙을 장기간 유지해야 한다면 클라이언트의 오버라이드, 병합, 로컬 규칙 기능을 우선 사용하고, 구독 갱신마다 수동으로 다시 추가하는 방식은 피하세요.

SEC-05

전형적인 상황과 규칙 조합 예시

아래 몇 가지 조합은 일상 설정에서 가장 자주 마주치는 요구를 다루므로, 정책 그룹 이름만 바꿔서 바로 참고해 사용할 수 있습니다.

사내망과 중국 본토는 다이렉트, 나머지는 프록시

rules:
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - IP-CIDR,10.0.0.0/8,DIRECT,no-resolve
  - IP-CIDR,127.0.0.0/8,DIRECT,no-resolve
  - GEOSITE,cn,DIRECT
  - GEOIP,CN,DIRECT
  - MATCH,PROXY

이 규칙 조합은 먼저 사내망과 로컬 주소를 제외해 내부망 접속이 잘못 프록시 경로로 들어가지 않도록 하고, 이어서 GEOSITE로 국내 도메인을 커버하며, GEOIP로 국내 IP지만 도메인 분류에 잡히지 않은 경우를 보완합니다. 마지막으로 MATCH가 나머지 트래픽을 프록시 정책 그룹으로 넘깁니다.

광고 및 추적 도메인 차단

rules:
  - DOMAIN-KEYWORD,doubleclick,REJECT
  - DOMAIN-SUFFIX,adservice.google.com,REJECT

REJECT는 매칭된 연결 요청을 곧바로 폐기하며, 클라이언트 쪽에서는 해당 리소스 로딩 실패나 타임아웃으로 나타납니다. 이런 규칙도 해당 도메인을 허용하는 다른 규칙보다 앞에 두어야 하며, 그렇지 않으면 더 넓은 허용 규칙이 먼저 처리해버려 무효화됩니다.

특정 앱 강제 다이렉트 연결

rules:
  - PROCESS-NAME,WeChat.exe,DIRECT
  - PROCESS-NAME,com.tencent.mm,DIRECT

일부 메신저나 로컬 네트워크 앱은 지연과 회선 안정성 요구가 높아, 따로 빼서 다이렉트 연결하는 편이 억지로 프록시를 태우는 것보다 체감이 좋은 경우가 많습니다. 데스크톱 프로세스 이름은 보통 확장자가 붙고, 안드로이드 앱은 패키지명을 적으면 됩니다.

SEC-06

규칙이 적용되지 않을 때 점검하는 순서

규칙을 작성한 뒤 분기 결과가 예상과 다르다면, 노드 자체를 의심하기보다 아래 순서로 먼저 점검하세요.

  1. 규칙 순서 확인

    범위가 더 넓은 규칙이 목표 규칙보다 앞에 작성되어 트래픽을 미리 가로챘는지 확인합니다. 가장 흔한 원인입니다.

  2. rule-providers 정상 로드 확인

    GEOSITE나 RULE-SET을 사용할 때 해당 규칙셋 주소가 만료되었거나 형식이 맞지 않으면 코어 실행이 실패하거나 해당 규칙이 조용히 무시될 수 있으므로, 클라이언트 로그로 로드 상태를 확인해야 합니다.

  3. 정책 그룹 이름 일치 확인

    규칙 세 번째 항목에 적은 정책 이름은 proxy-groups에 정의된 이름과 대소문자, 공백까지 정확히 일치해야 합니다. 오타가 있으면 해당 규칙 전체가 무효화되거나 오류가 발생합니다.

  4. 더 앞선 폴백 규칙에 걸렸는지 확인

    설정에 MATCH가 여러 번 있거나 너무 일찍 등장하는 광범위한 GEOIP/GEOSITE 규칙이 있다면, 새로 추가한 정확 규칙이 그 뒤로 밀려 영원히 실행되지 않을 수 있습니다.

"위에서 아래로, 매칭되면 즉시 종료"라는 핵심 로직만 확실히 이해하면, 낯선 구독 설정을 넘겨받든 처음부터 직접 분기 정책을 구성하든 점검 방향이 훨씬 명확해집니다. 커스텀 규칙은 한곳에 모아 관리하고 주석으로 경계를 표시해 두면 장기적으로 유지보수하기가 훨씬 편해집니다.

클라이언트 다운로드