중국 본토 사이트만 느리거나 안 열릴 때: Clash 대륙 우회·GEOIP CN·규칙 순서 분단계 체크리스트(2026)
Clash·Mihomo 계열에서 규칙 모드나 TUN을 켠 뒤 해외 사이트는 빠른데 중국 본토 웹·앱만 로딩이 길어지거나 일부가 열리지 않는 경우, 포럼에서는 국내 트래픽이 프록시로 잘못 나간다는 가설이 자주 등장합니다. 중국어권 설정 템플릿의 「대륙 우회」(본토는 직접, 나머지는 분류) 개념과 맞물려 GEOIP의 CN 처리·RULE-SET 묶음·맨 아래 MATCH 줄·DNS(fake-ip·hijack) 중 어디가 어긋났는지 한 번에 보기 어렵습니다. 이 글은 앱별 커스텀 규칙 튜토리얼과 달리, 가장 흔한 오설정 증상인 「국내 직결이 아니라 프록시 경유」를 로그와 설정 순서로 가르는 한국어 검색 의도용 체크리스트입니다. 분류·GEOIP·규칙 순서라는 키워드로 끝까지 따라가면, 구독 프로필을 바꾸기 전에도 원인 축을 상당히 좁힐 수 있습니다.
① 증상을 먼저 말로 고정하기: 「중국 사이트」가 무엇인지
접속 진단에서 가장 비용이 큰 실수는 증상을 포괄적으로 적어 두는 것입니다. 예를 들어 모든 국내 사이트가 아니라 특정 결제·쇼핑·동영상 CDN만 느리다면, 원인은 GEOIP CN 한 줄보다 해당 도메인이 해외 POP으로 잡히는 경우일 수 있습니다. 반대로 백도어·앱 스토어·행정 포털 전반이 동시에 지연되면 기본 정책이 PROXY이거나 GEOIP CN 규칙이 아예 없거나 너무 아래에 있는 패턴을 의심합니다. 메모해 둘 항목은 다음과 같습니다. 첫째, 문제가 되는 정확한 호스트 이름(브라우저 개발자 도구 네트워크 탭). 둘째, HTTP인지 HTTPS인지, IPv4만인지 IPv6도 섞이는지. 셋째, Wi-Fi와 셀룰러에서 동일한지. 이 세 가지가 같으면 Clash 쪽 분류와 DNS를 의심하는 근거가 됩니다.
또 하나, 대륙 우회라는 표현은 원래 중국어권 구독에서 쓰는 본토 트래픽은 직접 연결이라는 뜻에 가깝습니다. 한국 사용자 입장에서는 「우리나라 사이트는 직결, 해외만 프록시」와 비슷한 스플릿 목표로 읽히기도 하지만, GEOIP CN은 지리적으로 중국으로 분류된 IP 대역에 대해 동작합니다. 따라서 한국·일본 사용자에게는 그대로 가져오면 의미가 빈 규칙이 되거나, 다른 RULE-SET과 충돌해 의도와 다른 정책이 선택될 수 있습니다. 템플릿 이름만 보고 켜 두기보다, 내가 기대하는 직결 대상이 CN 데이터베이스 안에 있는지를 확인하는 습관이 필요합니다.
② 작동 원리: 규칙은 위에서 아래로, 첫 매칭이 이긴다
Clash의 rules는 일반적으로 리스트 상단부터 순서대로 평가되며, 처음 걸린 한 줄이 해당 연결의 정책을 결정합니다. 그래서 GEOIP나 거대한 RULE-SET보다 더 구체적인 예외(특정 DOMAIN-SUFFIX 등)를 쓰려면 반드시 위쪽에 두어야 합니다. 사용자들이 말하는 규칙 순서 문제는 대개 이 원리를 간과한 결과입니다. 예를 들어 상단에 모든 트래픽을 PROXY로 보내는 규칙이 있거나, RULE-SET이 GEOIP CN보다 먼저 매칭되면, 「중국은 DIRECT」라는 기대와 상관없이 이미 프록시로 나간 뒤입니다.
GEOIP,CN,DIRECT 같은 줄이 있어도, 그 위에 GEOIP가 아닌 IP 기반·DOMAIN 규칙이 먼저 걸리면 하단은 실행되지 않습니다. 반대로 CN 매칭이 너무 넓게 잡혀 실제로는 해외 서비스인데 직결로 붙는 경우도 있어, 「느리다」는 체감만으로는 부족하고 연결 로그의 정책 이름을 봐야 합니다. 문법이 헷갈리면 사용자 정의 규칙 튜토리얼에서 rules와 proxy-groups 이름을 맞추는 방법부터 짚는 것이 좋습니다.
# Conceptual — first match wins; keep CN/direct above broad PROXY RULE-SET if intended
rules:
- DOMAIN-SUFFIX,cn-service.example,DIRECT
- GEOIP,CN,DIRECT
- MATCH,PROXY
③ 체크 1: 모드(Global·Rule·Direct)와 클라이언트 UI의 의미
많은 GUI에서 Global은 사실상 모든 트래픽을 한 그룹으로 보내는 쪽에 가깝고, Rule이 rules를 태웁니다. 사용자가 「규칙을 잘 넣었는데도」라고 할 때, 실제로는 UI가 Global이거나 시스템 프록시가 다른 앱에 의해 덮어쓰인 경우가 있습니다. TUN 모드를 쓰면 OS 전체가 가상 인터페이스를 타므로, 브라우저만 Rule이어도 백그라운드 앱은 여전히 같은 스택을 탈 수 있습니다. TUN 모드 심화 글에서 말한 것처럼, 캡처 경로와 이름 해석 경로를 분리해 생각하면 혼란이 줄어듭니다.
실무에서는 문제 사이트를 열기 직전에 클라이언트 로그를 켜 두고, 선택된 정책이 기대한 proxy-group인지부터 확인합니다. Global이면 GEOIP CN을 아무리 맞춰도 소용없습니다. 먼저 모드를 Rule로 고정한 뒤 아래 단계로 넘어가세요.
④ 체크 2: GEOIP CN 줄이 존재하는지, 그리고 어디에 있는지
구독 프로필을 열어 rules: 섹션에서 GEOIP와 CN이 함께 있는 줄을 찾습니다. 코어에 따라 geoip 데이터 소스 경로나 no-resolve 옵션 문법이 다를 수 있으니, 사용 중인 Mihomo·Clash Meta 릴리스 문서를 한 번 확인하세요. GEOIP,CN,DIRECT가 없다면 「중국은 직결」이라는 분기 자체가 없으므로, 나머지 규칙에 따라 프록시로 나갈 수 있습니다. 반대로 줄은 있는데 너무 아래에 있으면, 그 위의 RULE-SET이나 DOMAIN-KEYWORD가 먼저 잡아챕니다.
no-resolve를 붙이는 패턴은 도메인 규칙으로 이미 목적지가 정해진 경우와의 관계를 조정하기 위한 것으로 자주 등장합니다. 잘못 이해하고 옵션만 복사하면 기대와 다른 분기가 나기도 하니, 예시 YAML을 통째로 붙여 넣기보다 한 줄씩 의미를 확인하는 편이 안전합니다.
⑤ 체크 3: RULE-SET이 GEOIP보다 먼저 PROXY를 걸고 있지 않은지
최신 프로필은 외부 RULE-SET으로 수천 줄을 불러오는 경우가 많습니다. 이때 중국 관련 도메인이 글로벌 프록시 목록에 포함돼 있으면, GEOIP CN보다 위쪽에서 이미 PROXY로 매칭됩니다. 사용자는 「GEOIP는 있는데 왜 느리지?」라고 느끼지만, 실제로는 도메인 규칙이 이긴 것입니다. 해결책은 예외 DOMAIN을 상단에 추가하거나, RULE-SET 구성을 바꾸는 것인데, 전자가 보통 더 빠릅니다.
로그에서 어느 규칙 줄이 적중했는지가 표시되면, 파일 이름이 GEOIP인지 RULE-SET인지 바로 알 수 있습니다. 적중 규칙이 원하지 않는 프록시 그룹이면, 그 줄보다 위에 더 좁은 규칙을 추가하는 전략이 Clash 계열에서 일관됩니다. 이 패턴은 Zoom·Teams 분류 글에서 말한 서비스별 예외와도 같은 가족입니다.
⑥ 체크 4: MATCH와 마지막 줄 — 「나머지 전부」의 행방
많은 템플릿은 맨 끝에 MATCH 또는 이에 상응하는 최종 분기를 둡니다. 여기가 PROXY면, 위에서 잡히지 않은 모든 연결은 프록시로 나갑니다. GEOIP CN이 그 위에서 중국 IP를 DIRECT로 보내지만, 도메인이 해외 CDN으로 해석되면 IP가 CN이 아닐 수 있어 MATCH까지 떨어져 프록시 경유가 됩니다. 이게 바로 「사이트는 중국인데 트래픽은 해외 노드를 탄다」는 상황의 한 유형입니다.
따라서 MATCH가 무엇을 가리키는지, 그리고 직결을 원하는 트래픽이 GEOIP·DOMAIN 어느 쪽으로 잡히는지를 같이 봐야 합니다. 마지막 줄을 DIRECT로 바꾸는 것은 전체 트래픽에 영향을 주므로, 보통은 특정 도메인 예외를 추가하는 편이 안전합니다.
⑦ 체크 5: DNS — fake-ip·enhanced-mode·브라우저 DoH와의 정렬
규칙은 이름과 IP를 어떻게 보느냐에 따라 완전히 다른 길을 탑니다. fake-ip를 쓰면 애플리케이션이 보는 주소와 실제 outbound가 바라보는 목적지가 문서를 읽지 않으면 어긋나 보입니다. Clash dns 블록에서 hijack·fallback을 쓰는 경우, 시스템 DNS와 브라우저 내장 DoH가 동시에 동작하면 어떤 요청은 Clash를 안 타고 나가기도 합니다. 그 결과 같은 호스트인데 규칙 로그만 보면 DIRECT인 것처럼 보이다가 체감은 느린 이중 경로가 생깁니다.
점검 순서는 다음과 같습니다. 첫째, 문제 재현 시 클라이언트 DNS 로그에 해당 도메인이 찍히는지. 둘째, fake-ip 사용 여부와 redir-host 류 설정. 셋째, OS·브라우저 DoH를 잠시 끄고 동일한지 비교. 한 번에 모든 축을 바꾸지 말고 한 가지씩 줄여 가면 원인 추적이 빨라집니다. TUN과 DNS의 큰 그림은 TUN 심화와 연결해 읽으면 정리하기 쉽습니다.
⑧ 체크 6: 스니핑(sniffing)과 호스트 이름 복원
Clash Meta 계열에서 sniffer가 켜져 있으면, IP만 보이던 연결에 도메인 이름을 복원해 규칙을 다시 매칭합니다. 이때 복원된 이름이 실제 브라우저 SNI와 다르면, GEOIP가 아닌 다른 DOMAIN 규칙에 걸려 의도와 다른 출구가 될 수 있습니다. 국내 사이트 문제의 상당수는 스니핑과 무관하지만, 「특정 사이트만」이면 스니핑 끄기 A/B를 한 번 해볼 가치가 있습니다. 자세한 절차는 Clash Meta sniffing·분류 예외 글을 참고하세요.
⑨ IPv6·캐리어·위탁 CDN: GEOIP만으로는 부족한 경우
IPv6가 활성화된 환경에서는 IPv4와 다른 경로로 나가며, GEOIP 결과가 예상과 다를 수 있습니다. 또 글로벌 CDN 앞에 두는 중국 서비스는 도메인은 .cn이어도 IP가 해외로 잡혀 CN이 아닌 경우가 있습니다. 이럴 때는 GEOIP만 믿지 말고 DOMAIN-SUFFIX로 직접 연결을 명시하는 편이 현실적입니다. 반대로 해외 사용자에게 서비스하는 중국 앱은 프록시가 더 빠를 수도 있어, 「느리다」가 항상 직결이 정답은 아닙니다.
⑩ 한 줄 요약과 안전한 실험 습관
Clash에서 중국 본토 사이트가 느리거나 열리지 않을 때는, 대륙 우회·GEOIP CN·규칙 순서·분류·DNS를 한 축씩 확인하십시오. Rule 모드인지, GEOIP CN 줄이 있고 위치가 맞는지, RULE-SET이 먼저 프록시를 걸지 않는지, MATCH가 무엇을 향하는지, fake-ip·DoH와 맞물리지 않는지를 순서대로 점검하면 국내 직결 기대와 설정의 괴리를 빠르게 줄일 수 있습니다. 프로필을 수정할 때는 백업을 남기고, 가능하면 최소 변경으로 재현 여부를 확인하세요.
클라이언트 패키지 선택과 설치 경로는 릴리스 페이지만 쫓기보다 사이트의 다운로드 페이지를 따르는 편이 덜 헷갈립니다. 처음 개념을 잡으려면 Clash 입문 튜토리얼을 함께 보는 것도 좋습니다. 규칙 기반 클라이언트는 전역 VPN보다 관측 가능한 분기에 강점이 있으니, 로그와 함께 쓰면 장기적으로 시간이 아낍니다. → Clash를 무료로 내려받고, 대륙 우회·GEOIP CN·DNS를 단계적으로 맞춰 보세요.