Clash 연결됐는데 인터넷이 안 될 때: DNS 유출과 fake-ip 단계별 점검
트레이 아이콘은 정상이고 로그에도 흐름이 보이는데 브라우저만 멈춰 있을 때, 원인은 대개 DNS가 Clash 밖에서 끝나고 있거나, 규칙이 트래픽을 프록시로 보내지 않는 경우입니다. 이 글에서는 먼저 프록시·노드 자체를 확인하고, 이어서 DNS·fake-ip·nameserver, 마지막으로 규칙 우선순위와 브라우저 보안 DNS까지 같은 순서로 좁혀 가는 방법을 정리했습니다.
어떤 상황을 말하는가
클라이언트의 「연결됨」은 로컬에서 커널이 떠 있고 프로필이 로드됐으며 어떤 아웃바운드가 선택됐다는 뜻에 가깝습니다. 반드시 「모든 앱의 모든 도메인이 프록시를 경유한다」는 뜻은 아닙니다. 그래서 카카오톡·슬랙은 되는데 크롬만 실패하거나, 터미널 curl은 되고 브라우저만 DNS 오류를 내는 등 겉으로 모순된 증상이 자주 나옵니다.
아래 단계는 공통 목표가 있습니다. TCP로 노드까지는 가는지 먼저 분리하고, 그다음 도메인 해석과 규칙 매칭이 한 흐름으로 맞는지 확인한 뒤, 시스템·브라우저가 Clash를 우회하는 DNS 경로가 없는지 제거합니다.
권장 점검 순서
한 번에 하나씩
- 시스템 프록시 또는 TUN이 실제로 켜져 있고, 포트·PAC가 다른 프로그램과 충돌하지 않는지 본다.
- 로그와 글로벌 모드로 노드 불능인지, 규칙/DNS 문제인지 가른다.
- DNS가 여전히 ISP·공유기로 새는지(DNS 유출),
nameserver·fallback이 도달 가능한지 본다. fake-ip와redir-host중 무엇을 쓰는지, 스니퍼·규칙 유형과 맞물리는지 확인한다.- 규칙 목록 위에서 아래로, 그리고 마지막
MATCH가 어디로 보내는지 확인한다. - 크롬·엣지의 보안 DNS(DoH), 백신 HTTPS 검사, 「네트워크 최적화」류 유틸을 끄고 다시 시험한다.
1단계: 시스템 프록시·포트·TUN
Windows에서는 시스템 프록시만 켜 두면 일부 앱은 여전히 직접 나갑니다. 반대로 TUN을 쓰는데 회사 VPN이나 다른 가상 어댑터와 라우팅이 겹치면 전체가 끊긴 것처럼 보일 수 있습니다.
- HTTP(S) 프록시 포트: 보통
7890이지만 General 화면 표시를 기준으로 하세요. OS 설정의 주소가127.0.0.1인지 확인합니다. - 모드: 디버깅 시 잠시
Global로 두고 같은 사이트를 열어 보세요. 이때 정상이면 노드 전체 다운이 아니라 규칙 또는 DNS 쪽을 의심합니다. - TUN: 서비스 모드 설치·기동 여부, 동시에 켜 둔 유사 툴이 없는지 확인합니다.
팁
터미널에서 HTTPS_PROXY=http://127.0.0.1:7890 curl -I https://www.google.com처럼 프록시를 명시한 결과와 비교하면, OS가 프록시를 안 타는지·아웃바운드가 죽었는지 빠르게 갈립니다.
2단계: 노드와 로그로 「가짜 연결」 제거
설정 파일에 오류가 없다고 해서 노드가 살아 있는 것은 아닙니다. Logs 탭에서 실패하는 호스트를 보며 timeout, reset, i/o timeout이 반복되면 먼저 노드·회선을 바꾸고, 방화벽이 Clash 아웃바운드를 막지 않는지 봅니다.
- Proxies에서 지연 측정으로 죽은 노드를 피합니다.
- 글로벌 모드에서 동일 사이트를 다시 열어 봅니다.
- 특정 사이트만 Rule에서 막히는 패턴이면 5단계 규칙으로 돌아갑니다.
3단계: DNS 유출과 nameserver
DNS 유출이란 트래픽은 프록시를 타는 것처럼 보이는데, 질의는 여전히 통신사·공유기 DNS로 가 오염·오해석을 당하는 상태를 말합니다. Clash의 dns 블록이 있어도 OS·공유기·브라우저가 따로 DNS를 쓰면 증상이 갈라집니다.
enhanced-mode와 해석 방식
Meta 계열에서 흔히 enhanced-mode: fake-ip 또는 redir-host를 봅니다. 직관적으로는 다음과 같이 기억할 수 있습니다.
- fake-ip: 앱에는 가짜 IP를 주고 연결 시점에 도메인을 다시 매핑합니다. 분류·성능에 유리하지만 스니퍼·규칙 조합에 민감할 수 있습니다.
- redir-host: 실제 IP에 가깝게 해석해 흐름을 보기 쉽고, 호환성 이슈를 줄이는 데 도움이 될 때가 있습니다.
nameserver는 기본 재귀 질의용입니다. 민감 도메인만 다른 업스트림을 쓰고 싶다면 nameserver-policy를 함께 쓰는 편이 안전합니다. 예시는 환경에 맞게 고치세요.
dns:
enable: true
enhanced-mode: fake-ip
nameserver:
- 223.5.5.5
- 119.29.29.29
fallback:
- https://dns.google/dns-query
fallback-filter:
geoip: true
geoip-code: CN주의
fallback의 DoH/DoT가 현재 네트워크에서 막혀 있으면 해석이 길게 멈춰 「인터넷이 끊긴 것」처럼 보일 수 있습니다. 당장은 도달 가능한 DNS로 바꾸거나 테스트용으로 redir-host를 검토해 보세요.
4단계: fake-ip와 규칙·스니퍼
fake-ip를 쓸 때는 도메인 기반 규칙(DOMAIN, DOMAIN-SUFFIX 등)이 해석 단계와 잘 맞는 편입니다. IP만 보고 판단하는 규칙이 많은데 스니퍼가 꺼져 있거나 호스트명을 못 살리면 매칭이 어긋날 수 있습니다. 최근 sniffer 설정을 건드렸다면 그 전후를 비교해 보세요.
호환성 테스트로 enhanced-mode를 잠시 redir-host로 바꾼 뒤 리로드했을 때 증상이 사라지면, 노드 문제가 아니라 fake-ip·스니퍼·규칙 유형 조합을 집중 점검하면 됩니다.
5단계: 규칙 우선순위와 MATCH
Clash는 위에서 아래로 읽으며 처음 맞는 한 줄만 적용합니다. 그래서 아래쪽에 프록시 규칙이 있어도, 위에 DIRECT나 REJECT가 먼저 걸리면 그대로 따라갑니다. RULE-SET·GEOIP·프로세스 규칙이 의도치 않게 막고 있는지, 목록 맨 끝 MATCH가 DIRECT로 떨어지는 구조는 아닌지 꼭 확인하세요. 구독 기본값이 「해외는 규칙으로 덮고 나머지 DIRECT」인데 앞줄이 비어 있으면 해외 사이트가 전부 직행하다 막히는 패턴도 흔합니다.
암기용
「구체적 규칙을 위에, 포괄 규칙·MATCH는 아래에」. 한 번에 대량 수정하기보다 조각을 바꾸고 로그로 바로 검증하세요.
6단계: 브라우저 보안 DNS·제3자 툴
크롬·엣지의 보안 DNS, 파이어폭스 DoH, 백신의 HTTPS 검사, 일부 「웹 가속」 프로그램은 Clash가 기대하는 DNS 경로를 우회합니다. 로그에 해당 도메인 질의가 거의 안 찍히는데 브라우저만 오류를 낼 때 의심하세요.
- 브라우저에서 보안 DNS를 끄고 시스템 기본으로 둡니다.
- 백신·최적화 툴을 잠시 종료해 차이를 봅니다.
- 특정 브라우저만이면 확장 프로그램·새 프로필로 분리합니다.
7단계: IPv6·공유기 등 잡변수
일부 환경에서는 IPv6가 우선되어 규칙·노드 밖으로 새는 경우가 있습니다. OS에서 IPv6를 잠시 끄고 테스트해 볼 수 있습니다. 특정 Wi-Fi에서만 안 되면 공유기 DNS 가드·유해차단 기능도 점검합니다.
자주 묻는 질문
글로벌은 되는데 룰 모드만 안 됩니다
아웃바운드는 살아 있고 규칙 매칭 또는 DNS 정보 불일치를 의심합니다. 로그에서 해당 호스트가 어떤 규칙에 걸렸는지 확인하고 5단계에서 순서를 조정하세요.
유튜브만 안 됩니다
규칙 외에 데이터센터 IP 차단도 있습니다. 글로벌에서도 실패하면 노드·지역을 바꾸는 편이 먼저입니다.
TLS·인증서 관련 로그가 보입니다
시간 동기화, 회사 SSL 가로채기, 중간자 검사를 의심합니다. 다른 네트워크에서 재현 여부를 보세요.
정리
- 프록시/TUN·포트를 확인하고 글로벌 모드로 노드 문제를 가른다.
- DNS 유출·
nameserver·fallback도달성을 본다. - fake-ip와 스니퍼·규칙 유형의 관계를 이해하고 필요 시 redir-host로 비교 테스트한다.
- 규칙은 위에서 아래로, 특히
MATCH의 행선지를 확인한다. - 브라우저 DoH와 우회 가능한 보안 소프트웨어를 끄고 다시 시험한다.
YAML을 최소한으로 건드리고 싶다면 다운로드 페이지에서 기본 DNS·분류가 정리된 빌드를 함께 보셔도 좋습니다.