Clash DNS 누수 점검 및 차단 설정 방법

먼저 DNS 누수로 판단할 기준 확인하기

브라우저에서 도메인에 접속하려면 먼저 도메인을 IP 주소로 변환해야 합니다. 프록시 연결이 Clash를 통해 전달된다고 해서 DNS 조회까지 반드시 프록시 경로를 따르는 것은 아닙니다. Windows가 여전히 현재 광대역 회선, 회사 네트워크 또는 공용 Wi-Fi에서 내려받은 DNS 서버로 UDP 53이나 TCP 53 조회를 보내면 네트워크 제공자는 조회한 도메인을 확인할 수 있습니다. 이것이 문제 해결에서 가장 흔한 DNS 누수입니다.

검사 결과에 한국 국내 통신사 DNS가 표시된다고 해서 곧바로 설정 오류인 것은 아닙니다. 규칙 모드에서는 중국 본토 도메인을 로컬 DNS로 처리하고 해외 도메인은 다른 DNS 그룹으로 보내도록 의도적으로 구성할 수 있으며, 이 경우 검사 페이지에 여러 DNS 출구가 함께 표시됩니다. 실제로 확인해야 할 점은 프록시가 처리해야 하는 도메인이 물리 네트워크 어댑터를 통해 직접 조회되는지, 노드를 바꾼 뒤에도 DNS 출구가 계속 로컬 네트워크에 머무는지입니다.

자주 발생하는 누수 경로

「System Proxy」만 켜면 브라우저 트래픽은 Clash로 들어가지만 다른 프로그램은 계속 시스템 DNS를 호출합니다.
설정 파일에서 dns.enable을 활성화했지만 Windows 네트워크 어댑터가 조회를 Clash의 수신 포트로 전달하지 않습니다.
TUN은 켜져 있지만 dns-hijack이 없어 애플리케이션이 직접 보낸 UDP 53 조회가 커널을 우회합니다.
redir-host 사용 시 시스템이나 애플리케이션이 별도의 DNS 조회를 유지해 로컬 DNS와 Clash DNS가 동시에 작동합니다.
암호화 DNS 주소 자체도 먼저 해석해야 하는데 사용 가능한 default-nameserver가 없어 시작 단계에서 조회 의존성이 생깁니다.
브라우저에서 독립 보안 DNS를 활성화하면 조회 요청이 브라우저가 지정한 DoH 서비스로 직접 연결되어 예상한 Clash 규칙을 거치지 않습니다.

온라인 검사 사이트로 세 차례 비교 테스트하기

온라인 DNS 검사는 현상을 빠르게 확인하는 데 유용하지만 한 번의 결과만으로 결론을 내릴 수는 없습니다. 브라우저 캐시, 시스템 DNS 캐시, 검사 사이트의 노드 위치 데이터베이스가 표시 결과에 영향을 줍니다. 같은 브라우저와 검사 페이지를 사용해 연속으로 세 번 테스트하고 프록시 출구 IP, DNS 서버 수, 통신사 이름과 지역을 기록하세요.

Clash를 완전히 종료하고 30초간 기다린 뒤 표준 검사를 한 번 실행해 로컬 네트워크의 DNS 기준값을 기록합니다.
Clash를 실행하고 시스템 프록시만 켠 다음 로컬 네트워크와 다른 지역의 노드를 선택해 전체 검사를 다시 실행합니다.
같은 노드를 유지한 채 TUN과 DNS 하이재킹을 켜고 캐시를 삭제한 뒤 세 번째 검사를 실행해 결과 변화를 비교합니다.

Windows DNS 및 브라우저 캐시 삭제

관리자 권한으로 PowerShell 또는 명령 프롬프트를 열고 다음 명령을 실행해 Windows DNS 캐시를 삭제합니다:

ipconfig /flushdns

Chromium 계열 브라우저는 자체 호스트 캐시와 연결 풀도 보존할 수 있습니다. 모든 브라우저 창을 닫았다가 다시 여는 것이 보통 가장 간단합니다. 테스트 중에는 다른 VPN, 게임 가속기, 가상 머신 네트워크 또는 회사 보안 클라이언트를 함께 실행하지 마세요. DNS가 다른 네트워크 구성 요소에 의해 가로채일 수 있습니다.

테스트 결과	가능한 원인	다음 단계
로컬 통신사 DNS만 표시됨	Clash DNS가 트래픽을 넘겨받지 못했거나 브라우저가 여전히 시스템 DNS를 사용함	TUN, dns-hijack 및 시스템 프록시 상태 확인
로컬 DNS와 원격 DNS가 함께 표시됨	규칙 분할, 캐시 또는 여러 DNS 경로가 동시에 존재함	캐시를 삭제한 뒤 53 포트 트래픽 캡처
노드를 바꿔도 DNS가 변하지 않음	DNS 서버가 항상 직접 연결되거나 설정에서 고정 DoH를 사용함	DNS 요청이 규칙에 따라 프록시를 거치는지 확인
검사는 정상인데 일부 애플리케이션에서 계속 누수됨	해당 애플리케이션이 독립 DNS를 사용하거나 시스템 프록시를 우회함	TUN으로 전환하고 DNS 하이재킹 활성화

Windows에서 DNS 직접 연결 여부 확인

Windows 기본 제공 도구인 pktmon으로 평문 53 포트 요청이 있는지 빠르게 확인할 수 있습니다. 별도 도구를 설치할 필요가 없어 TUN을 켜기 전후 물리 네트워크 어댑터에서 패킷이 나가는지 확인하기 좋습니다. 먼저 실행 중인 패킷 캡처 작업을 종료한 뒤 관리자 권한으로 PowerShell을 여세요.

pktmon stop
pktmon filter remove
pktmon filter add DNS -p 53
pktmon start --etw -m real-time

창을 실행한 상태로 두고 이전에 방문하지 않은 웹사이트 몇 곳을 엽니다. 대상 주소와 네트워크 어댑터를 확인하세요. 테스트가 끝나면 Ctrl+C를 누른 다음 다음 명령을 실행합니다:

pktmon stop
pktmon filter remove

대상이 192.168.1.1:53 같은 라우터 주소나 광대역 회선에서 내려온 공용 DNS이고, 패킷이 Wi-Fi 또는 이더넷 물리 어댑터에서 발생한다면 아직 Clash가 평문 조회를 넘겨받지 못한 것입니다. Clash를 시작하는 순간에만 소량의 요청이 보인다면 암호화 DNS 도메인을 위한 초기 조회일 수 있지만, 웹 탐색 중에도 계속 나타난다면 설정을 더 조정해야 합니다.

시스템에서 현재 사용하는 DNS 서버 확인

다음 PowerShell 명령은 모든 네트워크 어댑터의 DNS 주소를 표시합니다. 현재 연결에 사용하는 Wi-Fi나 이더넷, 그리고 Clash·Wintun·Mihomo 같은 가상 어댑터를 중점적으로 확인하세요:

Get-DnsClientServerAddress |
  Where-Object {$_.ServerAddresses.Count -gt 0} |
  Format-Table InterfaceAlias, AddressFamily, ServerAddresses -AutoSize

nslookup은 시스템 DNS 기준값을 확인하는 데 적합하지만 브라우저 누수를 단독으로 증명하는 도구는 아닙니다. 일반적으로 시스템에 설정된 DNS 서버를 직접 호출하므로 SOCKS·HTTP 프록시 또는 독립 DoH를 통해 브라우저가 보낸 요청은 재현하지 못할 수 있습니다. 문제를 확인할 때는 nslookup 결과를 pktmon 및 Clash 로그와 함께 살펴보세요.

nameserver·fallback·fake-ip 조정

DNS 설정의 목적은 서버 주소를 단순히 많이 추가하는 것이 아니라 세 가지를 명확히 정하는 데 있습니다. Clash가 일반 도메인을 처리할 DNS 서버, 암호화 DNS 주소의 최초 조회를 담당할 서버, 반환 결과를 규칙 시스템에 전달하는 방식입니다. 아래는 구조를 점검하기 위한 기본 예시이며 YAML을 사용할 때는 들여쓰기를 일관되게 유지해야 합니다.

dns:
  enable: true
  listen: 0.0.0.0:1053
  ipv6: false
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16

  default-nameserver:
    - 223.5.5.5
    - 119.29.29.29

  nameserver:
    - https://dns.alidns.com/dns-query
    - https://doh.pub/dns-query

  fallback:
    - https://1.1.1.1/dns-query
    - https://8.8.8.8/dns-query

  fallback-filter:
    geoip: true
    geoip-code: CN
    ipcidr:
      - 240.0.0.0/4

  fake-ip-filter:
    - "*.lan"
    - "localhost.ptlogin2.qq.com"
    - "+.stun.*.*"
    - "+.stun.*.*.*"

default-nameserver: 초기 조회만 담당

default-nameserver에는 보통 직접 접속할 수 있는 IP 주소를 입력해 DoH 서버 자체의 도메인을 조회합니다. 예를 들어 시스템이 HTTPS 연결을 만들려면 먼저 dns.alidns.com의 IP를 알아야 합니다. 여기에 도메인 형식의 주소를 입력하거나 지나치게 많은 주소를 넣는 것은 적절하지 않습니다. 안정적인 IP DNS 서버 두 개면 장애 대응에 충분합니다.

nameserver 및 fallback: 분할 목적 명확히 하기

nameserver는 기본 DNS 서버이고 fallback은 기존 Clash 설정에서 사용하는 보조 DNS 서버입니다. fallback-filter와 함께 사용하면 커널이 GeoIP와 응답 주소 범위 등의 조건에 따라 어느 그룹의 결과를 채택할지 결정합니다. Clash Meta와 mihomo 버전에 따라 DNS 정책 확장 기능이 다르므로 구독 설정으로 덮어쓸 때는 클라이언트가 로컬 DNS 섹션을 유지하는지도 확인해야 합니다.

DoH는 DNS 내용을 암호화할 뿐 연결이 자동으로 프록시를 통과하도록 보장하지 않습니다. 원격 DNS 서버에 프록시 규칙을 적용하려면 respect-rules·proxy-server-nameserver·nameserver-policy를 지원하는 최신 mihomo 커널을 사용하고, 먼저 프록시 서버 도메인용 독립 DNS를 준비해야 합니다. 그래야 프록시 서버를 조회하려면 먼저 프록시에 연결해야 하는 순환 의존성을 피할 수 있습니다.

fake-ip: 도메인을 먼저 규칙 시스템에 전달

fake-ip 모드는 먼저 애플리케이션에 198.18.0.0/16 범위의 매핑 주소를 반환한 뒤, 애플리케이션이 연결을 만들 때 원래 도메인을 복원해 규칙을 적용합니다. 애플리케이션이 자체적으로 DNS를 조회한 후 대상 IP만 제출하는 상황을 줄일 수 있어 규칙 분할과 DNS 가로채기가 더 안정적으로 작동합니다. 이 주소 대역은 벤치마크용 네트워크이므로 가정이나 회사의 실제 네트워크 대역과 겹치지 않아야 합니다.

로컬 네트워크 장치 검색, 프린터, 게임 플랫폼 멀티플레이, STUN 및 일부 로그인 도메인은 fake-ip에 적합하지 않을 수 있으므로 fake-ip-filter에 추가해야 합니다. 필터 목록에 검증되지 않은 규칙 수백 개를 그대로 복사해서는 안 됩니다. 항목을 하나 추가할 때마다 해당 도메인이 실제 IP 조회로 전환된다는 의미이기 때문입니다. 로컬 장치를 찾지 못하거나 애플리케이션 로그인 루프가 발생할 때 로그를 바탕으로 필요한 도메인만 추가하는 편이 관리하기 쉽습니다.

TUN 및 DNS 하이재킹으로 프록시 미사용 애플리케이션까지 처리

시스템 프록시는 Windows 프록시 설정을 따르는 프로그램에만 영향을 줍니다. 명령줄 도구, 게임, 스토어 앱과 일부 런처는 직접 연결을 만들 수 있으므로 System Proxy만으로는 DNS를 완전히 제어하기 어렵습니다. TUN 모드는 가상 네트워크 어댑터를 만들고 IP 계층에서 트래픽을 처리하며, dns-hijack과 함께 사용하면 애플리케이션이 보내는 53 포트 조회를 가로챌 수 있습니다.

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

Clash for Windows 0.20.39에서는 먼저 「General」→「Service Mode」로 이동해 서비스 모드를 설치한 다음 「General」→「TUN Mode」를 여세요. 설정 파일은 「Profiles」에서 현재 설정을 찾을 수 있으며, 오른쪽 클릭 메뉴의 「Edit」으로 DNS 섹션을 확인합니다. mihomo 기반 그래픽 클라이언트마다 메뉴 이름은 다를 수 있지만 커널 권한, TUN 스위치와 DNS 하이재킹 세 항목을 모두 확인해야 합니다.

strict-route: true는 Windows에서 멀티홈 DNS와 같은 우회 경로를 제한하는 데 도움이 되지만 회사 VPN, Hyper-V, WSL, 가상 머신 브리지와 네트워크 공유로 인해 라우팅이 달라질 수 있습니다. 활성화한 뒤 프린터나 NAS에 접속할 수 없다면 먼저 라우팅 테이블과 Clash 로그를 확인하고 모든 사설 주소를 곧바로 프록시 규칙에 추가하지 마세요.

IPv6도 같은 기준으로 확인하기

설정의 dns.ipv6: false는 Clash DNS가 AAAA 결과를 반환하지 않는다는 뜻이며, 프록시 노드나 현재 네트워크에 안정적인 IPv6가 없을 때 적합합니다. 로컬 네트워크와 프록시 노드가 모두 IPv6를 지원한다면 true로 바꿀 수 있지만 TUN, 라우팅과 규칙이 IPv6를 처리하는지 함께 확인해야 합니다. DNS의 AAAA 응답만 끄는 것은 시스템 수준에서 IPv6를 비활성화하는 것과 다릅니다.

정해진 순서로 재검사해 남은 문제 찾기

수정을 마친 뒤 여러 노드와 모드, 브라우저를 한꺼번에 바꾸지 마세요. 하나의 노드를 고정하고 먼저 설정을 다시 불러온 다음 동일한 순서로 재검사해야 어느 단계에서 변화가 생겼는지 판단할 수 있습니다.

클라이언트 로그에서 YAML이 정상적으로 로드되었고 들여쓰기, 필드 또는 DNS 서버 주소 오류가 없는지 확인합니다.
현재 설정에서 dns.enable이 true인지, 수신 포트 1053을 다른 프로그램이 사용하고 있지 않은지 확인합니다.
TUN과 dns-hijack을 활성화하고 ipconfig /flushdns를 실행합니다.
브라우저를 닫았다가 다시 열고 이전에 접속하지 않았던 도메인 세 곳을 방문합니다.
온라인 전체 검사를 실행하고 DNS 수, 지역 및 서비스 제공업체를 기록합니다.
동시에 pktmon으로 물리 네트워크 어댑터가 여전히 UDP 53 또는 TCP 53을 외부로 보내는지 확인합니다.
규칙 모드와 전역 모드를 각각 전환해 다시 테스트합니다. 규칙 모드에서만 로컬 DNS가 나타난다면 DNS 정책과 직접 연결 규칙을 확인해야 합니다.

검사 결과에 여전히 로컬 DNS가 표시됨

브라우저의 보안 DNS 설정을 확인합니다. 문제 해결 단계에서는 브라우저의 독립 DoH를 잠시 꺼서 조회가 시스템과 TUN으로 통일되게 한 다음 복원 여부를 결정할 수 있습니다.
Windows에 다른 VPN 가상 네트워크 어댑터가 함께 존재하는지 확인합니다. 두 TUN 드라이버가 동시에 실행되면 라우팅 우선순위가 시작 순서에 따라 바뀔 수 있습니다.
구독 업데이트 후 DNS 섹션이 덮어써졌는지 확인합니다. 화면에 TUN이 켜져 있어도 현재 로드된 설정에 예상한 항목이 남아 있다는 뜻은 아닙니다.
로그에 DNS timeout, connection refused, no such host가 반복해서 나타나는지 확인합니다. 시간 초과가 발생하면 애플리케이션이 자체 DNS 경로로 되돌아갈 수 있습니다.
방화벽이 Clash 또는 mihomo 커널의 DoH 서비스 TCP 443 연결을 허용하는지 확인합니다.

웹페이지는 열리지 않지만 누수는 사라짐

이는 보통 검사에 성공한 정상적인 상태가 아니라 DNS는 가로채졌지만 Clash 자체가 업스트림 조회를 완료하지 못한 경우입니다. 먼저 default-nameserver가 순수 IP 주소인지 확인하고 DoH 주소에 연결할 수 있는지 점검하세요. 프록시 서버가 도메인을 사용한다면 직접 연결 가능한 초기 조회 경로도 준비해야 합니다. 네트워크가 복구된 뒤 fallback, 정책 조회와 필터 항목을 단계적으로 추가하고 모든 고급 필드를 한꺼번에 활성화하지 마세요.