Clash 사용자 규칙 작성법: 규칙 종류, 위에서 아래로 적용되는 순서와 MATCH 최종 규칙

규칙 적용 전 확인 사항: 규칙 모드, 연결 가로채기, 설정 저장

Clash 사용자 규칙은 커널에 전달된 연결의 출구를 선택합니다. 규칙을 올바르게 작성해도 모든 앱의 트래픽이 규칙을 거치는 것은 아닙니다. 시스템 프록시는 보통 프록시 설정을 따르는 앱에만 적용되고, TUN은 더 많은 트래픽을 가로챌 수 있지만 라우팅, 권한, 제외 설정의 영향을 받습니다. 문제를 확인할 때는 먼저 클라이언트의 ‘연결’ 화면에서 대상 요청이 표시되는지 확인한 뒤 어떤 규칙이 적용됐는지 살펴보세요.

이 글은 Clash에서 흔히 사용하는 규칙 문법을 다루며, 프로세스 식별은 Clash Meta(mihomo)를 기준으로 설명합니다. 커널과 운영체제에 따라 지원 범위가 다르므로 특정 클라이언트의 편집 화면을 커널 기능 전체 목록으로 간주하면 안 됩니다. 먼저 클라이언트의 커널 정보나 시작 로그에서 실제 실행 중인 커널을 확인한 뒤 해당 기능을 사용하세요.

실행 모드를 ‘규칙’으로 설정하고, 구성 파일의 mode: rule도 확인하세요. 전역 모드에서는 여기서 다루는 일반 분기 규칙에 따라 출구를 선택하지 않습니다.
현재 편집한 설정이 실제로 활성화된 설정인지 확인하세요. 이름만 같은 다른 구독 설정이 활성화되어 있을 수 있습니다.
기존 설정을 백업한 뒤 클라이언트의 설정 검사 기능으로 YAML을 검증하고 다시 불러오세요.
대상 앱의 기존 연결을 끊고 새 요청을 보내세요. 이미 연결된 세션은 규칙을 업데이트해도 출구가 자동으로 바뀌지 않는 경우가 많습니다.

규칙 기본 문법: 종류, 매칭 대상, 정책 이름

대부분의 규칙은 종류,매칭 대상,정책 형식으로 작성합니다. 정책에는 DIRECT, REJECT 같은 내장 정책이나 설정에 정의된 프록시 노드 또는 그룹 이름을 사용할 수 있습니다. MATCH에는 매칭 대상이 필요하지 않으므로 MATCH,정책으로 작성합니다. 각 필드는 영문 쉼표로 구분하고, 규칙 하나를 YAML 목록의 문자열 하나로 입력하세요.

규칙 종류	예시	매칭 범위
`DOMAIN`	`DOMAIN,api.example.com,DIRECT`	이 도메인과 정확히 일치
`DOMAIN-SUFFIX`	`DOMAIN-SUFFIX,example.com,DIRECT`	루트 도메인과 모든 하위 도메인
`DOMAIN-KEYWORD`	`DOMAIN-KEYWORD,example,REJECT`	도메인에 지정한 문자열이 포함됨
`IP-CIDR`	`IP-CIDR,192.168.0.0/16,DIRECT,no-resolve`	대상 IPv4 주소가 이 네트워크 대역에 속함
`IP-CIDR6`	`IP-CIDR6,fc00::/7,DIRECT,no-resolve`	대상 IPv6 주소가 이 네트워크 대역에 속함
`PROCESS-NAME`	`PROCESS-NAME,curl.exe,DIRECT`	식별된 프로세스 이름과 일치
`MATCH`	`MATCH,DIRECT`	앞선 규칙에 매칭되지 않은 연결 처리

프록시 그룹 이름이 실제 설정에 있어야 합니다

PROXY는 자동으로 생성되는 ‘전체 프록시 스위치’가 아닙니다. 설정에 PROXY라는 이름의 노드나 그룹이 없으면 이를 참조할 때 설정을 불러오는 과정에서 프록시를 찾을 수 없다는 오류가 날 수 있습니다. 마찬가지로 노드 선택과 노드 선택 2는 서로 다른 이름이므로 화면에 표시되는 모습만 보고 이름을 짐작하면 안 됩니다.

아래 코드는 규칙 목록만 보여 주는 예시입니다. 기존 설정에 ‘노드 선택’이라는 프록시 그룹이 정의되어 있다고 가정합니다. 이 조건에 맞지 않으면 그대로 붙여 넣고 자동 생성되기를 기다리지 말고, 실제 설정에 있는 정책 이름으로 바꾸세요.

rules:
  - "DOMAIN,api.example.com,DIRECT"
  - "DOMAIN-SUFFIX,example.com,노드 선택"
  - "MATCH,노드 선택"

규칙에 도메인을 입력할 때는 https://, 경로, 포트를 포함하지 않습니다. https://example.com/docs에서 /docs 경로만 처리하고 싶어도 DOMAIN으로는 설정할 수 없습니다. 이 규칙은 연결 계층의 트래픽을 분기하는 기능이지 HTTP 경로를 라우팅하는 기능이 아닙니다.

위에서 아래로 규칙 적용: 구체적인 예외를 앞에, 포괄적인 규칙을 뒤에

일반 규칙은 목록 순서대로 검사하며, 처음 일치하는 규칙이 정책을 결정합니다. 이후에 더 ‘정확한’ 규칙이 있어도 계속 검사하지 않습니다. 시스템이 DOMAIN과 DOMAIN-SUFFIX의 순서를 자동으로 정리하거나 네트워크 대역의 크기에 따라 규칙을 재배치하지도 않습니다. 따라서 규칙의 순서 자체가 설정 로직의 일부입니다.

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

api.example.com: 첫 번째 규칙에 일치해 DIRECT로 연결되며, 두 번째 규칙의 거부 대상이 되지 않습니다.
www.example.com: 첫 번째 규칙에는 일치하지 않고 두 번째 규칙에 일치해 REJECT됩니다.
example.com: 두 번째 규칙에도 일치합니다. 접미사 규칙은 루트 도메인 자체도 포함합니다.
notexample.com: example.com 도메인 계층에 속하지 않으므로 세 번째 규칙이 적용됩니다.

앞의 두 규칙 순서를 바꾸면 api.example.com도 거부됩니다. 이 문제는 중복 규칙을 추가할 필요 없이 예외 규칙을 포괄적인 규칙보다 앞에 두면 해결됩니다. 일반적으로는 명시적인 서비스 예외, 필요한 경우의 LAN 직접 연결, 분류별 규칙 모음, 지역 IP 규칙, 마지막으로 최종 규칙 순으로 배치합니다. 다만 반드시 따라야 하는 순서는 아닙니다. 서비스 예외와 LAN 정책 중 무엇을 우선할지는 실제 요구에 따라 결정하세요.

키워드 규칙은 매칭 범위가 넓어지기 쉽습니다

DOMAIN-KEYWORD,example은 도메인 계층이 아니라 도메인 안에 해당 문자열이 있는지 검사하므로 notexample.com에도 적용될 수 있습니다. 특정 사이트와 하위 도메인을 분기하려면 보통 DOMAIN-SUFFIX를 먼저 고려하세요. 몇 줄 줄이려고 짧은 키워드 규칙을 목록 맨 앞에 두면 관련 없는 서비스까지 함께 매칭될 수 있습니다.

IP-CIDR과 no-resolve: 직접 DNS 조회를 제한할 뿐 DNS를 끄지는 않습니다

IP-CIDR은 대상 주소가 지정한 네트워크 대역에 속하는지 확인합니다. 요청에 도메인만 포함되어 있다면 IP 규칙을 판단하기 전에 커널이 대상 IP를 알아내야 할 수 있습니다. 규칙에 no-resolve를 추가하면 해당 규칙을 확인하기 위해 도메인을 직접 조회하지 않습니다. ‘IP 매칭을 건너뛴다’는 뜻도, ‘이 연결에서 DNS를 전혀 사용하지 않는다’는 뜻도 아닙니다.

rules:
  - "IP-CIDR,10.0.0.0/8,DIRECT,no-resolve"
  - "IP-CIDR,172.16.0.0/12,DIRECT,no-resolve"
  - "IP-CIDR,192.168.0.0/16,DIRECT,no-resolve"
  - "IP-CIDR6,fc00::/7,DIRECT,no-resolve"
  - "MATCH,DIRECT"

위에는 자주 사용하는 IPv4 사설 네트워크 대역 세 개와 IPv6 고유 로컬 주소 범위를 소개했습니다. 이는 LAN 규칙 예시일 뿐 모든 특수 목적 주소를 망라한 목록은 아닙니다. 연결 대상이 이미 192.168.1.1처럼 명확한 IP 주소라면 no-resolve가 설정된 규칙도 매칭될 수 있습니다.

도메인 접속과 IP 주소 접속은 따로 확인하세요

192.168.1.1에 직접 연결된다고 해서 해당 주소로 해석되는 도메인도 같은 규칙에 반드시 매칭되는 것은 아닙니다. 커널이 실제 대상 주소를 아직 파악하지 못한 경우 no-resolve 설정에 따라 IP 규칙을 위해 직접 조회할지 여부가 달라집니다. 이미 확보한 대상 IP, DNS 캐시, Fake-IP 매핑 등의 상태도 실제 판정에 영향을 주므로 연결 상세 정보를 확인하세요.

PROCESS-NAME: 프로세스 규칙의 권한 및 플랫폼 제한

프로세스 규칙은 ‘특정 프로그램을 항상 같은 출구로 연결’하려는 경우에 유용합니다. 예를 들어 Windows에서 PROCESS-NAME,curl.exe,DIRECT를 사용하면 커널이 curl.exe로 식별한 연결에 적용할 수 있습니다. 이름은 연결 상세 정보에 실제로 표시되는 프로세스명을 기준으로 하세요. 바탕 화면 바로 가기 이름이나 창 제목을 대신 사용하면 안 됩니다.

시스템 지원 여부 확인: 프로세스 검색은 커널, 운영체제, 실행 권한에 따라 달라집니다. mihomo의 find-process-mode 설정은 프로세스 검색 방식에 영향을 줍니다. 값이 off라면 프로세스 규칙이 정상적으로 프로세스를 식별할 것이라고 기대할 수 없습니다.
트래픽 출처 확인: 라우터를 거치는 다른 기기의 트래픽은 라우터에서 원격 기기 앱의 로컬 프로세스명을 확인하기 어려운 경우가 많습니다. 이때는 프로세스명을 억지로 지정하기보다 소스 주소 규칙을 고려하세요.
규칙 순서 확인: 프로세스 규칙으로 일반 웹사이트 분기보다 우선 적용하려면 관련 도메인 규칙보다 앞에 배치하세요. 보조 규칙으로만 사용할 경우 해당 규칙 뒤, MATCH 앞에 두면 됩니다.
보조 프로세스 확인: 하나의 앱이 여러 프로세스를 통해 네트워크에 연결될 수 있습니다. 브라우저 엔진, 업데이트 프로그램, 메인 앱의 프로세스명이 서로 다를 수 있으므로 연결을 하나씩 확인하세요.

Android 클라이언트의 앱별 프록시나 앱 제외 목록은 대개 VPN의 트래픽 처리 범위를 설정하는 기능이며, 데스크톱 플랫폼의 PROCESS-NAME과 동일하지 않습니다. 앱이 제외되어 트래픽이 커널에 전달되지 않으면 일반 규칙으로 매칭할 수 없습니다.

MATCH 최종 규칙: 분류되지 않은 트래픽의 출구를 마지막 규칙으로 결정

MATCH에는 도메인이나 네트워크 대역 조건이 없으며, 여기까지 내려온 연결을 처리합니다. 일반 규칙 목록의 맨 마지막에 배치해야 합니다. 앞에 두면 뒤에 있는 일반 규칙은 매칭 기회를 얻지 못합니다. 보통 명확한 최종 규칙 하나면 충분하며, 여러 개를 작성해도 장애 조치가 되지는 않습니다.

mode: rule
rules:
  - "DOMAIN,api.example.com,DIRECT"
  - "DOMAIN-SUFFIX,example.com,REJECT"
  - "IP-CIDR,192.168.0.0/16,DIRECT,no-resolve"
  - "MATCH,DIRECT"

이 코드는 내장 정책만 사용한 문법 예시로, 지정된 도메인은 거부하고 나머지 트래픽은 직접 연결합니다. 모든 상황에 적용할 수 있는 프록시 설정은 아닙니다. 분류되지 않은 트래픽을 프록시로 보내려면 마지막 줄의 DIRECT를 실제로 존재하는 프록시 그룹 이름으로 바꾸고, 해당 그룹이 원하는 출구를 선택하고 있는지 확인하세요.

최종 정책에 정답이 하나로 정해져 있지는 않습니다. 기본 프록시를 사용하면 분류되지 않은 해외 서비스에 대응할 수 있지만 로컬 서비스의 경로가 불필요하게 우회될 수 있습니다. 기본 직접 연결은 잘못된 프록시 연결을 줄여 주지만 대상 서비스에 맞는 규칙을 추가해야 합니다. 먼저 기본 동작을 정하고 예외를 추가하는 편이 전역 모드를 계속 바꾸며 문제를 찾는 것보다 훨씬 수월합니다.

검증 및 문제 해결: 실행 중인 설정부터 새 연결까지 확인

규칙을 점검할 때는 설정이 로드됐는지, 요청이 커널에 전달됐는지, 어떤 규칙에 매칭됐는지, 최종적으로 어떤 출구를 사용했는지 순서대로 확인해야 합니다. 웹페이지가 열리는지만 봐서는 DNS, 규칙, 노드 중 어디에 문제가 있는지 구별하기 어렵습니다.

최종 설정 확인: 최상위 rules: 키가 예상대로 하나만 있는지, 목록 들여쓰기가 일관적인지 확인하고 Tab은 사용하지 마세요. 새 규칙이 실제로 추가된 위치를 찾아 특히 MATCH 뒤에 붙지 않았는지 확인하세요.
로드 로그 확인: 정책이 없다는 메시지가 표시되면 프록시 그룹 이름을 글자 단위로 확인하세요. 지원되지 않는 규칙 종류라는 메시지가 나오면 커널의 기능을 확인하고, 지원 범위 차이를 들여쓰기 조정으로 해결하려고 하지 마세요.
새 요청 보내기: 기존 연결을 먼저 끊고 테스트 대상에 다시 접속하세요. ‘연결’ 화면에서 도메인, 대상 IP, 규칙 종류, 프록시 체인을 확인합니다. 연결 상세 정보의 항목 이름은 클라이언트마다 다를 수 있습니다.
프록시 진입 경로 문제 분리: 명시적 프록시 요청을 사용하면 앱이 시스템 프록시 설정을 따르지 않는 문제를 배제할 수 있습니다. 이때도 수신 포트가 현재 실행 중인 커널에 실제로 속하는지 확인해야 합니다.

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

여기서는 로컬 HTTP 또는 혼합 프록시 포트가 7890이라고 가정합니다. 실제 mixed-port 값이 7897이라면 명령에서도 포트를 똑같이 바꿔야 합니다. 이 테스트는 명시적 HTTP 프록시 경로를 확인하며 TUN이 정상적으로 트래픽을 가로채는지까지 증명하지는 않습니다. 앞의 거부 예시에서 해당 도메인에 접속할 수 없는 것은 규칙의 예상 동작이므로 매칭 기록도 함께 확인하세요.

자주 발생하는 증상 3가지와 점검 순서

규칙을 저장했는데 적용되지 않음: 먼저 현재 설정과 최종 규칙 목록을 확인한 뒤 실행 모드를 점검하고, 마지막으로 기존 연결을 끊고 다시 시도하세요. 중복 규칙부터 추가하지 마세요.
도메인 규칙이 계속 매칭되지 않음: 커널이 도메인 정보를 확보했는지 확인하세요. 대상 IP만 있고 사용할 수 있는 도메인 매핑이나 스니핑 결과가 없다면 도메인 규칙이 사이트를 알아서 식별할 수는 없습니다.
프록시 그룹에 매칭됐지만 출구가 잘못됨: 그룹에서 현재 선택된 항목과 프록시 체인을 확인하세요. 규칙은 어떤 정책에 연결할지 결정하고, 프록시 그룹은 실제 노드를 결정합니다. 두 단계 모두 점검해야 합니다.

안정적으로 수정하려면 한 번에 한 종류의 규칙만 변경하고, 설정을 불러온 뒤 새 연결로 다시 테스트하세요. 구체적인 규칙을 앞에, 포괄적인 규칙을 뒤에 두고 MATCH로 마무리한 다음 영구 저장되는 오버라이드 기능을 사용해야 구독 업데이트 후 수정한 설정이 원래 상태로 되돌아가는 일을 막을 수 있습니다.