Clash DNS 누출 점검 및 차단 설정: Fake-IP와 nameserver 구성

먼저 DNS 누출의 기준부터 확인하기

브라우저에서 도메인에 접속하려면 먼저 도메인을 IP 주소로 변환해야 합니다. Clash를 켠 뒤 웹 연결은 프록시를 거치더라도 DNS 조회는 라우터, 통신사 DNS, 시스템에 지정된 공용 DNS 또는 브라우저가 별도로 사용하는 암호화 DNS로 직접 전송될 수 있습니다. 이 경우 프록시 출구와 DNS 요청 출구가 서로 다른 경로를 사용합니다.

확인할 때 단순히 “검사 페이지에 표시된 DNS 주소가 프록시 노드 IP와 같은가”만 비교해서는 안 됩니다. 공용 DoH 서비스는 별도의 서버가 응답하며, Anycast로 인해 인근 데이터센터로 조회가 분산될 수도 있으므로 두 주소가 다른 것은 정상일 수 있습니다. 실제로 확인해야 할 부분은 검사 결과에 현지 통신사, 회사 네트워크, 학교 네트워크 또는 가정용 라우터의 DNS가 나타나는지, 그리고 조회가 예상한 프록시 및 규칙 경로를 우회했는지입니다.

자주 나타나는 네 가지 DNS 경로

요청 출처	가능한 경로	점검 항목
시스템 일반 DNS	UDP 또는 TCP 53 포트	TUN이 53 포트를 인계하는지, 시스템 프록시 모드가 해당 프로그램에 적용되는지 확인
브라우저 보안 DNS	브라우저에서 선택한 DoH 주소	브라우저 설정이 시스템 DNS를 덮어쓰는지, 검사 중에도 같은 정책을 유지하는지 확인
Clash 내장 DNS	nameserver, fallback 또는 정책으로 지정된 서버	상위 서버 주소, 프록시 경로와 규칙이 올바른지 확인
애플리케이션 내장 리졸버	하드코딩된 DNS, DoH 또는 DoT	TUN 라우팅이 해당 앱을 포함하는지, 앱이 시스템 프록시를 우회하는지 확인

반복 가능한 DNS 누출 점검 절차 만들기

한 번의 검사 결과는 캐시, 브라우저 연결 재사용, 상위 서버의 Anycast 분산에 영향을 받을 수 있습니다. 신뢰할 수 있는 방법은 먼저 기준값을 기록하고 캐시를 삭제한 다음, 직접 연결과 프록시 연결 상태에서 각각 반복 검사하는 것입니다. 전체 과정에서 같은 브라우저, 같은 네트워크와 같은 설정을 유지하고 여러 변수를 동시에 바꾸지 마세요.

1단계: Clash를 켜지 않은 상태의 기준값 기록

Clash 클라이언트를 완전히 종료하고 시스템 프록시와 TUN이 모두 꺼져 있는지 확인합니다.
dnsleaktest.com 또는 browserleaks.com/dns를 열고 표준 검사와 확장 검사를 각각 한 번씩 실행합니다.
감지된 DNS 사업자, 국가 또는 지역, 서버 수를 기록합니다. 가정용 인터넷 회선에서는 1~4개의 DNS 주소가 표시되는 경우가 많습니다.
운영체제의 네트워크 세부 정보도 열어 현재 네트워크 어댑터가 받은 DNS 주소를 기록합니다. 192.168.1.1 같은 라우터 주소일 수도 있고, 네트워크에서 전달받은 공용 주소일 수도 있습니다.

이 결과는 로컬 리졸버를 식별하는 데 사용됩니다. 이후 Clash를 켠 뒤 같은 사업자와 주소가 다시 나타나면 조회가 여전히 로컬 네트워크에서 전송되는지 판단할 수 있습니다.

2단계: 캐시 삭제 후 프록시 켜기

Windows에서는 먼저 터미널에서 ipconfig /flushdns를 실행합니다. macOS에서는 sudo dscacheutil -flushcache를 실행한 뒤 sudo killall -HUP mDNSResponder를 실행합니다. Linux의 캐시 삭제 방법은 리졸버 서비스에 따라 다르며, systemd-resolved를 사용한다면 resolvectl flush-caches를 실행할 수 있습니다.

그런 다음 클라이언트를 실행하고 대상 설정을 가져온 뒤 프록시를 켭니다. 모든 앱의 DNS를 확인하려면 「설정」→「네트워크」→「TUN 모드」에서 TUN을 켜세요. 브라우저의 시스템 프록시만 테스트한다면 TUN은 끈 상태로 두고, 이번 결과가 해당 브라우저의 트래픽 경로만 나타낸다는 점을 분명히 해야 합니다.

3단계: 두 차례 검사 실행

첫 번째 검사는 일반 창에서 실행해 평소 브라우징 환경의 실제 결과를 확인합니다.
두 번째 검사는 새 시크릿 창에서 실행해 페이지 캐시, Service Worker와 기존 연결의 영향을 줄입니다.
각 회차마다 확장 검사를 한 번 이상 실행합니다. 확장 검사는 대개 더 많은 무작위 하위 도메인 조회를 발생시켜 혼합된 DNS 경로를 쉽게 드러냅니다.
첫 번째 검사에서 지정한 DoH 리졸버 2개가 표시됐는데 두 번째 검사에서 갑자기 로컬 통신사 리졸버 3개가 추가됐다면, 더 이상적인 한 번의 결과만 믿지 말고 간헐적 누출로 처리해야 합니다.

Fake-IP 모드가 도메인 조회를 인계하는 방식

mihomo 커널에서 enhanced-mode: fake-ip를 사용하면 일반 도메인에 예약 주소를 반환하고 커널 내부에 “도메인—Fake-IP” 매핑을 유지합니다. 앱이 이 예약 주소에 연결하면 커널이 원래 도메인을 복원한 뒤 도메인 규칙, 정책 그룹 선택과 실제 대상 조회를 계속 처리할 수 있습니다. 일반적으로 사용되는 주소 풀은 198.18.0.1/16이며, 네트워크 벤치마크용 예약 범위에서 유래한 주소이므로 공용 인터넷 대상으로 사용해서는 안 됩니다.

Fake-IP의 장점은 연결 단계까지 도메인 정보를 유지하는 데 있습니다. 앱에 실제 IP를 바로 반환하는 방식보다 DOMAIN, DOMAIN-SUFFIX, GeoSite 등의 규칙이 안정적으로 매칭되기 쉽고, 앱이 먼저 실제 주소를 조회한 뒤 연결해 규칙 적용이 어긋나는 문제도 줄일 수 있습니다.

출발점으로 사용할 수 있는 DNS 설정

dns:
  enable: true
  listen: 0.0.0.0:1053
  ipv6: false
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  fake-ip-filter-mode: blacklist
  fake-ip-filter:
    - "*.lan"
    - "*.local"
    - "localhost.ptlogin2.qq.com"
    - "+.stun.*.*"
    - "+.stun.*.*.*"
  default-nameserver:
    - 223.5.5.5
    - 1.1.1.1
  nameserver:
    - https://dns.alidns.com/dns-query
    - https://1.1.1.1/dns-query
  proxy-server-nameserver:
    - https://223.5.5.5/dns-query
    - https://1.1.1.1/dns-query

예시에서 수신 포트는 1053으로 설정해 시스템에서 흔히 사용하는 53 포트를 직접 점유하지 않도록 했습니다. 시스템 DNS를 실제로 인계할 때는 일반적으로 TUN의 dns-hijack이 53 포트 조회를 커널로 전달하며, 일반 사용자 프로세스가 권한이 필요한 포트를 직접 수신하도록 요구하지 않습니다.

default-nameserver는 초기 조회를 담당합니다

default-nameserver는 주로 DoH, DoT 같은 상위 DNS 서버 자체의 도메인을 조회하는 데 사용됩니다. 예를 들어 nameserver가 https://dns.alidns.com/dns-query라면 HTTPS 연결을 만들기 전에 커널이 dns.alidns.com의 IP를 먼저 알아야 합니다. 여기에는 직접 접속할 수 있는 IP 주소를 우선 입력해 “DNS 서버를 조회하려면 먼저 DNS 조회가 필요한” 순환 의존을 피하는 것이 좋습니다.

이 항목은 모든 서비스 도메인의 주 조회 목록이 아니며, 시스템 네트워크 어댑터의 DNS 설정과도 다릅니다. default-nameserver에 주소를 열 개 넘게 넣는다고 안정성이 자동으로 높아지지는 않으며, 오히려 테스트 변수가 늘어납니다. 대개 경로가 안정적이고 직접 도달할 수 있는 주소 2개면 충분합니다.

nameserver가 일반 도메인 조회를 처리합니다

nameserver는 일반 조회에 사용하는 주요 상위 서버입니다. UDP DNS뿐 아니라 DoH나 DoT도 사용할 수 있습니다. 로컬 네트워크가 평문 53 포트 조회를 관찰할 가능성을 줄이려면 https://1.1.1.1/dns-query 같은 DoH 주소를 선택하는 방법이 일반적입니다. 다만 암호화는 클라이언트와 DNS 서비스 사이의 전송만 보호하며, 모든 도메인을 하나의 상위 서버에 맡겨야 한다는 뜻도 아니고 요청이 반드시 프록시를 거친다는 뜻도 아닙니다.

DNS 연결이 규칙을 따르도록 설정해야 한다면 해당 필드를 지원하는 mihomo 버전에서 respect-rules: true를 사용할 수 있습니다. 이 경우 프록시 노드 서버의 도메인을 조회할 proxy-server-nameserver도 함께 설정해야 합니다. 그렇지 않으면 노드 도메인 자체에서 순환 조회가 발생할 수 있습니다.

nameserver-policy로 정밀하게 분리하기

도메인별로 리졸버를 지정해야 할 때는 nameserver-policy를 사용할 수 있습니다. 내부 도메인, 로컬 네트워크 서비스 또는 특정 조회 결과가 필요한 지역 사이트에 적합하며, 모든 요청을 여러 상위 서버에 병렬로 보내는 방식보다 동작을 검증하기 쉽습니다.

dns:
  enable: true
  enhanced-mode: fake-ip
  nameserver:
    - https://1.1.1.1/dns-query
  nameserver-policy:
    "geosite:cn":
      - https://dns.alidns.com/dns-query
    "+.internal.example":
      - 192.168.1.1

마지막 항목은 실제로 내부 도메인이 존재하는 경우에만 사용해야 합니다. 192.168.1.1이 가정용 라우터라면 해당 라우터에 조회를 보내는 일부 요청은 로컬 네트워크를 통과합니다. 이는 명시적인 정책 선택이며, 의도하지 않은 누출과 혼동해서는 안 됩니다.

fake-ip-filter에서 제외할 도메인

모든 도메인에 Fake-IP를 반환하는 것이 적합한 것은 아닙니다. 로컬 네트워크 검색, 기기 화면 전송, 일부 STUN 탐색, 운영체제 연결성 검사와 실제 주소에 의존하는 일부 프로그램에는 예외가 필요할 수 있습니다. fake-ip-filter는 일치하는 항목에 실제 조회 결과를 제공하는 기능이지, 전체 Fake-IP 모드를 끄는 기능이 아닙니다.

최소한의 예외 목록부터 시작하기

*.lan, *.local: 로컬 기기와 로컬 네트워크 서비스에 흔히 사용됩니다.
라우터 관리 도메인: 실제로 사용할 때만 추가하고, 이 기기와 관계없는 제조사 도메인을 그대로 복사하지 마세요.
음성, 영상 또는 온라인 연결 문제가 발생할 때만 로그에 나타난 STUN 도메인에 규칙을 추가합니다.
필터를 추가해야만 특정 앱이 작동한다면 최상위 도메인 전체를 제외하지 말고 정확한 도메인을 기록하세요.

필터 목록이 지나치게 넓으면 Fake-IP의 도메인 매핑 기능이 약해집니다. 예를 들어 *.com을 바로 추가하면 많은 사이트가 실제 IP를 반환하게 되고 도메인 규칙의 매칭 과정도 추적하기 어려워집니다. 항목을 추가할 때마다 장애 현상, 로그에 기록된 도메인과 재검사 결과를 남겨 나중에 더 이상 필요 없는 예외를 제거할 수 있도록 하세요.

TUN 모드와 DNS 하이재킹의 핵심 설정

시스템 프록시는 HTTP 또는 SOCKS 프록시 설정을 따르는 프로그램에 주로 영향을 줍니다. 많은 게임, 명령줄 도구, 백그라운드 서비스와 자체 네트워크 스택을 사용하는 앱은 시스템 프록시를 읽지 않으므로 시스템 프록시만 켜서는 DNS가 Clash로 들어간다고 보장할 수 없습니다. TUN 모드는 가상 네트워크 어댑터로 IP 트래픽을 인계하므로 전체 기기의 DNS 경로를 확인하는 데 더 적합합니다.

tun:
  enable: true
  stack: mixed
  auto-route: true
  auto-detect-interface: true
  strict-route: true
  dns-hijack:
    - any:53
    - tcp://any:53

any:53은 일반적인 53 포트 DNS 조회를 인계하고, 추가한 tcp://any:53은 TCP DNS를 처리합니다. auto-route는 라우팅을 자동으로 추가하며, auto-detect-interface는 기본 출구 인터페이스를 식별합니다. strict-route는 조회가 TUN을 우회할 가능성을 줄일 수 있지만 가상 머신, 기업 VPN, 로컬 네트워크 공유와 여러 네트워크 어댑터 환경에서는 기존 라우팅에 영향을 줄 수 있으므로 항목별 검증이 필요합니다.

클라이언트에서 확인할 순서

「구성」 페이지로 이동해 현재 설정이 정상적으로 로드되었고 인터페이스에 YAML 파싱 오류가 없는지 확인합니다.
「설정」→「네트워크」→「TUN 모드」로 이동해 TUN을 켜고 시스템 안내에 따라 네트워크 또는 관리자 권한을 부여합니다.
「설정」→「매개변수 설정」으로 이동해 이전에 캐시된 설정 사본이 아니라 대상 커널과 대상 설정을 사용하고 있는지 확인합니다.
「로그」를 열고 레벨을 일시적으로 Debug로 바꾼 뒤 dns, fake-ip 또는 테스트 도메인을 검색합니다.
테스트가 끝나면 로그 레벨을 Info로 되돌려 대량의 디버그 정보가 장기간 기록되지 않도록 합니다.

클라이언트 버전에 따라 메뉴 문구는 조금 다를 수 있지만 확인 대상은 같습니다. 현재 설정, 커널 DNS, TUN 스위치, 라우팅 인계와 로그 기록이 모두 같은 실행 인스턴스에 대응해야 합니다. 시스템 트레이에 다른 Clash 클라이언트가 남아 있다면 두 프로세스가 동시에 프록시, 포트와 라우팅을 변경할 수 있습니다.

자주 발생하는 누출 원인과 해결 방법

시스템 프록지만 켜고 TUN은 켜지 않은 경우

브라우저의 웹 연결은 프록시를 사용할 수 있지만 시스템 조회는 네트워크 어댑터의 DNS로 전송될 수 있습니다. TUN과 DNS 하이재킹을 켜거나 시스템 DNS를 클라이언트의 수신 주소로 명확하게 지정해 해결하세요. 전체 기기를 인계하는 경우에는 일반적으로 전자가 관리하기 쉽습니다.

브라우저가 자체적으로 DoH를 켠 경우

브라우저가 선택한 DoH 서비스에 직접 연결해 Clash의 도메인 분기를 우회할 수 있습니다. 먼저 브라우저 보안 DNS를 끄고 비교하세요. 끈 뒤 검사 결과가 정상으로 돌아오면 브라우저가 시스템 설정을 따르게 할지, 규칙으로 해당 DoH 연결을 명확히 인계할지 결정합니다. 한 브라우저의 결과만으로 모든 앱을 판단하지 마세요.

nameserver가 평문 UDP로 직접 연결되는 경우

nameserver에 8.8.8.8, 1.1.1.1 같은 IP만 입력하면 조회가 대개 UDP 53으로 전송됩니다. TUN 라우팅이 처리할 수도 있지만 전송 자체는 암호화된 DNS가 아닙니다. 로컬 네트워크에서 관찰될 가능성을 줄이려면 해당 DoH 주소로 바꾸고 로그에서 HTTPS 연결에 실제로 적용된 정책을 확인하세요.

노드 도메인에서 조회 순환이 발생하는 경우

프록시 노드 주소가 도메인이라면 프록시를 연결하기 전에 커널이 먼저 노드를 조회해야 합니다. 그런데 이 조회에도 아직 연결되지 않은 프록시를 사용하도록 규칙이 지정되면 순환이 발생합니다. 설정은 정상적으로 로드되지만 모든 노드가 시간 초과되는 것이 일반적인 증상입니다. 노드 도메인 전용으로 proxy-server-nameserver를 설정하고, 해당 리졸버가 프록시 연결 전에 도달 가능한지 확인하세요.

IPv6 조회 또는 연결이 다른 경로를 사용하는 경우

설정의 ipv6: false는 커널 DNS가 AAAA 결과를 반환할지에만 영향을 주며 운영체제의 모든 IPv6 트래픽을 반드시 끄지는 않습니다. 로컬 네트워크가 IPv6를 제공하는데 TUN 라우팅이 IPv4만 포함하면 앱이 IPv6로 우회할 수 있습니다. 테스트할 때 IPv4·IPv6 주소와 DNS 결과를 함께 확인하세요. 비교를 위해 시스템 네트워크 어댑터의 IPv6를 일시적으로 끌 수 있지만, 최종적으로는 TUN과 라우팅의 적용 범위를 수정해야 합니다.

오래된 캐시로 인한 잘못된 결과

시스템, 브라우저, 앱과 mihomo 커널은 모두 조회 결과를 캐시할 수 있습니다. 설정을 바꾼 직후 기존 페이지를 새로 고치면 새 조회가 발생하지 않을 수 있습니다. 시스템 캐시를 삭제하고 브라우저를 재시작한 뒤 무작위 하위 도메인이나 검사 사이트의 확장 모드로 조회를 다시 발생시키세요.

수정 후 전체 검증 목록

검증 단계에서는 웹 페이지가 열리는지만 확인하지 마세요. 연결 성공은 적어도 하나의 경로가 작동한다는 뜻일 뿐, 모든 DNS가 예상대로 흐른다는 증거는 아닙니다. 아래 순서대로 실행하고 각 단계의 결과를 기록하는 것이 좋습니다.

설정 로드 확인: 로그에 yaml, parse, dns config 관련 오류가 없어야 합니다.
수신 포트 확인: 예시의 1053 또는 실제 설정 포트가 현재 커널에서 수신 중이고 다른 프로세스가 사용하지 않는지 확인합니다.
Fake-IP 확인: 일반 도메인을 조회할 때 198.18.0.0/16 범위의 반환값이 보여야 하며, 필터 목록의 도메인은 실제 주소를 반환해야 합니다.
규칙 매칭 확인: 연결 또는 로그 페이지에서 테스트 도메인에 적용된 규칙과 정책 그룹을 확인해 의도치 않게 DIRECT로 빠지지 않았는지 확인합니다.
확장 검사 실행: 두 번 연속 실행하고 결과에 기준 단계에서 기록한 로컬 통신사 리졸버가 더 이상 나타나지 않는지 확인합니다.
브라우저 설정을 바꿔 재검사: 보안 DNS 사용과 시스템 설정 따르기 두 상태에서 각각 테스트해 차이가 어디에서 발생하는지 확인합니다.
브라우저가 아닌 앱 테스트: 명령줄 도구나 다른 앱으로 연결을 시작해 TUN 인계가 브라우저에만 적용되는 것이 아닌지 확인합니다.
재시작 후 재검사: 클라이언트와 시스템을 다시 시작한 뒤 TUN, DNS와 설정 선택이 예상대로 복원되는지 확인합니다.

nslookup example.com 127.0.0.1
dig @127.0.0.1 -p 1053 example.com A
dig @127.0.0.1 -p 1053 example.com AAAA

명령에 사용하는 주소와 포트는 실제 수신 값에 맞게 조정해야 합니다. 클라이언트가 127.0.0.1:1053에서만 수신한다면 -p 1053을 생략할 수 없습니다. Fake-IP 모드에서 A 레코드가 198.18.x.x를 반환하는 것은 대체로 정상이며, 대상 사이트의 실제 공용 IP 주소가 아닙니다.

더 안정적인 조정 순서

실제 점검에서는 “기준 확인—통합 인계—예외 축소—로그 검증” 순서로 진행하는 것이 좋습니다. 먼저 명확한 nameserver 2개를 유지하고 Fake-IP와 TUN DNS 하이재킹을 켜 기본 경로를 안정화한 다음, nameserver-policy, 로컬 네트워크 조회와 앱 호환 항목을 추가하세요.

처음부터 규모가 큰 DNS 설정을 통째로 복사하지 마세요. 필드가 많을수록 조회 경로를 설명하기 어려워집니다. 대부분의 개인 기기에서는 각 상위 서버의 용도, 각 예외의 출처와 각 조회가 프록시를 통과하는지를 설명할 수 있는 것이 많은 리졸버를 쌓는 것보다 중요합니다. 수정 후 같은 검사 사이트, 같은 브라우저 상태와 같은 네트워크에서 반복 테스트해야 누출이 실제로 해결됐는지 판단할 수 있습니다.