먼저 규칙 분기의 실행 모델을 확인하세요
Clash와 Clash Meta(mihomo)의 규칙 시스템은 목록 순서에 따라 위에서 아래로 매칭됩니다. 하나의 연결이 조건에 맞는 첫 번째 규칙과 일치하면 이후 규칙은 더 이상 판단하지 않습니다. 따라서 설정 결과는 어떤 규칙을 작성했는지뿐 아니라 각 규칙을 어느 위치에 배치했는지에도 좌우됩니다.
일반적인 중국 본토 직접 연결·해외 프록시 설정은 “구체적인 예외를 먼저, 포괄적인 규칙은 나중에”라는 순서로 구성할 수 있습니다. 먼저 LAN과 반드시 직접 연결해야 하는 도메인을 처리한 뒤 차단 규칙과 지정 프록시 도메인을 처리하고, 중국 본토 도메인과 중국 본토 IP를 매칭한 다음 마지막에 MATCH로 매칭되지 않은 트래픽을 받습니다.
rules:
- DOMAIN,router.asus.com,DIRECT
- DOMAIN-SUFFIX,qq.com,DIRECT
- DOMAIN-SUFFIX,bilibili.com,DIRECT
- DOMAIN-SUFFIX,github.com,해외 프록시
- GEOIP,CN,DIRECT
- MATCH,해외 프록시www.qq.com에 접속하면 DOMAIN-SUFFIX,qq.com,DIRECT와 일치하고, GitHub에 접속하면 “해외 프록시” 그룹으로 들어갑니다. 확인 결과 중국 본토 주소에 해당하는 나머지 연결은 GEOIP,CN,DIRECT가 처리하며, 남은 트래픽은 최종적으로 “해외 프록시”에 전달됩니다.
세 가지 동작은 각각 무엇을 의미할까요?
- DIRECT: 연결이 프록시 노드를 거치지 않고 로컬 장치 또는 현재 게이트웨이에서 직접 전송됩니다.
- REJECT: 코어가 연결을 거부합니다. 확인된 광고 도메인, 추적 도메인 또는 접속할 필요가 없는 대상에 적합합니다.
- 프록시 그룹 이름: 연결을 “해외 프록시”, “자동 선택”, “장애 조치”와 같은 지정 그룹에 전달합니다. 그룹 내부에서 실제 노드를 결정합니다.
규칙의 세 번째 항목은 중국어, 공백, 대소문자를 포함해 프록시 그룹 이름과 완전히 일치해야 합니다. 규칙에는 해외 프록시라고 썼지만 proxy-groups의 실제 이름이 해외 노드라면 코어가 검증할 때 프록시 그룹이 없다는 오류를 표시하는 경우가 많습니다.
DOMAIN, DOMAIN-SUFFIX, DOMAIN-KEYWORD 중 무엇을 선택할까요?
도메인 규칙은 일반적으로 IP 규칙보다 직관적이며 사이트 단위 분기에 적합합니다. 규칙 유형을 선택할 때는 경계가 명확한 매칭 방식을 우선해 짧은 키워드 하나가 관련 없는 많은 도메인에 영향을 주지 않도록 해야 합니다.
| 규칙 유형 | 매칭 범위 | 적용 사례 |
|---|---|---|
DOMAIN |
완전한 도메인만 매칭 | 특정 API, 다운로드 도메인 또는 사내 호스트만 별도로 처리 |
DOMAIN-SUFFIX |
주 도메인과 하위 도메인 매칭 | 한 사이트에 속한 대부분의 서비스 처리 |
DOMAIN-KEYWORD |
도메인에 지정 문자열이 포함된 경우 | 도메인 패턴이 명확하지만 접미사로 묶을 수 없는 일부 사례 |
rules:
- DOMAIN,api.example.net,해외 프록시
- DOMAIN-SUFFIX,example.org,해외 프록시
- DOMAIN-KEYWORD,cdnvideo,해외 프록시DOMAIN,api.example.net은 이 완전한 호스트 이름만 매칭하며 www.example.net에는 자동으로 적용되지 않습니다. DOMAIN-SUFFIX,example.org는 example.org, www.example.org, static.example.org를 매칭할 수 있습니다. 반면 DOMAIN-KEYWORD는 적용 범위를 바로 파악하기 어려우므로 사용 개수를 제한해야 합니다.
구체적인 예외는 포괄적인 접미사 규칙보다 앞에 배치해야 합니다
같은 사이트의 대부분 요청은 프록시를 사용하지만 다운로드 서버는 직접 연결해야 한다면, 먼저 완전한 도메인 예외를 작성한 다음 도메인 접미사 규칙을 작성합니다:
rules:
- DOMAIN,download.example.org,DIRECT
- DOMAIN-SUFFIX,example.org,해외 프록시
- MATCH,해외 프록시두 규칙의 순서를 바꾸면 download.example.org가 먼저 접미사 규칙과 일치하므로 직접 연결 예외가 적용되지 않습니다. rules를 수정한 뒤 “규칙은 분명히 있는데 실제로 실행되지 않는” 가장 흔한 원인 중 하나입니다.
프록시 그룹으로 수동 선택·속도 테스트·장애 조치를 분리하세요
rules는 트래픽이 어느 정책으로 들어갈지 결정하고, proxy-groups는 그 정책에서 어떤 노드를 사용할지 결정합니다. 많은 규칙에 노드 이름을 직접 작성해도 작동하지만, 노드가 업데이트되거나 이름이 바뀌면 하나씩 수정해야 합니다. 더 안정적인 방법은 규칙이 일관되게 프록시 그룹을 가리키도록 하고, 프록시 그룹에서 노드를 관리하는 것입니다.
proxy-groups:
- name: 해외 프록시
type: select
proxies:
- 자동 선택
- 장애 조치
- 홍콩 노드 A
- 싱가포르 노드 A
- DIRECT
- name: 자동 선택
type: url-test
proxies:
- 홍콩 노드 A
- 싱가포르 노드 A
- 일본 노드 A
url: https://www.gstatic.com/generate_204
interval: 300
tolerance: 50
- name: 장애 조치
type: fallback
proxies:
- 홍콩 노드 A
- 싱가포르 노드 A
- 일본 노드 A
url: https://www.gstatic.com/generate_204
interval: 300select, url-test, fallback의 차이
- select: 사용자가 그룹 내 항목을 직접 선택합니다. rules에서 최종적으로 참조하는 진입점으로 적합합니다.
- url-test: 그룹 내 노드를 주기적으로 테스트해 지연 시간이 낮은 사용 가능한 항목을 선택합니다. 예시는 300초마다 테스트하며,
tolerance: 50은 지연 시간 차이가 50밀리초 미만일 때 잦은 전환을 줄인다는 의미입니다. - fallback: 목록 순서에 따라 사용할 수 있는 첫 번째 노드를 사용합니다. 단순히 최저 지연 시간을 추구하기보다 고정된 우선순위를 중시합니다.
지연 시간 테스트 주소는 응답 본문이 작고 상태가 안정적이어야 합니다. 한 번의 속도 측정은 테스트 주소까지의 왕복 시간만 보여 줄 뿐, 동영상 처리량이나 모든 웹사이트의 연결 품질을 직접 나타내지는 않습니다. 실제 노드를 선택할 때는 5~10분 동안의 연결 실패율, 페이지 첫 바이트 도착 시간, 다운로드 속도도 확인해야 합니다.
중국 본토 직접 연결과 해외 프록시의 전체 rules 순서
GEOIP,CN,DIRECT만으로는 모든 중국 본토 서비스를 처리할 수 없습니다. GEOIP는 대상 IP의 지역을 기준으로 판단하며, 연결이 IP 매칭 단계에 들어간 뒤에야 작동합니다. 일부 사이트는 해외 CDN, 글로벌 Anycast 또는 해외 주소를 사용하므로 중국 본토 사용자를 대상으로 하더라도 CN 주소 데이터베이스에 포함되지 않을 수 있습니다. 따라서 자주 사용하는 중국 본토 도메인 규칙은 일반적으로 GEOIP보다 앞에 배치해야 합니다.
rules:
# 로컬 네트워크 및 예약 주소
- 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
# 명시적인 도메인 동작
- DOMAIN-SUFFIX,qq.com,DIRECT
- DOMAIN-SUFFIX,weixin.qq.com,DIRECT
- DOMAIN-SUFFIX,bilibili.com,DIRECT
- DOMAIN-SUFFIX,github.com,해외 프록시
- DOMAIN-SUFFIX,githubusercontent.com,해외 프록시
# IP 지역 및 최종 대체 규칙
- GEOIP,CN,DIRECT
- MATCH,해외 프록시no-resolve는 이 IP 규칙을 실행할 때 규칙 매칭만을 위해 추가로 도메인을 조회하지 않도록 코어에 알립니다. 이미 대상 IP를 확보한 연결과 LAN 대역 규칙에 적합하지만, 일반적인 DNS 설정을 대신할 수는 없습니다. 도메인 판단에 의존하는 요청은 Clash DNS 모듈이 안정적으로 결과를 얻을 수 있어야 합니다.
LAN 규칙을 앞에 배치해야 하는 이유
프린터, NAS, 라우터 관리 페이지, LAN 개발 서비스는 일반적으로 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16을 사용합니다. 이러한 주소가 최종 대체 규칙에 의해 원격 프록시로 전송되면 연결이 자주 시간 초과됩니다. TUN 모드는 더 넓은 시스템 트래픽을 가로채므로 사설 주소를 직접 연결로 명확히 보존해야 합니다.
기업 내부 네트워크에서 사용자 지정 대역을 사용한다면 실제 대역도 추가해야 합니다. 예를 들어 사내 네트워크 서비스가 100.64.20.0/24에 있다면 IP-CIDR,100.64.20.0/24,DIRECT,no-resolve를 추가할 수 있습니다. 다만 100.64.0.0/10은 통신사급 NAT에도 자주 사용되므로 네트워크 구조를 모르는 상태에서 직접 연결 범위를 넓혀서는 안 됩니다.
RULE-SET: 대규모 규칙을 별도 파일로 분리하기
도메인이 수백 또는 수천 개에 이르면 주 설정 파일에서 직접 관리하기가 어려워집니다. mihomo는 rule-providers로 규칙 모음을 불러온 뒤 rules에서 RULE-SET으로 참조할 수 있습니다. 이렇게 하면 광고 차단, 중국 본토 도메인, 프록시 도메인, 사설 네트워크를 각각 관리할 수 있습니다.
rule-providers:
reject-domain:
type: file
behavior: domain
format: yaml
path: ./ruleset/reject-domain.yaml
domestic-domain:
type: file
behavior: domain
format: yaml
path: ./ruleset/domestic-domain.yaml
rules:
- RULE-SET,reject-domain,REJECT
- RULE-SET,domestic-domain,DIRECT
- GEOIP,CN,DIRECT
- MATCH,해외 프록시해당 domain 유형 규칙 파일에는 payload 목록을 사용할 수 있습니다. 다음 내용은 형식을 설명하기 위한 것이며, 실제 배포 시에는 검토된 도메인 목록으로 교체해야 합니다:
payload:
- '+.ads.example.test'
- '+.tracker.example.test'
- 'metrics.example.test'behavior: domain은 도메인 모음에 적합하고, behavior: ipcidr은 IPv4·IPv6 네트워크 대역에 적합합니다. behavior: classical은 규칙 유형이 포함된 기존 형식 항목을 담을 수 있습니다. behavior는 규칙 파일의 내용과 일치해야 합니다. IP 대역을 domain 모음에 넣으면 로드에 실패하거나 매칭되지 않습니다.
원격 규칙 모음의 업데이트 정책
HTTP 유형 provider를 사용할 때는 일반적으로 url, 로컬 캐시 path, 업데이트 간격 interval을 지정해야 합니다. 예를 들어 interval: 86400은 86400초마다 업데이트를 확인한다는 의미입니다. 규칙 소스에 잠시 접근할 수 없어도 코어는 보통 캐시된 파일을 계속 사용하지만, 처음 시작할 때 로컬 캐시가 없으면 로드하지 못할 수 있습니다.
광고 차단 규칙은 중국 본토 직접 연결 모음보다 앞에 배치해야 합니다. 그렇지 않으면 두 모음에 동시에 포함된 도메인이 먼저 DIRECT와 일치합니다. 로그인, 결제, 인증 코드, 미디어 재생 같은 핵심 요청은 도메인에 ad, track 등의 문자열이 있다는 이유만으로 차단해서는 안 됩니다. 페이지 구성 요소가 사라졌다면 먼저 연결 로그에서 REJECT된 호스트를 찾은 뒤 정확한 허용 규칙을 추가하세요.
rules:
- DOMAIN,login.example.test,DIRECT
- RULE-SET,reject-domain,REJECT
- RULE-SET,domestic-domain,DIRECT
- GEOIP,CN,DIRECT
- MATCH,해외 프록시DNS, TUN 모드와 규칙 결과의 관계
시스템 프록시 모드는 주로 HTTP 또는 SOCKS 프록시 설정을 따르는 앱의 트래픽을 처리하고, TUN 모드는 가상 네트워크 인터페이스를 통해 더 많은 TCP·UDP 트래픽을 가로챕니다. 두 모드 모두 최종적으로 같은 rules를 사용할 수 있지만 DNS 조회 경로와 트래픽 적용 범위는 다릅니다.
fake-ip 모드에서 예약 주소가 보이는 것은 정상일까요?
enhanced-mode: fake-ip을 활성화하면 클라이언트가 먼저 앱에 198.18.0.0/15 범위의 매핑 주소를 반환한 다음, 코어가 원래 도메인에 따라 규칙을 실행할 수 있습니다. 이는 대상 웹사이트가 실제로 해당 대역에 있다는 뜻이 아닙니다. 문제를 확인할 때는 앱에 표시된 대상 IP만 보지 말고 연결 상세 정보의 Host, Rule, Rule Payload를 확인해야 합니다.
dns:
enable: true
listen: 0.0.0.0:1053
enhanced-mode: fake-ip
fake-ip-range: 198.18.0.1/16
nameserver:
- 223.5.5.5
- 119.29.29.29
fallback:
- tls://1.1.1.1:853
- tls://8.8.8.8:853예시에서는 Clash DNS가 1053 포트에서 수신하도록 설정해 로컬 장치에서 이미 사용 중인 53 포트 서비스와 직접 충돌하지 않게 했습니다. 일반적인 클라이언트는 수신 주소와 DNS 하이재킹을 자동으로 관리하므로, 덮어쓰기 로직을 모르는 상태에서 그래픽 인터페이스와 구독 원본 파일을 동시에 수정해서는 안 됩니다.
TUN을 켠 뒤 LAN에 접속할 수 없을 때
먼저 사설 네트워크 대역의 DIRECT 규칙이 MATCH보다 앞에 있는지 확인한 다음 TUN의 라우팅 제외 항목, 엄격한 라우팅 설정, DNS 하이재킹을 점검하세요. mihomo 설정에서 흔히 사용하는 DNS 하이재킹 형식에는 any:53이 있으며, TUN으로 들어오는 53번 포트 조회를 코어가 처리하도록 전달하는 목적입니다. 로컬에서 AdGuard Home, systemd-resolved, 기업 VPN DNS를 동시에 실행 중이라면 여러 서비스가 같은 포트를 차지하지 않도록 해야 합니다.
설정 검증, 매칭 확인 및 흔한 오류
수정을 마치면 먼저 문법을 검증한 다음 설정을 다시 불러오세요. mihomo 1.19.x는 명령줄에서 설정 디렉터리를 지정해 테스트할 수 있으며, 설치 방식에 따라 바이너리 이름과 디렉터리가 다를 수 있습니다:
mihomo -t -d /etc/mihomo테스트가 통과하면 클라이언트에서 「설정」→「다시 불러오기」를 실행하거나 서버에서 해당 재시작 명령을 실행하세요. 일부 데스크톱 클라이언트에서는 「설정」→「설정 디렉터리」에서 설정 디렉터리를 엽니다. 구독 설정을 다시 업데이트하면 직접 편집한 파일이 덮어써질 수 있으므로, 장기적으로 사용할 사용자 지정 규칙은 클라이언트가 지원하는 오버라이드·병합 설정 또는 별도로 관리하는 provider 파일에 저장해야 합니다.
규칙이 매칭되지 않을 때의 점검 순서
- 연결 페이지에서 대상 도메인을 찾고 실제로 매칭된 Rule과 정책 그룹을 기록합니다.
- 대상 도메인이 CNAME 리디렉션을 거치는지 확인하세요. 실제 연결 호스트는 브라우저 주소 표시줄의 주소와 다를 수 있습니다.
- rules 위쪽에 더 포괄적인 DOMAIN-SUFFIX, RULE-SET 또는 GEOIP 규칙이 이미 있는지 검색합니다.
- 규칙이 참조하는 프록시 그룹 이름이
proxy-groups와 완전히 일치하는지 확인합니다. - 설정을 다시 불러온 뒤 현재 활성화된 설정 파일이 수정한 파일인지 확인합니다.
- 앱 자체의 DNS 캐시를 지우거나 기존 연결을 끊은 다음 새 요청을 다시 보냅니다.
중국 본토 웹사이트가 여전히 프록시를 사용할 때
먼저 GEOIP보다 앞에서 프록시 규칙 모음과 매칭된 것은 아닌지 확인하세요. 도메인 규칙이 없다면 대상 IP가 CN으로 인식되는지 점검합니다. 글로벌 CDN을 사용하는 사이트는 해외 주소로 조회될 수 있으므로 주요 서비스 도메인에 DOMAIN-SUFFIX 직접 연결 규칙을 추가해야 하며, GEOIP 또는 IP-CIDR 범위를 넓혀서는 안 됩니다.
해외 웹사이트가 간헐적으로 직접 연결될 때
중국 본토 도메인 모음, 키워드 규칙 또는 범위가 지나치게 넓은 사용자 지정 IP 직접 연결 대역이 있는지 확인하세요. 브라우저에서 별도의 보안 DNS를 사용하고 있는지도 확인해야 합니다. 도메인 조회와 연결을 서로 다른 프로그램이 처리하면 로그에 예상한 도메인 정보가 나타나지 않을 수 있습니다. 문제를 확인하는 동안에는 Clash DNS가 통합 처리하도록 잠시 설정한 뒤 다른 DNS 설정을 하나씩 되돌리세요.
프록시 그룹에 노드가 있지만 사용할 수 없다고 표시될 때
노드 자체와 상태 확인 주소를 각각 테스트하세요. 모든 노드가 동시에 실패한다면 노드가 전부 작동하지 않는 것이 아니라 테스트 주소가 현재 네트워크에서 제한되었을 가능성이 있습니다. 안정적인 소용량 응답 주소로 바꾸고 테스트 간격은 300~600초로 유지해 지나치게 잦은 탐색으로 연결 수가 늘어나지 않도록 하세요.
유지 관리하기 쉬운 분기 설정의 조건
안정적인 규칙 설정은 항목 수를 늘리는 데 목표를 두지 않고 명확한 우선순위를 유지합니다. 사설 네트워크와 정확한 예외를 앞에 두고, 차단 모음과 서비스 도메인을 그다음에 배치하며, 중국 본토 도메인과 GEOIP로 넓은 범위를 분류하고 MATCH로 최종 대체 처리를 합니다. 프록시 노드는 select, url-test, fallback 등의 프록시 그룹으로 통합 관리하고, rules가 자주 바뀌는 노드 이름에 직접 의존하지 않도록 합니다.
조정할 때마다 한 계층만 수정하고 연결 로그로 확인하는 것이 좋습니다. DNS 모드 변경, TUN 활성화, 규칙 모음 교체, 프록시 그룹 수정까지 한 번에 진행하면 문제의 원인을 찾기 어려워집니다. “문법 검증, 다시 불러오기, 새 연결 생성, 매칭 규칙 확인” 순서로 테스트하면 대개 몇 분 안에 문제가 규칙 순서, DNS, 노드 또는 시스템 적용 범위 중 어디에 있는지 판단할 수 있습니다.