이 증상, 지금 글의 범위인가요?

Clash·Mihomo 계열 클라이언트에서 프록시는 켜졌고 지연 측정도 대체로 통과하는데, 일부 사이트만 탭이 하얗게 남거나 원형 로딩만 돌다 끊기는 경우가 있습니다. 반대로 YouTube·GitHub 등은 되는데 특정 은행·쇼핑몰·사내 포털만 안 되기도 하고, HTTP는 되는데 HTTPS만 느리기도 합니다. 이런 “부분적 접속 실패”는 단순히 노드 하나를 바꾼다고 해결되지 않을 때가 많고, 이름 해석 경로(DNS)와 연결 직전의 호스트 정보 처리가 어긋난 패턴이 자주 등장합니다.

본문은 기술적 동작 설명과 설정 점검 순서에 한정하며, 관할 법규와 조직 정책은 사용자가 직접 확인해야 합니다. 전체 연결이 아예 안 되거나 로그에 포트 점유·dial tcp 실패가 줄을 잇는다면, 우선 로그로 포트와 노드를 가르는 글과 짝을 이뤄 보는 편이 빠릅니다.

Fake-IP와 Redir-Host, 한 줄로 무엇이 다른가

Mihomo(Clash Meta) 문맥에서 말하는 enhanced-mode의 두 축은 대개 다음과 같이 기억하면 실무에서 덜 헷갈립니다.

  • Fake-IP: 애플리케이션이 도메인을 물으면, 코어가 가짜 사설 대역(예: 198.18.0.0/16)의 주소를 먼저 돌려줍니다. 실제 TCP 연결을 맺을 때 코어가 다시 이름·IP를 맞추고 규칙에 맞는 출구로 보냅니다. 규칙 매칭이 빨라지고 지역별 분류와 잘 맞지만, 일부 앱·게임·구형 TLS 스택은 “가짜 IP”를 이상하게 다루다 멈출 수 있습니다.
  • Redir-Host: 흐름이 실제 DNS 응답에 더 가깝게 붙습니다. 어떤 리졸버가 질의를 대신하느냐, 응답이 오염·차단되지 않았느냐가 그대로 체감 품질에 반영됩니다. 호환성 면에서는 유리한 경우가 있으나, nameserver·폴백·프록시 경유 DNS를 잘못 묶으면 “프록시는 타는데 이름만 엉뚱한 곳으로 간다”는 증상이 나올 수 있습니다.

둘 중 “정답”이 있는 것이 아니라, 지금 쓰는 앱·브라우저·TUN 여부·구독 규칙 밀도에 맞는 쪽을 고르는 문제에 가깝습니다. DNS가 새는 문제와의 관계는 DNS 유출 방지 가이드에서 넓게 다루었으니, 이 글에서는 “안 열림” 쪽 트리에 집중합니다.

고장 트리: 먼저 로그로 가지를 친다

설정을 줄줄이 바꾸기 전에, 아래 순서로 한 번에 한 축만 움직이는 습관이 중요합니다.

  1. 재현: 문제 사이트 하나를 고정하고, 시크릿 창·다른 브라우저·터미널 curl -v로 동일 증상인지 확인합니다. 캐시·확장 프로그램을 배제하면 “Clash만의 문제”인지 좁혀집니다.
  2. DNS 로그: 코어 로그에서 해당 호스트에 대한 해석·캐시·폴백 메시지를 봅니다. 질의가 Clash 내부 DNS로 들어오는지, 시스템 리졸버로 새는지가 갈립니다.
  3. 연결 로그: match된 정책 그룹, 체인 끝의 노드, TLS 핸드셰이크 직전 오류가 있는지 봅니다. 여기서 이미 타임아웃이면 DNS 다음 단계가 아니라 회선·SNI·방화벽 쪽을 의심합니다.

로그 문구가 읽히기 시작하면, 아래 분기로 들어가면 됩니다.

분기 A: HTTPS·HTTP/3만 이상할 때 — 스니퍼(sniffer) 의심

일부 빌드·프로필에서는 TLS나 QUIC에서 호스트 이름을 다시 읽어 규칙을 보강하는 스니퍼 기능이 켜져 있습니다. 정상일 때는 도메인 기반 분류를 돕지만, 구현·지문·중간 장비와 맞물리면 특정 사이트만 간헐적 실패로 나타나기도 합니다.

실무에서는 다음 순서를 권합니다.

  1. 문제가 난 사이트를 열어 본 상태에서 스니퍼 관련 옵션을 끄거나 최소화하고 프로필을 다시 불러옵니다.
  2. 동일 시나리오를 반복해 증상이 사라지면, 스니퍼와 겹치는 규칙(PROCESS·DOMAIN-SUFFIX 순서 등)을 점검합니다.
  3. 끄면 분류 정확도가 떨어진다면, “항상 켬” 대신 필요한 스니프 대상만 남기는 쪽으로 조정합니다. GUI마다 스위치 이름이 다르므로 사용 중인 클라이언트 문서를 기준으로 하세요.

스니퍼를 끈 뒤에도 같은 호스트에서 TLS 경고만 반복된다면, 이번에는 DNS 모드나 규칙 쪽으로 넘어갑니다.

분기 B: Fake-IP에서만 깨질 때 — 필터와 예외

Fake-IP를 쓰는 환경에서 흔한 패턴은 다음과 같습니다.

  • 스트리밍·뱅킹·일부 CDN이 클라이언트가 받은 IP와 실제 연결 출구 IP의 불일치를 민감하게 다루는 경우
  • 앱이 DNS 응답을 캐시한 뒤, 코어의 재해석 타이밍과 어긋나 잘못된 조각으로 이어지는 경우
  • fake-ip-filter(또는 동등 옵션)에 넣어야 할 로컬·LAN·특정 도메인이 빠져 있는 경우

조치 순서 제안은 이렇습니다.

  1. 문제 도메인을 fake-ip-filter 후보에 올려 실제 IP 해석 경로를 타게 해 봅니다.
  2. 그래도 불안정하면, 테스트 프로필에서만 enhanced-mode를 redir-host로 바꿔 동일 사이트를 비교합니다. 한쪽에서만 나아지면 원인 축이 DNS 모드 쪽으로 거의 확정됩니다.
  3. 규칙 파일에서 해당 DOMAIN이 더 아래에 묻혀 DIRECT로 떨어지거나 반대로 의도와 다른 그룹으로 붙는지 확인합니다. 구독 규칙이 길수록 순서가 생명입니다. 구조를 정리하는 방법은 Rule Provider 가이드를 참고하세요.

분기 C: Redir-Host에서만 느리거나 열리지 않을 때

Redir-Host는 “실제로 어떤 DNS가 답했는가”가 그대로 노출됩니다. 다음을 순서대로 봅니다.

  1. nameserver와 fallback 풀이 지연·오염·지역 차단 없이 기대한 경로로 나가는지, 로그와 외부 DNS 테스트로 확인합니다.
  2. 민감한 질의를 프록시 경유 DoH 등으로 보내야 한다면, 문법이 코어 버전과 맞는지·실제 패킷이 우회하는지 확인합니다. “설정만 되어 있고 트래픽은 ISP로 간다”는 패턴이 여기서 자주 나옵니다.
  3. 브라우저 보안 DNS(HTTPS DNS)가 켜져 있으면 Clash 밖에서 이름이 끝나 규칙과 어긋날 수 있으니, 비교 시에는 끄고 재현해 봅니다.

IPv6가 활성인데 터널·규칙은 IPv4 위주면 AAAA 관련 이상 증상이 섞일 수 있습니다. 유출·이중 스택 이슈는 DNS 가이드의 IPv6 절과 함께 보는 것이 안전합니다.

모드 전환을 안전하게 하는 방법

Fake-IP ↔ Redir-Host 전환은 체감이 크게 달라질 수 있으므로, 백업한 단일 프로필 사본에서 먼저 시험하세요. 전환 후에는 다음을 꼭 확인합니다.

  • OS·클라이언트가 가리키는 DNS IP·포트가 코어의 dns.listen과 일치하는지
  • TUN·시스템 프록시를 켠 상태에서 UDP 53 하이재킹이나 라우팅 예외가 과하게 잡혀 LAN·사내 이름이 깨지지 않는지
  • 전환 직후 브라우저 DNS 캐시를 비우거나, 재시작 후 동일 사이트를 다시 연다

지연과 응답성은 DNS 모드와도 연결됩니다. 트레이드오프를 숫자로 보고 싶다면 속도 최적화 팁과 병행해 측정해 보세요.

규칙만으로 안 될 때 체크할 것

DNS 모드와 스니퍼를 손봐도 특정 호스트만 남으면, 규칙 엔진 쪽을 이렇게 의심합니다.

  • DOMAIN-KEYWORD가 의도보다 넓게 잡혀 다른 정책으로 빨려 들어간 경우
  • GEOIP·IPCIDR이 Fake-IP 대역과 충돌하거나 순서상 먼저 매칭되는 경우
  • 프로세스 규칙이 특정 브라우저만 다른 그룹으로 보내는 경우

한 번에 여러 줄을 고치기보다, 문제 호스트 하나에 대해 임시로 최상단에 명시 DOMAIN 규칙을 두고 매칭 로그를 확인하는 방식이 디버깅 비용을 줄여 줍니다.

정리: 선택은 “모드 하나”가 아니라 “증상 한 줄”에서 시작

부분적 웹 접속 실패는 원인이 한 가지로 떨어지지 않지만, 로그로 스니퍼·DNS 모드·규칙 순서 세 축을 나누면 대부분의 경우 빠르게 수렴합니다. Fake-IP는 속도와 규칙 매칭에 유리한 대신 앱 호환과 필터 관리 부담이 있고, Redir-Host는 투명하지만 upstream DNS 품질에 더 민감합니다. 오늘 증상이 스니퍼를 끄면 사라지는지, Redir-Host로만 나아지는지, fake-ip-filter 한 줄로 해결되는지부터 기록해 두면 다음번 유사 이슈에서 시간을 크게 아낄 수 있습니다.

기억할 점: 모드 전환 후 “이상해졌다”면 즉시 백업 프로필로 되돌리고, 한 옵션씩만 바꿔 재현 조건을 고정하세요.

규칙형 클라이언트는 GUI·코어·구독이 함께 움직이므로, 버전 메모를 남겨 두면 동일 증상이 재등장했을 때 비교가 쉽습니다. 처음 설정 흐름은 Clash 사용 문서에서 익힌 뒤, 이 글의 DNS·스니퍼 축을 덧붙이면 구조 이해가 한층 빨라집니다.

오픈 소스 코어의 변경과 이슈는 Mihomo GitHub 저장소에서 확인할 수 있습니다. 클라이언트 설치 패키지는 서명·배포 관점에서 공식 다운로드 페이지를 우선하는 편이 안전합니다.

같은 증상이라도 Windows TUN·macOS 확장·DNS 하이재킹 조합에 따라 표면 현상이 달라질 수 있습니다. 플랫폼별로는 Windows TUN 점검·macOS 확장·구독 글과 짝을 이루면 전체 그림이 잡힙니다.

→ Clash를 무료로 내려받아 DNS 모드·규칙·구독을 한곳에서 정리해 보세요