1 DNS 유출이 생기는 이유
많은 사용자가 «프록시만 켜면 안전하다»고 가정하지만, 애플리케이션은 연결 전에 도메인 이름을 IP로 바꾸는 단계를 거칩니다. 이 질의가 운영체제 기본 리졸버나 라우터의 DNS로 그대로 나가면, 암호화된 HTTPS 페이로드는 보이지 않아도 어떤 호스트를 조회했는지는 로그에 남을 수 있습니다. 브라우저 확장 프록시는 종종 HTTP 레이어만 가리고 DNS는 OS에 맡기기 때문에, 체감상 «잘 되는데 유출 테스트에서만 실패»하는 패턴이 자주 나옵니다.
Clash Meta(Mihomo) 계열은 이 문제를 dns 섹션으로 한 번에 다룹니다. 핵심은 앱이 보는 해석 경로와 규칙 엔진이 보는 도메인 정보를 맞추는 것입니다. 전역 TUN으로 트래픽을 모으는 구성은 Clash Verge Rev TUN 가이드와 같이 읽으면 OS별 예외 처리까지 일관되게 잡기 쉽습니다.
2 Mihomo DNS 파이프라인을 한 줄로 이해하기
Mihomo에서 dns.enable: true를 켜면 코어는 지정한 listen 주소에서 DNS를 받거나, TUN·시스템 훅과 결합해 트래픽과 같은 경로로 질의를 끌어옵니다. 이후 nameserver 목록의 서버로 실제 해석을 시도하고, 조건에 따라 fallback 체인으로 넘깁니다. Rule 모드에서는 도메인 기반 규칙이 먼저 평가되므로, DNS가 OS 쪽에서 먼저 끝나 버리면 «규칙은 A인데 실제 연결은 B로 간다»는 불일치가 생깁니다.
서버나 헤드리스 환경에서 코어만 돌릴 때는 Linux Mihomo·systemd 가이드의 기본 템플릿을 출발점으로 삼고, 아래 절에서 설명하는 DoH·FakeIP 옵션을 덧입히면 됩니다. GUI 클라이언트는 동일한 키를 프로필 편집기에 쓰면 되므로 개념은 같습니다.
3 FakeIP: 왜 쓰고, 무엇을 포기하는가
enhanced-mode: fake-ip(또는 구 설정의 동등 옵션)을 켜면, 코어는 애플리케이션에 fake-ip-range 안의 가짜 주소를 돌려주고 실제 IP는 내부에서만 알고 있습니다. 이렇게 하면 규칙 매칭 시점에 도메인 정보가 유지되어 지역별·키워드별 분기가 안정적입니다. 반대로 앱이 직접 받은 «진짜 IP」로 연결을 열어 버리면, 프록시가 개입하기 전에 이미 경로가 고정되는 경우가 있습니다.
FakeIP는 만능이 아닙니다. fake-ip-filter에 넣은 도메인·접미사는 필터를 타지 않고 일반 해석을 하므로, LAN 이름(*.local), 스트리밍 CDN, 일부 STUN/VoIP 호스트는 여기서 예외로 빼는 경우가 많습니다. 필터를 과하게 넓히면 «가짜 IP의 이점」이 줄고, 너무 좁히면 특정 앱만 끊기는 현상이 남습니다. 운영자는 자신의 규칙 세트와 충돌하는 도메인을 로그로 모아 점진적으로 조정하는 편이 안전합니다.
nameserver-policy를 의심하세요.
4 DoH·DoT와 upstream 체인 설계
평문 UDP DNS는 마지막 홉에서 스니핑되기 쉽습니다. Mihomo는 https:// 스킴의 DNS-over-HTTPS와 tls://의 DNS-over-TLS를 같은 목록에 섞어 쓸 수 있습니다. 실무에서는 nameserver에 지연과 신뢰도가 검증된 공인 리졸버를 두고, 검열이나 오탐이 의심될 때만 타는 fallback에 더 느리지만 관통력 있는 서버를 배치하는 패턴이 흔합니다.
fallback-filter의 geoip·ipcidr 조건은 «이 응답은 신뢰할 수 없다»고 판단될 때 자동으로 보조 서버로 넘기게 해 줍니다. 예를 들어 특정 국가의 가짜 응답이나 블랙홀 대역을 걸러 내려는 식입니다. 다만 필터가 과하면 정상 응답까지 fallback으로 밀려 지연만 커지는 경우도 있으니, 로그의 DNS 단계 시간을 보며 조절해야 합니다.
차단망에서는
DoH 엔드포인트 자체가 막힌 환경에서는 DNS 질의를 프록시 그룹을 타고 나가게 하는 advanced 패턴을 쓰기도 합니다. 이때는 «DNS가 프록시를 타기 위해 먼저 DNS가 필요하다»는 순환을 피하도록, 최소한의 신뢰 가능한 로컬 또는 직통 경로를 하나 남겨 두는 것이 중요합니다. 구체 키 이름은 빌드마다 미세하게 다를 수 있으니 사용 중인 Mihomo 버전 문서를 함께 확인하세요.
5 권장 YAML 스니펫(출발점)
아래는 교육용 출발점입니다. 지역·위협 모델·구독 규칙에 맞게 서버 목록과 필터를 반드시 바꾸세요. listen 포트는 이미 다른 데몬이 쓰는지 확인한 뒤 조정합니다.
dns:
enable: true
listen: 127.0.0.1:1053
ipv6: false
enhanced-mode: fake-ip
fake-ip-range: 198.18.0.1/16
fake-ip-filter:
- "*.lan"
- "*.local"
- "+.stun.*"
default-nameserver:
- tls://223.5.5.5
nameserver:
- https://dns.google/dns-query
- https://1.1.1.1/dns-query
fallback:
- https://8.8.8.8/dns-query
- tls://1.1.1.1:853
fallback-filter:
geoip: true
geoip-code: CN
ipcidr:
- 240.0.0.0/4
- 0.0.0.0/32
default-nameserver는 TLS·HTTPS 형식의 upstream을 부팅할 때 먼저 필요한 «최소 직통」 역할을 합니다. 운영 중 geoip-code 값은 거주 지역과 규칙 세트에 맞게 바꾸고, 중국 본토 직접 트래픽을 쓰지 않는다면 해당 키 자체를 단순화할 수도 있습니다. 핵심은 한 번에 여러 상충하는 리졸버를 섞지 않는 것입니다.
6 TUN·OS 리졸버와의 정렬
TUN 모드를 켜면 패킷이 가상 인터페이스로 모이지만, OS가 여전히 자체 stub resolver를 유지하면 일부 앱은 Clash를 우회합니다. Windows의 NRPT, Linux의 systemd-resolved, Android의 Private DNS는 각각 다른 방식으로 «시스템 DNS」를 고정합니다. 이들이 Clash의 DNS 리스너와 싸우면 «브라우저만 되고 앱 스토어만 실패» 같은 부분 유출이 생깁니다.
실무에서는 (1) 클라이언트가 제공하는 hijack-dns 계열 옵션을 켤 수 있는지 확인하고, (2) 불가능하면 OS 설정을 127.0.0.1의 Clash DNS 포트로 일시 맞춘 뒤, (3) Android에서는 디버깅 동안 Private DNS를 자동으로 두는 단계를 밟습니다. 모든 플랫폼에서 완벽한 «원 클릭」 해법은 없고, 증상별로 어느 레이어가 질의를 가로채는지를 로그로 확인하는 과정이 필요합니다.
7 흔한 실수와 디버깅 순서
- 이중 프록시: 다른 VPN과 Clash를 동시에 켜 DNS만 한쪽으로 새는 경우. 한 번에 하나의 터널 스택만 활성화해 재현해 보세요.
- IPv6 우회: IPv4만 프록시하고 AAAA는 직통으로 나가면 «절반만 보호»가 됩니다. 환경에 맞게 IPv6를 끄거나 동일 정책으로 넘기세요.
- 과도한 fallback: 모든 질의가 느린 해외 서버로만 나가면 체감 지연이 커집니다. 국내·CDN은 DIRECT 규칙과 맞춰 국내 리졸버를 병행하는 편이 낫습니다.
- 필터 누락: 게임·음성 채널이 FakeIP와 충돌하면 화이트리스트에 도메인을 추가해야 합니다.
로그에서 DNS 단계와 outbound 선택이 같은 타임스탬프에 찍히는지 비교하면, 문제가 해석인지 라우팅인지 빠르게 갈립니다.
8 유출 검증은 이렇게
브라우저에서 제공하는 «DNS leak test」 페이지는 캐시와 확장 프로그램의 영향을 받습니다. 가능하면 Clash 로그의 DNS 질의 목적지를 먼저 보고, 외부 테스트 사이트는 보조 증거로만 쓰세요. 테스트 시에는 시크릿 모드·확장 비활성화·동일 TUN 상태를 유지하는 것이 좋습니다.
또 다른 실전 검증은 dig나 nslookup이 어느 IP를 바라보는지 확인하는 것입니다. 시스템이 Clash 리스너가 아닌 라우터로 질의한다면, 아직 OS 레벨 정렬이 끝나지 않은 것입니다. 이때는 앞 절의 TUN·OS 설정을 다시 점검합니다.
9 정리
DNS 유출 방지는 «옵션 하나 켜기»가 아니라 해석 경로·규칙 엔진·OS 설정을 한 흐름으로 맞추는 작업입니다. Meta(Mihomo) 커널에서는 DoH·DoT로 전송 구간을 암호화하고, FakeIP로 애플리케이션이 보는 주소와 규칙이 기대하는 도메인 컨텍스트를 동기화합니다. fallback과 geoip 필터는 환경에 맞게 단순하게 유지하는 것이 장기 운영에 유리합니다.
GUI 클라이언트를 쓰면 YAML을 직접 만지는 부담이 줄지만, 문제가 생겼을 때는 결국 같은 개념으로 되돌아옵니다. 최신 빌드와 플랫폼별 패키지는 다운로드 페이지에서 비교할 수 있고, TUN·systemd·모바일까지 한 생태계로 묶어 두면 노드만 바꿔도 DNS 정책을 그대로 재사용할 수 있습니다. 단일 용도 앱 여러 개를 설치해 우회하는 방식보다, 규칙과 DNS를 한 코어에서 관리하는 편이 실수와 유출 표면을 동시에 줄이는 경우가 많습니다.