1 왜 «출국용 프록시」만으론 부족한가
일반적인 구독 프로필은 «차단된 해외 사이트를 프록시로」 보내도록 짜여 있습니다. 그런데 한국·일본·미국 등에 거주하면서 소홍서·RedNote처럼 대륙 데이터센터와 전용 도메인에 강하게 묶인 앱을 쓰면, API·이미지·짧은 동영상 일부가 실제 사용자 위치와 다른 출구 IP로 보입니다. 그 결과 (1) 캐시·CDN이 멀어 버퍼링이 늘고, (2) 리스크 모델이 로그인·본인확인·기기 바인딩 단계에서 경고를 내거나, (3) 결제·푸시·서드파티 SDK 호출이 타임아웃처럼 보이기도 합니다.
해결의 중심은 «전부 프록시」가 아니라 대륙으로 가야 할 트래픽은 ISP 회선으로 그대로, «정말 필요한 해외만 노드»라는 해외 사용자 관점의 귀국 분할(중국 직결)입니다. 즉 GEOIP로 중국 대륙 IP 대역을 잡고, 보조적으로 RULE-SET으로 알려진 국내 상용 접미사를 DIRECT에 올려 두는 패턴입니다. 이렇게 하면 미국 쇼핑·OTT용 규칙과도 역할이 겹치지 않고, 독자가 원하는 장면만 분리해 유지보수할 수 있습니다.
2 프록시 오분류 때 흔한 증상
- 피드는 되는데 상세·댓글이 자주 실패 — 일부 호스트만 다른 리전으로 나가는 경우.
- 첫 화면은 빠른데 이미지·동영상만 느림 — CDN 호스트가 프록시 경유로 멀어짐.
- SMS·OTP·본인확인이 반복 — 출구 IP·DNS 응답이 앱 기대와 어긋남(반드시 서비스 정책·약관을 따르세요).
- Wi‑Fi에선 괜찮고 LTE만 이상 — 캐리어 DNS·IPv6 경로가 Clash 밖으로 새는 경우와 겹침.
3 규칙 순서: DIRECT를 먼저 올린다
Clash 계열에서 rules: 리스트는 위에서 아래로 첫 매칭이 승리합니다. MATCH나 «나머지 전부 프록시」가 너무 위에 있으면, 아래에 아무리 GEOIP, CN을 넣어도 도달하지 못합니다. 따라서 (1) LAN·로컬호스트·RFC1918, (2) 중국 도메인 RULE-SET(사용 중인 카탈로그 기준), (3) GEOIP, CN, DIRECT, (4) 필요 시 특정 해외 DOMAIN·RULE-SET, (5) 마지막 MATCH 순이 안전한 출발점입니다. 프로필 작성자가 이미 GEOIP, CN, DIRECT를 넣어 두었다면, 그 줄이 실제로 프록시 줄보다 위에 있는지 로그로 한 번만 확인하세요.
rule-providers를 쓸 때는 behavior(domain·classical 등)과 갱신 주기를 Mihomo 문서에 맞게 두고, 오래된 로컬 캐시만 믿지 말고 GeoIP·목록 수동 갱신 절차를 연 1~2회라도 습관화하면 오분류가 줄어듭니다.
4 GEOIP로 중국 대륙 IP를 직결로
GEOIP, CN, DIRECT 한 줄은 «해석된 목적지 IP가 중국 대륙 데이터베이스에 속하면 로컬 회선으로 보낸다»는 뜻입니다. 전제는 (1) 도메인이 신뢰할 만한 DNS로 실제 대륙 IP로 풀리는 것, (2) 스니퍼가 HTTPS에서 목적지를 제때 알 수 있는 것 — 두 가지입니다. 데이터베이스는 mmdb 종류·버전에 따라 경계가 조금씩 다르므로, 이상 징후가 있을 때는 카탈로그와 geoip 파일 날짜를 함께 봅니다.
GEOIP, CN이 반드시 같은 바구니에 담기지는 않습니다. 앱이 실제로 어느 리전 IP를 쓰는지 로그와 nslookup으로 확인하고, 필요하면 별도 IP-CIDR·GEOIP 줄을 추가하세요.
5 RULE-SET: 도메인 묶음으로 «미끄러짐」 방지
IP만으로는 부족할 때가 있습니다. 예를 들어 글로벌 CDN 앞단 이름이 여러 리전을 오가거나, 앱이 첫 요청에서 아직 IP가 확정되지 않은 경우입니다. 이때 구독이나 커뮤니티에서 제공하는 중국 직통·국내 상용 목록을 RULE-SET으로 넣어 DIRECT에 매핑하면, 이름 단계에서 먼저 직결을 고정할 수 있습니다. 키워드는 rule-providers 정의와 rules의 RULE-SET, 프로바이더명, DIRECT 연결입니다. 출처가 불분명한 규칙 파일은 검토 후 쓰고, 민감한 환경에서는 직접 작은 DOMAIN-SUFFIX 묶음만 유지하는 편이 낫습니다.
소홍서·RedNote가 내부적으로 쓰는 호스트 이름은 공개 문서가 거의 없으므로, 이 글에서는 구체 도메인 나열 대신 자신의 로그에서 반복되는 접미사를 수집해 개인 RULE-SET에 넣는 방법을 권합니다. Mihomo 대시보드나 코어 로그의 policy hit 한 줄을 복사해 두면 다음 주 갱신 때 규칙이 쌓입니다.
6 DNS·FakeIP가 규칙을 망가뜨릴 때
fake-ip 모드를 쓰면 앱이 보는 IP와 실제 직결·프록시 결정에 쓰는 IP가 어긋날 수 있습니다. 브라우저 보안 DNS가 OS 스텁을 건너뛰면 더욱 그렇습니다. 중국 트래픽을 DIRECT로 보내려면, 해당 이름이 Clash dns 섹션에서 기대한 체인으로 풀리는지 확인해야 합니다. nameserver-policy로 특정 접미사만 대륙 쪽 공용 리졸버로 보내는 식의 스플릿도 가능하지만, 프라이버시·신뢰도는 본인 책임으로 선택하세요.
자세한 체인 설계는 Meta DNS·FakeIP 유출 방지와, 데스크톱 브라우저 조합은 Chrome·Edge 보안 DNS 글을 함께 보는 것이 좋습니다. 모바일 전용 DNS는 안드로이드 Private DNS와 Clash 글의 순서와 겹칩니다.
7 HTTPS SNI와 스니퍼(sniffer)
TLS가 잡히기 전에는 도메인 규칙이 비어 있는 것처럼 보일 수 있습니다. Mihomo의 sniffer가 켜져 있으면 SNI로 도메인을 복원해 규칙 매칭 순서를 안정시킬 수 있지만, 과도한 스니핑은 오히려 다른 앱과 충돌할 수 있으므로 문서 권장 범위 안에서 켭니다. 동작 원리와 트레이드오프는 HTTPS SNI 스니퍼 글의 표를 참고하세요.
8 최소 스케치(이름은 예시)
아래는 개념용입니다. provider-cn-domains URL·경로는 본인 환경의 안전한 규칙 소스로 바꾸고, 코어 버전에 맞는 키만 남기세요.
# rule-providers (example keys — replace URL with your trusted source)
rule-providers:
cn-domains:
type: http
behavior: domain
url: "https://example.invalid/rules/cn-domain.yaml"
path: ./ruleset/cn-domain.yaml
interval: 86400
rules:
- DOMAIN-SUFFIX,local,DIRECT
- IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
- IP-CIDR,10.0.0.0/8,DIRECT,no-resolve
- RULE-SET,cn-domains,DIRECT
- GEOIP,CN,DIRECT
- MATCH,PROXY
no-resolve가 붙은 IP 규칙은 DNS 우회 없이 패킷 단계에서만 맞추므로, 순서와 함께 문서를 읽고 배치하세요. 실서비스에서는 앱별로 IPv6 경로가 켜져 있으면 별도 IP-CIDR6도 검토합니다.
9 현장 체크리스트
GEOIP, CN, DIRECT가 최종MATCH, PROXY보다 위에 있는가- 중국 전용 RULE-SET이 최신인가(파일 mtime·interval)
- DNS가 FakeIP·브라우저 DoH와 충돌하지 않는지 보고, 필요하면 스플릿 정책을 둔다
- 문제 재현 시 코어 로그에서 해당 흐름이 DIRECT로 찍히는가
- 홍콩·싱가포르 등 「가까운」 회선만 쓰는 호스트는 별도 규칙이 필요한가
- 모바일은 Private DNS / IPv6 / 앱 전용 네트워크 보안 정책을 함께 볼 것
10 정리
RedNote와 소홍서 붐은 2025–2026에도 이어지며, 해외 사용자 입장에선 귀국 직결 분할이 일상 설정과 직결됩니다. GEOIP와 RULE-SET으로 대륙 트래픽을 DIRECT에 두고, DNS·스니퍼·규칙 순서까지 한 세트로 맞추면 체감 지연과 검증 단계 이슈를 많이 줄일 수 있습니다. 클라이언트는 프로필·로그 관리가 쉬운 Clash Verge Rev 계열이 유지보수에 유리하고, 설치는 사이트 허브의 패키지를 우선하는 편이 출처 정리에 낫습니다.
→ 중국 직결·해외 분할을 한 프로필에서 다시 짜 보려면 Clash를 무료로 받아 보세요 — 실행 파일은 다운로드 페이지를 먼저 이용하고, GitHub는 릴리스 노트·이슈 확인용으로 두면 버전 관리가 수월합니다.
