Clash 국내외 트래픽 분할 설정: 규칙 순서와 프록시 그룹 실전 가이드

Routing model

국내외 트래픽 분할의 판단 모델부터 이해하기

Clash의 트래픽 분할은 단순히 “현재 웹사이트가 국내인지 해외인지”를 판단하는 방식이 아닙니다. 설정 파일의 규칙을 위에서부터 차례로 확인해 각 연결을 처리합니다. 규칙은 도메인, 도메인 접미사, IP 주소, 대상 포트, 프로세스 이름 또는 외부 규칙 세트를 기준으로 매칭할 수 있습니다. 규칙이 매칭되면 연결은 지정된 프록시 그룹, 프록시 노드 또는 내장 동작으로 전달됩니다. 일반적으로 DIRECT는 직접 연결, PROXY는 PROXY라는 이름의 프록시 그룹으로 처리, REJECT는 연결 거부를 뜻합니다.

따라서 “국내 트래픽은 직접 연결하고 나머지는 프록시로 보낸다”는 목표일 뿐, 모든 상황을 처리하는 단일 규칙은 아닙니다. 실제 설정에서는 먼저 LAN과 명확한 예외를 처리한 뒤 특정 도메인, 지역 도메인과 대상 IP를 판단하고, 마지막으로 앞선 규칙에 매칭되지 않은 연결을 기본 규칙으로 처리합니다. 해외 도메인을 사용하지만 로컬에 서버를 둔 사이트나, 국내 도메인을 사용하면서 해외 API에 의존하는 서비스는 지역 데이터베이스만으로 판단하면 예상과 다른 결과가 나올 수 있으므로 더 구체적인 도메인 규칙이 필요합니다.

또한 “규칙이 매칭된 프록시 정책”과 “최종으로 사용된 노드”를 구분해야 합니다. 예를 들어 규칙이 연결을 해외 트래픽 프록시 그룹으로 전달하더라도, 해당 그룹은 다시 자동 선택이나 홍콩 노드 같은 하위 그룹을 참조할 수 있습니다. 로그에 “해외 트래픽” 규칙이 매칭되었다고 해서 이것이 최종 출구라는 뜻은 아닙니다. 프록시 그룹의 현재 선택 항목과 연결 상세 정보의 경로를 함께 확인해야 합니다.

규칙 또는 동작	역할	배치하기 좋은 위치
`DOMAIN`	완전한 도메인 하나와 정확히 매칭	일반 도메인 규칙보다 앞
`DOMAIN-SUFFIX`	특정 도메인과 하위 도메인 매칭	지역 및 IP 규칙보다 앞
`RULE-SET`	규칙 제공자의 규칙 집합 참조	규칙 세부도 순서대로 배치
`GEOIP`	대상 IP의 소속 지역으로 매칭	도메인 규칙 다음
`MATCH`	앞선 규칙에 매칭되지 않은 연결 처리	규칙 목록의 마지막

Rule order

규칙은 위에서 아래로 매칭되므로 구체적인 규칙을 우선 배치해야 한다

mihomo는 연결을 처리할 때 rules의 상단부터 아래로 확인하며, 조건에 맞는 첫 번째 규칙이 해당 연결의 정책을 결정합니다. 이후 규칙은 더 이상 적용되지 않습니다. 규칙 내용은 올바르지만 위치가 잘못된 경우는 지역별 트래픽 분할에서 가장 흔한 설정 문제입니다. 예를 들어 범위가 매우 넓은 국내 도메인 규칙을 먼저 작성하고 그중 특정 도메인만 프록시로 보내도록 뒤에서 지정하면, 해당 예외 규칙은 절대 적용되지 않습니다.

안정적인 순서 구성은 “가장 구체적인 규칙”에서 “가장 포괄적인 규칙”으로 단계적으로 넓혀 가는 방식입니다. LAN, 루프백 주소와 가정용 기기 도메인은 일반적으로 직접 연결해야 원격 노드로 우회되지 않습니다. 반드시 프록시를 사용하거나 직접 연결해야 하는 업무 도메인은 수동 예외로 앞쪽에 둡니다. 광고나 추적 도메인을 거부할지는 페이지 기능을 고려해 신중하게 결정해야 합니다. 그 다음에 지역 도메인, 지역 IP 규칙을 묶어 배치하고 마지막에 기본 규칙을 둡니다. 구독마다 규칙 이름은 다를 수 있지만 정렬 원칙은 같습니다.

로컬 네트워크와 사설 주소: 라우터 관리 페이지, NAS, 프린터와 LAN 서비스는 일반적으로 DIRECT를 사용해 원격 노드로 우회되지 않도록 합니다.
수동 지정 예외: 반드시 프록시를 사용하거나 직접 연결해야 하는 도메인, 특정 출구가 필요한 완전한 도메인과 도메인 접미사를 일반 규칙보다 앞에 배치합니다.
업무 규칙 세트: 개발 플랫폼, 스트리밍 또는 메신저처럼 서비스 유형별로 관리되는 규칙 세트를 참조합니다.
국내 도메인과 IP: 도메인 기반 지역 규칙을 GEOIP보다 먼저 적용해, DNS로 확인된 IP에만 의존할 때 발생하는 오차를 줄입니다.
최종 기본 규칙: MATCH를 기본 프록시 그룹으로 연결해 분류되지 않은 연결에도 명확한 처리 방향을 지정합니다.

“확인된 국내 리소스는 직접 연결하고 나머지는 기본적으로 프록시를 사용한다”는 목표라면, 기본 규칙은 다시 지역 판단을 수행하지 말고 프록시 그룹을 가리켜야 합니다. 반대로 소수의 서비스만 프록시를 사용하게 하려면 해당 서비스를 먼저 나열한 뒤 마지막에 MATCH,DIRECT로 마무리합니다. 두 방식에 절대적인 우열은 없으며, 기본 동작과 유지 관리 비용이 다를 뿐입니다.

Proxy groups

프록시 그룹으로 규칙의 의도와 노드 선택을 분리하기

해외 규칙마다 특정 노드를 직접 연결하면 단순해 보이지만, 구독 업데이트로 노드 이름이 바뀌는 순간 많은 규칙이 작동하지 않게 됩니다. 유지 관리가 쉬운 방식은 규칙이 안정적인 프록시 그룹 이름을 가리키도록 하고, 프록시 그룹에서 노드, 자동 테스트 그룹 또는 다른 프록시 그룹을 관리하는 것입니다. 규칙은 “이 유형의 트래픽을 어떻게 처리할지”를 표현하고, 프록시 그룹은 “현재 어떤 출구로 처리할지”를 결정합니다.

실용적인 구성은 보통 전체 진입점, 지역 선택, 자동 테스트의 3단계로 구성합니다. 전체 진입점은 해외 트래픽처럼 이름을 정하고 유형은 select로 설정해 자동 그룹, 특정 지역 그룹 또는 DIRECT를 수동으로 선택할 수 있게 합니다. 지역 그룹은 구독의 해당 노드를 참조하거나 proxy-providers와 필터 조건을 사용해 노드를 동적으로 가져올 수 있습니다. 자동 그룹은 일반적으로 url-test로 후보 노드를 주기적으로 검사하고 응답 지연이 낮은 출구를 선택합니다.

url-test 결과는 해당 시점에 검사 주소가 응답한 상태만 보여 주며, 모든 웹사이트의 실제 속도를 의미하지는 않습니다. 지역 간 네트워크 경로, 대상 사이트의 제한과 노드 부하가 모두 사용 경험에 영향을 줍니다. 로그인 지역이 중요하거나 특정 지역 및 안정적인 출구가 필요한 서비스에는 자주 전환되는 자동 그룹보다 수동 지역 그룹이 더 제어하기 쉽습니다.

proxy-groups:
  - name: 해외 트래픽
    type: select
    proxies:
      - 자동 선택
      - 홍콩 노드
      - 일본 노드
      - DIRECT

  - name: 자동 선택
    type: url-test
    proxies:
      - HK-01
      - JP-01
      - SG-01
    url: https://www.gstatic.com/generate_204
    interval: 300

  - name: 국내 트래픽
    type: select
    proxies:
      - DIRECT
      - 해외 트래픽

위 예시의 노드 이름은 proxies에 실제로 존재하는 이름과 일치해야 합니다. 노드가 프록시 제공자에서 오는 경우 그룹 안에서는 존재하지 않는 노드 이름을 그대로 복사하지 말고 해당 use 설정을 사용해야 합니다. 설정의 참조 관계에는 엄격한 조건이 있습니다. 규칙이 참조하는 프록시 그룹과 프록시 그룹이 참조하는 노드 또는 하위 그룹은 모두 설정에 정의되어 있어야 합니다. Clash Verge Rev에서 구독을 가져온 뒤 생성되는 그룹 이름은 다를 수 있으므로, 수정하기 전에 현재 설정 구조를 먼저 확인해야 합니다.

YAML practice

예외 규칙부터 기본 규칙까지: 트래픽 분할 설정 실전

아래 규칙 조각은 일반적인 구성 방식을 보여 줍니다. 로컬 주소는 직접 연결하고, 지정한 개발 서비스는 프록시로 보내며, 명확한 국내 서비스는 직접 연결한 다음 지역 데이터로 일반적인 경우를 처리하고, 마지막으로 인식되지 않은 트래픽을 해외 프록시 그룹으로 전달합니다. 이는 구조 예시일 뿐 기존 구독 설정을 그대로 덮어쓰면 안 됩니다. 실제 설정에는 포트, DNS, 노드, 프록시 그룹과 규칙 제공자 정의가 추가로 필요할 수 있습니다.

rules:
  - DOMAIN,router.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,해외 트래픽
  - DOMAIN-SUFFIX,githubusercontent.com,해외 트래픽

  - DOMAIN-SUFFIX,gov.cn,DIRECT
  - DOMAIN-SUFFIX,example.cn,DIRECT

  - GEOSITE,CN,DIRECT
  - GEOIP,CN,DIRECT,no-resolve
  - MATCH,해외 트래픽

GEOSITE는 mihomo가 지원하는 지리 기반 사이트 규칙으로, 해당 지리 데이터 파일이 필요합니다. 설정마다 데이터 로드 방식과 규칙 세트가 다를 수 있습니다. 현재 설정에서 사용할 수 있는 GeoSite 데이터가 없다면 이미 정의된 RULE-SET을 사용하거나 필요한 도메인 규칙을 직접 관리해야 하며, 로드할 수 없는 데이터 참조 한 줄만 추가해서는 안 됩니다. GEOIP는 대상 IP를 기준으로 지역을 판단하므로 도메인 규칙이 포함하지 못한 연결을 보완하는 데 적합합니다.

no-resolve는 이 IP 규칙을 확인할 때 대상 IP를 얻기 위해 커널이 추가 도메인 조회를 능동적으로 수행하지 않도록 지정합니다. 일부 IP-CIDR 및 GEOIP 규칙의 끝에 사용할 수 있지만 클라이언트 전체의 DNS 기능을 비활성화한다는 뜻은 아닙니다. 연결 정보에 이미 대상 IP가 포함되어 있다면 규칙은 정상적으로 판단할 수 있습니다.

외부 규칙 제공자를 사용할 때는 규칙 본문과 업데이트 출처를 분리할 수 있습니다. 규칙 제공자에 동작 유형, 형식, 저장 경로와 업데이트 간격을 정의한 뒤 rules에서 RULE-SET으로 참조해야 합니다. 아래 예시는 논리적 관계를 보여 주며, 주소와 파일 이름은 실제로 관리되는 출처에서 제공하는 유효한 값으로 바꿔야 합니다.

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

rules:
  - RULE-SET,local-direct,DIRECT
  - GEOIP,CN,DIRECT,no-resolve
  - MATCH,해외 트래픽

규칙 세트의 behavior는 파일 내용과 일치해야 합니다. domain은 도메인 유형 페이로드에, ipcidr은 네트워크 대역 페이로드에 사용하며, classical은 규칙 유형이 포함된 클래식 규칙을 담을 수 있습니다. 형식이 맞지 않으면 규칙 제공자 업데이트가 실패하거나 페이로드를 해석하지 못할 수 있습니다. 원격 규칙 세트에는 안정적인 업데이트 출처도 필요합니다. 출처에 일시적으로 연결할 수 없을 때 클라이언트는 보통 저장된 로컬 파일을 계속 사용하지만, 최초 가져오기에 실패하면 사용할 캐시가 없을 수 있습니다.

DNS and TUN

DNS, 시스템 프록시와 TUN이 결과에 미치는 영향

규칙 자체가 연결 방향을 결정하지만, 클라이언트가 연결을 수신할 수 있는지, 도메인을 올바르게 복원할 수 있는지, DNS 조회가 어디로 향하는지는 최종 결과에 영향을 줍니다. 시스템 프록시는 운영체제의 프록시 설정을 따르는 앱만 대상으로 합니다. 일부 게임, 명령줄 도구, 가상 머신 프로그램 또는 자체 네트워크 스택을 구현한 소프트웨어는 시스템 프록시를 우회할 수 있습니다. 이 경우 규칙이 아무리 완전해도 mihomo에 들어오지 않은 트래픽은 연결 목록에 표시되지 않습니다.

TUN 모드는 가상 네트워크 인터페이스를 통해 더 넓은 범위의 TCP 및 UDP 트래픽을 인계받으므로 시스템 프록시 설정을 읽지 않는 프로그램까지 포함해야 할 때 적합합니다. TUN을 활성화해도 규칙을 위에서 아래로 매칭하는 원칙은 바뀌지 않고, 규칙 엔진에 들어올 수 있는 트래픽 범위만 넓어집니다. 또한 TUN은 시스템 권한, 라우팅 테이블, 다른 VPN 소프트웨어와 보안 도구의 영향을 받을 수 있으므로, 먼저 시스템 프록시 모드에서 기본 분할을 확인한 뒤 필요에 따라 활성화해야 합니다.

DNS 설정은 “규칙은 올바른데 결과가 일치하지 않는” 문제를 특히 자주 일으킵니다. fake-ip 모드에서는 클라이언트가 예약 주소를 먼저 반환하고 내부에 도메인과 연결의 매핑을 유지하므로, 이후 규칙이 도메인 기준으로 매칭될 수 있습니다. 일부 LAN 서비스, 기기 검색 또는 가상 주소와 호환되지 않는 프로그램은 fake-ip-filter에 추가해야 할 수 있습니다. redir-host 등의 모드에서는 조회 과정과 연결 수립 방식이 다르지만, DNS 조회가 다른 프로그램에 의해 완전히 우회되지 않도록 해야 한다는 점은 같습니다.

도메인이 시스템 외부에서 먼저 IP로 해석되면 커널이 받은 연결에 도메인 규칙에 필요한 정보가 없을 수 있으며, 결과적으로 IP 규칙이나 MATCH로만 처리될 수 있습니다. 따라서 도메인 규칙이 매칭되지 않을 때는 YAML 표기만 확인하지 말고 연결 상세 정보의 대상 호스트, 해석 결과와 매칭 규칙을 함께 살펴봐야 합니다.

Verification

설정 변경 후 실제 트래픽 경로 확인하기

트래픽 분할은 웹페이지가 열리는지만으로 검증할 수 없습니다. 직접 연결과 프록시 모두 접속에 성공할 수 있지만 지연 시간, 출구 위치와 매칭 규칙은 다릅니다. 신뢰할 수 있는 확인 방법은 설정 로드 상태, 연결 상세 정보, 매칭 규칙, 프록시 그룹 선택과 외부 출구 결과를 함께 확인하는 것입니다. 또한 한 번에 한 종류의 조건만 변경해야 합니다.

1단계: 설정이 정상적으로 로드되었는지 확인

YAML을 저장한 뒤 클라이언트 알림과 커널 로그를 확인해 들여쓰기, 필드 유형, 중복 이름 또는 규칙 제공자 해석 오류가 없는지 점검합니다. YAML은 공백으로 계층을 표현하므로 Tab 문자나 잘못된 들여쓰기로 로드에 실패할 수 있습니다. 클라이언트가 여전히 이전 설정을 사용한다면 이후 테스트 결과에 방금 변경한 내용이 반영되지 않습니다.

2단계: 기존 연결을 정리한 뒤 테스트

브라우저는 HTTP/2, HTTP/3와 장시간 연결을 재사용하며 앱도 연결 풀을 유지할 수 있습니다. 규칙을 변경해도 이미 수립된 연결은 새 규칙에 따라 출구를 자동으로 다시 선택하지 않는 경우가 많습니다. 대상 연결을 닫고 앱을 다시 열거나 클라이언트에서 해당 연결을 종료한 뒤 새로 접속해야 합니다. DNS 캐시도 비교 결과에 영향을 줄 수 있으므로 필요하면 캐시가 만료될 때까지 기다리거나 시스템 방식으로 새로고침합니다.

3단계: 연결 상세 정보와 매칭 경로 확인

Clash Verge Rev의 연결 페이지에서 대상 도메인을 찾아 매칭된 규칙 유형, 규칙 페이로드, 프록시 그룹과 최종 노드를 확인합니다. DOMAIN-SUFFIX가 매칭되어야 하는데 MATCH로 표시된다면 도메인이 해당 규칙에 전달되지 않았거나, 앞선 규칙에 먼저 가로채였거나, 연결에 IP 정보만 남아 있을 수 있습니다. 프록시 그룹은 올바르게 매칭되었지만 노드가 잘못되었다면 규칙을 수정하지 말고 프록시 그룹 페이지에서 현재 선택 항목을 확인해야 합니다.

4단계: 직접 연결과 프록시 출구를 각각 검증

직접 연결로 명확히 설정한 대상 하나와 프록시로 명확히 설정한 대상 하나를 선택해 비교합니다. 필요하면 신뢰할 수 있는 출구 주소 조회 서비스로 공인 출구를 확인할 수 있지만, 조회 서비스마다 사용하는 네트워크, 캐시와 IP 지역 데이터베이스가 다를 수 있다는 점에 유의해야 합니다. 지역 표시는 보조 증거일 뿐이며, 가장 중요한 정보는 클라이언트에 표시된 매칭 규칙과 연결 경로입니다.

직접 연결 대상에는 DIRECT가 표시되어야 하며, 먼저 특정 프록시 그룹에 매칭되더라도 해당 그룹의 현재 선택 항목이 DIRECT여야 합니다.
프록시 대상에는 예상한 프록시 그룹이 표시되고 연결 경로를 따라 실제 노드까지 이어져야 합니다.
거부 규칙은 연결이 차단된 것으로 표시되어야 하며, 동시에 페이지에 필요한 API나 정적 리소스가 차단되지 않았는지도 확인해야 합니다.
UDP, QUIC와 TCP는 서로 다른 연결을 만들 수 있으므로 문제를 진단할 때 프로토콜 유형을 확인해야 합니다.

Troubleshooting

트래픽 분할 결과가 이상할 때의 점검 순서

국내 웹사이트도 프록시를 통해 연결되는 경우

먼저 국내 규칙보다 앞에 넓은 범위의 프록시 규칙이 있는지 확인합니다. 예를 들어 최상위 도메인 전체나 대형 규칙 세트 하나를 포괄하는 규칙이 해당될 수 있습니다. 이후 국내 프록시 그룹의 현재 선택 항목이 실제로 DIRECT인지 확인합니다. 설정이 GEOIP,CN,DIRECT만 사용하고 대상이 해외 CDN 주소를 이용한다면 매칭되지 않을 수 있으므로, 안정적인 서비스에는 명확한 도메인 직접 연결 규칙을 추가할 수 있습니다.

해외 서비스가 간헐적으로 직접 연결되는 경우

대상 서비스에 여러 업무 도메인이 포함되어 있는지 확인합니다. 최신 웹사이트는 로그인, API, 이미지, 동영상과 통계용 도메인에 동시에 접속하는 경우가 많으므로 기본 도메인 하나에만 프록시를 설정하면 모든 요청을 처리할 수 없습니다. 연결 목록에서 실제 도메인을 수집한 뒤 필요한 도메인 접미사를 추가하거나 잘 관리되는 서비스 규칙 세트를 사용합니다. 관찰된 임시 CDN 호스트를 하나씩 정확한 규칙으로 등록하기보다 안정적인 도메인 경계를 먼저 파악해야 합니다.

규칙은 올바르게 표시되지만 서비스를 사용할 수 없는 경우

프록시 규칙이 매칭되었다는 것은 연결이 해당 정책으로 전달되었다는 뜻일 뿐, 노드에 반드시 연결할 수 있다는 의미는 아닙니다. 프록시 그룹에서 유효한 노드를 선택했는지, 노드가 필요한 UDP 트래픽을 지원하는지, DNS가 정상인지, 대상 서비스가 출구 지역을 제한하는지와 시스템 시간이 정확한지를 차례로 확인합니다. 같은 그룹의 다른 노드로 일시적으로 바꿔 비교하면 규칙 문제와 노드 경로 문제를 구분하는 데 도움이 됩니다.

TUN 활성화 후 LAN 기기에 연결할 수 없는 경우

사설 네트워크 대역 규칙이 앞쪽에 있고 DIRECT를 가리키는지 확인합니다. 동시에 TUN의 자동 라우팅, 엄격한 라우팅 설정과 시스템의 다른 가상 네트워크 어댑터도 점검합니다. 호스트 이름으로 LAN 기기에 접속한다면 로컬 도메인 조회나 검색 도메인이 원격 DNS로 대체되지 않았는지도 확인해야 합니다. 먼저 기기 IP로 테스트하면 라우팅 문제와 로컬 도메인 조회 문제를 구분하는 데 도움이 됩니다.

구독 업데이트 후 사용자 지정 규칙이 사라지는 경우

구독으로 생성된 설정을 직접 편집하면 다음 구독 업데이트 때 새 내용으로 덮어써질 수 있습니다. Clash Verge Rev는 설정 병합, 스크립트 또는 오버라이드 기능을 통해 로컬 변경 사항을 보존할 수 있지만, 구체적인 메뉴는 현재 버전과 설정 관리 방식에 따라 다릅니다. 적용하기 전에 작동하는 설정을 백업하고, 사용자 지정 프록시 그룹과 규칙은 독립적이고 확인하기 쉬운 조각으로 유지해야 합니다. 구독 업데이트 후에는 참조하는 이름이 여전히 존재하는지도 확인합니다.

Checklist

지속적으로 관리할 수 있는 트래픽 분할 체크리스트

안정적인 국내외 트래픽 분할은 규칙을 끝없이 쌓기보다 명확한 기본 정책과 꼭 필요한 소수의 예외에 달려 있습니다. 설정을 완료한 뒤에는 다음 체크리스트로 다시 확인할 수 있습니다.

LAN과 사설 주소 규칙이 앞쪽에 있으며 DIRECT를 명확히 사용한다.
반드시 프록시를 사용하거나 직접 연결해야 하는 업무 도메인이 지역 일반 규칙보다 앞에 있다.
규칙이 참조하는 프록시 그룹 이름이 설정에 정의된 이름과 완전히 일치한다.
프록시 그룹이 참조하는 노드, 하위 그룹 또는 프록시 제공자가 실제로 존재한다.
지역 도메인 규칙이 지역 IP 규칙보다 먼저 오고 MATCH가 마지막에 있다.
외부 규칙 세트의 동작 유형, 파일 형식과 페이로드 내용이 서로 일치한다.
변경 후 기존 연결을 종료하고 연결 페이지에서 규칙, 프록시 그룹과 최종 노드를 확인한다.
시스템 프록시가 대상 프로그램을 처리하지 못할 때 TUN 모드가 필요한지 검토한다.
구독 업데이트 후 사용자 지정 오버라이드를 다시 확인해 이름 변경으로 프록시 그룹 참조가 끊기지 않도록 한다.

설정의 핵심은 규칙 수를 늘리는 것이 아니라 모든 연결이 설명 가능한 경로를 따라 명확한 정책에 도달하게 만드는 것입니다. 먼저 “로컬 직접 연결, 지정 예외, 지역 판단, 최종 기본 규칙”이라는 뼈대를 소수의 규칙으로 만들고, 연결 기록에 따라 실제 요구 사항을 보완하는 편이 겹치는 규칙 세트를 여러 개 바로 가져오는 것보다 유지 관리와 문제 해결이 쉽습니다.