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

먼저 규칙 모드를 켜고 트래픽이 코어로 들어오는지 확인하세요

클라이언트의 모드 선택 메뉴에서 「규칙 / Rule」을 선택하세요. 그런 다음 「프록시 / Proxies」로 이동해 사용할 프록시 그룹에서 연결 가능한 노드를 선택합니다. 국내외 트래픽의 출구는 규칙에 따라 결정됩니다. 전역 모드에서는 이 분류 로직이 적용되지 않으며, 직접 연결 모드에서도 아래 규칙에 따라 프록시를 선택하지 않습니다.

이 문서에서는 mihomo 코어를 사용하는 클라이언트를 기준으로 설명합니다. Clash는 클라이언트와 설정 생태계를 통칭하는 이름으로 널리 쓰이지만, 구형 Clash 코어는 GEOSITE, 데이터 파일 및 일부 매개변수 지원 방식이 다를 수 있습니다. 먼저 클라이언트의 「정보」 또는 코어 정보 화면에서 코어 이름을 확인하세요. 설정 오류가 발생하면 앱 이름만 보지 말고 실제 코어와 로그부터 확인해야 합니다.

현재 설정 확인: 「설정 / Profiles」에서 활성화된 구독을 찾아 먼저 백업용으로 내보내세요. 사용자 설정은 구독 업데이트 후 사라지지 않도록 클라이언트에서 제공하는 재정의, 병합 또는 확장 설정에 추가하는 것이 좋습니다.
트래픽 처리 방식 확인: 브라우저만 테스트할 때는 먼저 시스템 프록시를 켜세요. 시스템 프록시를 사용하지 않는 프로그램까지 처리하려면 TUN을 활성화합니다. 두 방식 모두 같은 트래픽 분리 규칙을 사용할 수 있습니다.
수신 포트 확인: 아래 예시에서는 mixed-port: 7890을 사용합니다. 실제 포트는 현재 적용 중인 설정을 기준으로 확인하세요. 예시에 7890이 나온다고 해서 클라이언트가 해당 포트에서 수신 중이라고 단정할 수는 없습니다.
연결 기록 열기: 「연결 / Connections」과 「로그 / Logs」를 찾아 두세요. 이후 대상 도메인, 일치한 규칙, 최종 정책 경로를 함께 확인해야 합니다.

GEOSITE, GEOIP, RULE-SET의 역할 구분하기

트래픽은 도메인이나 대상 IP를 기준으로 분류할 수 있습니다. 국내 서비스도 여러 지역의 CDN을 이용하는 경우가 많고, 해외 서비스가 가까운 지역의 주소로 해석될 수도 있습니다. 따라서 IP의 지역과 서비스에 적용해야 할 출구는 같은 의미가 아닙니다. 일반적으로 명확한 도메인 규칙을 먼저 적용하고 IP 지리 데이터베이스를 보조 기준으로 사용합니다.

규칙 유형	판단 기준	적용하기 좋은 대상
`DOMAIN-SUFFIX`	도메인과 하위 도메인	고정된 출구가 필요한 특정 서비스
`GEOSITE`	도메인 분류 데이터베이스	국내 서비스, 해외 서비스 등의 일괄 분류
`GEOIP`	대상 IP와 주소 데이터베이스	사설 네트워크 또는 지역 IP 추가 판별
`RULE-SET`	설정에서 지정한 규칙 제공자	별도로 관리하는 직접 연결, 프록시, 차단 목록
`MATCH`	앞선 규칙과 일치하지 않은 연결 처리	규칙 목록의 마지막 줄

규칙 순서: 먼저 일치하는 규칙이 적용됩니다

rules는 위에서 아래 순서로 확인하며, 처음 일치한 규칙의 정책을 적용합니다. 권장 순서는 필요한 예외 허용, 광고 차단, 로컬 네트워크 직접 연결, 서비스별 도메인 규칙, 국내 도메인, 해외 도메인, 국내 IP, 최종 기본 규칙입니다. MATCH를 앞쪽에 두면 뒤에 있는 규칙은 적용되지 않습니다.

GEOSITE의 cn과 geolocation-!cn은 널리 쓰이는 데이터 세트의 분류 이름이지만, 모든 데이터 소스에 포함되는 것은 아닙니다. 후자는 ‘국내가 아닌 모든 도메인’을 뜻하지도 않습니다. 사용 전에 현재 geosite 데이터에 해당 분류가 있는지 확인하세요. GEOIP 데이터 파일만 있다고 해서 GEOSITE도 사용할 수 있다고 볼 수는 없습니다.

설정 조합: 국내는 직접 연결, 해외는 프록시, 광고는 차단

아래 예시에서는 로컬 규칙 세트 두 개를 사용해 광고 도메인과 직접 연결할 서비스 도메인을 각각 관리합니다. 원격으로 관리되는 목록으로 바꾸기 전에 규칙 로드와 일치 여부를 먼저 확인할 수 있습니다. 예시의 PROXY는 정책 그룹 이름입니다. 설정에 실제로 존재하는 프록시 그룹 이름으로 바꾸거나 같은 이름의 그룹이 있는지 확인해야 합니다. 노드를 자동으로 만드는 키워드가 아닙니다.

1단계: 로컬 규칙 세트 파일 만들기

코어가 접근할 수 있는 설정 디렉터리에 rules 폴더를 만들고 아래 두 파일을 각각 저장하세요. 상대 경로는 일반적으로 코어의 작업 디렉터리를 기준으로 하며, 구독 파일을 다운로드한 위치와 다를 수 있습니다. 일부 GUI 클라이언트는 파일 경로를 제한하므로 클라이언트에서 허용하는 설정 디렉터리를 사용하세요.

rules/local-ads.yaml: classical 동작을 사용합니다. 파일에는 전체 규칙 유형을 작성하되 출구 정책은 넣지 않습니다.

payload:
  - DOMAIN-SUFFIX,doubleclick.net
  - DOMAIN-SUFFIX,googlesyndication.com

rules/local-direct.yaml: domain 동작을 사용하고 도메인 패턴만 작성합니다. 이 규칙 세트 문법에서 앞에 +.를 붙이면 도메인 자체와 하위 도메인이 모두 포함됩니다.

payload:
  - '+.bilibili.com'
  - '+.bilibili.cn'

여기서는 광고 도메인 두 개만 사용해 차단 흐름을 보여줍니다. 전체 광고를 차단하는 목록은 아닙니다. 광고 도메인이 로그인, 통계 또는 콘텐츠 로딩에 필요한 경우도 있으므로 목록을 확장한 뒤에는 항목별로 확인하세요. 직접 연결 목록 역시 작성 방법을 보여주는 예시일 뿐입니다. 동영상, 이미지, 계정 서비스가 다른 도메인을 사용할 수 있으니 연결 기록을 참고해 추가해야 합니다.

2단계: 규칙 제공자와 트래픽 분리 규칙 병합하기

아래 항목을 현재 설정에 병합하세요. 기존 rule-providers가 있다면 해당 항목을 유지하고, rules가 있다면 순서를 맞춰 통합하세요. 같은 YAML 계층에 같은 이름의 키를 두 번 작성하면 안 됩니다. 클라이언트의 「규칙 추가」가 구독의 MATCH 뒤에 붙는 방식이라면 해당 규칙도 적용되지 않습니다. 앞에 삽입하는 규칙이나 전체 순서를 제어할 수 있는 재정의 방식을 사용하세요.

mixed-port: 7890
mode: rule

rule-providers:
  local-ads:
    type: file
    behavior: classical
    format: yaml
    path: ./rules/local-ads.yaml
  local-direct:
    type: file
    behavior: domain
    format: yaml
    path: ./rules/local-direct.yaml

rules:
  - RULE-SET,local-ads,REJECT
  - 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
  - IP-CIDR6,fc00::/7,DIRECT,no-resolve
  - RULE-SET,local-direct,DIRECT
  - GEOSITE,cn,DIRECT
  - GEOSITE,geolocation-!cn,PROXY
  - GEOIP,CN,DIRECT
  - MATCH,PROXY

이 코드는 기존 노드, proxy-groups, 사용 가능한 지리 데이터베이스가 있어야 동작하는 병합 예시이며, 단독으로 구독에 사용할 수 없습니다. 사설 주소 대역은 흔히 쓰이는 범위만 표시했으므로 특수 목적 주소 전체를 포함하지 않습니다. 기업 네트워크에서 다른 내부 대역을 사용한다면 실제 네트워크 구성에 맞춰 추가하세요.

3단계: 기본 정책과 호환성 확인하기

국내 도메인은 먼저 직접 연결: GEOSITE,cn,DIRECT를 IP 판별 규칙보다 앞에 둡니다. 그래야 국내 서비스가 다른 지역의 CDN 주소로 해석되더라도 프록시 기본 규칙으로 넘어가지 않습니다.
분류된 해외 서비스는 먼저 프록시 연결: 해외 도메인 규칙을 국내 IP 규칙보다 앞에 두면 CDN 주소의 위치 때문에 해외 서비스가 실수로 직접 연결되는 일을 줄일 수 있습니다.
분류되지 않은 연결은 프록시로 처리: MATCH,PROXY는 해외 서비스에 대한 연결 가능성을 우선합니다. MATCH,DIRECT로 바꾸면 목록에 없는 해외 도메인이 직접 연결에 실패할 수 있으므로 사용 목적에 맞게 선택하세요.
분류 항목이 없으면 해당 규칙부터 제거: 코어에서 GEOSITE 분류를 찾을 수 없다는 오류가 나오면 먼저 설정이 정상적으로 로드되도록 복구한 뒤 사용할 데이터 소스를 설정하세요. 로드 오류를 감추려고 클라이언트를 반복해서 재시작하지 마세요.

DNS와 no-resolve: DNS 문제를 규칙 문제와 구분하기

설정을 저장하고 다시 불러온 다음, 규칙 세트 파일을 찾을 수 없음, 정책 그룹이 존재하지 않음, 지리 데이터베이스 읽기 실패 등의 오류가 로그에 있는지 확인하세요. 설정이 정상적으로 로드되면 DNS를 점검합니다. 도메인이 잘못된 주소로 해석되면 규칙 순서가 맞더라도 직접 연결 시간 초과나 서비스 접속 실패가 발생할 수 있습니다.

국내 IP 규칙에 no-resolve를 추가해야 할까요?

예시의 GEOIP,CN,DIRECT에는 no-resolve가 없습니다. 따라서 IP가 필요한 규칙과 도메인만 있는 연결을 비교할 때 코어가 판별을 계속하기 위해 DNS 조회를 수행할 수 있습니다. 국내 도메인 분류에 포함되지 않은 국내 주소를 직접 연결하는 데 도움이 되지만 DNS 결과에 더 크게 의존하게 됩니다.

GEOIP,CN,DIRECT,no-resolve로 바꾸면 해당 규칙은 자체 판별을 위해 도메인 조회를 수행하지 않습니다. 대상 IP를 이미 알고 있는 연결은 규칙과 일치할 수 있지만, 도메인만 있고 사용할 수 있는 주소가 없는 연결은 MATCH로 넘어갈 수 있습니다. 따라서 이 매개변수를 추가한다고 국내 서비스 판별 정확도가 높아지는 것은 아닙니다.

Fake-IP와 TUN 점검 사항

Fake-IP: 앱이 198.18.0.0/16 범위에 속하는 매핑 주소를 받을 수 있습니다. 실제 범위는 fake-ip-range를 확인하세요. 이 주소는 서버의 실제 위치를 나타내지 않으므로 지역 정보를 조회해 트래픽 분리가 적절한지 판단할 수 없습니다.
도메인 정보: DNS가 제대로 처리되고 주소가 매핑되어야 코어가 도메인을 복원해 GEOSITE 규칙을 적용할 수 있습니다. 앱이 별도의 암호화 DNS를 사용하거나, 캐시된 IP에 직접 연결하거나, 기존 연결을 재사용하면 확인 결과가 달라질 수 있습니다.
TUN: 가상 네트워크 인터페이스의 라우팅과 DNS 처리가 실제로 적용되는지 확인하세요. TUN은 처리 대상 범위를 넓혀 주지만 정책 그룹 이름, 규칙 순서 또는 데이터베이스 분류를 자동으로 수정하지는 않습니다.
DNS 리졸버 선택: 국내 도메인과 프록시 대상 도메인의 해석 결과를 각각 테스트하세요. 도메인별로 리졸버를 선택해야 한다면 nameserver-policy를 설정하세요. 변경하기 전에 현재 mihomo 문서와 클라이언트의 DNS 재정의 동작을 확인해야 합니다.

트래픽 분리 확인하기: 웹페이지 접속 여부만 보지 말고 일치한 규칙을 확인하세요

설정을 다시 불러온 뒤 테스트 앱에서 계속 사용 중인 기존 연결을 닫거나 클라이언트의 연결 화면에서 해당 연결을 종료한 다음 새 요청을 보내세요. 기존 TCP 연결은 규칙을 바꿔도 즉시 새 경로를 선택하지 않는 경우가 많고, 브라우저가 연결을 재사용하면 이전 결과가 한동안 유지될 수 있습니다.

국내 직접 연결 확인: www.bilibili.com을 열고 연결 기록에서 도메인을 검색하세요. 메인 페이지 도메인은 local-direct 또는 그보다 앞에 있는 직접 연결 규칙과 일치하고, 최종 정책 경로는 DIRECT로 표시되어야 합니다. 관련 리소스는 별도로 확인하세요.
해외 프록시 연결 확인: 실제로 프록시가 필요한 해외 서비스에 접속해 geolocation-!cn 또는 MATCH와 일치하는지 확인하세요. 정책 경로가 PROXY에서 예상한 노드로 이어지는지, 그룹 안의 직접 연결 항목을 선택한 것은 아닌지도 확인해야 합니다.
차단 확인: https://doubleclick.net/을 요청했을 때 연결이 local-ads 규칙과 일치하고 REJECT 정책이 적용되어야 합니다. 브라우저 오류만으로는 충분하지 않습니다. 연결 기록을 확인해 규칙이 차단한 것인지 DNS 또는 네트워크 오류인지 구분하세요.
로컬 네트워크 연결 확인: 실제로 사용하는 라우터나 NAS 주소에 접속해 사설 대역 규칙과 직접 연결 출구를 확인하세요. 회사 네트워크에 별도 라우팅이 있다면 시스템 라우팅 테이블도 함께 점검해야 합니다.

명시적 프록시로 시스템 프록시 설정의 영향 확인하기

macOS의 「터미널」에서 아래 명령을 실행하면 요청을 로컬 7890 포트로 명시적으로 보낼 수 있습니다. --max-time 15는 한 번의 테스트를 15초로 제한합니다. 진단을 위한 설정일 뿐 성능 측정 결과는 아닙니다. 실제 포트가 다르면 먼저 명령을 수정하세요.

curl -I --max-time 15 \
  --proxy http://127.0.0.1:7890 \
  https://www.bilibili.com/

curl -I --max-time 15 \
  --proxy http://127.0.0.1:7890 \
  https://www.wikipedia.org/

HTTP 상태 코드는 대상 서비스가 결정합니다. 리디렉션, 접근 제한, HEAD 요청 거부 등이 출력에 영향을 줄 수 있습니다. 여기서는 요청이 클라이언트 연결 기록에 나타나는지, 어떤 규칙과 일치했는지, 정책 경로가 어떻게 이어지는지를 확인하는 것이 핵심입니다. 200, 403 또는 한 번의 시간 초과만으로 국내외 트래픽 분리가 정확한지 판단할 수는 없습니다.

자주 발생하는 문제: 설정, 규칙 일치, 출구 순서로 점검하기

증상	우선 확인할 항목	해결 방법
국내 사이트가 계속 프록시로 연결됨	실제 도메인, 직접 연결 목록, 규칙 순서	연결 기록을 참고해 도메인을 추가하고 명시적인 직접 연결 규칙을 프록시 규칙보다 앞에 배치합니다.
해외 사이트가 직접 연결 규칙과 일치함	범위가 넓은 직접 연결 규칙, 그룹 내 선택 항목	도메인 범위를 좁히고 프록시 그룹에서 DIRECT가 선택되었는지 확인합니다.
저장 후에도 변경 사항이 전혀 적용되지 않음	현재 설정, 재정의 결과, 모드	대상 설정이 실행 중인지 확인하고 Rule 모드로 전환합니다.
광고가 계속 표시됨	같은 도메인에서 광고를 제공하는지, 실제 규칙과 일치했는지	광고 전용 도메인을 추가합니다. 같은 도메인에서 제공되는 콘텐츠는 브라우저 콘텐츠 필터로 처리해야 합니다.
프록시 요청 시간 초과	규칙 일치 기록, 노드 연결 상태, DNS	불필요한 규칙을 추가하기 전에 먼저 경로가 올바른지 확인한 다음 노드와 DNS를 테스트합니다.
다시 불러올 때 파일 오류가 표시됨	경로, YAML 들여쓰기, behavior	작업 디렉터리를 확인하고 파일 형식과 규칙 제공자 선언을 일치시킵니다.

예외 규칙은 필요한 범위로만 제한하세요

광고 규칙이 로그인에 필요한 도메인까지 차단한다면 확인된 필수 도메인만 차단 규칙보다 앞에 별도로 추가하세요. 서비스 제공자의 상위 도메인 전체를 허용하기보다는 DOMAIN으로 정확히 일치시키는 것이 좋습니다. 반대로 특정 해외 서비스를 반드시 프록시로 연결해야 한다면 국내 분류 규칙 앞에 정확한 규칙을 추가하세요. 국내 직접 연결 규칙 전체를 삭제하지 마세요.

로컬 파일을 원격 구독 규칙 세트로 바꿀 때는 type, behavior, format과 업데이트 주기를 함께 확인하세요. domain 목록을 classical 규칙으로 그대로 읽을 수는 없으며, YAML 규칙도 확장자만 바꾼다고 바이너리 규칙 세트가 되지 않습니다. 업데이트 후에는 되돌릴 수 있는 설정을 보관하고 같은 도메인 목록으로 다시 검증하세요.

최종 점검은 세 가지로 정리할 수 있습니다. 연결이 실제로 코어에 들어오는지, 예상한 규칙과 일치하는지, 정책 그룹에서 올바른 출구를 선택했는지 확인하세요. 이 세 단계를 나눠 기록해야 국내 직접 연결, 해외 프록시 연결, 광고 차단을 무작정 규칙을 늘리지 않고 안정적으로 관리할 수 있습니다. 클라이언트 사용 방법은 사용 가이드에서, 설정 항목은 고급 설정 가이드에서 확인할 수 있습니다.