중국 본토 웹만 느릴 때: Clash GeoIP·DIRECT 분류 단계 설정

1. 증상: 국내 사이트만 이상할 때 의심할 것

대표적인 패턴은 이렇습니다. 구글·유튜브·깃허브는 프록시 덕분에 잘 열리는데, 본토 전자상거래·은행·세무·실명 인증이 붙은 포털만 페이지가 반쯤 뜨거나 첫 화면은 되는데 결제 단계에서 멈춥니다. 지도·배송 조회·캡차가 끝없이 새로고침되거나, “현재 지역에서 이용할 수 없습니다” 같은 문구가 뜨기도 합니다. 이런 증상은 단순히 노드 한 대가 느린 것과 다르게, 본래 짧아야 할 국내 회선을 해외로 돌려 보낸 뒤 서비스 쪽 정책과 맞지 않아 생기는 경우가 많습니다.

또 다른 신호는 프록시만 끄면 바로 나아진다는 점입니다. 전역이 아니라 규칙 모드인데도 그렇다면, “모든 것을 프록시로” 잡아 두었거나, GeoIP나 국내 직접 연결 규칙이 너무 뒤에 있어 앞선 규칙에 이미 걸렸을 가능성을 의심해야 합니다. 반대로 프록시를 꺼도 느리다면 ISP 혼잡, 사이트 자체 장애, DNS 문제 쪽을 같이 봐야 하고, 이 글의 초점은 전자(오분류)입니다.

한국·일본 등 다른 지역 사용자도 중국 본토 서비스에 접속할 때 비슷한 증상을 겪을 수 있습니다. 본토 서비스는 대륙 IP에서만 허용하거나 반대로 특정 해외 대역을 제한하는 경우가 있어, “분류만 바로잡아도” 체감이 크게 달라지는 경우가 많습니다.

2. 로그로 “어느 정책으로 나갔는지” 확인

설정을 뜯기 전에 실제 연결이 어떤 정책 이름으로 나갔는지를 한 번 고정하는 것이 좋습니다. Clash·Mihomo 계열 클라이언트는 보통 연결 목록이나 로그에 DIRECT인지 PROXY 그룹인지, 어떤 규칙에 매칭되었는지를 보여 줍니다. 문제가 나는 사이트의 호스트명을 떠올리고, 브라우저에서 해당 페이지를 연 직후 로그에서 같은 목적지를 찾아 보세요.

확인 포인트

정책(policy) 열: DIRECT가 아니라 ♻ 자동 선택·🔰 프록시 같은 그룹으로 나가면, 본토 트래픽이 노드를 탄 것입니다.
규칙(rule) 열: MATCH나 광범위한 DOMAIN-SUFFIX에 먼저 걸렸는지 확인합니다. “전부 프록시” 템플릿은 여기서 한 번에 걸리기 쉽습니다.
목적지 IP 대역: 로그에 실제 목적지가 보이면, 해당 주소가 알려진 중국 본토 대역인지 대조해 볼 수 있습니다(정확도는 GeoIP 데이터 버전에 좌우).

이 단계에서 이미 본토 호스트가 DIRECT로 찍힌다면, 느림의 원인은 노드 오분류가 아니라 DNS 해석, fake-ip, QUIC, 브라우저 확장, TUN 라우팅 등 다른 축일 수 있습니다. fake-ip와 DNS를 다룬 글이나 TUN·라우팅 점검 글로 넘어가는 편이 빠릅니다.

팁: 테스트할 때는 한 번에 한 가지만 바꾸세요. 규칙·노드·DNS를 동시에 수정하면 로그만 복잡해지고, 나중에 어떤 줄이 효과가 있었는지 기억하기 어렵습니다.

3. 규칙 순서와 최종 MATCH의 함정

Clash 규칙 엔진은 위에서 아래로 읽으며, 처음 매칭된 한 줄에서 결정이 납니다. 그래서 “아래쪽에 GeoIP CN DIRECT를 넣어 두었는데도 안 먹는다”는 상황은, 대개 그 위에 더 넓은 조건이 먼저 있기 때문입니다.

자주 있는 실수

최종 MATCH가 프록시 그룹인데, 그 위에 본토 예외가 거의 없음.
GEOIP,CN보다 앞에 있는 DOMAIN-KEYWORD·넓은 DOMAIN-SUFFIX가 해외 CDN 도메인까지 프록시로 보냄(일부 본토 사이트는 정적 자원이 글로벌 도메인을 씀).
구독에서 가져온 규칙 세트가 한 덩어리로 앞에 붙어 사용자가 추가한 DIRECT 줄이 사실상 도달하지 못함.

해결의 기본 원칙은 단순합니다. “반드시 직접 연결해야 할 것(사설망, 랜, 본토 대역)”을 프록시보다 위에 두고, 그다음에 지역·도메인별 프록시 분기, 마지막에 MATCH를 둡니다. 운영하면서 튜닝할 때도 이 순서를 깨지 않는 것이 장기적으로 덜 고생합니다.

로그에서 보이는 것	우선 의심
본토 사이트가 프록시 그룹으로 나감	`GEOIP,CN,DIRECT`가 없거나, 위 규칙에 먼저 걸림, 또는 GeoIP 데이터 미탑재
일부 자원만 느림	정적 도메인이 별도 규칙에 잡힘; geosite·도메인 단위 예외 필요
DIRECT인데도 인증 오류	DNS가 해외 업스트림이라 잘못된 CDN 에지; fake-ip·필터·fake-ip-filter 점검

4. GeoIP CN DIRECT 배치(핵심)

GeoIP는 목적지 IP가 어떤 국가·지역 코드에 해당하는지 판별해 규칙에 씁니다. 중국 본토 트래픽을 직접 연결로 돌리려면, 사용 중인 커널 문서에서 허용하는 형식으로 GEOIP 규칙을 추가하고, 프록시로 보내는 넓은 규칙들보다 위에 두어야 합니다. 일반적으로 CN 코드를 DIRECT에 연결하는 한 줄이 가장 단순한 출발점입니다.

사설망·LAN을 먼저

GeoIP보다 앞에 사설 IP 대역과 LAN 호스트를 DIRECT로 두는 템플릿이 많습니다. 이유는 단순합니다. 사설 대역은 GeoIP 데이터와 무관하게 반드시 직접 연결해야 하기 때문입니다. 공유기 관리 페이지, NAS, 프린터가 프록시를 타면 증상이 더 이상하게 보입니다.

설정 예시(구조 참고용)

필드명·정확한 키는 Mihomo / Meta·사용 중인 코어 버전 문서를 따르세요. 아래는 규칙 블록 안에서의 순서 감각을 보여 주는 예입니다.

rules:
  # Private / LAN first — adjust to your core's rule types
  - IP-CIDR,10.0.0.0/8,DIRECT
  - IP-CIDR,172.16.0.0/12,DIRECT
  - IP-CIDR,192.168.0.0/16,DIRECT
  - IP-CIDR,127.0.0.0/8,DIRECT
  # Mainland China → direct (requires geoip database / data slice)
  - GEOIP,CN,DIRECT
  # Then your proxy rules for everything else
  - MATCH,PROXY

실제 구독 파일에서는 rule-providers로 긴 목록을 불러오기도 하고, GEOIP,CN 대신 지역별 규칙 세트를 쓰기도 합니다. 중요한 것은 데이터 파일이 클라이언트에 존재하고 갱신 경로가 살아 있다는 점입니다. GeoIP 데이터가 비어 있거나 경로가 틀리면 해당 규칙이 기대대로 동작하지 않고, 모든 것이 아래쪽 MATCH로 떨어져 프록시로만 나갈 수 있습니다.

주의: “중국 본토 = 항상 빠름”은 아닙니다. 일부 서비스는 해외 IP에서의 접속을 의도적으로 제한합니다. 반대로 특정 본토 사이트는 해외 CDN을 써서 GeoIP 한 줄만으로는 부족할 수 있어, 로그를 보며 도메인 단위 보완이 필요할 때가 있습니다.

5. geosite·도메인 목록 등 대안

GEOIP,CN는 IP 기준이라, 도메인 단계에서 이미 프록시로 분류된 트래픽과 섞이면 기대와 다를 수 있습니다. 그럴 때는 geosite나 커뮤니티 규칙 세트에 있는 cn·china 카테고리 등을 활용해, 알려진 본토 도메인 묶음을 DIRECT로 보내는 방법이 흔합니다. 구독 템플릿마다 이름이 다르므로, 자신이 쓰는 리스트의 문서를 확인하는 것이 안전합니다.

실무에서의 절충

많은 사용자는 GeoIP CN + 주요 쇼핑·금융 도메인 몇 줄을 함께 씁니다. 이유는 앞 절에서 말했듯 일부 사이트는 정적 자원이 글로벌 호스트명을 쓰기 때문입니다. 로그에 찍힌 호스트를 개발자 도구 네트워크 탭에서 모아, 반복해서 보이는 도메인을 DIRECT 쪽 규칙에 추가하는 방식이 부담은 있지만 확실합니다.

반대로 해외 서비스만 골라 프록시하는 “화이트리스트형” 구성은 관리 비용이 크지만, 본토 트래픽이 실수로 노드를 타는 일은 줄어듭니다. 자신의 사용 패턴과 구독 갱신 주기에 맞는 쪽을 고르면 됩니다.

6. DNS·fake-ip·TUN과의 관계

규칙이 아무리 완벽해도 DNS가 먼저 엉키면 “본토 사이트인데 해외 에지로 붙는다”는 현상이 남을 수 있습니다. 특히 fake-ip를 켠 환경에서는 연결 초기에 보이는 주소와 실제 백엔드의 관계를 헷갈리기 쉬워, 증상이 GeoIP 문제와 비슷하게 보이기도 합니다. 이때는 규칙을 늘리기 전에 fake-ip-filter와 DNS 업스트림을 점검하는 순서가 맞습니다.

TUN 모드를 쓰는 경우에는 시스템 라우팅 테이블과 Clash 내부 분류가 동시에 작동합니다. 겉으로는 “국내 사이트가 느리다”로 보이지만, 실제로는 특정 대역이 TUN으로 흡수되지 않거나 예외 라우트가 어긋난 경우일 수 있습니다. Windows 환경이라면 TUN·방화벽·라우팅 글의 순서로 먼저 전체 경로가 정상인지 확인한 뒤, 이 글의 GeoIP·DIRECT 층으로 돌아오면 중복 수정을 줄일 수 있습니다.

정리하면, DNS·TUN·규칙은 같은 증상을 공유할 수 있으므로, 로그에서 정책 이름과 규칙 매칭을 먼저 고정하고 어느 층을 고칠지 정하는 것이 시간 낭비를 줄입니다.

7. 요약

프록시를 켠 뒤 중국 본토 웹만 느리거나 이상하다면, 먼저 연결이 DIRECT인지 프록시 그룹인지를 로그로 확인하세요. 프록시로 나간다면 GEOIP,CN,DIRECT와 사설망 DIRECT를 프록시보다 위에 두는 규칙 순서가 핵심이며, GeoIP 데이터 경로가 살아 있는지도 함께 봐야 합니다. IP만으로 부족한 사이트는 geosite·도메인 규칙으로 보완하고, 증상이 DNS·fake-ip·TUN과 겹치면 해당 글의 점검 순서를 앞당기는 편이 낫습니다.

장기적으로는 “이 호스트는 DIRECT, 이 CDN은 프록시”처럼 자주 틀어지는 줄만 메모해 두면 구독이 갱신돼도 같은 실수를 반복하지 않기 쉽습니다. 클라이언트 설치와 기본 개념은 사이트 문서에서 정리되어 있으니, 규칙 파일을 편집하기 전에 구조를 한 번 훑어 보는 것을 권합니다.

규칙·DNS·모드를 나눠 이해해 두면, 해외 콘텐츠는 매끄럽게, 본토 업무·쇼핑은 직접 회선으로 처리하는 구성을 안정적으로 유지하기 쉬워집니다.

→ Clash 클라이언트를 무료로 내려받고, 분류와 연결을 한층 편하게 맞춰 보세요