중국 본토 사이트가 프록시로 새면 느립니다: Clash GEOIP CN·DIRECT·MATCH 순서와 DNS·fake-ip로 잡기 (2026)

어떤 증상부터 의심하나요?

mode: rule로 두었고 구독 프로필에도 ‘국내 직결’, ‘GEOIP,CN,DIRECT’ 같은 문구가 보이는데도, 브라우저나 앱에서 중국 본토(대륙) 웹 서비스가 기대보다 지연되고, 속도 테스트나 트레이스가 해외 우회처럼 동작합니다. 간혹 본토 전용 페이지가 차단 페이지로 바뀌거나, CDN이 해외 에지로만 붙는 식으로 이상해집니다.

이 글에서는 그 원인을 “규칙이 없어서”보다는 있는 줄이 순서 때문에 먼저 패배했거나, DNS·fake-ip 때문에 IP 기반 규칙이 헛돌거나, MATCH까지 내려가면서 전부 프록시로 간 경우에 초점을 맞춥니다. 개념 전체를 처음 읽는 분은 규칙 분할 완전 가이드를 함께 보시면 문맥이 이어집니다.

준수: 네트워크 관리 규정·서비스 약관·거주 지역 및 방문 지역 법령을 지키는 범위에서만 프록시·분할 규칙을 사용해야 합니다. 회사 또는 학교망에서 허용되지 않은 구성이라면 적용해서는 안 됩니다.

MATCH와 ‘첫 일치’를 다시 짚기

Clash 계열(Mihomo 등)에서는 규칙 배열 위에서 한 줄만 통과하면 그 아래는 보지 않습니다. 그래서 목록 안쪽에 아무리 GEOIP,CN,DIRECT를 두었어도, 그 보다 위 줄에서 이미 특정 게시판처럼 넓게 Proxy나 GLOBAL 그룹에 붙어버리면 본토 IP도 우회 노드를 탑니다. 반대로 DIRECT를 과하게 위에 깔아 두면 예외 처리하려던 해외 전용 호스트까지 직결로 떨어져 다른 문제가 나기도 합니다.

MATCH 한 줄은 “여기까지 온 모든 나머지”에 대한 최종 폴백입니다. 흔히 맨 마지막에 MATCH,프록시그룹명처럼 씁니다. 본토를 직결로 두려면 반드시 MATCH 바로 위·혹은 그보다 훨씬 위 어딘가에서 중국 라우팅이 잡히게 해야 합니다. GEOIP 줄이 존재하는데도 효력이 없다면 거의 항상 더 위 줄이 선수를 친 것이거나, 해당 줄이 IP를 못 받아 매칭에 실패한 경우입니다.

GEOIP CN을 어디에 둘까요?

중국 사용자 커뮤니티에서 자주 등장하는 패턴인 GEOIP,cn,DIRECT(대소문자는 템플릿에 따라 다름)은 “목적지 IP가 GeoIP DB상 중국이라면 직결”이라는 뜻입니다. 다만 많은 무료 rule-set에는 글로벌 대형 사이트, 광고, 외부 제공 RULE-SET 줄이 매우 많고, 그중 일부가 GEOIP,CN,DIRECT 보다 위에서 이미 해당 도메인을 프록시로 보낼 수 있습니다. 그 경우 지연은 줄어들지 않습니다.

정리하면, 본토 우선 직결을 원한다면 (1) 사설망·로컬·LAN 예외처럼 절대 흔들리면 안 되는 블록, (2) 정말로 프록시를 타야 하는 도메인·RULE-SET, (3) 그 다음에 GEOIP CN → DIRECT, (4) 마지막 MATCH 순서가 자연스럽습니다. 구독이 한 덩어리로 RULE-SET을 위에 깔아 두었다면 그 안의 순서까지 펼쳐져 있다고 가정해야 합니다.

로그로 ‘어느 줄에 걸렸는지’부터 보기

대부분의 GUI나 대시보드에는 연결별로 규칙 이름·정책이 찍히는 디버그 로그가 있습니다. 느린 본토 사이트를 하나 골라 재현한 뒤, 같은 순간의 항목이 어떤 RULE-SET / DOMAIN / GEOIP 줄을 가리키는지 확인하세요. 기대했던 ‘GEOIP-CN 직결’이 아니라면 순서 조정 또는 해당 RULE-SET의 예외 블록이 필요합니다.

로그상 호스트명이 비어 있고 IP만 있는 경우가 있다면 다음 절에서 다룰 DNS 해석 경로를 의심합니다. 브라우저만 다른 경로를 쓰고 있다면 브라우저만 우회하기 글과 응용 설정이 동시에 검토됩니다.

DNS·fake-ip가 규칙을 망치는 경우

dns.enhanced-mode: fake-ip를 켜 두면 많은 클라이언트에서 도메인 요청 처리 방식이 달라져, 어떤 흐름에서는 규칙 엔진이 목적지 IP를 규칙 매칭용으로 받기 전에 연결이 시작됩니다. 특히 도메인이 아니라 이미 해석된 IP로만 들어오는 연결에서는 DOMAIN-SUFFIX류가 회피되고 GEOIP·IP-CIDR 단계까지 내려가는데, 이때 의도와 다른 IP 해석 결과가 나오면 곧바로 잘못된 GEOIP 결과나 MATCH까지 밀립니다.

개선 패턴으로는 다음이 많이 씁니다. 특정 CDN·금융·사내 포털처럼 민감한 목록은 fake-ip-filter(또는 문서 명칭의 동등 설정) 안에 두어 해당 호스트만 실제 레코드를 쓰게 하거나, GEOIP 줄에 no-resolve(지원 버전 및 문법 준수)를 붙여 DNS가 명확해진 뒤 IP 판정을 하게 하는 방식입니다. 정확한 키 이름은 사용 중인 커널·클라이언트 버전 매뉴얼과 맞추는 것이 안전합니다.

nameserver·fallback·nameserver-policy가 모두 우회 노드 안쪽 DNS를 바라보고 있으면, 본토용 질의까지 해외 레지스트리로 새어 나가 돌아오는 IP가 원치 않는 에지일 수 있습니다. “분할은 맞는데 체감만 이상할 때”에는 DNS 유출 여부를 한 줄씩 줄여 검증하는 접근이 효과적입니다. TUN·시스템 DNS와의 결합은 TUN 모드 가이드와 같이 보는 편이 좋습니다.

스트리밍용 스니퍼(Sniffer)와의 구분

TLS나 HTTP 헤더를 다시 읽어 도메인 규칙을 살리는 스니퍼 기능은 규칙 우선순위 문제와 증상이 비슷해 보일 수 있지만 원인층은 다릅니다. 호스트 이름이 노드 구간까지 가려져 있던 흐름을 회복하고 싶다면 Mihomo 스니퍼 안내를 참고하고, 본 글에서는 “로그에는 이미 올바른 도메인이 보이는데도 GEOIP 줄 앞 다른 줄이 걸린다” 같은 순서 문제에 집중합니다.

GEOIP 데이터·문법 오타 점검

존재하지 않는 국가 코드를 썼거나 로컬 mmdb 파일이 깨져 있으면 해당 GEOIP 줄이 전부 무의미해집니다. 구독이 geoip: 섹션에서 외부 URL을 받도록 되어 있는지, 클라이언트 업데이트 후 경로가 달라지지 않았는지 확인하세요. ‘cn’ 표기 자체가 지역 정책 문서에서는 ‘CN’처럼 대문자로 통일되어야 하는 빌드도 있습니다.

주의: 신뢰할 수 없는 출처에서 받은 규칙 세트에는 악성·과도하게 넓은 DOMAIN 규칙이 섞일 수 있습니다. 인지된 레포지토리와 체크섬 검증 가능한 제공자를 사용하세요.

패턴 참고용 rules: 축약 예시

아래는 개념을 잡기 위한 순서 예시이며, 프록시 그룹 이름·RULE-SET URL·항목 순서는 본인 구독과 실제 로그 결과에 맞게 바꿔야 합니다. 직결을 강하게 고정하고 싶은 본토 서비스는 DOMAIN-SUFFIX 명시 한두 줄을 추가하는 편이 안정적입니다.

YAMLrules:
  # Local / RFC1918 예시 블록
  - DOMAIN-SUFFIX,local,DIRECT
  - IP-CIDR,127.0.0.0/8,DIRECT,no-resolve
  - IP-CIDR,10.0.0.0/8,DIRECT,no-resolve

  # Must-proxy exceptions (narrow rules / RULE-SET) — above GEOIP CN
  - DOMAIN-SUFFIX,video-site-you-need-proxy-for.example,Proxy

  # China mainland IPs → DIRECT
  - GEOIP,cn,DIRECT

  # Final fallback — often proxy if not mainland
  - MATCH,Proxy

실제 설정에서는 차단 목록·광고·스트리밍 전용 RULE-SET이 매우 많이 끼어 들어 가므로, 위 축약도를 받아 적기보다 로그 한 줄 단위로 끌어 올리기가 더 빠릅니다.

현장 체크리스트

  1. rule 모드와 실제 활성 프로필이 동일 파일인지(프로필 전환 미적용 포함) 확인한다.
  2. 느린 대상만 재현했을 때 로그의 매칭 규칙 이름이 무엇인지 적는다.
  3. 매칭이 MATCH 쪽이라면 위쪽에 존재하는 광역 RULE-SET·DOMAIN을 줄인다.
  4. GEOIP,cn,DIRECT가 존재해도 안 먹는다면 목적지 IP가 정말 CN으로 분류되는지, fake-ip 때문에 막혔는지 본다.
  5. 중요 본토 서비스는 GEOIP 단독에 맡기지 않고 DOMAIN-SUFFIX 예외까지 둔다.

정리하며

중국 본토 같은 ‘가까워야 하는’ 트래픽마저 프록시를 타면 지연만 늘고 운영자 입장에서는 설정이 망가진 느낌이 큽니다. 다만 원인 대부분은 단순합니다. 규칙 엔진이 맨 처음 참이 된 한 줄만 존중한다는 성질, MATCH까지 밀린 뒤의 일괄 정책, 그리고 DNS·fake-ip 때문에 IP 검사 줄이 헛바퀴돌 때가 많습니다.

같은 맥락의 일반 규칙 설계 전체를 익히려면 역시 규칙 분할 장문 가이드를 권하지만, 이 글이 말하는 ‘누설·속도 깨짐’ 디버깅은 로그 순서 검증이라는 하나의 레버로 많이 줄어듭니다. 여러 상용 우회 클라이언트와 비교해 보면 Clash 생태계는 RULE-SET·YAML을 직접 만질 여지가 남아 있어 원인 규명이 오히려 수월할 때가 많습니다.

아직 테스트할 클라이언트가 없다면 → Clash 클라이언트를 무료로 내려받아 rule 모드를 켠 뒤, 대시보드 로그 한 줄부터 위 체크리스트대로 맞춰 보시길 바랍니다.