Clash 국내외 규칙 기반 라우팅 설정: 정책 그룹·규칙 제공자·최종 폴백 실전 가이드

Clash의 규칙 기반 라우팅은 단순히 “중국 국내 도메인은 직접 연결하고 해외 도메인은 프록시로 보낸다”는 방식이 아닙니다. 실제 연결 경로를 결정하는 구조는 세 가지입니다. 규칙은 트래픽을 식별하고, 정책 그룹은 출구를 선택하며, 프록시 노드 또는 내장 동작이 이를 실행합니다. 어느 한 계층의 이름·순서·참조 관계라도 일치하지 않으면 웹사이트가 잘못된 경로로 연결되거나, 로컬 네트워크 서비스가 프록시를 거치거나, 앱 연결이 시간 초과되거나, 노드를 바꾼 뒤에도 일부 연결이 이전 경로를 계속 사용하는 문제가 나타날 수 있습니다.

다음 설정 방식은 규칙 모드를 지원하는 Clash 클라이언트에 적용할 수 있으며, Clash Meta라는 이름으로 배포되다가 현재는 일반적으로 mihomo라고 불리는 코어에도 사용할 수 있습니다. 클라이언트마다 GUI 명칭이 다를 수 있고, 코어 버전에 따라 규칙 유형·규칙 제공자 형식·프로세스 매칭 기능도 달라집니다. 수정하기 전에 실제 사용 중인 코어를 확인하고, 정상적으로 시작되는 설정을 별도로 보관하세요.

직접 연결·프록시·차단·폴백 모델부터 정하기

관리하기 쉬운 중국 국내외 라우팅 설정이라면 최소한 네 가지 처리 결과를 구분해야 합니다. 첫째는 DIRECT로, 연결을 로컬 네트워크에 직접 맡깁니다. 둘째는 PROXY 같은 사용자 정의 프록시 정책 그룹입니다. 셋째는 REJECT로, 접근할 필요가 없는 도메인이나 네트워크 대역을 차단합니다. 넷째는 최종 폴백 정책으로, 앞선 모든 규칙에 매칭되지 않은 트래픽을 처리합니다.

DIRECT가 곧 “중국 국내”를 뜻하는 것은 아닙니다. 로컬 네트워크 주소·프린터·라우터 관리 페이지·사내 시스템은 대개 직접 연결이 필요하지만, 일부 중국 국내 서비스는 계정 지역·사무실 출구·테스트 목적에 따라 프록시를 사용해야 할 수 있습니다. 반대로 해외 사이트도 현재 네트워크에서 직접 접속될 수 있습니다. 따라서 지역 규칙은 넓은 범위의 기본 판단에 사용하고, 업무별 예외는 지역 규칙보다 앞에 배치해야 합니다.

DIRECT

직접 연결 출구

현재 시스템 네트워크를 통해 직접 연결하며, 로컬 네트워크·중국 국내에서 자주 쓰는 서비스·로컬 출구가 필요한 업무에 적합합니다.

PROXY

프록시 정책 그룹

선택한 노드 또는 자동 선택 그룹으로 연결을 전달합니다. 정책 그룹 이름은 규칙에 지정한 대상 이름과 완전히 일치해야 합니다.

REJECT

차단 동작

매칭된 연결을 즉시 거부합니다. 로그인·결제·리소스 로딩에 영향을 주지 않도록 범위가 명확한 규칙을 사용하세요.

MATCH

미매칭 폴백

앞선 규칙에 매칭되지 않은 연결을 처리합니다. 반드시 규칙 목록 마지막에 배치해야 하며, 그렇지 않으면 뒤의 규칙이 매칭 기회를 얻지 못합니다.

정책 그룹으로 노드 선택과 업무 의도 분리하기

규칙에 특정 노드 이름을 직접 입력해도 동작하지만 유지 관리 비용이 높습니다. 구독이 갱신되면 노드 이름이 바뀔 수 있고, 여러 규칙이 동일한 특정 노드에 중복으로 연결되기도 합니다. 더 안정적인 방법은 규칙이 의미가 분명한 정책 그룹을 참조하도록 하고, 정책 그룹에서 노드·자동 속도 측정 그룹·다른 정책 그룹을 선택하는 것입니다.

일반적인 구조에는 전체 진입점인 PROXY, 자동 속도 측정 그룹인 AUTO, 수동 선택 그룹, 그리고 미디어·업무·개발 서비스별 그룹이 포함됩니다. 업무 규칙은 업무용 정책 그룹만 가리키고, 노드 변경은 그룹 내부에서 처리합니다. 이렇게 하면 규칙 파일의 안정성을 유지하면서도 클라이언트 화면에서 출구를 임시로 바꿀 수 있습니다.

mode: rule

proxy-groups:
  - name: PROXY
    type: select
    proxies:
      - AUTO
      - MANUAL
      - DIRECT

  - name: AUTO
    type: url-test
    use:
      - airport
    url: https://www.gstatic.com/generate_204
    interval: 300
    tolerance: 80

  - name: MANUAL
    type: select
    use:
      - airport

위 예시의 airport는 반드시 proxy-providers에 정의되어 있어야 합니다. use가 참조하는 것은 프록시 제공자이지 규칙 제공자가 아닙니다. url-test는 테스트 결과에 따라 조건에 맞는 노드를 선택하지만, 지연 시간이 가장 낮다고 해서 모든 업무의 처리량이 가장 높은 것은 아닙니다. 대상 서비스가 출구 지역을 요구한다면 지역별 그룹이나 수동 선택 그룹을 만들고, 전체 속도 측정 결과에만 의존하지 마세요.

PROXY에서 DIRECT를 선택할 수 있게 하면 임시 진단에 편리하지만, 사용자가 이 그룹을 전환할 때 해당 그룹을 참조하는 모든 규칙의 출구가 바뀐다는 뜻이기도 합니다. 반드시 고정 프록시를 사용해야 하는 업무에는 DIRECT가 포함되지 않은 별도 정책 그룹을 만드세요. 반드시 직접 연결해야 하는 트래픽은 규칙이 바로 DIRECT를 가리키도록 하여 전체 정책 그룹 전환의 영향을 피합니다.

정책 그룹 이름은 한 가지 표기로 통일하기

YAML의 이름은 문자 내용을 구분합니다. 규칙에는 PROXY라고 쓰고 정책 그룹 이름은 Proxy로 지정하면 같은 대상으로 인식되지 않습니다. 한글 이름·공백·기호도 대체로 사용할 수 있지만, 클라이언트 간에 설정을 옮길 때는 짧은 영문 대문자 이름이 확인하기 편합니다. 이름에 특수 문자가 포함되면 따옴표로 감싸고, 규칙·정책 그룹·스크립트 참조에서 동일하게 유지하세요.

규칙 제공자 구독과 정책 그룹 연동 방식

rule-providers는 재사용할 규칙 세트를 선언하는 데 사용합니다. 노드 구독과는 역할이 다릅니다. 노드 구독은 프록시 서버 정보를 제공하고, 규칙 세트는 도메인·IP 대역·클래식 규칙 항목을 제공합니다. 규칙 세트 자체는 출구를 결정하지 않습니다. rules에서 RULE-SET으로 참조하고 DIRECT·PROXY 또는 다른 정책을 지정해야 연결 결정에 참여합니다.

rule-providers:
  reject-list:
    type: http
    behavior: domain
    format: yaml
    path: ./ruleset/reject.yaml
    url: https://example.com/rules/reject.yaml
    interval: 86400

  cn-domain:
    type: http
    behavior: domain
    format: yaml
    path: ./ruleset/cn-domain.yaml
    url: https://example.com/rules/cn-domain.yaml
    interval: 86400

  cn-ip:
    type: http
    behavior: ipcidr
    format: yaml
    path: ./ruleset/cn-ip.yaml
    url: https://example.com/rules/cn-ip.yaml
    interval: 86400

예시 주소는 필드 구조를 보여주기 위한 용도일 뿐이며, 실제 설정에서는 규칙 관리자가 제공하는 원본 파일 주소를 사용해야 합니다. path는 규칙 세트의 로컬 캐시 위치이므로 클라이언트가 해당 디렉터리에 쓸 수 있어야 합니다. interval은 보통 초 단위이며, 하루로 설정하면 잦은 요청을 줄일 수 있습니다. 규칙 업데이트 주기는 상위 제공자의 관리 주기에 맞추세요. 간격을 지나치게 짧게 설정해도 매칭 정확도가 높아지지는 않습니다.

behavior는 규칙 세트 항목을 해석하는 방식을 결정합니다. domain은 도메인 및 도메인 접미사 목록에 적합하고, ipcidr은 IPv4·IPv6 네트워크 대역에 적합하며, classical은 유형이 포함된 클래식 규칙을 담을 수 있습니다. 파일 내용은 선언한 동작 및 형식과 일치해야 합니다. 도메인 목록을 ipcidr로 선언하거나 클래식 규칙 파일을 순수 도메인 목록으로 읽으면 대개 파싱 오류가 발생하거나 규칙이 매칭되지 않습니다.

규칙 순서: 구체적인 예외에서 범위형 폴백까지

Clash는 목록을 위에서 아래로 확인하며, 처음 매칭된 규칙이 즉시 처리 정책을 결정합니다. 모든 규칙을 비교한 뒤 “가장 정확한” 규칙을 고르는 방식이 아닙니다. 따라서 순서는 “구체적인 예외를 앞에, 포괄적인 집합을 뒤에, 최종 폴백은 마지막에”라는 원칙을 따라야 합니다.

권장하는 기본 순서는 명확한 차단 항목, 로컬 네트워크 및 사설 주소, 반드시 직접 연결할 업무, 반드시 프록시를 사용할 업무, 중국 국내 도메인 집합, 중국 국내 IP 집합, 기타 지역 또는 프록시 집합, 마지막으로 MATCH입니다. 프로젝트에 따라 분류를 조정할 수 있지만, 넓은 범위의 규칙을 해당 규칙이 포함하는 예외보다 앞에 배치해서는 안 됩니다.

rules:
  - RULE-SET,reject-list,REJECT
  - DOMAIN-SUFFIX,internal.example,DIRECT
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - IP-CIDR,10.0.0.0/8,DIRECT,no-resolve

  - DOMAIN-SUFFIX,service-needs-proxy.example,PROXY
  - DOMAIN-SUFFIX,service-needs-direct.example,DIRECT

  - RULE-SET,cn-domain,DIRECT
  - RULE-SET,proxy-domain,PROXY
  - RULE-SET,cn-ip,DIRECT,no-resolve
  - GEOIP,CN,DIRECT,no-resolve

  - MATCH,PROXY

위 예시의 업무 도메인도 순서를 설명하기 위한 것이므로, 배포할 때는 실제로 제어할 도메인으로 바꿔야 합니다. 반드시 프록시를 사용해야 하는 도메인이 중국 국내 도메인 규칙 세트에도 포함되어 있다면 cn-domain보다 앞에 배치해야 합니다. 그렇지 않으면 먼저 직접 연결로 매칭됩니다. 차단 규칙의 범위가 지나치게 넓으면 로그인 API·정적 리소스·인증 코드 도메인이 먼저 거부될 수 있으며, 뒤에 프록시 규칙이 있어도 계속 판단하지 않습니다.

DOMAIN은 완전한 도메인과 매칭되고, DOMAIN-SUFFIX는 지정한 도메인과 하위 도메인에 매칭되며, DOMAIN-KEYWORD는 도메인에 키워드가 포함되어 있는지만 확인합니다. 키워드 규칙은 적용 범위가 넓어 이름만 비슷하고 업무상 무관한 사이트까지 잘못 매칭할 수 있으므로, 보통은 완전한 도메인·접미사 또는 관리되는 규칙 세트를 우선 사용해야 합니다.

IP-CIDR과 GEOIP는 IP 기준으로 판단합니다. no-resolve를 추가하면 규칙 매칭을 위해 대상 IP를 얻으려고 추가 DNS 조회를 발생시키는 일을 피할 수 있지만, 코어가 이미 대상 IP를 확보한 경우에만 해당 규칙이 매칭됩니다. 이 옵션을 넣을지는 DNS 모드·연결 메타데이터·코어 동작을 함께 검증해 결정해야 하며, 모든 규칙에 기계적으로 복사해서는 안 됩니다.

MATCH는 직접 연결과 프록시 중 무엇을 사용해야 할까

폴백 경로는 설정 목표에 따라 달라집니다. “중국 국내는 직접 연결하고 나머지는 프록시로 보낸다”는 일반적인 모델이라면 MATCH,PROXY를 사용할 수 있습니다. 그러면 새로 등장해 아직 규칙 세트에 포함되지 않은 도메인이 먼저 프록시 정책으로 들어갑니다. 기본은 직접 연결하고 일부 업무만 프록시를 사용해야 하는 환경이라면 MATCH,DIRECT를 쓸 수 있지만, 프록시가 필요한 규칙을 빠짐없이 포함해야 합니다. 두 방식에 보편적인 우열은 없으며, 알 수 없는 트래픽이 발생했을 때 어떤 출구가 더 통제 가능한 위험을 제공하는지가 핵심입니다.

DNS 및 TUN 모드가 라우팅 결과에 미치는 영향

규칙 순서가 올바른데도 접속 결과가 이상하다면 DNS를 확인해야 합니다. 도메인 요청·DNS 응답·실제 연결이 서로 다른 경로를 거칠 수 있습니다. 시스템 DNS가 네트워크 환경의 영향을 받은 주소를 반환하면 도메인 규칙이 예상한 정책에 매칭되어도 이후 연결이 시간 초과될 수 있습니다. Clash 내장 DNS를 사용할 때는 nameserver·proxy-server-nameserver·폴백 DNS와 규칙 기반 라우팅의 관계를 확인하고, 코어 로그에서 실제 조회가 어느 서버로 전달되었는지 살펴보세요.

fake-ip 모드에서는 코어가 앱에 예약 주소를 반환하고, 연결 단계에서 매핑을 통해 대상 도메인을 복원합니다. 따라서 도메인 규칙이 안정적으로 판단에 참여하는 데 유리하지만, 일부 로컬 네트워크 장치·로컬 네트워크 도메인·게임 플랫폼·실제 IP에 의존하는 앱은 fake-ip-filter에 추가해야 할 수 있습니다. 필터 항목을 무제한으로 늘려서는 안 됩니다. 범위가 너무 넓으면 더 많은 요청이 실제 IP 조회로 되돌아가 도메인 라우팅의 일관성도 떨어집니다.

redir-host 모드는 실제 DNS 응답 주소를 앱에 직접 반환하며, fake-ip와 호환 경로가 다릅니다. 모드를 전환한 뒤에도 이전 DNS 캐시와 기존 연결이 남아 있을 수 있으므로 테스트 전에 관련 앱의 연결을 끊고 운영체제에 맞게 DNS 캐시를 삭제해야 합니다. 브라우저 페이지만 새로 고쳐서는 전체 연결 경로가 다시 만들어지지 않을 수 있습니다.

TUN 모드는 더 많은 시스템 트래픽을 가로채지만, 규칙이 위에서 아래로 매칭되는 기본 로직 자체를 바꾸지는 않습니다. TUN을 활성화하면 원래 시스템 프록시를 우회하던 앱도 Clash로 들어올 수 있어 규칙 매칭 횟수가 늘어납니다. 앱이 대상 IP만 제공하면 도메인 규칙에 사용할 메타데이터가 부족할 수 있습니다. 스니핑을 지원하는 코어는 일부 HTTP 또는 TLS 트래픽에서 호스트 정보를 복원할 수 있지만, 모든 프로토콜에서 유효한 것은 아닙니다.

“브라우저 라우팅은 정상인데 명령줄이나 데스크톱 앱이 잘못된 경로를 사용한다면” 해당 프로그램이 코어에 들어왔는지, TUN 라우팅이 적용되었는지, 도메인이 식별되었는지, 최종적으로 어떤 규칙에 매칭되었는지를 차례로 확인해야 합니다. 웹페이지에 표시되는 출구 주소만으로 시스템 전체를 판단하지 마세요. 프로세스마다 시스템 프록시·직접 연결 소켓·QUIC·독립 DNS를 사용할 수 있습니다.

접속 결과를 추측하지 말고 연결 로그로 검증하기

라우팅 설정을 완료한 뒤 가장 효과적인 검증 방법은 클라이언트 연결 패널이나 코어 로그를 확인하는 것입니다. 테스트할 때마다 대상 호스트·매칭된 규칙·선택된 정책 그룹·실제 노드·연결 결과를 기록하세요. “열린다”는 사실만으로 규칙이 올바르다고 볼 수는 없습니다. 대상이 직접 연결을 지원할 수도 있고, 캐시·대체 도메인·이미 수립된 장기 연결을 사용했을 수도 있습니다.

설정이 로드되었는지 확인합니다. 설정 업데이트 시간과 코어 로그를 확인하여 YAML 들여쓰기·필드 오타·규칙 세트 다운로드·정책 그룹 참조 오류를 배제하세요.
테스트 정책을 고정합니다. 자동 속도 측정 그룹이 테스트 중 출구를 바꾸지 않도록 PROXY에 상태가 명확한 노드를 임시로 선택하세요.
로컬 네트워크와 사설 주소를 테스트합니다. 라우터 관리 페이지·로컬 네트워크 장치·내부 도메인이 DIRECT에 매칭되는지 확인하고, TUN이 예약 네트워크 대역을 잘못 가로채는지도 점검하세요.
중국 국내 도메인과 IP를 테스트합니다. 도메인 규칙 세트·IP 규칙 세트·GEOIP 중 무엇에 매칭되는지 확인하세요. 바로 MATCH로 떨어진다면 규칙 세트 내용이나 도메인 식별 경로를 점검해야 합니다.
강제 프록시 예외를 테스트합니다. 해당 규칙이 중국 국내 대규모 집합보다 앞에 있고 지정한 정책 그룹에 실제로 매칭되는지 확인하세요. 앞선 접미사 규칙에 먼저 가로채여서는 안 됩니다.
알 수 없는 도메인을 테스트합니다. 사용자 정의 규칙에 없는 대상을 선택하여 최종적으로 MATCH가 받는지 확인하고 폴백 정책을 검증하세요.

자주 발생하는 현상과 확인할 항목

현상	우선 확인할 항목	처리 방향
중국 국내 사이트가 프록시로 연결됨	중국 국내 규칙 세트가 로드되었는지, MATCH 앞에 배치되었는지 확인	provider 상태·규칙 참조 이름·도메인의 실제 매칭 항목을 확인
특정 도메인에 강제 프록시를 적용할 수 없음	앞에 더 넓은 직접 연결 접미사 규칙이 있는지 확인	구체적인 프록시 예외를 포괄적인 직접 연결 집합보다 앞에 배치
로컬 네트워크 주소 연결 시간 초과	사설 네트워크 대역 규칙과 TUN 라우팅	사설 주소 직접 연결 규칙을 추가하고 자동 라우팅 및 인터페이스 선택을 확인
규칙 세트 업데이트 실패로 표시됨	URL 응답·형식·behavior·캐시 디렉터리	반환된 내용이 규칙 파일인지 확인하고 코어 지원 여부와 디렉터리 권한을 점검
정책 전환 후에도 결과가 바뀌지 않음	기존 연결·DNS 캐시·앱 연결 풀	기존 연결을 종료한 뒤 다시 테스트하고, 필요하면 시스템 DNS 캐시를 삭제

장기간 설정을 유지할 때는 사용자 정의 예외·공용 규칙 세트·폴백 규칙을 분리해 관리하는 것이 좋습니다. 사용자 정의 예외는 대개 수가 적으므로 용도를 설명하는 주석과 함께 주 설정에 넣고, 공용 도메인 및 IP 집합은 규칙 제공자가 업데이트하도록 맡기며, 폴백 정책은 고정해 두세요. 문제가 발생했을 때 로컬 예외·원격 집합·출구 정책 중 무엇이 바뀌었는지 빠르게 판단할 수 있습니다.

변경할 때마다 한 계층만 조정하세요. 먼저 정책 그룹이 연결되는지 확인하고, 다음으로 규칙 세트가 로드되는지 검증한 뒤, 마지막으로 규칙 순서를 조정합니다. DNS·TUN·규칙 제공자·정책 그룹을 한 번에 수정하면 로그에 여러 변수가 섞여 실제 원인을 찾기 어려워집니다. 설정 필드와 클라이언트 사용법을 더 확인하려면 고급 설정 문서와 사용 문서를 함께 참고해 항목별로 점검하세요.