Clash 사용자 규칙 작성법: 규칙 유형·매칭 순서·모바일 오버라이드

규칙 모드, 대상 정책, 코어부터 확인하기

Clash 사용자 규칙은 연결을 어떤 아웃바운드로 보낼지 정하는 기능이지, 프록시 노드를 만드는 기능은 아닙니다. 규칙이 매칭되면 내장된 DIRECT나 REJECT, 또는 설정에 이미 등록된 노드나 정책 그룹으로 연결할 수 있습니다. 정책 그룹에서 실제 아웃바운드가 결정되므로, 규칙이 프록시 그룹에 매칭되어도 최종 연결이 반드시 프록시 노드를 통하는 것은 아닙니다. 해당 그룹에서 직접 연결을 선택했을 수도 있습니다.

수정하기 전에 다음 세 가지를 확인하세요. 규칙을 불러올 수 있는지, 판정에 적용되는지, 매칭 후 어디로 연결되는지가 이 항목들에 따라 달라집니다.

실행 모드: 규칙 모드로 전환합니다. 인터페이스에는 보통 ‘규칙’ 또는 Rule로 표시됩니다. 전역 모드와 직접 연결 모드에서는 아래와 같은 일반 규칙 목록에 따라 연결이 분배되지 않습니다.
정책 이름: 설정의 proxy-groups에서 대상 그룹 이름을 확인하세요. 대소문자, 공백, 한글까지 정확히 일치해야 합니다. 이름이 잘못되면 설정을 불러오지 못할 수 있습니다.
코어 종류: 클라이언트가 원본 Clash, Clash Meta, mihomo 중 무엇을 사용하는지 확인하세요. Meta 계열은 이후 mihomo로 이름이 바뀌었습니다. 새 규칙이나 규칙 집합 형식이 추가되었다고 해서 이전 코어에서도 지원된다고 단정할 수는 없습니다.

주요 규칙 유형과 기본 문법

대부분의 규칙은 ‘규칙 유형, 매칭 조건, 대상 정책’ 순서로 작성하며 각 항목은 영문 쉼표로 구분합니다. MATCH에는 매칭 조건이 없으므로 대상 정책만 적습니다. YAML에서는 규칙마다 목록 항목을 하나씩 만들고 공백으로 들여씁니다. 들여쓰기에 Tab을 섞지 마세요.

rules:
  - DOMAIN,example.com,DIRECT
  - DOMAIN-SUFFIX,example.org,아웃바운드 선택
  - DOMAIN-KEYWORD,example,아웃바운드 선택
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - IP-CIDR6,fc00::/7,DIRECT,no-resolve
  - GEOIP,CN,DIRECT
  - MATCH,아웃바운드 선택

이 코드는 문법 설명을 위한 예시이며, 단독으로 실행할 수 있는 완성된 구독 설정이 아닙니다. 기존 설정에 합칠 때는 최상위 rules 항목을 하나만 남기고, 각 규칙이 실제 요구사항에 맞는지 확인하세요.

유형	매칭 대상	사용 시 참고 사항
`DOMAIN`	정확히 일치하는 도메인	`example.com`은 `www.example.com`과 일치하지 않습니다.
`DOMAIN-SUFFIX`	도메인 및 하위 도메인	`example.com`을 입력하면 됩니다. `*.`을 붙일 필요는 없습니다.
`DOMAIN-KEYWORD`	도메인에 포함된 키워드	접미사 매칭보다 범위가 넓어 관련 없는 도메인까지 포함될 수 있습니다.
`IP-CIDR` / `IP-CIDR6`	대상 IPv4 / IPv6 대역	대상 주소를 기준으로 매칭합니다. 휴대폰이 연결된 현재 Wi-Fi의 IP 대역을 기준으로 하지 않습니다.
`GEOIP`	대상 IP의 지리 정보 데이터베이스 분류	결과는 사용하는 데이터베이스에 따라 다릅니다. 웹사이트의 언어나 회사의 등록 국가와 같은 의미는 아닙니다.
`RULE-SET`	규칙 제공자에 포함된 항목	이름은 `rule-providers`에 정의된 항목과 일치해야 합니다.
`MATCH`	아직 매칭되지 않은 모든 연결	보통 목록 끝에 두어 기본 처리 규칙으로 사용합니다.

도메인 규칙에는 전체 URL을 입력하지 않습니다

https://www.example.com/account에 매칭하려면 도메인인 www.example.com을 입력하세요. https://, 경로, 쿼리 매개변수는 DOMAIN에 넣지 않습니다. 일반 도메인 규칙은 URL 경로 필터가 아니며, 같은 HTTPS 도메인 내의 서로 다른 페이지를 구분할 수도 없습니다.

DOMAIN-SUFFIX,example.com,DIRECT는 루트 도메인과 하위 도메인에 적용되지만, notexample.com을 해당 도메인의 하위 도메인으로 취급하지는 않습니다. 로그인 주소 하나만 처리하려면 정확한 도메인을 사용하세요. 도메인 접미사 전체에 지나치게 넓은 직접 연결 또는 거부 규칙을 적용하지 않는 편이 좋습니다.

IP 규칙과 no-resolve의 차이

연결에 도메인은 있지만 판정에 사용할 실제 대상 IP가 없으면 IP 규칙이 DNS 조회를 유발할 수 있습니다. 끝에 no-resolve를 붙이면 해당 규칙 하나만을 위해 도메인을 별도로 조회하지 않습니다. 이미 사용할 수 있는 대상 IP가 있다면 매칭은 계속 가능합니다. DNS 전체를 끄는 옵션도 아니고, ‘이 규칙을 항상 적용’하는 표시도 아닙니다.

따라서 GEOIP,CN,DIRECT,no-resolve는 이 옵션을 뺀 규칙과 같은 도메인 연결에서도 다른 결과를 낼 수 있습니다. 중국 본토 도메인이 IP 규칙에 매칭되지 않으면 노드를 계속 바꾸기보다 로그에 표시된 도메인, 대상 IP, DNS 동작부터 확인하세요.

매칭 순서: 첫 번째로 매칭된 규칙 적용, 구체적인 규칙은 위에

여기에 소개된 일반 규칙은 목록을 위에서 아래로 검사하며, 처음 매칭된 규칙의 정책을 선택하고 이후 규칙은 확인하지 않습니다. 규칙 유형에 자동 우선순위가 있는 것은 아닙니다. 아래쪽에 적힌 DOMAIN 규칙이 위쪽의 DOMAIN-SUFFIX보다 자동으로 우선 적용되지는 않습니다.

rules:
  - DOMAIN,login.example.com,DIRECT
  - DOMAIN-SUFFIX,example.com,아웃바운드 선택
  - MATCH,아웃바운드 선택

login.example.com은 첫 번째 규칙에 매칭되어 직접 연결됩니다.
www.example.com은 첫 번째 규칙을 건너뛰고 두 번째 규칙에 매칭됩니다.
example.net은 앞의 두 규칙에 매칭되지 않아 세 번째 규칙이 적용됩니다.

앞의 두 규칙 순서를 바꾸면 로그인 도메인이 먼저 접미사 규칙에 매칭되어, 뒤에 있는 정확한 도메인의 직접 연결 규칙은 적용되지 않습니다. ‘Clash 사용자 규칙을 추가했는데 적용되지 않음’ 문제를 확인할 때는 새로 추가한 규칙만 보지 말고 위쪽에 더 넓은 범위의 규칙이 있는지 먼저 살펴보세요.

MATCH를 맨 마지막에 두는 이유

MATCH는 앞에서 매칭되지 않은 모든 연결을 처리합니다. 그 뒤에 있는 일반 규칙은 실행되지 않습니다. ‘명시적인 예외 → 서비스 또는 업무별 규칙 집합 → 일반 지역 규칙 → MATCH’ 순으로 정리하면 관리하기 편합니다. 실제 요구사항에 따라 조정하세요. 이는 유지 관리를 위한 권장 방식이지, 코어가 강제하는 분류 순서는 아닙니다.

RULE-SET: 규칙 제공자와 참조 위치를 함께 확인

RULE-SET은 여러 매칭 조건을 별도 파일에 모아 두고 기본 규칙 목록에서 참조하는 방식입니다. 목록 순서를 건너뛰지는 않습니다. 참조가 적힌 줄에서 해당 규칙 집합의 매칭을 확인합니다. 제공자 이름, 동작 유형, 파일 형식, 파일 내용이 서로 맞아야 합니다.

아래는 mihomo에서 로컬 파일을 사용하는 예시입니다. 먼저 코어가 접근할 수 있는 설정 디렉터리에 ./rules/local-direct.yaml을 준비한 다음 제공자 정의를 추가하세요. 모바일에서 해당 디렉터리에 파일을 쓸 수 있는지는 클라이언트에 따라 다릅니다. 파일을 시스템의 ‘다운로드’ 폴더에 두었다고 해서 코어가 읽을 수 있는 것은 아닙니다.

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

rules:
  - RULE-SET,local-direct,DIRECT
  - MATCH,아웃바운드 선택

규칙 파일의 내용은 다음과 같습니다. classical 항목에는 규칙 유형을 유지하되 대상 정책은 적지 않습니다. 대상 정책은 기본 설정의 RULE-SET,local-direct,DIRECT에서 일괄 지정합니다.

payload:
  - DOMAIN,example.com
  - DOMAIN-SUFFIX,example.org
  - IP-CIDR,192.168.0.0/16,no-resolve

behavior: domain: 도메인 집합에 사용합니다. 항목은 해당 도메인 집합의 문법에 맞춰 작성해야 하며, 위의 classical 내용을 그대로 넣으면 안 됩니다.
behavior: ipcidr: IP 대역 집합에 사용합니다. 도메인 규칙을 함께 넣는 용도가 아닙니다.
behavior: classical: 규칙 유형이 포함된 항목에 사용합니다. 이 글처럼 도메인과 IP 조건을 섞어 쓰는 예시에 적합합니다.

원격 제공자를 사용하려면 다운로드 주소, 캐시 경로, 업데이트 간격도 설정해야 합니다. 구독 업데이트와 규칙 제공자 업데이트는 별개입니다. 기본 구독을 새로고침했다고 해서 모든 외부 규칙 파일까지 갱신된 것은 아닙니다. 모바일에서 예외 규칙을 두세 개만 추가하려는 경우에는 제공자를 새로 만드는 것보다 일반 규칙을 직접 작성하는 편이 문제를 찾기 쉽습니다.

모바일에서 구독 규칙 오버라이드하기: 원격 구독은 유지하고 로컬 규칙은 따로 관리

원격 구독은 설정의 원본이고, 클라이언트 오버라이드는 설정을 불러올 때 로컬에서 수정하는 기능입니다. 구독으로 생성된 YAML을 직접 편집하면 다음 업데이트에서 내용이 바뀔 수 있습니다. 원래 구독은 유지하고 클라이언트의 설정 오버라이드, 규칙 관리 또는 확장 설정 메뉴에서 로컬 규칙을 저장하는 편이 안전합니다.

Android 클라이언트에서 확인할 순서

현재 사용하는 설정의 상세 화면을 열어 실제로 실행 중인 구독이 무엇인지 먼저 확인하세요. 예비 설정을 수정해 놓고 다른 설정으로 계속 테스트하지 않도록 주의합니다.
클라이언트의 규칙 관리 또는 오버라이드 메뉴를 찾아 ‘규칙 앞에 추가’, 목록 병합, 전체 교체 중 어떤 방식을 지원하는지 확인하세요. Android 클라이언트마다 메뉴 이름은 다를 수 있습니다.
먼저 DOMAIN,example.com,DIRECT처럼 정확한 규칙 하나를 추가하세요. DNS, TUN, 규칙 여러 개를 한꺼번에 수정하지 마세요.
저장한 뒤 설정을 다시 불러오고, 알 수 없는 정책이나 YAML 구문 오류, 규칙 제공자 로드 실패가 표시되는지 확인하세요.
원래 구독을 한 번 새로고침한 뒤 로컬 규칙이 최종 규칙 목록 앞부분에 남아 있는지 확인하세요. 한 번 저장할 수 있다고 해서 구독 업데이트 후에도 유지되는 것은 아닙니다.

‘YAML 병합’을 입력하는 메뉴라면 배열을 어떻게 처리하는지 먼저 확인하세요. rules는 배열입니다. 병합 도구에 따라 배열 전체를 교체하기도 하고, 앞에 추가하거나 뒤에 붙이는 기능을 제공하기도 합니다. 규칙 하나만 들어 있는 rules: 블록을 그대로 붙이면 구독의 기존 규칙 전체를 덮어쓸 수 있습니다. 오버라이드 형식은 클라이언트 기능에 따라 다르므로 모든 모바일 클라이언트에 통하는 공통 앞부분 추가 필드는 없습니다.

iOS 클라이언트에서는 규칙을 옮기기 전에 설정 형식부터 확인

iOS 프록시 클라이언트마다 설정 문법, 모듈, 로컬 규칙 적용 방식이 다릅니다. 구독을 지원한다는 이유만으로 모두 Clash YAML을 그대로 실행할 수 있다고 생각하면 안 됩니다. 먼저 클라이언트가 명시적으로 지원하는 형식을 확인하세요. 다른 규칙 문법을 사용한다면 rules: 블록 전체를 붙여 넣지 말고, 해당 클라이언트의 기본 규칙 메뉴에서 조건을 추가해야 합니다.

시스템 VPN 권한은 클라이언트가 트래픽을 처리할 수 있게 해 줄 뿐, Clash 규칙을 다른 설정 형식으로 변환해 주지는 않습니다. 설치 방법을 선택해야 한다면 먼저 모바일 클라이언트 선택 가이드를 확인한 뒤, 선택한 클라이언트의 설정 형식과 오버라이드 기능을 살펴보세요.

규칙이 적용되지 않을 때: 웹페이지 결과보다 연결 로그 확인

웹페이지가 열리는지는 DNS, 노드 상태, 서버 상태, 기존 연결의 영향을 함께 받습니다. 규칙을 확인할 때는 클라이언트의 연결 기록이나 로그에서 대상 도메인, 매칭된 규칙, 정책 그룹, 최종 아웃바운드를 살펴보세요. 페이지가 빨라지거나 느려진 것만으로 특정 규칙이 적용됐다고 볼 수는 없습니다.

증상	먼저 확인할 항목	조치
설정을 저장한 뒤 불러오지 못함	들여쓰기, 영문 쉼표, 정책 그룹 이름	마지막 변경 사항을 되돌리고 규칙 하나부터 다시 확인합니다.
규칙은 있지만 계속 매칭되지 않음	실행 모드, 위쪽의 넓은 범위 규칙, MATCH 위치	규칙 모드로 전환하고 테스트 규칙을 적절한 앞쪽 위치로 옮깁니다.
프록시 그룹에 매칭됐지만 직접 연결됨	정책 그룹의 현재 선택과 중첩 그룹	정책 그룹을 따라가며 최종적으로 DIRECT가 선택됐는지 확인합니다.
도메인 규칙이 매칭되지 않음	연결 기록에 도메인이 표시되는지	DNS와 트래픽 처리 방식을 확인하세요. 브라우저 주소창만 보고 판단하지 마세요.
구독 업데이트 후 규칙이 사라짐	원본 파일을 수정했는지 별도 오버라이드를 사용했는지	클라이언트가 지원하는 영구 오버라이드 메뉴로 옮긴 뒤 업데이트 후에도 유지되는지 테스트합니다.

TUN/VPN으로 트래픽을 처리하는 단계와 규칙 매칭은 별개입니다

TUN 또는 시스템 VPN을 켜면 트래픽을 처리할 조건이 갖춰질 뿐, 모든 앱의 트래픽이 코어로 들어오는 것은 아닙니다. Android의 앱별 설정, 우회 앱 목록, 클라이언트 라우팅 설정으로 특정 앱이 우회될 수 있습니다. 코어에 도달하지 않은 연결은 설정에 있는 규칙과 매칭되지 않습니다.

또 다른 흔한 문제는 코어에 도메인 없이 IP만 표시되는 경우입니다. 앱 자체의 암호화 DNS, 고정 IP 직접 연결, DNS 처리 설정 차이 등이 도메인 정보에 영향을 줄 수 있습니다. mihomo의 도메인 스니핑은 지원되는 프로토콜에서 식별에 도움을 줄 수 있지만, 모든 암호화 연결을 식별한다고 보장할 수는 없습니다. 관련 기능을 켜기 전에 현재 DNS 설정을 먼저 파악하세요. 개념을 확인하려면 DNS 기술 참고 자료를 함께 살펴보세요.

한 번에 한 항목만 바꾸고 새 연결로 확인

규칙을 수정해도 기존 연결은 연결 시점의 아웃바운드를 계속 사용할 수 있습니다. 저장하고 다시 불러온 다음 관련 앱의 기존 연결을 끊거나 앱을 다시 열어 새 연결 기록을 확인하세요. ‘정확한 규칙 하나 추가 → 매칭 확인 → 구독 새로고침 → 다시 확인’ 순서로 테스트하는 것이 좋습니다. 문제가 생기면 앱 데이터를 바로 삭제하지 말고 이전에 정상 작동하던 설정으로 되돌리세요.