문제 해결 예상 읽기 시간 12분

Clash DNS 누수 검사 방법과 누수 방지 설정 실전: enhanced-mode 및 nameserver 구성

DNS 누수 검사 사이트의 결과를 해석하고, dns의 enhanced-mode·fake-ip 필터·nameserver 설정과 수정 결과 확인 방법을 안내합니다.

먼저 검사 대상을 구분하세요: 외부 IP와 DNS 조회 경로는 다릅니다

브라우저로 웹사이트에 접속할 때는 보통 먼저 도메인을 DNS 리졸버에 전달한 뒤, 조회된 IP 주소로 연결합니다. Clash가 웹 연결을 인계했다고 해서 DNS 요청까지 반드시 같은 처리 경로를 거치는 것은 아닙니다. 웹페이지에는 프록시 노드의 외부 IP가 표시되지만, 검사 페이지에는 여전히 로컬 인터넷 서비스 제공업체, 라우터가 내려준 리졸버 또는 시스템에 수동으로 입력한 공용 DNS가 표시되는 경우가 흔합니다. 문제를 점검할 때는 ‘연결 외부 경로’와 ‘도메인 조회 경로’를 나누어 기록해야 합니다.

DNS 검사 페이지에 표시되는 것은 보통 검사 도메인의 재귀 조회를 수행한 리졸버의 외부 주소이며, 컴퓨터가 요청을 직접 보낸 대상 주소가 아닙니다. 예를 들어 시스템이 라우터의 192.168.1.1에 조회를 요청하고 라우터가 다시 통신사에 요청을 전달하면, 검사 결과에는 통신사의 재귀 서버만 표시될 수 있습니다. DoH를 사용하면 클라우드 서비스 제공업체의 애니캐스트 노드, 협력 네트워크 또는 실제 노드와 다른 도시가 표시될 수도 있습니다. 따라서 도시가 다르다는 이유만으로 이상을 단정할 수 없으며, 통신사명, 자율시스템, 요청 수와 반복 검사 결과를 함께 확인해야 합니다.

재현 가능한 세 가지 테스트 구성

  1. 현재 공인 IP, 네트워크 통신사와 지역을 기록한 뒤 Clash를 잠시 종료하고 기준선 검사를 한 번 진행합니다.
  2. Clash를 실행하되 TUN은 먼저 끄고 시스템 프록시만 켠 다음, 시크릿 창에서 두 번째 검사를 진행합니다.
  3. 이 글의 설정과 TUN DNS 하이재킹을 활성화하고 캐시를 삭제한 뒤 연결을 새로 수립하여 세 번째 검사를 진행합니다.

각 라운드에서 표준 테스트와 확장 테스트를 한 번씩 실행하고, 리졸버 수·조직명·국가 또는 지역을 저장하는 것이 좋습니다. 단일 결과는 브라우저 캐시, 검사 사이트의 부하와 DNS 애니캐스트 조정의 영향을 받기 쉽습니다. 실험 기록은 30초 간격으로 3라운드 연속 실행할 수 있습니다. 같은 통신사 리졸버가 3라운드 모두 나타난다면, 한 번만 우연히 나타난 경우보다 경로 문제를 더 명확하게 판단할 수 있습니다.

관찰 항목 정상적인 의미 추가 확인이 필요한 결과
웹 외부 IP 현재 프록시 노드의 외부 IP와 일치 여전히 로컬 유선 또는 모바일 네트워크 주소
DNS 조직 설정한 DoH 서비스 또는 예상한 원격 조회 경로와 일치 로컬 통신사, 가정용 라우터의 상위 DNS 또는 사내망 리졸버가 표시됨
리졸버 수 개수가 안정적이고 반복 검사 간 변화가 적음 로컬 리졸버와 원격 리졸버가 동시에 섞여 있음
IPv6 결과 설정한 IPv6 옵션 및 프록시 기능과 일치 IPv4는 프록시를 거치지만 IPv6 연결 또는 조회가 예상 경로를 우회함

누수가 시스템 프록시, TUN 또는 브라우저 DoH에서 발생하는지 확인

시스템 프록시는 주로 HTTP 또는 SOCKS 프록시를 지원하는 애플리케이션의 트래픽을 인계합니다. 기존 UDP 53 DNS 요청은 일반적으로 시스템 프록시의 처리 범위에 포함되지 않으므로, 시스템 프록시만 켜면 운영체제가 여전히 네트워크 어댑터에 설정된 DNS 주소로 패킷을 보낼 수 있습니다. Clash의 혼합 포트는 보통 7890이며 이는 프록시 인바운드 포트이지 시스템 DNS 포트가 아닙니다. 시스템 DNS를 127.0.0.1:7890으로 직접 지정해도 사용할 수 있는 DNS 서비스가 되지 않습니다.

TUN 모드는 네트워크 계층에서 트래픽을 인계하며 dns-hijack과 함께 사용하면 53번 포트로 향하는 DNS 요청을 가로채 mihomo 내장 DNS 모듈로 전달할 수 있습니다. 시스템 프록시 설정을 따르지 않는 프로그램, 게임 런처와 일부 명령줄 도구에는 이 경로가 더 완전합니다. 다만 애플리케이션이 직접 수립한 DoH 또는 DoT 연결은 일반 HTTPS 또는 TLS 트래픽으로 처리되므로, 53번 포트 하이재킹만으로 해당 리졸버 선택을 바꿀 수는 없습니다.

요청 출처별로 하나씩 확인하기

클라이언트마다 메뉴 명칭은 다르지만 점검 목표는 같습니다. 원본 YAML 편집을 지원하는 데스크톱 클라이언트를 예로 들면, 「구독」→ 현재 설정 오른쪽 메뉴 →「파일 편집」에서 설정 텍스트를 열 수 있습니다. 저장한 뒤에는 「구독」→ 현재 설정 →「다시 불러오기」도 실행해야 합니다. TUN은 보통 「설정」→「Clash 설정」→「TUN 모드」에 있습니다. 구독 업데이트가 로컬 파일을 덮어쓴다면 구독 캐시를 직접 장기간 수정하지 말고, 오버라이드 또는 병합 설정 기능으로 DNS 항목을 저장하세요.

enhanced-mode, nameserver 및 부트스트랩 리졸버 설정

다음 예시는 mihomo v1.19.10의 설정 구조를 기준으로 합니다. 핵심 관계는 다음과 같습니다. default-nameserver는 DoH 서버 자체의 도메인을 조회하고, nameserver는 일반 도메인 조회를 담당하며, proxy-server-nameserver는 프록시 서버 도메인을 별도로 처리할 수 있습니다. nameserver-policy는 도메인 또는 규칙 집합에 따라 리졸버를 지정합니다. 부트스트랩 리졸버는 IP 주소를 사용해야 DoH 도메인을 조회할 때 아직 연결되지 않은 동일한 DoH 서비스에 다시 의존하는 일을 피할 수 있습니다.

dns:
  enable: true
  listen: 0.0.0.0:1053
  ipv6: true
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  fake-ip-filter-mode: blacklist
  fake-ip-filter:
    - "*.lan"
    - "*.local"
    - "localhost"
    - "time.*.com"
    - "ntp.*.com"

  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

  nameserver-policy:
    "geosite:cn":
      - https://dns.alidns.com/dns-query
    "geosite:geolocation-!cn":
      - https://1.1.1.1/dns-query

fake-ip가 규칙 분기에 유용한 이유

enhanced-mode: fake-ip를 활성화하면 mihomo는 먼저 애플리케이션에 198.18.0.0/16 범위의 예약 주소를 반환하고, 도메인과 가상 주소 사이의 매핑을 저장합니다. 애플리케이션이 이 주소에 연결하면 커널이 원래 도메인을 복원한 뒤 DOMAIN, DOMAIN-SUFFIX, GEOSITE 등의 규칙으로 매칭할 수 있습니다. 도메인 정보를 유지하면서 애플리케이션이 시스템 조회 결과를 직접 사용해 대상 IP만 남는 상황도 줄일 수 있습니다.

fake-ip는 실제 공인 주소를 영구적으로 바꾸는 기능이 아니라 커널 내부의 매핑 방식입니다. 최종 연결을 수립할 때는 정책에 따라 실제 대상 주소를 조회하고 연결합니다. 도메인 규칙에 의존하는 일반적인 설정에 적합하지만, LAN 검색·프린터·시간 동기화·일부 게임 로그인·IP 리터럴 검사를 사용하는 프로그램은 가상 주소를 받아들이지 못할 수 있으므로 필터 목록이 필요합니다.

redir-host는 어떤 경우에 적합한가

enhanced-mode: redir-host는 애플리케이션에 실제 조회 결과를 반환하므로 호환성이 더 직접적인 편이지만, 도메인 매핑과 규칙 매칭 동작은 fake-ip와 다릅니다. 오래된 프로그램이 fake-ip에서 계속 연결에 실패한다면 먼저 해당 도메인을 필터 목록에 추가하세요. 장애 범위가 넓고 도메인을 특정하기 어려울 때만 일시적으로 redir-host로 전환해 비교 테스트를 진행하는 것이 좋습니다. enhanced-mode를 바꾼 뒤에는 반드시 DNS 캐시를 삭제하고 새 연결을 만들어야 기존 기록이 결론을 방해하지 않습니다.

TUN에 DNS 하이재킹과 엄격한 라우팅 추가

dns 항목만 설정해서는 충분하지 않습니다. 시스템이 다른 DNS 서버의 53번 포트로 보내는 요청을 내장 DNS로 유입해야 합니다. mihomo의 TUN 설정에서는 dns-hijack: any:53으로 이러한 요청을 가로챌 수 있습니다. auto-route는 라우팅을 추가하고, strict-route는 일부 플랫폼에서 트래픽이 다른 인터페이스로 우회할 가능성을 줄입니다. 운영체제마다 필요한 권한이 다르며, Windows는 보통 관리자 권한이 필요하고 Linux는 TUN 생성 및 라우팅 변경 권한이 필요합니다.

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

any:53은 일반적인 DNS 요청을 처리하며, tcp://any:53을 추가하면 TCP 53을 사용하는 조회도 포함할 수 있습니다. DNS 응답이 UDP가 전달할 수 있는 크기를 넘거나 서버가 재시도를 요구하거나 애플리케이션이 TCP를 직접 선택할 때 후자의 설정이 사용됩니다. 이 설정만으로 브라우저 내장 DoH가 자동 차단되지는 않습니다. DoH는 443번 포트를 사용하기 때문입니다. 모든 브라우저가 Clash DNS를 따르게 하려면 브라우저의 「설정」→「개인정보 보호 및 보안」→「보안 DNS」에서 시스템 제공업체를 선택하거나 사용자 지정 제공업체를 끈 뒤 다시 테스트하세요.

리스닝 포트와 포트 충돌

예시에서는 mihomo DNS의 리스닝 주소로 0.0.0.0:1053을 사용합니다. 1053은 비특권 포트라 로컬 디버깅에 편리합니다. TUN 하이재킹이 53번 포트 요청을 해당 모듈로 전달하므로, 일반적으로 시스템 네트워크 설정에 포트가 포함된 DNS 주소를 입력할 필요가 없습니다. 다른 로컬 DNS 프로그램이 이미 1053을 사용 중이면 커널 로그에 바인딩 실패가 나타납니다. Windows에서는 netstat -ano | findstr :1053으로 사용 여부를 확인하고, Linux에서는 ss -lntup | grep 1053으로 리스닝 프로세스를 확인할 수 있습니다.

TUN을 사용하지 않고 시스템이 로컬 DNS에 직접 조회하도록 하는 구성에서는 시스템이 보통 표준 53번 포트만 허용합니다. 이 경우 DNS 서비스가 127.0.0.1:53에서 수신하도록 설정하고 포트 권한 및 충돌 여부를 확인해야 합니다. 이 방식은 플랫폼 네트워크 설정과 관련되어 네트워크 전환, VPN 소프트웨어 또는 DHCP 갱신으로 덮어써지기 쉽습니다. 데스크톱 Clash Meta 클라이언트에서는 TUN과 DNS 하이재킹을 함께 사용하는 편이 일관성을 유지하기 쉽습니다.

fake-ip-filter를 정밀하게 설정해 LAN 및 특수 프로토콜 장애 방지

필터 목록의 도메인은 fake-ip 응답을 건너뛰고 실제 주소를 사용합니다. 목록이 너무 짧으면 장치 검색, LAN 관리 페이지 또는 시간 동기화에 문제가 생길 수 있고, 너무 넓으면 많은 도메인이 일찍 실제 IP로 변환되어 도메인 매핑 기반 처리의 효과가 약해집니다. 설정 원칙은 장애 로그에서 구체적인 도메인을 추출하고, 가장 좁은 접미사나 전체 도메인을 우선 추가하는 것입니다. 대형 최상위 도메인 전체를 한꺼번에 제외하지 마세요.

dns:
  fake-ip-filter:
    - "*.lan"
    - "*.local"
    - "router.asus.com"
    - "time.windows.com"
    - "time.apple.com"
    - "stun.*"
    - "+.msftconnecttest.com"
    - "+.msftncsi.com"

*.lan과 *.local은 주로 가정용 LAN과 로컬 검색을 위한 항목입니다. 시간 서버가 실제 주소를 반환하면 직접 UDP 통신만 허용하는 일부 시스템 서비스에 도움이 됩니다. 네트워크 연결 상태 확인 도메인은 시스템의 ‘인터넷 연결 여부’ 판단에 영향을 줄 수 있습니다. 실제로 추가하기 전에는 클라이언트 로그의 조회 도메인을 확인하세요. 운영체제 버전에 따라 사용하는 확인 도메인이 완전히 같지는 않습니다.

LAN 도메인은 어느 DNS에 맡겨야 할까

회사 또는 가정 내부 도메인을 라우터만 조회할 수 있다면 nameserver-policy로 지정한 접미사를 내부 DNS에 전달할 수 있습니다. 예를 들어 라우터 DNS가 192.168.1.1이고 내부 도메인이 home.arpa라면 해당 접미사에만 정책을 설정할 수 있습니다. 사용 전에 해당 주소가 실제로 재귀 조회를 제공하는지 확인하고, 공용 네트워크에서 기존 LAN 주소를 계속 사용하지 않도록 주의하세요.

dns:
  nameserver-policy:
    "+.home.arpa":
      - 192.168.1.1
    "+.corp.example":
      - 10.20.0.53

내부 DNS 주소는 보통 직결로 처리해야 합니다. 그렇지 않으면 조회가 프록시 노드로 전송되어 접근하지 못할 수 있습니다. 클라이언트가 설정 병합을 지원한다면 LAN 전용 정책을 특정 네트워크에서만 활성화되는 로컬 오버라이드에 저장할 수 있습니다. 노트북을 회사 네트워크에서 가정 네트워크로 전환한 뒤에는 10.20.0.53 같은 사설 주소가 계속 참조되고 있지 않은지 확인해 매번 조회가 시간 초과로 지연되는 일을 막으세요.

캐시를 삭제하고 수정 결과 확인

DNS 설정을 바꿔도 기존 연결과 여러 계층의 캐시는 즉시 사라지지 않습니다. 운영체제, 브라우저, 애플리케이션과 mihomo 커널이 모두 조회 결과를 보관할 수 있습니다. 확인하기 전에 설정을 다시 불러오고 TUN을 껐다가 다시 켠 다음 시스템 DNS 캐시를 삭제하세요. Windows에서는 ipconfig /flushdns를 실행하고, systemd-resolved를 사용하는 Linux에서는 resolvectl flush-caches를 실행합니다. macOS에서는 sudo dscacheutil -flushcache를 실행한 뒤 mDNSResponder를 재시작하세요. 브라우저는 모든 창을 닫았다가 다시 열거나 새 시크릿 창을 사용해야 합니다.

비교 가능한 실제 테스트 기록

Windows 11 24H2, mihomo v1.19.10, 가정용 인터넷과 IPv4/IPv6 듀얼 스택 환경에서 기준선 확장 테스트로 20건의 조회를 실행했으며, 로컬 통신사의 재귀 리졸버 2개가 결과에 표시되었습니다. 시스템 프록시만 활성화하자 웹 외부 IP는 프록시 노드로 바뀌었지만, 20건의 조회는 여전히 같은 통신사 리졸버 그룹에서 처리되었습니다. fake-ip, 두 그룹의 DoH nameserver, TUN과 any:53 하이재킹을 활성화한 뒤 3라운드 연속 테스트에서는 설정한 공용 DNS 네트워크만 표시되었고 로컬 통신사 리졸버는 더 이상 나타나지 않았습니다.

이 수치는 전후 비교 방식을 설명하기 위한 예시이며, 모든 네트워크에서 같은 개수가 나와야 한다는 뜻은 아닙니다. 공용 DNS는 애니캐스트를 사용하므로 검사 페이지에 라운드마다 1~4개의 엣지 노드가 표시될 수 있습니다. 조직 소속이 설정 목표와 일치하고 로컬 조회 경로가 섞이지 않으며 웹 외부 IP가 규칙의 예상과 일치한다면 수정이 정상적으로 적용된 것으로 볼 수 있습니다. 두 종류의 리졸버가 동시에 나타난다면 브라우저 DoH, IPv6 라우팅 또는 시스템 DNS를 우회하는 백그라운드 애플리케이션을 계속 확인해야 합니다.

테스트 단계 웹 외부 IP DNS 검사 결과 결론
Clash 종료 로컬 인터넷 회선 통신사 리졸버 2개 기준선 기록
시스템 프록시만 사용 프록시 노드 여전히 통신사 리졸버 2개 DNS가 시스템 프록시로 인계되지 않음
TUN 및 DNS 하이재킹 프록시 노드 공용 DoH 네트워크 조회 경로가 설정과 일치

명령줄 교차 검증

브라우저 검사 외에도 mihomo의 1053 포트로 직접 조회해 내장 DNS가 응답하는지 확인할 수 있습니다. Windows에서 지정 포트를 지원하는 도구를 설치한 뒤 dig @127.0.0.1 -p 1053 example.com을 사용할 수 있으며, Linux와 macOS에서도 같은 명령을 실행할 수 있습니다. fake-ip 모드에서 198.18.0.0/16 범위의 주소가 반환되는 것은 정상적인 현상입니다. 요청이 시간 초과되면 규칙 그룹을 계속 조정하기보다 먼저 리스닝 포트와 커널 로그를 확인하세요.

그 다음 nslookup example.com 같은 시스템 기본 조회를 실행합니다. TUN 하이재킹이 켜져 있으면 명령에 표시되는 서버 이름이 여전히 라우터 또는 시스템 설정 주소로 나타나더라도 실제 53번 포트 트래픽은 이미 커널이 가로챘을 수 있습니다. 따라서 최종 판단은 mihomo 로그, 검사 사이트 결과와 전후 비교를 함께 바탕으로 내려야 하며, nslookup 첫 줄에 표시되는 서버만 봐서는 안 됩니다.

자주 발생하는 이상과 해결 방법

설정 후 모든 도메인 조회가 실패함

검사는 정상인데 일부 애플리케이션에 로그인할 수 없음

먼저 로그에서 애플리케이션이 접속하는 도메인을 찾고, 하나씩 fake-ip-filter에 추가해 범위를 좁혀 확인하세요. STUN, LAN 검색, NTP 또는 연결 상태 확인과 관련된 경우에는 실제 IP 응답이 더 적합한 경우가 많습니다. 전체 도메인을 추가한 뒤 정상으로 돌아온다면 같은 서비스 접미사까지 확대할 필요가 있는지 검토하세요. 처음부터 모든 도메인을 필터링하면 어떤 요청이 fake-ip와 호환되지 않는지 판단할 수 없습니다.

IPv4는 정상인데 IPv6에는 여전히 로컬 네트워크가 표시됨

프록시 노드와 선택한 DNS가 예상한 IPv6 동작을 지원하는지 확인하세요. 현재 프록시 경로가 IPv6를 처리하지 못한다면 비교를 위해 dns.ipv6을 false로 임시 설정하고 검사 페이지에서 AAAA 결과가 사라지는지 확인할 수 있습니다. 동시에 TUN이 IPv6 기본 경로를 포함하는지도 점검하세요. 장기적으로는 노드 성능에 따라 IPv6를 완전히 인계할지, 시스템과 DNS 양쪽에서 관련 경로를 일관되게 비활성화할지 결정해야 하며, 한쪽 옵션만 바꾸는 방식은 피해야 합니다.

구독 업데이트 후 설정이 원래대로 돌아감

구독 파일은 원격에서 생성되므로 새로 고칠 때 로컬 캐시를 교체합니다. 클라이언트의 오버라이드, 설정 병합 또는 스크립트 확장 기능에 DNS와 TUN 설정을 저장해야 합니다. 일반적인 경로는 「구독」→ 현재 설정 오른쪽 메뉴 →「오버라이드 설정」입니다. 완료 후 「구독」→「업데이트」를 실행하고 설정 미리보기를 다시 열어 enhanced-mode, nameserver, dns-hijack이 여전히 포함되어 있는지 확인하세요.

Clash 클라이언트 다운로드 Windows, macOS, Android, iOS 및 Linux 지원