Clash 규칙 라우팅 실전: 중국 본토 사이트는 직접 연결하고 해외 서비스는 프록시로 보내는 rules 설정

1. 규칙 모드와 트래픽 유입 경로 확인

“중국 본토 사이트는 직접 연결하고 해외 서비스는 프록시로 보내기”가 제대로 작동하려면 세 가지 조건이 필요합니다. 요청이 클라이언트로 들어오고, 규칙 모드가 활성화되어 있으며, 설정의 규칙이 사용 가능한 아웃바운드를 가리켜야 합니다. rules만 수정하고 글로벌 모드를 계속 사용하면 라우팅 결과를 확인할 수 없습니다. 브라우저가 프록시를 전혀 사용하지 않는 경우에도 규칙은 적용되지 않습니다.

FlClash는 mihomo 코어를 사용합니다. 이 글에서는 mihomo 규칙 문법을 기준으로 설명하며, 이전 Clash 버전과 현재 코어의 데이터베이스 기능이 완전히 같다고 가정하지 않습니다. 시작하기 전에 현재 설정을 백업하고 다음 항목을 확인하세요.

사용 중인 설정 확인: 프로필 목록에서 현재 적용 중인 구독 또는 로컬 설정을 확인하세요. 비활성 복사본을 수정하지 않도록 주의해야 합니다.
아웃바운드 모드는 규칙 모드: 인터페이스의 규칙 모드는 설정 항목 mode: rule에 해당합니다. 글로벌 모드와 직접 연결 모드에서는 아래 규칙 체인에 따라 라우팅되지 않습니다.
요청이 코어에 도달하는지 확인: 시스템 프록시를 사용한다면 앱이 시스템 프록시를 지원하고 따르는지 확인하세요. TUN을 사용한다면 가상 네트워크 어댑터가 실행 중인지, 라우팅이 대상 요청을 처리하는지 점검하세요.
프록시 아웃바운드 사용 가능 여부: 대상 정책 그룹이 존재하고 연결 가능한 프록시가 선택되어 있어야 합니다. 규칙이 제대로 매칭되어도 상위 서버 연결까지 성공한다는 뜻은 아닙니다.

2. rules는 위에서부터 매칭되며 처음 일치한 규칙이 아웃바운드를 결정

일반적인 규칙 형식은 “유형, 매칭 대상, 정책”입니다. 예를 들면 DOMAIN-SUFFIX,github.com,PROXY와 같습니다. 코어는 규칙을 순서대로 확인하며, 규칙 하나가 일치하면 대개 해당 연결에 적용할 정책이 결정되고 뒤에 있는 더 구체적인 규칙을 계속 찾지 않습니다. 따라서 예외 규칙은 앞에, 분류 규칙은 중간에, 기본 대체 규칙은 마지막에 배치하세요.

규칙 유형	판별 대상	적합한 용도
`DOMAIN`	전체 도메인	호스트 이름 하나의 아웃바운드 지정
`DOMAIN-SUFFIX`	도메인 접미사	기본 도메인과 하위 도메인 모두 포함
`GEOSITE`	도메인 분류 데이터베이스	사이트 그룹별 라우팅
`GEOIP`	대상 IP의 분류	도메인 규칙을 보완해 놓친 주소 처리
`MATCH`	나머지 모든 요청	마지막 기본 대체 규칙이며 매칭 대상 필드는 없음

정확한 도메인과 접미사의 차이

rules:
  - DOMAIN,api.github.com,PROXY
  - DOMAIN-SUFFIX,github.com,PROXY
  - MATCH,PROXY

첫 번째 규칙은 api.github.com만 매칭합니다. 두 번째 규칙은 github.com과 그 하위 도메인을 모두 매칭하지만 notgithub.com은 같은 접미사로 취급하지 않습니다. 위 예시의 첫 번째 규칙은 정확한 도메인 매칭 방식을 보여줍니다. 두 규칙이 같은 정책을 가리킨다면 보통 접미사 규칙만으로 충분합니다.

DIRECT는 내장 직접 연결 아웃바운드입니다. PROXY는 고정된 내장 프록시 키워드가 아니라 이 글에서 정한 정책 그룹 이름입니다. 실제 설정에서 다른 그룹 이름을 사용한다면 예시의 PROXY를 모두 설정에 있는 정확한 이름으로 바꿔야 합니다.

3. 정책 그룹을 준비한 다음 중국 본토 직결 규칙 작성

구독에는 보통 proxies, proxy-providers, proxy-groups 중 일부 또는 전체가 이미 포함되어 있습니다. 예시 규칙으로 구독 파일 전체를 덮어쓰지 마세요. 먼저 proxy-groups를 찾아 프록시 그룹의 name과 해당 그룹에서 현재 선택된 실제 아웃바운드를 확인하세요.

기존 정책 그룹이 있으면 이름을 그대로 사용

현재 설정에 사용 가능한 PROXY 정책 그룹이 있다면 아래 규칙에서 그대로 사용할 수 있습니다. 그룹 이름이 “프록시 선택”이라면 규칙은 GEOSITE,geolocation-!cn,프록시 선택으로 작성해야 합니다. 그룹 이름의 공백과 대소문자도 이름의 일부이므로 화면에 보이는 대로 임의로 줄이지 마세요.

직접 설정할 때는 기존 프록시로 선택 그룹 구성

다음은 mihomo 정책 그룹 예시입니다. 설정에 사용 가능한 프록시 또는 프록시 제공자가 이미 정의되어 있어야 합니다. include-all: true를 설정하면 구성된 프록시와 프록시 제공자 안의 프록시가 선택 항목에 포함됩니다. 이 설정이 프록시 연결 정보를 새로 만들어 주는 것은 아닙니다.

proxy-groups:
  - name: PROXY
    type: select
    include-all: true

이 항목은 기존 proxy-groups 목록에 병합하세요. 같은 이름의 최상위 필드를 하나 더 만들면 안 됩니다. 불러온 뒤 그룹에 선택 가능한 프록시가 있는지 확인하세요. 목록이 비어 있다면 규칙을 수정하기 전에 구독 또는 프록시 제공자를 먼저 복구해야 합니다. 설정을 불러오려고 유일한 아웃바운드를 DIRECT로 바꾸지 마세요. 그렇게 하면 “해외 프록시” 트래픽도 결국 직접 연결됩니다.

4. 조정 가능한 중국 본토 직결·해외 프록시 rules 예시

아래 내용은 규칙 조각이며 전체 구독 설정이 아닙니다. 사용하려면 먼저 사용 가능한 PROXY 그룹이 있어야 하고 GeoSite 데이터에 cn 및 geolocation-!cn 분류가 포함되어 있는지 확인해야 합니다. 규칙은 로컬 네트워크 IPv4 직접 연결, 도메인 예외, 도메인 분류, IP 보완, 최종 기본 대체의 다섯 단계로 구성됩니다.

mode: rule

rules:
  # 로컬 네트워크 주소와 로컬 도메인
  - DOMAIN,localhost,DIRECT
  - DOMAIN-SUFFIX,lan,DIRECT
  - 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,github.com,PROXY

  # 먼저 도메인 분류 적용
  - GEOSITE,cn,DIRECT
  - GEOSITE,geolocation-!cn,PROXY

  # 이어서 알려진 대상 IP로 보완
  - GEOIP,CN,DIRECT,no-resolve

  # 다른 규칙에 일치하지 않은 연결
  - MATCH,PROXY

도메인 분류를 GEOIP보다 먼저 두는 이유

사이트의 서비스 지역과 서버 IP의 위치는 같지 않습니다. 하나의 서비스가 여러 지역의 CDN을 사용할 수도 있고, 해외 서비스가 중국 본토에 접속 지점을 둘 수도 있습니다. 알려진 도메인 분류로 아웃바운드를 먼저 결정한 다음 IP 규칙으로 누락된 항목을 보완하면 IP 위치만 보고 잘못 라우팅하는 경우를 줄일 수 있습니다. 프록시로 보내려는 도메인 예외는 GEOSITE,cn,DIRECT보다 앞에 배치하세요.

MATCH를 마지막에 두면 어떤 의미일까요?

MATCH,PROXY는 식별되지 않은 트래픽을 기본적으로 프록시로 보낸다는 뜻입니다. 그렇다고 중국 본토의 모든 서비스가 직접 연결되는 것은 아닙니다. 데이터베이스에 등록되지 않았거나 대상 IP를 얻지 못했거나 IP 분류가 부정확하면 요청이 기본 대체 규칙에 도달할 수 있습니다. MATCH,DIRECT로 바꾸면 식별되지 않은 해외 서비스도 직접 연결될 수 있습니다. 두 방식은 서로 다른 선택이며, 자동 판별을 기대하고 둘 다 작성하면 안 됩니다.

5. GEOSITE, GEOIP와 no-resolve의 적용 범위

GeoSite 분류는 데이터베이스를 기반으로 하며 실시간 위치 조회가 아닙니다

GEOSITE,cn,DIRECT는 도메인 목록을 기준으로 매칭하며 서버가 어느 국가에 있는지 확인하는 규칙이 아닙니다. geolocation-!cn도 특정 분류 이름이지, 그 밖의 모든 분류를 자동으로 반전하는 일반 문법이 아닙니다. 데이터 소스에 해당 분류가 없으면 설정을 불러올 때 분류를 찾을 수 없다는 오류가 발생할 수 있습니다.

이런 오류가 발생하면 먼저 클라이언트 로그에서 GeoSite 로드 정보를 확인하고 데이터베이스가 다운로드되었는지, 파일을 읽을 수 있는지, 사용하려는 분류가 포함되어 있는지 점검하세요. 확인하기 어렵다면 해외 분류 규칙을 일시적으로 제거해 나머지 트래픽을 MATCH,PROXY로 처리할 수 있습니다. 중국 본토 분류와 다른 규칙은 정상적으로 로드되어야 합니다. 실제로 없는 분류 이름을 비슷한 철자로 바꿔가며 반복해서 추가하지 마세요.

no-resolve는 추가 DNS 조회를 막지만 매칭 가능성도 달라집니다

GEOIP,CN,DIRECT,no-resolve는 이 IP 규칙만을 위해 도메인을 별도로 조회하지 말라는 뜻입니다. 연결에 사용할 수 있는 실제 대상 IP가 이미 있다면 판별할 수 있습니다. 도메인만 있고 사용할 IP가 없다면 이 규칙이 임의로 위치를 알아낼 수 없으므로 요청은 다음 규칙으로 넘어갑니다.

IP 주소에 직접 연결: 대상이 처음부터 IP 주소라면 도메인 조회 없이 해당 주소를 확인할 수 있습니다.
도메인을 포함한 HTTP CONNECT 또는 SOCKS 요청: 규칙 체인에 들어올 때 실제 대상 IP가 이미 있다고 단정할 수 없습니다.
Fake-IP 환경: 도메인을 복원하고 실제 주소를 얻을 수 있는지는 DNS 가로채기, 매핑 상태, 규칙 처리 과정에 따라 달라집니다. 앱에 표시된 가상 주소만 보고 판단할 수 없습니다.

중국 본토 IP 규칙이 더 많은 미확인 도메인에 적용되도록 하려면 해당 규칙에서 no-resolve를 제거하는 방안을 검토할 수 있습니다. 필요할 때 코어가 도메인을 조회하도록 허용하는 방식입니다. 다만 DNS 조회가 발생하고 결과는 선택된 리졸버의 영향을 받습니다. 변경 전에 DNS 요청 경로와 연결 가능 여부를 확인해 DNS 시간 초과를 규칙 오류로 오해하지 않도록 하세요.

6. 웹페이지 속도가 아닌 연결 기록으로 규칙 매칭 확인

설정을 성공적으로 불러온 뒤 새 연결을 만들어 확인해야 합니다. 브라우저는 기존 HTTP/2 또는 HTTP/3 세션을 재사용할 수 있으므로 규칙을 바꿔도 이전 연결의 아웃바운드가 자동으로 다시 선택되지는 않습니다. 대상 페이지를 닫고 관련 연결을 종료한 다음 요청을 다시 보내면 결과를 더 정확히 확인할 수 있습니다.

설정과 모드 확인: 현재 설정을 다시 불러왔는지, 규칙 모드가 유지되고 있는지 확인하세요. 불러오기에 실패했다면 로그에 표시된 YAML, 정책 그룹 또는 데이터베이스 오류부터 해결하세요.
로컬 네트워크 주소 테스트: 192.168.1.1처럼 실제로 사용 중인 라우터 관리 주소에 접속하세요. 요청이 클라이언트로 들어오면 사설 주소 규칙이나 예상한 직접 연결 규칙이 매칭되어야 합니다.
중국 본토 사이트 테스트: www.baidu.com에 접속한 뒤 연결 상세 정보에서 대상 도메인, 매칭된 규칙, 최종 아웃바운드를 확인하세요. 중국 본토 도메인 분류 또는 중국 본토 IP 규칙에 해당하는 DIRECT가 예상 결과입니다.
명시한 예외 테스트: github.com에 접속해 DOMAIN-SUFFIX 예외가 매칭되고 PROXY 그룹에서 선택한 프록시를 통해 연결되는지 확인하세요.
규칙과 연결 상태 구분: PROXY가 매칭됐는데 연결 시간이 초과된다면 선택된 프록시, DNS, 대상 서비스를 계속 점검하세요. 먼저 중국 본토 규칙을 전부 삭제하지 마세요.

웹페이지 하나가 메인 사이트, 이미지, 로그인 API, 통계 도메인에 동시에 요청을 보낼 수 있습니다. 메인 페이지가 직접 연결된다고 해서 페이지의 모든 연결이 직접 연결되는 것은 아닙니다. 실패한 요청의 도메인을 각각 확인하세요. 여기 제시된 주소는 검증 대상이며, 네트워크 지연 시간이나 성공률을 실측해 보장하는 내용은 아닙니다.

7. 자주 발생하는 규칙 충돌과 해결 방법

증상	우선 확인할 항목	해결 방법
모든 연결이 같은 프록시를 경유함	글로벌 모드인지, 앞부분에 MATCH 규칙이 있는지	규칙 모드로 전환하고 기본 대체 규칙을 맨 뒤로 이동
추가한 도메인 규칙이 매칭되지 않음	앞에 있는 접미사, 분류 또는 규칙 집합이 먼저 매칭되는지	명시적 예외를 더 포괄적인 규칙보다 앞에 배치
불러오는 중 정책을 찾을 수 없다는 오류가 표시됨	규칙 대상과 정책 그룹 이름이 일치하는지	기존 그룹 이름을 사용하고 대소문자와 공백을 확인
중국 본토 사이트가 MATCH로 넘어감	분류에 포함되어 있는지, 실제 대상 IP가 있는지	도메인 규칙을 보완하고 no-resolve 및 DNS 동작을 점검
구독 업데이트 후 사용자 지정 규칙이 사라짐	구독이 생성한 내용에 규칙을 직접 추가했는지	유지되는 오버라이드 기능을 사용하거나 별도의 로컬 설정 관리
연결 목록에 대상 요청이 표시되지 않음	앱이 시스템 프록시를 우회하는지, TUN 라우팅이 적용되는지	먼저 트래픽 유입 경로를 해결한 뒤 규칙 점검

구독 오버라이드는 “추가 성공” 표시만으로 판단하지 마세요

FlClash 버전에 따라 설정 편집 및 오버라이드 메뉴가 다를 수 있으므로 현재 버전에서 실제로 제공하는 기능을 기준으로 확인하세요. 핵심은 최종 적용된 규칙 목록을 확인하는 것입니다. 사용자 지정 규칙은 기본 대체 규칙인 MATCH보다 앞에 있어야 합니다. 규칙을 뒤에 추가하는 기능으로 새 규칙이 MATCH 뒤에 들어가면 파일에 표시되더라도 매칭될 수 없습니다.

구독에 이미 RULE-SET이 있더라도 위에서 아래로 매칭되는 순서는 동일합니다. 이 글의 예시를 사용하려고 모든 규칙 집합을 삭제하지 마세요. 먼저 기존 중국 본토 분류, 프록시 분류, 기본 대체 규칙을 확인한 뒤 중복 항목을 정리하세요. 복구 가능한 설정을 저장하고 구독을 업데이트한 다음 다시 확인하면 규칙이 덮어써진 사실을 놓치는 일을 줄일 수 있습니다.

한 번에 한 단계씩 수정

“도메인 예외 → GeoSite 분류 → GeoIP 보완 → MATCH 기본 대체” 순서로 단계별 검증을 권장합니다. 먼저 명확한 도메인 하나가 올바른 정책에 매칭되도록 한 뒤 적용 범위를 넓히세요. DNS 변경, TUN 전환, 규칙 전면 수정, 프록시 교체를 한꺼번에 진행하면 어떤 변경이 결과에 영향을 줬는지 파악하기 어렵습니다.

최종적으로 저장할 것은 규칙 텍스트만이 아닙니다. 현재 규칙 모드인지, 연결 상세 정보에 예상한 규칙이 표시되는지, 정책 그룹에서 실제 선택된 아웃바운드가 예상과 일치하는지까지 확인해야 합니다. 이 세 가지를 모두 확인해야 나중에 검증할 수 있는 중국 본토 직결·해외 프록시 설정이 완성됩니다.