Clash 사용자 규칙
DOMAIN, DOMAIN-SUFFIX, IP-CIDR, GEOIP, PROCESS-NAME 규칙과 위에서 아래로 적용되는 매칭 순서, no-resolve 옵션, rule-providers 활용법을 정리합니다.
규칙이 적용되기 위한 세 가지 조건
Clash 규칙은 연결에 적용할 아웃바운드 정책을 선택하며, 프록시 노드를 생성하지는 않습니다. 설정에서 노드, 정책 그룹, 규칙은 서로 다른 역할을 합니다. 노드는 출구를 제공하고, 정책 그룹은 선택 가능한 출구를 구성하며, rules는 연결을 어느 출구로 보낼지 결정합니다. 문제를 진단할 때는 이 세 계층을 분리해 살펴보세요. 노드가 작동하지 않는 문제를 규칙 미매칭으로 오해하지 않는 데 도움이 됩니다.
- 연결이 커널에 들어왔는지 확인하세요. 시스템 프록시는 보통 프록시 설정을 따르는 프로그램에만 적용됩니다. 게임, 일부 명령줄 도구, UDP 트래픽은 프록시를 거치지 않을 수 있습니다. TUN을 사용하면 연결을 처리하는 범위를 넓힐 수 있지만, 라우팅과 제외 항목, 권한도 확인해야 합니다.
- 현재 모드가 규칙 모드인지 확인하세요. 설정에서
mode: rule에 해당합니다. 전역 모드와 직접 연결 모드에서는 일반적으로 여기에 작성한 규칙 목록에 따라 트래픽을 분류하지 않습니다. - 실제로 실행 중인 설정을 수정했는지 확인하세요. 클라이언트에 표시되는 구독 원문, 재정의 설정, 커널이 최종적으로 사용하는 설정은 서로 다를 수 있습니다. 저장한 뒤 설정 검증 결과를 확인하고 다시 불러오세요.
규칙 문법과 주요 유형
대부분의 규칙은 유형,매칭 대상,정책 형식입니다. 쉼표는 영문 반각 문자를 사용합니다. 규칙은 YAML 목록 항목으로 rules: 아래에 작성하며, 각 항목 앞에는 하이픈을 붙입니다. 내장 정책 DIRECT는 직접 연결, REJECT는 연결 거부를 뜻합니다. 그 밖의 정책 이름은 정의된 노드 또는 정책 그룹 이름과 정확히 일치해야 합니다.
| 규칙 유형 | 예시 | 매칭 범위 |
|---|---|---|
DOMAIN | DOMAIN,api.example.com,DIRECT | 해당 도메인과 정확히 일치하며 하위 도메인은 포함하지 않습니다. |
DOMAIN-SUFFIX | DOMAIN-SUFFIX,example.com,DIRECT | 루트 도메인과 하위 도메인에 매칭되며 otherexample.com에는 매칭되지 않습니다. |
DOMAIN-KEYWORD | DOMAIN-KEYWORD,example,DIRECT | 도메인에 포함된 문자열을 기준으로 매칭하며, 접미사 규칙보다 범위가 넓습니다. |
IP-CIDR | IP-CIDR,192.168.0.0/16,DIRECT,no-resolve | IPv4 대상 네트워크에 매칭됩니다. 예시 범위는 192.168.0.0~192.168.255.255입니다. |
IP-CIDR6 | IP-CIDR6,fc00::/7,DIRECT,no-resolve | IPv6 네트워크에 매칭됩니다. 예시는 고유 로컬 주소 범위입니다. |
GEOIP | GEOIP,CN,DIRECT,no-resolve | 로컬 IP 지리 데이터베이스를 기준으로 주소를 매칭하며, 정확도는 데이터베이스에 따라 달라집니다. |
PROCESS-NAME | PROCESS-NAME,curl.exe,DIRECT | 커널이 인식한 프로세스 이름을 기준으로 매칭하며, 운영체제와 권한의 영향을 받습니다. |
MATCH | MATCH,출구 | 앞선 규칙에 매칭되지 않은 연결을 처리합니다. 매칭 대상은 입력하지 않습니다. |
도메인 규칙에는 프로토콜, 포트, 경로를 입력하지 않습니다
https://api.example.com:443/v1/status를 분류하려면 도메인 규칙에는 api.example.com만 입력합니다. 전체 URL을 DOMAIN에 넣어도 웹 주소 기준으로 매칭되지 않습니다. 대상 포트별로 구분하려면 커널이 지원하는 DST-PORT를 사용할 수 있습니다. 다만 DST-PORT,443,출구만 단독으로 추가하면 특정 웹사이트가 아니라 해당 위치 이후에 검사되는 모든 443 포트 연결에 매칭됩니다.
본문의 example.com은 문법을 보여 주기 위한 예약 예시 도메인입니다. 실제 설정에서는 분류하려는 도메인으로 바꾸세요. 이 예시 항목을 그대로 두고 자주 방문하는 웹사이트의 연결 경로가 바뀌기를 기대해서는 안 됩니다.
매칭 순서와 예외 규칙
일반 규칙은 목록의 위에서 아래 순서로 확인하며, 처음으로 매칭된 규칙이 정책을 결정합니다. 이후 규칙은 더 이상 확인하지 않습니다. 커널이 자동으로 더 정밀한 규칙을 선택하거나 아래쪽의 거부 규칙을 보고 결과를 다시 계산하지는 않습니다. 따라서 예외 규칙은 보통 일반 규칙보다 앞에 두고, MATCH는 마지막에 둡니다.
rules:
- DOMAIN,api.example.com,DIRECT
- DOMAIN,ads.example.com,REJECT
- DOMAIN-SUFFIX,example.com,출구
- IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
- MATCH,출구api.example.com은 첫 번째 규칙에 매칭되어 직접 연결됩니다.ads.example.com은 두 번째 규칙에 매칭되어 연결이 거부됩니다.www.example.com은 세 번째 규칙에 매칭되어 ‘출구’ 정책 그룹으로 전달됩니다.- 대상 주소가
192.168.1.20이고 앞선 도메인 규칙에 매칭되지 않은 연결은 로컬 네트워크 규칙에 매칭됩니다. - 나머지 연결은 마지막
MATCH규칙으로 전달됩니다.
세 번째 접미사 규칙을 첫 번째로 옮기면 api.example.com과 ads.example.com이 모두 먼저 해당 규칙에 매칭됩니다. 뒤에 있는 직접 연결 및 거부 규칙은 문법이 올바르더라도 실행되지 않습니다.
프로세스 규칙에도 같은 순서가 적용됩니다
PROCESS-NAME,curl.exe,DIRECT를 목록 맨 위에 두면 해당 프로세스의 연결은 웹사이트 규칙을 확인하기 전에 직접 연결될 수 있습니다. 특정 도메인에 예외를 적용하려면 도메인 규칙을 우선 사용하세요. 프로그램 전체의 연결 경로를 고정하려는 경우에만 프로세스 규칙을 사용하면 됩니다. Windows에서는 이름에 .exe가 붙는 경우가 많고 Linux와 macOS에서는 보통 확장자가 없습니다. 연결 상세 정보에 표시된 실제 프로세스 이름을 기준으로 설정하세요.
no-resolve의 정확한 의미
no-resolve는 IP 유형 규칙을 검사할 때 도메인 정보만 있는 연결에 대해 도메인 조회를 별도로 시작하지 않도록 하는 옵션입니다. DNS를 차단하는 옵션도 아니고, 연결에서 도메인이 최종적으로 해석되지 않는다는 뜻도 아닙니다. 클라이언트 DNS, 다른 규칙, 실제 아웃바운드 연결 과정에서 도메인이 해석될 수 있습니다.
rules:
- DOMAIN-SUFFIX,example.com,출구
- IP-CIDR,10.0.0.0/8,DIRECT,no-resolve
- GEOIP,CN,DIRECT,no-resolve
- MATCH,출구연결에 도메인 정보만 있고 첫 번째 규칙에 매칭되지 않는 상황을 가정해 보겠습니다. 다음 IP 규칙을 검사할 때 no-resolve를 사용하면 해당 규칙만을 위해 추가로 도메인을 조회하지 않습니다. 연결에 사용할 수 있는 대상 IP가 이미 있다면 IP 유형 규칙으로 매칭할 수 있습니다. 실제 대상 IP가 있는지는 DNS 모드, 연결 진입 경로, 메타데이터에 따라 달라집니다. 도메인이 실제로 어떤 IP로 해석됐는지만 보고 규칙에 반드시 매칭된다고 판단할 수는 없습니다.
자주 선택하는 두 가지 방식
- 도메인 분류 우선: 주요 도메인 규칙을 앞에 두고 IP 규칙에
no-resolve를 추가하면 규칙 평가 중 발생하는 부가적인 도메인 조회를 줄일 수 있습니다. 대신 도메인 정보만 있는 일부 연결은 기본 규칙으로 바로 넘어갈 수 있습니다. - 해석된 IP 기준 분류: 특정 IP 규칙에서
no-resolve를 생략하면 평가 중 도메인 조회를 허용할 수 있습니다. 이 방식은 DNS 응답과 조회 시간에 영향을 받으므로 DNS 설정도 함께 확인해야 합니다.
GEOIP,CN은 데이터베이스에 기록된 IP의 지리적 위치를 판별하는 규칙이지, 웹사이트 운영 주체를 판별하거나 ‘중국 본토의 모든 웹사이트’를 의미하지는 않습니다. CDN을 사용하는 웹사이트는 해석된 주소에 따라 결과가 달라질 수 있습니다. 안정적으로 제어해야 하는 서비스에는 구체적인 도메인 규칙을 사용하는 편이 좋습니다.
rule-providers로 규칙 재사용하기
여러 설정에서 같은 도메인과 네트워크 목록을 재사용하려면 매칭 조건을 규칙 제공자에 넣고 RULE-SET으로 불러올 수 있습니다. 제공자는 규칙 내용을 불러오는 역할을 합니다. 실제 우선순위는 제공자의 선언 위치가 아니라 기본 rules 목록에서 RULE-SET이 놓인 위치에 따라 결정됩니다.
기본 설정: 로컬 classical 규칙 세트
rule-providers:
local-direct:
type: file
behavior: classical
path: ./rules/local-direct.yaml
rules:
- DOMAIN,api.example.com,출구
- RULE-SET,local-direct,DIRECT
- MATCH,출구규칙 세트 파일: rules/local-direct.yaml
payload:
- DOMAIN-SUFFIX,example.com
- IP-CIDR,192.168.0.0/16,no-resolve
- IP-CIDR6,fc00::/7,no-resolve규칙 세트의 항목에는 DIRECT나 정책 그룹 이름을 쓰지 않습니다. 대상 정책은 기본 설정의 RULE-SET,local-direct,DIRECT에서 일괄 지정합니다. 이 예시에서는 api.example.com이 기본 목록의 첫 번째 규칙에 먼저 매칭됩니다. 같은 루트 도메인의 다른 하위 도메인만 규칙 세트로 넘어가 직접 연결됩니다.
path는 일반적으로 커널의 작업 디렉터리를 기준으로 해석되며, 다운로드한 구독 파일이 있는 디렉터리를 기준으로 하지 않을 수 있습니다. 클라이언트에서 허용하는 규칙 파일 경로를 확인하고 파일을 먼저 만들어야 합니다. 파일이 없거나 디렉터리에 접근할 수 없거나 내용 형식이 잘못되면 제공자를 불러오지 못할 수 있습니다.
| behavior | 내용 형식 | 사용 사례 |
|---|---|---|
classical | 유형이 포함된 규칙. 예: DOMAIN-SUFFIX,example.com | 하나의 규칙 세트에서 도메인과 IP 등 여러 조건을 함께 관리할 때 적합합니다. |
domain | 커널의 도메인 규칙 세트 문법에 따라 도메인 항목 입력 | 도메인 목록만 관리하며 classical의 유형 접두사는 사용하지 않습니다. |
ipcidr | 192.168.0.0/16과 같은 주소 범위 입력 | IPv4 및 IPv6 네트워크 목록을 별도로 관리합니다. |
behavior만 바꿔서는 세 가지 형식을 혼용할 수 없습니다. HTTP 제공자를 사용하려면 신뢰할 수 있는 실제 규칙 주소와 업데이트 주기도 설정해야 합니다. 원격 규칙은 트래픽 분류 결과를 바꿀 수 있으므로 출처와 업데이트 내용을 확인하고, 출처를 알 수 없는 규칙 세트를 모든 사용자 지정 예외보다 앞에 두지 마세요.
검증용 최소 설정
아래 설정은 mihomo의 문법과 규칙 매칭 순서를 확인하기 위한 예시입니다. 프록시 노드는 포함되어 있지 않으며 ‘출구’ 그룹에는 DIRECT만 있으므로 거부 규칙을 제외한 실제 아웃바운드 연결은 직접 연결됩니다. 규칙 동작을 확인한 다음 기존 노드나 노드 제공자를 정책 그룹에 연결하세요.
mixed-port: 7890
allow-lan: false
mode: rule
log-level: info
proxy-groups:
- name: 출구
type: select
proxies:
- DIRECT
rules:
- DOMAIN,api.example.com,DIRECT
- DOMAIN,ads.example.com,REJECT
- DOMAIN-SUFFIX,example.com,출구
- IP-CIDR,127.0.0.0/8,DIRECT,no-resolve
- 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,::1/128,DIRECT,no-resolve
- IP-CIDR6,fc00::/7,DIRECT,no-resolve
- MATCH,출구명령줄에서 테스트하기 쉽도록 포트에 7890을 지정했습니다. 다른 프로세스가 이미 사용 중이라면 사용 가능한 포트로 변경하고 테스트 명령도 함께 수정하세요. allow-lan: false는 로컬 네트워크에 프록시 진입점을 공개하지 않습니다. 실제 클라이언트에서 수신 포트를 덮어쓸 수 있으므로 실행 중인 설정과 리스닝 상태를 확인하세요.
먼저 설정을 검증하고 요청을 테스트하세요
mihomo -t -f ./config.yaml
curl -I --proxy http://127.0.0.1:7890 https://example.com첫 번째 명령을 실행하려면 로컬에서 mihomo라는 실행 파일을 사용할 수 있어야 하고 현재 디렉터리에 config.yaml이 있어야 합니다. 그래픽 클라이언트를 사용한다면 클라이언트의 설정 검사 기능으로 대신할 수 있습니다. 두 번째 명령은 요청을 HTTP 프록시로 명시적으로 보내므로 명령줄이 시스템 프록시 설정을 상속하는지에 영향을 받지 않습니다. Windows PowerShell에서는 curl.exe로 해당 프로그램을 호출할 수 있습니다.
예시 요청은 DOMAIN-SUFFIX,example.com,출구에 매칭되어야 합니다. 연결 상세 정보나 로그에서 규칙 유형, 매칭 대상, 정책 체인을 확인해 검증하세요. 웹페이지 로딩 속도나 출구 IP만으로는 판단할 수 없습니다. 서로 다른 두 규칙이 같은 정책을 가리킬 수 있으므로 출구가 같다는 사실만으로 동일한 규칙이 적용됐다고 볼 수 없습니다.
규칙이 적용되지 않을 때 확인할 순서
- 연결이 표시되는지 확인하세요. 클라이언트의 연결 목록에 대상 요청이 없다면 먼저 프록시 진입점, TUN 라우팅, 애플리케이션 설정을 확인하세요. 요청이 커널에 들어오지 않았다면 규칙 순서를 바꿔도 해결되지 않습니다.
- 실제 규칙 모드를 확인하세요. 전역 모드나 직접 연결 모드가 아닌지 확인하고, 편집기에서 보고 있는 파일 이름이 아니라 현재 활성화된 설정을 확인하세요.
- 처음 매칭된 규칙을 확인하세요. 연결이 범위가 넓은 접미사, 키워드 또는 프로세스 규칙에 매칭된다면 필요한 예외를 해당 규칙보다 앞에 두세요.
MATCH뒤에 적용이 필요한 규칙을 추가하지 마세요. - 정책 이름을 확인하세요. ‘출구’와 ‘프록시 출구’는 서로 다른 이름입니다. 정의되지 않은 정책을 참조하면 설정 검증에 실패할 수 있으므로 먼저 설정 로딩 오류를 해결하세요.
- 도메인 및 프로세스 메타데이터를 확인하세요. 연결에 IP 정보만 있으면 도메인 규칙에서 사용할 매칭 대상이 없을 수 있습니다. 프로세스 이름이 비어 있으면 프로세스 규칙도 예상대로 동작하지 않습니다. TUN이 모든 연결의 도메인과 프로세스 정보를 자동으로 채워 주는 것은 아닙니다.
- 제공자 상태를 확인하세요. 파일이 존재하는지, 형식이
behavior와 일치하는지, 클라이언트가 규칙 세트를 정상적으로 불러왔는지 확인하세요. 로컬 파일을 수정한 뒤에는 클라이언트 안내에 따라 제공자를 업데이트하거나 설정을 다시 불러오세요. - 새 연결로 다시 테스트하세요. 설정을 업데이트한 뒤에도 이미 연결된 장시간 연결은 기존 아웃바운드 경로를 계속 사용할 수 있습니다. 기존 요청을 중지하고 새 연결을 시작하세요. 필요하면 해당 연결을 종료한 뒤 다시 테스트하세요.
규칙을 정리할 때는 순서를 일관되게 유지하세요. 명확한 거부 및 직접 연결 예외를 앞에 두고, 서비스 도메인 규칙 세트를 그다음에 배치합니다. 프로세스 및 IP 유형 규칙은 실제 우선순위에 맞춰 정리하고, 마지막에는 명확한 MATCH 규칙을 둡니다. DNS, TUN, 전체 규칙을 한꺼번에 바꾸기보다 조건을 한 종류씩 수정하고 새 연결로 매칭 결과를 확인해야 원인을 쉽게 찾을 수 있습니다.