먼저 문제가 DNS 누출인지 확인하기

DNS 누출은 일반적으로 도메인 조회가 예상한 Clash 또는 mihomo DNS 처리 경로를 거치지 않고 운영체제, 라우터, 브라우저 내장 보안 DNS 또는 인터넷 서비스 제공업체의 리졸버에서 직접 처리되는 현상을 말합니다. 웹 트래픽이 프록시를 통과하더라도 도메인 조회는 로컬 네트워크에서 별도로 전송될 수 있습니다. 따라서 외부 관찰자가 조회 대상을 확인할 수 있고, 잘못된 응답이나 오염된 결과, 규칙 매칭 이상 또는 프로그램마다 같은 사이트의 동작이 달라지는 문제가 발생할 수 있습니다.

로컬 통신사의 DNS 서버가 표시된다고 해서 반드시 설정이 잘못된 것은 아닙니다. 먼저 기대하는 동작을 분명히 해야 합니다. 설정의 nameserver가 원래 로컬 공용 DNS라면 검사 페이지에 해당 사업자가 표시되는 것은 정상입니다. 반대로 지정한 DoH, DoT 또는 원격 리졸버를 사용하도록 설정했는데도 라우터 주소, 광대역 통신사 리졸버 또는 회사 네트워크 DNS가 반복해서 나타난다면 추가 점검이 필요합니다.

주요 증상

  • 브라우저에서는 정상적으로 접속되지만 터미널의 curl, 소프트웨어 업데이트 프로그램 또는 게임 플랫폼에서는 같은 도메인에 연결되지 않습니다.
  • 프록시 노드를 바꿔도 DNS 검사 결과에 로컬 인터넷 통신사의 리졸버가 계속 표시됩니다.
  • 규칙에서 도메인 매칭을 사용하지만 로그에는 IP만 표시되어 DOMAIN-SUFFIX 규칙이 예상대로 작동하지 않습니다.
  • TUN을 켜면 일부 사이트에서 잘못된 지역 콘텐츠가 표시되고, TUN을 끄면 정상으로 돌아옵니다.
  • 브라우저, nslookup 및 Clash 로그에서 같은 도메인에 서로 다른 주소가 반환됩니다.
  • fake-ip를 사용하도록 설정했는데 시스템 조회 결과가 공인 IP로 직접 반환되고 198.18.0.0/16 범위의 주소가 나오지 않습니다.

먼저 기준 상태를 기록하고 바로 설정을 바꾸지 않기

  1. 현재 클라이언트, 커널 버전 및 사용 중인 설정 파일 이름을 기록합니다.
  2. 실행 모드가 규칙, 전역 또는 직접 연결 중 무엇인지 확인하고 TUN과 시스템 프록시의 활성화 상태를 기록합니다.
  3. 브라우저와 시스템 DNS 캐시를 비운 뒤 테스트를 두 번 반복합니다.
  4. 브라우저, 명령줄 및 독립 실행 애플리케이션을 각각 테스트하여 한 프로그램의 동작을 시스템 전체의 결론으로 오해하지 않도록 합니다.
  5. Clash 로그에 DNS 요청, 규칙 매칭 및 연결 대상이 표시되는지 확인합니다.

시스템 프록시만 활성화한 경우 운영체제의 일반 DNS 조회가 반드시 가로채지는 않습니다. HTTP 또는 SOCKS 프록시는 애플리케이션 연결을 담당할 뿐이며, 시스템 리졸버는 네트워크 어댑터에 설정된 DNS 서버로 UDP 53 요청을 계속 보낼 수 있습니다. TUN 모드와 DNS 하이재킹을 함께 사용하면 더 많은 애플리케이션을 처리할 수 있지만, TUN, 라우팅, DNS 수신 주소 및 하이재킹 규칙이 실제로 적용되어야 합니다.

브라우저 검사 페이지와 명령줄로 교차 검증하기

브라우저 검사 페이지 올바르게 사용하기

일반적인 DNS leak test 페이지를 연 뒤 먼저 표준 테스트를 실행하고 확장 테스트를 진행합니다. 테스트 전 다른 프록시 확장 프로그램을 끄고 브라우저 창 하나만 남긴 다음 검사 페이지를 새로 고칩니다. 결과에는 보통 리졸버의 IP, 네트워크 조직 및 지역이 표시됩니다. 지역이 프록시 노드와 같은지만 보지 말고, 이 정보를 설정의 DoH, DoT 또는 일반 DNS 서비스 제공업체와 비교하세요.

브라우저가 자체 보안 DNS를 사용할 수 있습니다. Chrome, Edge 및 Firefox는 운영체제 리졸버를 우회하여 브라우저에 지정된 DoH 서비스로 직접 요청을 보낼 수 있습니다. 따라서 브라우저 검사 페이지는 해당 시점의 브라우저 경로만 보여 줄 뿐, 시스템 전체가 Clash에 의해 처리된다는 것을 단독으로 증명하지는 못합니다.

  • Chromium 계열 브라우저에서 「설정」→「개인정보 보호 및 보안」→「보안」→「보안 DNS 사용」을 확인합니다.
  • Firefox에서 「설정」→「개인정보 보호 및 보안」→「DNS over HTTPS」를 확인합니다.
  • Clash DNS 처리를 테스트할 때는 브라우저 보안 DNS를 일시적으로 끄고 검증을 마친 뒤 실제 운영 방침에 따라 다시 켤지 결정할 수 있습니다.
  • 브라우저 DoH를 유지한다면 이를 별도의 DNS 경로로 간주해야 하며, 이를 사용해 Clash의 dns 섹션을 검증해서는 안 됩니다.

Clash DNS 수신 포트에 직접 질의하기

설정에 listen: 127.0.0.1:1053이 있다고 가정하면, dig가 설치된 Windows, macOS 또는 Linux에서 다음과 같이 해당 포트로 직접 질의할 수 있습니다:

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

fake-ip 모드에서는 A 레코드가 보통 198.18.0.0/16 범위의 예약 주소를 반환하며, 예를 들어 198.18.0.23이 표시됩니다. 이 결과는 대상 웹사이트의 실제 주소가 아니라 커널이 도메인 매핑에 사용하는 가상 주소입니다. 이후 해당 주소로 연결되면 커널이 원래 도메인을 복원하고 규칙에 따라 프록시 정책을 선택합니다.

설정에서 enhanced-mode: redir-host를 사용하면 보통 실제 공인 IP가 반환됩니다. 이때 198.18.x.x가 나타나는지만으로 누출 여부를 판단할 수 없으며, 로그와 패킷 캡처 및 업스트림 리졸버 결과를 함께 확인해야 합니다.

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

Windows PowerShell에서 각 네트워크 어댑터의 DNS 주소를 확인할 수 있습니다:

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

결과가 여전히 라우터 주소(예: 192.168.1.1)라면 시스템 프록시만 사용하는 환경에서는 흔한 현상입니다. TUN을 켠 뒤 루프백 주소로 바꿔야 하는지는 클라이언트 구현에 따라 다릅니다. 많은 mihomo GUI 클라이언트는 네트워크 어댑터의 DNS를 영구적으로 변경하지 않고 DNS 하이재킹으로 UDP 53을 가로챕니다. 클라이언트 동작을 이해하지 못한 상태에서 모든 네트워크 어댑터를 수동으로 127.0.0.1로 바꾸지 마세요. 커널이 종료된 뒤 시스템 전체에서 도메인 조회가 되지 않을 수 있습니다.

Linux에서 systemd-resolved를 사용한다면 다음 명령을 실행할 수 있습니다:

resolvectl status
resolvectl query example.com

macOS에서는 시스템 리졸버 순서를 확인할 수 있습니다:

scutil --dns
dscacheutil -q host -a name example.com

패킷 캡처로 53번 포트에 직접 연결하는지 확인하기

검사 결과가 여전히 분명하지 않다면 테스트 중 DNS 트래픽을 캡처할 수 있습니다. Linux에서는 다음 명령으로 기존 UDP 및 TCP DNS 트래픽을 관찰합니다:

sudo tcpdump -ni any 'port 53'

Windows에서는 시스템에 포함된 pktmon을 사용하거나 네트워크 분석 도구에서 dns 또는 udp.port == 53 필터를 설정할 수 있습니다. 테스트 질의를 실행한 뒤 물리 네트워크 어댑터가 라우터나 통신사 DNS로 직접 패킷을 보내는 것이 보이면 기존 DNS가 예상 경로를 우회하고 있는 것입니다. DoH는 443번 포트, DoT는 853번 포트를 사용하므로 53번 포트만 필터링해서는 찾을 수 없습니다. 대상 IP, 프로세스 및 Clash 로그를 함께 확인해야 합니다.

fake-ip, redir-host 및 DNS 하이재킹 이해하기

fake-ip 처리 과정

  1. 애플리케이션이 시스템에 도메인 조회를 요청합니다.
  2. 조회 요청이 Clash DNS 리스너로 전송되거나 TUN의 DNS 하이재킹 규칙에 의해 가로채집니다.
  3. 커널이 198.18.0.0/16 범위의 가상 주소를 반환하고 가상 주소와 도메인의 매핑을 저장합니다.
  4. 애플리케이션이 해당 가상 주소에 연결하면 TUN 또는 투명 프록시 계층이 연결을 가로챕니다.
  5. 커널이 원래 도메인을 복원하고 도메인 규칙을 실행한 다음 정책 그룹에 따라 실제 연결을 수립합니다.

이 방식은 로컬에서 미리 조회하여 규칙에 필요한 정보가 사라지는 문제를 줄이고 도메인 기반 분류에도 유리합니다. 그렇다고 업스트림 DNS가 사라지는 것은 아닙니다. 커널은 프록시 서버 도메인, 직접 연결 대상 또는 일부 제외 도메인을 조회해야 할 수 있으므로 default-nameserver, nameserver, proxy-server-nameserver 및 규칙 동작을 올바르게 설정해야 합니다.

redir-host의 적용 범위

redir-host는 애플리케이션에 실제 IP를 반환하므로 호환성이 직관적인 편이지만, 도메인과 연결의 연관성이 스니핑, 캐시 및 매핑에 더 의존할 수 있습니다. 도메인 규칙이 많고 TUN 인계와 복잡한 트래픽 분류를 사용하는 경우 mihomo는 일반적으로 fake-ip가 더 적합합니다. 로컬 네트워크 장치 검색, 프린터, 게임 로그인, 사내망 또는 실제 DNS 결과에 의존하는 애플리케이션 문제가 있다면 fake-ip 전체를 끄기보다 먼저 특정 도메인을 fake-ip-filter에 추가하세요.

fake-ip-filter에 무엇을 넣어야 할까

필터 목록의 도메인은 가상 주소 처리를 건너뜁니다. 실제 장애를 기준으로 적용하고 범위가 지나치게 넓은 와일드카드 규칙은 피하세요. 일반적인 시작점은 다음과 같습니다:

fake-ip-filter:
  - "*.lan"
  - "*.local"
  - "localhost"
  - "time.*.com"
  - "time.*.gov"
  - "ntp.*.com"
  - "+.stun.*.*"
  - "+.stun.*.*.*"

*.local은 mDNS와 로컬 네트워크 서비스 검색에 주로 사용됩니다. NTP와 STUN 같은 프로토콜도 특수한 조회 방식이나 직접 주소 동작에 의존할 수 있습니다. mihomo 버전과 클라이언트 내장 템플릿에 따라 기본 필터 항목이 이미 포함되어 있을 수 있습니다. 구독 설정을 병합할 때는 최종 적용 설정을 먼저 확인하여 사용자 목록이 클라이언트의 호환성 규칙을 덮어쓰지 않도록 하세요.

DNS 하이재킹은 악의적인 변조가 아니다

TUN 설정에서 dns-hijack은 지정한 대상의 DNS 요청을 커널 처리로 리디렉션한다는 뜻입니다. 예를 들어 any:53은 모든 주소로 향하는 53번 포트 요청을 가로채는 데 사용됩니다. 이는 애플리케이션이 시스템 DNS를 우회하여 고정 서버에 직접 질의하는 문제를 해결합니다. 브라우저 DoH는 HTTPS를 사용하고 대상 포트가 443이므로 any:53에 의해 가로채지지 않습니다.

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

커널 버전에 따라 필드 형식과 프로토콜 지원이 다를 수 있습니다. 수정하기 전에 클라이언트의 「설정」→「커널」 또는 「정보」에서 실제로 mihomo를 사용하는지 확인하고 설정 검증 기능으로 문법을 검사하세요. 구독 원본만 편집하는 것으로는 충분하지 않습니다. 구독이 갱신되면 수정 내용이 덮어써질 수 있으므로 클라이언트가 제공하는 오버라이드, 병합 또는 Mixin 기능을 우선 사용하세요.

시작점으로 사용할 수 있는 mihomo DNS 설정

다음 설정은 필드 간 관계를 이해하기 위한 예시입니다. 수신 포트는 1053으로 지정하여 시스템에서 이미 사용하는 53번 포트 서비스와 직접 충돌하지 않게 했습니다. 실제 인계 방식은 클라이언트의 TUN 및 DNS 하이재킹 설정에 따라 결정됩니다.

dns:
  enable: true
  listen: 127.0.0.1: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:
    - tls://1.1.1.1:853
    - https://1.1.1.1/dns-query

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

  fake-ip-filter:
    - "*.lan"
    - "*.local"
    - "localhost"
    - "time.*.com"
    - "time.*.gov"
    - "ntp.*.com"
    - "+.stun.*.*"
    - "+.stun.*.*.*"

default-nameserver: 업스트림 서버 자체의 도메인 해결

default-nameserver는 DoH·DoT 업스트림 서버 또는 기타 기본 연결에 필요한 도메인을 조회하는 데 사용하며, 보통 직접 접속할 수 있는 IP 형식의 DNS를 입력합니다. 모든 서비스 도메인을 처리하는 유일한 리졸버는 아닙니다. 작동하는 부트스트랩 리졸버 없이 DoH 주소를 도메인 형식으로만 입력하면 순환 의존이 발생할 수 있습니다. DoH를 사용하려면 먼저 DoH 도메인을 조회해야 하지만, 현재 이를 조회할 서버가 없기 때문입니다.

nameserver: 주요 조회 경로

nameserver는 일반 도메인 조회에 사용되는 주요 업스트림입니다. 예시는 HTTPS DNS를 사용하여 장치와 리졸버 사이의 조회 내용을 암호화합니다. 두 업스트림은 가용성 확보를 위한 것이며, 목록 순서대로 반드시 하나씩 질의한다는 뜻은 아닙니다. 실제 동시 처리, 캐시 및 결과 선택은 커널 구현과 버전에 따라 달라집니다.

일반 UDP DNS는 223.5.5.5처럼 입력할 수도 있지만 조회 내용이 기존 DNS 형식으로 전송됩니다. DoT는 tls://1.1.1.1:853과 같은 형식을 사용하고, DoH는 완전한 HTTPS 주소를 사용합니다. 설정이 성공적으로 로드되었다고 해서 네트워크가 해당 포트에 접속할 수 있다는 뜻은 아닙니다. 로그에서 시간 초과, TLS 핸드셰이크 실패 또는 인증서 오류가 있는지도 확인해야 합니다.

fallback 및 fallback-filter: 결과에 따라 대체 리졸버 선택

fallback은 다른 리졸버 그룹을 제공하고 fallback-filter은 언제 대체 결과를 사용할지 결정합니다. 예시의 geoip: true와 geoip-code: CN은 IP 지리 데이터베이스를 이용해 결과를 판단하며, 240.0.0.0/4 같은 특수 주소 대역은 비정상 결과를 걸러내는 조건으로 사용할 수 있습니다.

이 메커니즘은 GeoIP 데이터의 정확성에 의존합니다. CDN 주소, Anycast 주소 및 새로 할당된 네트워크 대역은 잘못 분류될 수 있으므로 지역 판정을 절대적인 기준으로 삼아서는 안 됩니다. 특정 웹사이트가 fallback을 활성화했을 때만 이상하다면 먼저 두 리졸버 그룹이 각각 어떤 주소를 반환하는지 확인한 뒤 도메인 정책이나 필터 조건을 조정하세요.

ipv6: 네트워크 환경에 맞게 명확히 활성화하기

예시는 ipv6: false를 사용합니다. 로컬 네트워크에 안정적인 IPv6이 없거나 프록시 노드가 IPv6을 지원하지 않거나, 먼저 점검 범위를 줄이고 싶은 경우에 적합합니다. 로컬과 프록시 경로가 모두 IPv6을 완전히 지원한다면 true로 바꾸고 TUN 라우팅, 프록시 출구 및 AAAA 조회도 확인하세요. DNS의 AAAA 반환만 끄는 것으로 모든 IPv6 우회 문제가 해결되지는 않으며, 시스템에 이미 존재하는 IPv6 연결과 애플리케이션 내장 조회도 별도로 점검해야 합니다.

순서대로 DNS 우회 문제 해결하기

1단계: 최종 적용 설정 확인

구독 내용, 클라이언트 오버라이드 및 실행 중 설정이 함께 최종 설정을 만들 수 있습니다. 클라이언트의 「설정」→「현재 설정」 또는 「설정」→「실행 설정 보기」에서 dns.enable, enhanced-mode, 수신 주소 및 TUN 설정이 실제로 존재하는지 확인하세요. 메뉴 이름은 클라이언트마다 조금씩 다르지만, 확인 대상은 구독 다운로드 폴더의 원본 YAML이 아니라 커널이 실제로 로드한 설정이어야 합니다.

2단계: 포트가 수신 중인지 확인

Windows에서는 다음을 실행할 수 있습니다:

Get-NetTCPConnection -LocalPort 1053 -ErrorAction SilentlyContinue
Get-NetUDPEndpoint -LocalPort 1053 -ErrorAction SilentlyContinue

macOS 또는 Linux에서는 다음을 실행할 수 있습니다:

lsof -nP -iTCP:1053 -iUDP:1053
ss -lntup | grep 1053

수신 중인 항목이 없다면 먼저 커널 로그를 확인하세요. 흔한 원인으로는 YAML 들여쓰기 오류, 포트 사용 중, 클라이언트가 수정한 설정을 로드하지 않음, 보안 프로그램이 커널의 포트 바인딩을 차단함 등이 있습니다. 다른 포트(예: 1054)로 바꾸었다면 직접 질의 명령과 클라이언트 인계 설정도 함께 수정해야 합니다.

3단계: 직접 질의와 시스템 질의를 따로 검증

  1. dig @127.0.0.1 -p 1053을 사용하여 Clash DNS 자체가 응답하는지 확인합니다.
  2. 서버를 지정하지 않은 dig example.com 또는 nslookup example.com으로 시스템 기본 경로를 확인합니다.
  3. TUN을 켠 상태와 끈 상태에서 각각 테스트하고 반환된 주소를 기록합니다.
  4. 브라우저 검사 페이지를 열어 브라우저 보안 DNS가 결과에 영향을 주는지 확인합니다.
  5. 커널 로그에 테스트 도메인과 최종 매칭된 규칙 및 정책이 표시되는지 관찰합니다.

Clash에 직접 질의하면 정상인데 시스템 기본 질의가 여전히 라우터를 거친다면 문제는 nameserver 자체가 아니라 인계 계층에 있습니다. 이때는 TUN이 실제로 시작되었는지, 필요한 시스템 권한을 얻었는지, DNS 하이재킹이 적용되었는지, 현재 네트워크 어댑터가 제외되지 않았는지 확인하세요. 직접 질의도 시간 초과된다면 먼저 DNS 리스너 또는 업스트림 연결을 복구해야 합니다.

4단계: 캐시를 비운 뒤 다시 테스트

Windows 시스템 DNS 캐시 지우기:

ipconfig /flushdns

macOS에서는 다음을 실행할 수 있습니다:

sudo dscacheutil -flushcache
sudo killall -HUP mDNSResponder

Linux의 캐시 방식은 배포판에 따라 다릅니다. systemd-resolved를 사용한다면 다음을 실행할 수 있습니다:

sudo resolvectl flush-caches

그런 다음 브라우저를 완전히 종료하고 다시 엽니다. 웹페이지 새로 고침만으로는 브라우저 자체의 호스트 캐시와 기존 연결이 삭제되지 않습니다. 연결을 장시간 유지하는 메신저, 게임 플랫폼 및 동기화 도구도 프로세스를 종료한 뒤 다시 시작해야 합니다.

5단계: 브라우저와 애플리케이션 내장 DoH 처리

명령줄과 시스템 질의가 모두 Clash로 들어가는데 브라우저 검사 결과에 다른 리졸버 그룹이 표시된다면 먼저 브라우저 보안 DNS를 확인하세요. 일부 보안 소프트웨어, 기업용 클라이언트 및 모바일 애플리케이션에도 DoH가 내장되어 있습니다. 이들의 HTTPS 요청은 일반 웹 트래픽처럼 Clash를 통과할 수도 있고 규칙에 따라 직접 연결될 수도 있지만, 어느 경우에도 Clash의 로컬 DNS 모듈을 거치지는 않습니다.

처리 방법은 두 가지입니다. 애플리케이션 내장 DoH를 끄고 시스템이 일괄적으로 Clash를 사용하게 하거나, 애플리케이션 DoH를 유지하면서 별도의 라우팅 규칙을 명확히 지정할 수 있습니다. 전자는 중앙 관리와 장애 분석에 유리하고, 후자는 애플리케이션별 DNS 정책이 필요한 환경에 적합합니다. 확인되지 않은 업스트림을 여러 세트 동시에 관리하지 마세요. 애플리케이션과 도메인에 따라 검사 결과가 달라질 수 있습니다.

자주 발생하는 잘못된 설정과 수정 방법

nameserver만 작성하고 DNS를 활성화하지 않음

dns:
  enable: false
  nameserver:
    - https://dns.alidns.com/dns-query

enable: false이면 이후의 업스트림 설정이 예상한 로컬 DNS 서비스를 만들지 못합니다. true로 바꾼 뒤 수신 포트와 인계 방식을 확인하세요.

수신 주소를 로컬 네트워크에 노출함

listen: 0.0.0.0:1053은 모든 인터페이스에서 수신합니다. 로컬 네트워크 장치가 이 컴퓨터를 DNS 서버로 사용해야 할 때만 고려하고, 방화벽으로 접속 출처를 제한하세요. 단일 장치에서 사용할 때는 127.0.0.1:1053에 우선 바인딩하여 불필요한 로컬 네트워크 접근 면을 줄이는 것이 좋습니다.

fake-ip 반환값을 오염된 결과로 오해함

198.18.x.x는 fake-ip에서 정상적으로 사용하는 가상 주소 범위입니다. 이 주소가 보이면 hosts에 기록하거나 곧바로 직접 연결 규칙에 추가하지 말고 애플리케이션 연결과 규칙 매칭을 계속 테스트하세요. 특정 애플리케이션이 실제로 호환되지 않는다면 해당 도메인을 fake-ip-filter에 정확히 추가합니다.

여러 프로그램이 동시에 53번 포트를 사용함

로컬 광고 차단기, 가상 머신 소프트웨어, 컨테이너 서비스 및 다른 프록시 도구가 53번 포트를 수신할 수 있습니다. 두 프로그램이 같은 주소와 프로토콜에서 하나의 포트를 안정적으로 공유할 수는 없습니다. Clash를 1053에서 수신하게 한 뒤 앞단 DNS가 해당 포트로 전달하게 하거나, 충돌하는 서비스를 중지하고 Clash가 통합 관리하도록 할 수 있습니다. 변경 후에는 UDP와 TCP 수신 상태를 모두 확인해야 합니다.

시스템 프록시가 전역 DNS 인계와 같다고 오해함

시스템 프록시는 주로 HTTP 프록시 설정을 지원하는 애플리케이션에 영향을 줍니다. DNS, 게임 트래픽, 명령줄 도구 및 시스템 프록시를 읽지 않는 프로그램은 계속 직접 연결할 수 있습니다. 더 폭넓게 인계하려면 TUN을 사용하고 자동 라우팅, 네트워크 어댑터 감지, DNS 하이재킹 및 시스템 권한이 모두 적용되었는지 확인하세요. TUN은 단순히 “더 강한 프록시”를 켜는 기능도 아닙니다. 네트워크 스택 경로가 바뀌므로 문제를 진단할 때는 한 번에 하나의 옵션만 변경해야 합니다.

수정 후 확인 체크리스트

  • 커널 로그에 DNS 업스트림 시간 초과, 수신 실패 또는 설정 필드 오류가 없습니다.
  • dig @127.0.0.1 -p 1053이 정상적인 지연 시간 내에 결과를 반환합니다.
  • fake-ip 모드에서 테스트 도메인이 198.18.0.0/16 범위의 주소를 반환합니다.
  • TUN을 켠 뒤 시스템 기본 질의에 해당하는 도메인을 Clash 로그에서 찾을 수 있습니다.
  • 물리 네트워크 어댑터의 패킷 캡처에 예상하지 않은 직접 UDP 또는 TCP 53번 질의가 더 이상 나타나지 않습니다.
  • 브라우저 보안 DNS의 활성화 상태가 현재 구성과 일치하며, 확인되지 않은 독립 경로가 더 이상 생기지 않습니다.
  • DNS 검사 페이지에 표시되는 리졸버가 nameserver 및 fallback 설계와 일치합니다.
  • 로컬 네트워크, NTP, STUN 또는 기업 내부망 도메인이 호환되지 않는 경우 정확한 fake-ip-filter 규칙으로 처리했습니다.
  • 구독 갱신 후에도 오버라이드가 유지되며 클라이언트와 장치를 다시 시작해도 결과가 변하지 않습니다.

DNS 누출 문제를 해결하는 핵심은 경로를 나누어 확인하는 것입니다. 먼저 Clash DNS가 응답할 수 있는지 확인하고, 다음으로 운영체제 질의가 커널에 들어오는지 확인한 뒤, 브라우저와 애플리케이션에 별도의 DoH가 있는지 점검하세요. 검사 페이지, 명령줄, 로그 및 패킷 캡처 결과가 서로 일치해야 합니다. nameserver 주소 하나만 바꾸는 것으로는 보통 인계 계층 문제가 해결되지 않습니다. 수신, 하이재킹, 업스트림 및 애플리케이션 동작이 모두 일치해야 조회 경로가 안정적이라고 할 수 있습니다.