Clash 국내·해외 트래픽 분리 설정: 국내 사이트는 직접 연결, 해외 서비스는 프록시로

트래픽 분리의 전제: 규칙, 프록시 그룹, 트래픽 가로채기

국내·해외 트래픽 분리는 웹페이지 언어로 연결 경로를 판단하지 않습니다. Clash 코어는 연결 정보를 읽어 위에서부터 규칙을 확인한 뒤 해당 연결을 지정된 프록시 그룹으로 전달합니다. 도메인, 대상 IP, 프로세스 정보를 제대로 식별할 수 있는지가 최종 결과에 영향을 줍니다. 국내 사이트가 해외 API를 호출하거나 해외 사이트가 국내 CDN을 사용할 수도 있으므로, 주소창만 보지 말고 실제 연결을 기준으로 확인해야 합니다.

이 설정은 mihomo 코어를 사용하는 클라이언트를 대상으로 합니다. 구버전 Clash 코어와 일부 모바일 클라이언트는 지원하는 필드가 다를 수 있으니 가져오기 전에 클라이언트의 코어 안내를 확인하세요. 예제에서는 로컬 규칙 파일을 사용해 원격 규칙 다운로드 오류와 트래픽 분리 오류를 구분합니다.

트래픽 가로채기: 시스템 프록시는 프록시 설정을 따르는 앱의 트래픽만 처리합니다. TUN은 처리 범위를 넓힐 수 있지만 라우팅 및 제외 설정의 영향을 받습니다.
규칙 모드: 설정에서 mode: rule을 사용해야 rules 목록에 따라 트래픽을 분리합니다. 전역 모드에서는 이 글의 규칙 순서를 검증할 수 없습니다.
프록시 그룹: 연결을 내보낼 경로를 선택합니다. 도메인이 특정 그룹에 매칭되어도 해당 그룹이 반드시 프록시 노드를 사용한다는 뜻은 아닙니다.
규칙 세트: 재사용할 매칭 조건을 저장합니다. 규칙 세트 자체는 연결 경로를 결정하지 않습니다. 경로는 이를 참조하는 RULE-SET 규칙에서 지정합니다.

전체 기본 설정: 연결 경로부터 명확하게 지정하기

예제 환경 및 파일 위치

예제에서는 인증이 필요 없는 SOCKS5 업스트림이 로컬 127.0.0.1:1080에서 대기 중이라고 가정합니다. mihomo는 127.0.0.1:7890에서 대기합니다. 두 포트를 서로 연결하면 프록시 루프가 발생하므로 주의하세요. 설정 파일만 있고 사용할 수 있는 업스트림이 없다면 해외 프록시 연결은 불가능합니다.

코어 작업 디렉터리에 config.yaml을 저장하고 rules 디렉터리를 만드세요. 아래에서 다루는 규칙 파일 세 개도 생성해야 합니다. 데스크톱 클라이언트는 별도의 코어 작업 디렉터리를 관리할 수 있습니다. 상대 경로는 구독 파일 위치가 아니라 해당 작업 디렉터리를 기준으로 합니다.

mixed-port: 7890
allow-lan: false
bind-address: 127.0.0.1
mode: rule
log-level: info
ipv6: false

proxies:
  - name: 로컬 업스트림
    type: socks5
    server: 127.0.0.1
    port: 1080
    udp: false

proxy-groups:
  - name: 해외 프록시
    type: select
    proxies:
      - 로컬 업스트림
  - name: 국내 직결
    type: select
    proxies:
      - DIRECT
  - name: 광고 차단
    type: select
    proxies:
      - REJECT
      - DIRECT

rule-providers:
  ad-domains:
    type: file
    behavior: domain
    format: yaml
    path: ./rules/ad-domains.yaml
  cn-domains:
    type: file
    behavior: domain
    format: yaml
    path: ./rules/cn-domains.yaml
  overseas-services:
    type: file
    behavior: classical
    format: yaml
    path: ./rules/overseas-services.yaml

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,local,DIRECT
  - RULE-SET,ad-domains,광고 차단
  - DOMAIN,cloud.tencent.com,국내 직결
  - RULE-SET,cn-domains,국내 직결
  - RULE-SET,overseas-services,해외 프록시
  - MATCH,해외 프록시

이미 구독 노드가 있다면 “해외 프록시”가 구독에서 제공하는 노드나 프록시 그룹을 참조하도록 설정하고, 예제의 “로컬 업스트림”을 바꾸면 됩니다. 사용 중인 구독 설정에 proxies 섹션 전체를 그대로 덮어쓰지 마세요. 일부 클라이언트는 구독을 새로고침할 때 설정을 다시 작성합니다. 장기간 설정을 유지하려면 클라이언트에서 지원하는 오버라이드 또는 병합 기능을 사용하세요. 메뉴 이름은 클라이언트 버전에 따라 다를 수 있습니다.

예제에서 IPv6을 끈 것은 처음 문제를 확인할 때 범위를 좁히기 위한 것이며, IPv6을 트래픽 분리에 사용할 수 없다는 뜻은 아닙니다. 예제 업스트림은 UDP 포워딩도 지원하지 않습니다. 브라우저의 TCP 요청으로 기본 동작을 확인하고, 게임·음성 통화·QUIC은 업스트림 프로토콜과 트래픽 처리 방식을 따로 확인하세요.

규칙 파일 작성법: domain과 classical

광고 도메인 파일

아래 내용을 rules/ad-domains.yaml로 저장하세요. behavior: domain은 도메인 목록 형식을 사용하므로 프록시 그룹 이름이나 DOMAIN-SUFFIX, 접두사를 적지 않습니다. +.는 도메인 자체와 하위 도메인을 모두 포함합니다.

payload:
  - '+.doubleclick.net'
  - '+.googlesyndication.com'

광고 규칙은 쉽게 되돌릴 수 있도록 설정하세요. 일부 사이트는 통계·로그인·재생 API를 관련 도메인에서 제공하므로 차단 범위를 넓히면 페이지 일부가 표시되지 않을 수 있습니다. 오차단이 확인되면 먼저 “광고 차단”을 DIRECT로 바꿔 확인한 다음 해당 도메인에 예외를 추가하세요. 처음부터 모든 트래픽 분리 규칙을 삭제하지 마세요.

국내 직결 도메인 파일

아래 내용을 rules/cn-domains.yaml로 저장하세요. 이 목록은 지정한 도메인 범위만 다루며 모든 국내 사이트를 자동으로 식별하지 않습니다. 도메인을 추가할 때는 연결 패널에서 실제 요청을 확인하세요. 주소창의 도메인이 페이지의 모든 리소스 출처와 일치하는 것은 아닙니다.

payload:
  - '+.baidu.com'
  - '+.bilibili.com'
  - '+.bilibili.tv'
  - '+.qq.com'
  - '+.tencent.com'
  - '+.jd.com'
  - '+.taobao.com'

도메인 분류는 연결 경로에 대한 선호를 나타낼 뿐, 서버의 물리적 위치를 증명하지는 않습니다. 같은 브랜드의 서비스라도 서로 다른 지역에 배포될 수 있습니다. 특정 해외 서비스를 프록시로 연결하려면 해당 서비스의 더 구체적인 도메인 규칙을 먼저 추가한 뒤 브랜드 도메인 전체를 포괄하는 직결 규칙을 배치하세요.

해외 서비스 파일

아래 내용을 rules/overseas-services.yaml로 저장하세요. behavior: classical은 규칙 유형이 포함된 항목을 저장할 수 있지만, 항목 끝에 프록시 그룹 이름을 적지는 않습니다. 이를 참조하는 기본 설정에서 이미 “해외 프록시”를 지정했습니다.

payload:
  - DOMAIN-SUFFIX,github.com
  - DOMAIN-SUFFIX,githubusercontent.com
  - DOMAIN-SUFFIX,githubassets.com
  - DOMAIN-SUFFIX,wikipedia.org
  - DOMAIN-SUFFIX,wikimedia.org

GitHub 페이지, 원본 콘텐츠, 정적 리소스 도메인을 구분해 적으면 나중에 특정 리소스 유형의 연결 경로를 조정하기 쉽습니다. 마지막의 MATCH 규칙도 이 연결들을 프록시로 보내지만, 명시적인 규칙은 여전히 유용합니다. 로그에서 매칭된 규칙 세트를 확인할 수 있고, 나중에 기본 경로를 바꾸더라도 해당 서비스의 연결 경로는 그대로 유지됩니다.

규칙 순서: 먼저 일치하는 규칙이 연결 경로를 결정

규칙은 자동으로 “더 구체적인 규칙 우선” 순서로 정렬되지 않습니다. DOMAIN 정확 일치 규칙으로 더 포괄적인 규칙을 덮어쓰려면 앞에 배치해야 합니다. 규칙 세트도 충돌을 자동으로 해결하지 않습니다. 같은 도메인이 광고 세트와 직결 세트에 모두 있으면 먼저 검사되는 규칙이 결과를 결정합니다.

순서	매칭 대상	이유
1	루프백 및 사설 IPv4 주소	로컬 서비스와 일반적인 LAN 대상은 우선 직결
2	광고 도메인 세트	확인된 광고 요청을 우선 차단
3	정확한 서비스 예외	뒤에 오는 포괄적인 도메인 분류를 덮어씀
4	국내 도메인 세트	국내 서비스 중 지정된 도메인은 직결
5	해외 서비스 세트	프록시가 필요한 서비스를 명시적으로 지정
6	MATCH	앞선 규칙에 일치하지 않은 모든 연결을 처리

예외 규칙은 덮어쓸 규칙보다 앞에 배치하세요

기본 설정의 cloud.tencent.com은 정확한 서비스 규칙의 예입니다. 이 도메인은 원래 +.tencent.com에도 매칭되므로 현재 연결 경로는 달라지지 않습니다. 특정 서비스를 프록시로 연결하려면 정확 일치 규칙의 정책을 “해외 프록시”로 바꾸세요. Tencent 도메인 세트 전체를 프록시 그룹으로 옮기지는 마세요.

광고 규칙에 허용 예외를 추가하려면 광고 규칙 세트보다 앞에 배치해야 합니다. 반대로 MATCH,DIRECT를 첫 번째 규칙으로 두면 뒤에 있는 광고·국내·해외 규칙은 검사되지 않습니다. 기본 규칙은 반드시 마지막에 두세요.

규칙 업데이트 및 GEOIP 보완: 오분류 범위 줄이기

로컬 파일에서 HTTP 규칙 소스로 전환하기

로컬 type: file 규칙 세트는 일정 시간마다 자동으로 내려받아 갱신되지 않습니다. 자동 업데이트가 필요하다면 접근 가능한 HTTPS 규칙 주소와 캐시 path, interval을 지정한 type: http를 사용하세요. 예를 들어 interval: 86400은 86,400초, 즉 24시간마다 확인한다는 뜻이며 매일 자정에 갱신된다는 의미는 아닙니다.

원격 규칙 소스를 선택할 때는 먼저 콘텐츠 형식을 확인하세요. behavior: domain은 도메인 목록에, behavior: classical은 규칙 유형이 포함된 항목에 사용합니다. format: yaml은 payload가 포함된 YAML 파일을 지정합니다. 웹 미리보기 주소, 전체 구독 설정, 바이너리 규칙 파일은 같은 YAML 규칙 소스로 사용할 수 없습니다. 다운로드에 성공해도 콘텐츠 형식이 맞지 않으면 불러오지 못합니다.

규칙 소스는 매칭 조건만 제공해야 합니다. 출처가 불분명한 전체 설정을 기존 구독 설정 대신 적용하지 마세요.
처음 배포할 때는 수동으로 업데이트한 뒤 로그를 확인하고 자동 업데이트를 사용하세요. 캐시가 반드시 존재한다고 가정하지 마세요.
원격 목록을 확장한 뒤에는 광고 규칙, 서비스 예외, 국내 직결 규칙이 서로 겹치는 범위를 다시 확인하세요.

GEOIP CN은 보조 규칙으로만 사용

코어에 필요한 GeoIP 데이터가 준비되어 있다면 MATCH 앞에 GEOIP,CN,국내 직결을 추가해 도메인 규칙에 일치하지 않은 연결을 중국 IP로 분류할 수 있습니다. 이 규칙은 대상 IP와 데이터베이스에 의존하므로 서비스 도메인 분류를 대체하지 않습니다. 해외 서비스가 중국 CDN을 사용하면 직결로 분류될 수 있고, 국내 서비스가 해외 주소를 사용하면 계속 프록시로 연결될 수 있습니다.

no-resolve를 추가하면, 예를 들어 GEOIP,CN,국내 직결,no-resolve처럼 설정할 경우 매칭만을 위해 도메인을 직접 확인하지 않습니다. 이때 매칭에 사용할 실제 대상 IP가 연결에 없으면 규칙을 건너뛸 수 있습니다. 따라서 일부 규칙으로 인한 이름 확인을 줄일 수는 있지만, “국내 사이트를 더 정확하게 판별”하는 옵션은 아닙니다. 기본 설정은 GeoIP에 의존하지 않으므로 먼저 기본 트래픽 분리 동작을 확인할 수 있습니다.

검증 및 문제 해결: 규칙 매칭부터 연결 결과까지 확인

네 단계로 설정 확인하기

문법과 파일을 확인합니다. mihomo 명령줄을 사용하는 경우 예제 디렉터리에서 mihomo -t -d . -f config.yaml을 실행하세요. 데스크톱 클라이언트에서는 설정 검사 기능을 사용하고 로컬 규칙 파일 세 개가 모두 불러와졌는지 확인합니다.
트래픽이 처리되는지 확인합니다. 시스템 프록시를 켜거나 아래처럼 프록시를 명시하는 명령을 사용하세요. 명령으로는 접속되지만 브라우저 연결 패널에 기록이 없다면 규칙을 바꾸기 전에 브라우저의 프록시 설정을 확인합니다.
현재 정책을 확인합니다. 모드가 규칙 모드인지, “해외 프록시”가 사용 가능한 업스트림을 선택했는지, “광고 차단”이 REJECT를 선택했는지 확인하세요.
새 연결로 다시 테스트합니다. 규칙을 바꾼 뒤 기존 연결을 종료하고 테스트하세요. 브라우저는 기존 연결을 재사용할 수 있으며 정책을 바꿔도 이미 설정된 세션의 연결 경로가 즉시 바뀌지는 않습니다.

curl -I --proxy http://127.0.0.1:7890 https://www.baidu.com
curl -I --proxy http://127.0.0.1:7890 https://github.com
curl -I --proxy http://127.0.0.1:7890 https://www.wikipedia.org

Windows에서 curl이 다른 명령으로 연결된 경우 curl.exe를 사용하세요. 이 명령은 7890 포트를 거치는 요청을 테스트합니다. TUN이 트래픽을 처리하는지는 검증하지 않으며, HTTP 상태 코드만으로 웹사이트의 모든 리소스를 사용할 수 있다고 판단할 수 없습니다.

매칭 기록으로 문제 원인 찾기

테스트 대상	예상 규칙	예상 정책
www.baidu.com	cn-domains	국내 직결 → DIRECT
github.com	overseas-services	해외 프록시 → 로컬 업스트림
www.wikipedia.org	overseas-services	해외 프록시 → 로컬 업스트림
ad.doubleclick.net	ad-domains	광고 차단 → REJECT

표의 결과는 예제 설정을 기준으로 한 예상값이며 실제 속도나 사용 가능성을 보장하지 않습니다. 광고 도메인은 광고 서비스 페이지가 표시되는지가 아니라 어떤 규칙이 연결을 처리하는지 확인해야 합니다. 규칙과 정책이 예상대로인데도 접속에 실패하면 규칙 순서를 계속 바꾸기보다 업스트림 연결, 대상 서비스, DNS를 확인하세요.

DNS와 TUN으로 인한 일반적인 문제

도메인 규칙을 적용하려면 코어가 도메인을 확인할 수 있어야 합니다. 앱이 IP 주소로 직접 연결하거나 브라우저가 별도의 암호화 DNS를 사용하거나 TUN 환경에서 DNS 요청이 제대로 처리되지 않으면 도메인 식별에 문제가 생길 수 있습니다. fake-ip는 가상 주소 매핑으로 도메인 정보를 복원하는 데 도움이 되지만, 클라이언트 DNS 설정과 TUN의 DNS 가로채기 및 우회 설정을 함께 확인해야 합니다. 필드 하나만 바꿨다고 모든 요청이 도메인 규칙에 매칭되는 것은 아닙니다.

로그만으로 원인을 찾기 어려울 때에만 log-level을 임시로 debug로 바꾸고, 확인이 끝나면 info로 되돌리세요. 로그를 공유하기 전에 구독 주소, 인증 정보, 개인 접속 기록을 삭제하세요. 최종 점검에서는 연결이 코어에 도달했는지, 예상한 규칙에 매칭됐는지, 해당 연결 경로를 실제로 사용할 수 있는지 각각 확인해야 합니다. 세 조건이 모두 충족되어야 국내·해외 트래픽 분리 설정이 제대로 완료된 것입니다.