Clash DNS 누수 테스트 및 차단 설정: fake-ip·nameserver-policy 실전 가이드

DNS 누수 판단 기준: 이름 확인 경로와 연결 출구

Clash로 웹페이지가 열린다고 해서 모든 DNS 요청이 예상한 경로를 거치는 것은 아닙니다. 브라우저는 HTTP 프록시로 연결을 보낼 수도 있고, 미리 시스템 리졸버를 호출할 수도 있습니다. 백그라운드 앱은 시스템 프록시를 무시할 수 있으며, 브라우저의 보안 DNS가 별도의 HTTPS 조회 연결을 만들기도 합니다. 문제를 점검할 때는 도메인 이름을 어디서 조회하는지와 조회 요청이 어떤 경로로 나가는지를 따로 기록해야 합니다.

이 글에서 ‘DNS 누수’는 지정된 조회 경로를 거쳐야 하는 도메인 조회가 실제로는 로컬 네트워크, 통신사 또는 그 밖의 예상하지 않은 DNS 서비스로 전달되는 경우를 뜻합니다. 중국 본토에서 직접 연결할 서비스를 위해 로컬 DNS를 지정했다면, 테스트 페이지에 중국 주소가 표시된다는 이유만으로 누수라고 판단해서는 안 됩니다. 판단 기준은 결과에 특정 국가명이 있는지가 아니라 사전에 정한 분기 정책입니다.

관찰 결과	실제 의미	다음 확인 사항
웹사이트 접속 출구가 변경됨	현재 웹페이지 연결이 프록시를 통과함	DNS를 별도로 확인해야 하며, 이 결과만으로 DNS 출구를 판단할 수 없음
통신사 DNS 리졸버가 감지됨	테스트 도메인을 해당 재귀 DNS 서비스가 최종 조회함	시스템 DNS, 브라우저 보안 DNS, 분기 정책 확인
여러 DNS 리졸버가 감지됨	병렬 조회, 전달 또는 여러 출구가 사용될 수 있음	nameserver, fallback 및 테스트 조건 비교
198.18 대역 주소가 반환됨	Fake-IP 매핑이 적용되었을 수 있음	트래픽이 동일한 코어로 돌아오는지 추가 확인

테스트 준비: 클라이언트, 브라우저, 네트워크 조건 고정

아래 설정은 mihomo 코어를 기준으로 합니다. Clash Meta는 mihomo의 이전 명칭이며, 구형 Clash 원본과 업데이트가 중단된 클라이언트는 모든 필드를 지원하지 않을 수 있습니다. 먼저 클라이언트의 ‘정보’ 또는 코어 정보 화면에서 코어 이름과 버전을 확인한 뒤 현재 설정을 내보내세요. 클라이언트 버전과 코어 버전을 각각 기록하고, ‘Clash 최신 버전’처럼 뭉뚱그려 적지 마세요.

되돌릴 방법을 확보하세요. 구독 설정과 로컬 오버라이드를 내보내고 시스템 프록시, TUN, 브라우저 보안 DNS의 기존 설정 상태를 기록해 두세요.
테스트 조건을 통일하세요. 같은 네트워크, 같은 노드, 같은 브라우저에서 비교하고 테스트 중에는 다른 VPN 및 프록시 도구를 일시 중지하세요.
먼저 브라우저 자체 DNS 조회를 확인하세요. Chrome은 ‘설정’ → ‘개인 정보 보호 및 보안’ → ‘보안’에서 ‘보안 DNS 사용’을 찾으세요. Firefox는 ‘설정’ → ‘개인 정보 및 보안’에서 ‘HTTPS를 통한 DNS’를 확인하세요. 메뉴 이름은 버전에 따라 달라질 수 있습니다.
설정이 실제로 적용되는 위치를 확인하세요. 구독 원본 파일은 업데이트할 때 덮어써질 수 있습니다. 클라이언트에서 제공하는 로컬 오버라이드 또는 병합 기능으로 변경 사항을 유지하고, 최종 실행 설정을 확인하세요.

온라인 DNS 누수 테스트: 위치만 보지 말고 조건별로 비교

DNSLeakTest를 열어 먼저 Standard test를 실행한 다음 Extended test를 실행하세요. 테스트 사이트는 임의의 하위 도메인을 이용해 재귀 DNS가 권한 DNS 서버에 질의하는 방식을 관찰합니다. 따라서 결과에는 보통 DNS 서비스의 출구가 표시되며, 시스템 설정에 입력한 서버 주소나 프록시 노드 주소가 표시되는 것은 아닙니다.

세 가지 테스트 결과 기록 방법

기준선: 클라이언트의 프록시 처리를 끈 상태에서 한 번 테스트하고 DNS 리졸버 IP, 운영 주체, 현재 네트워크를 기록하세요.
시스템 프록시: 클라이언트의 시스템 프록시를 켜고 TUN은 끈 상태에서 다시 테스트하세요. 결과가 바뀌지 않았다면 테스트 경로가 여전히 기존 DNS 조회 경로를 사용할 가능성이 있다는 뜻입니다.
TUN 처리: 아래의 DNS 및 TUN 설정을 적용한 뒤 테스트하고, 동일한 항목을 기록하세요. 클라이언트의 연결 패널에서도 DNS 연결을 확인하세요.

각 조건에서 두 번씩 테스트하는 것을 권장합니다. 결과가 다르면 노드를 바로 바꾸지 말고 캐시, 브라우저 보안 DNS, 여러 업스트림의 병렬 조회부터 확인하세요. 공용 DNS 서비스는 애니캐스트와 분산형 출구를 사용할 수 있어 테스트 페이지의 국가나 도시 표시가 정확하지 않을 수 있습니다. 표시된 운영 주체가 예상과 맞는지, 특정 DNS 경로를 끈 뒤 결과가 달라지는지를 중점적으로 비교하세요.

온라인 테스트는 브라우저가 시작한 테스트 조회만 확인하므로 시스템의 모든 앱이 DNS 처리되고 있음을 증명하지는 않습니다. 로컬에서도 조회를 실행하고, 필요한 경우 물리 네트워크 인터페이스의 트래픽을 살펴보세요. 구독 링크, 접속 도메인 또는 접근 토큰이 포함된 전체 로그를 공개 커뮤니티에 그대로 올리지 마세요.

fake-ip 기본 설정: 도메인과 연결을 올바르게 연결하기

Fake-IP 모드에서는 먼저 앱에 가상 주소를 반환하고, 이후 코어가 매핑을 통해 도메인을 복원해 규칙을 적용합니다. 연결 전에 실제 DNS 조회에 의존하는 경우를 줄일 수 있지만, 암호화 프로토콜은 아니며 모든 DNS를 자동으로 가로채지도 않습니다. 앱이 가상 주소를 받은 뒤 코어를 우회해 연결하면 오히려 시간 초과가 발생할 수 있습니다.

아래는 설정 병합용 조각이며 전체 구독 설정이 아닙니다. 기존 프록시 노드, 정책 그룹, 규칙은 유지해야 합니다. 실행 설정에 이미 dns:가 있다면 하위 필드를 병합하고, 파일 끝에 같은 최상위 키를 중복 추가하지 마세요.

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"
  default-nameserver:
    - 223.5.5.5
  proxy-server-nameserver:
    - https://223.5.5.5/dns-query
  nameserver:
    - https://1.1.1.1/dns-query
  nameserver-policy:
    "+.qq.com":
      - https://dns.alidns.com/dns-query

listen은 DNS 서비스를 로컬 1053 포트에만 바인딩합니다. 일반적인 시스템 DNS 설정에서는 포트를 지정할 수 없으므로 127.0.0.1만 입력했다고 DNS가 처리되는 것은 아닙니다.
default-nameserver는 DNS 서버 자체의 도메인을 조회하는 부트스트랩 DNS용입니다. 일반 도메인에 사용하는 기본 업스트림 DNS가 아닙니다.
proxy-server-nameserver는 프록시 노드의 도메인을 조회할 경로를 지정해 노드 이름 조회와 프록시 연결 사이의 순환 의존성을 줄입니다.
nameserver-policy의 +.qq.com은 해당 도메인과 하위 도메인에 일치하며, 지정한 업스트림으로 전달합니다. 별도의 규칙이 조회 방식을 변경하지 않는 한 나머지 도메인은 nameserver를 사용합니다.
fake-ip-filter에 일치하는 도메인에는 실제 조회 결과가 반환됩니다. 그렇다고 해당 도메인이 직접 연결로 설정되는 것은 아니며, 공용 DNS가 로컬 네트워크 이름을 조회해 준다는 보장도 없습니다.

이 예시에서는 초기 문제 해결 변수를 줄이기 위해 DNS의 AAAA 응답을 일시적으로 끕니다. 운영체제의 IPv6를 비활성화하는 설정은 아니며 앱이 캐시된 IPv6 주소를 사용하는 것도 막지 않습니다. IPv6가 필요한 환경에서는 관련 기능을 다시 활성화하고 IPv6 라우팅, DNS, 프록시 처리가 모두 정상인지 확인하세요. 경로 문제를 감추기 위해 하나의 설정을 계속 꺼 두지 마세요.

fallback 필터: 응답을 선택하는 기능이지 외부 조회를 차단하는 기능이 아닙니다

fallback은 ‘주 DNS가 시간 초과된 뒤에만 보조 서버에 접속한다’는 뜻으로 오해하기 쉽습니다. 일반적인 설정에서는 기본 업스트림과 fallback이 병렬로 조회된 뒤 필터 조건에 따라 사용할 응답을 선택할 수 있습니다. 따라서 같은 도메인 조회가 여러 DNS 서비스에 노출될 수 있으며, ‘하나의 DNS 서비스만 허용된다’는 증거로 사용할 수 없습니다.

아래는 중국 내 주소를 우선하는 별도 설정 예시입니다. 이 방식을 사용한다면 해당 필드를 하나의 dns: 아래에 병합하세요. 앞서 소개한 단일 업스트림 방식과 목적이 다르므로 먼저 기본 설정을 검증한 뒤 fallback을 추가할지 결정하는 것이 좋습니다.

dns:
  enable: true
  listen: 127.0.0.1:1053
  enhanced-mode: fake-ip
  default-nameserver:
    - 223.5.5.5
  nameserver:
    - https://dns.alidns.com/dns-query
  fallback:
    - https://1.1.1.1/dns-query
  fallback-filter:
    geoip: true
    geoip-code: CN
    ipcidr:
      - 240.0.0.0/4

이 예시는 GeoIP 조건으로 기본 DNS 응답을 판단합니다. CN 조건을 만족하지 않거나 지정된 주소 범위에 해당하는 응답은 fallback 결과로 대체될 수 있습니다. 실제 동작은 지리 데이터와 코어 구현에 따라 달라지므로 IP의 지리적 분류를 도메인의 신뢰도 판단으로 여겨서는 안 됩니다. 여러 국가에 걸친 CDN, 기업 서비스, 데이터 갱신 지연으로 인해 예상과 다른 결과가 나올 수 있습니다.

‘특정 도메인 몇 개만 지정한 DNS를 사용하면 된다’면 fallback 조건을 넓히기보다 nameserver-policy를 사용하는 편이 검증하기 쉽습니다. 전용 DNS 정책이 적용된 도메인이 기본 업스트림과 fallback 조합을 그대로 따를 것이라고 단정하지 마세요. 현재 버전의 문서와 실제 조회 로그를 확인해야 합니다.

TUN으로 DNS 가로채기: 시스템 프록시가 처리하지 못하는 조회 보완

시스템 프록시는 프록시 설정을 따르는 앱을 위한 기능이며, 시스템 DNS까지 처리한다는 뜻은 아닙니다. TUN은 가상 네트워크 인터페이스로 트래픽을 받아 일치하는 DNS 요청을 코어의 DNS 모듈로 전달합니다. 아래 설정 조각은 앞의 DNS 기본 설정과 병합할 수 있지만, 가상 네트워크 인터페이스를 만들 수 있는지는 시스템 권한, 클라이언트 서비스, 플랫폼 지원 여부에 달려 있습니다.

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

any:53은 TUN으로 들어오는 UDP 53 요청을 처리하며, 두 번째 항목은 TCP 53을 추가합니다. 이는 시스템 방화벽 규칙이 아닙니다. 실제로 코어의 처리 경로에 들어온 트래픽만 가로챌 수 있습니다. 여러 네트워크 인터페이스, 가상 머신, 컨테이너, 다른 VPN, 특정 시스템 라우팅에 따라 이 전제가 달라질 수 있습니다.

53번 포트 이외의 경로

DoH: 보통 HTTPS의 443 포트를 사용하므로 DNS 53 가로채기만으로는 기존 DNS 조회와 구별할 수 없습니다. 앱의 보안 DNS 설정을 관리하거나 해당 연결의 경로를 명시적으로 지정하세요.
DoT: 보통 TCP 853을 사용합니다. 모바일 기기의 비공개 DNS가 이 경로를 쓸 수 있으므로 별도로 확인해야 합니다.
로컬 네트워크 검색: mDNS는 보통 UDP 5353을 사용하며 여기서 다루는 일반 DNS 가로채기 범위에 포함되지 않습니다. 프린터, 화면 미러링, 로컬 도메인 검색은 별도로 테스트하세요.

활성화 후 전체 네트워크가 끊기면 먼저 TUN을 꺼서 연결을 복구한 다음 관리자 권한 또는 서비스 모드, 기본 출구 네트워크 인터페이스, 라우팅 충돌을 확인하세요. 여러 클라이언트에서 TUN을 동시에 켜지 말고 포트 충돌을 해결하겠다며 DNS 서비스를 0.0.0.0에 바로 공개하지 마세요. 수신 주소를 변경하면 로컬 네트워크 접근 제어도 함께 고려해야 합니다.

로컬 검증 및 최종 점검: 설정 적용, 트래픽 처리, 구독 업데이트

먼저 1053 포트 수신 및 Fake-IP 응답 확인

dig가 설치된 시스템에서 다음 명령을 실행하세요. 포트를 명시하면 운영체제의 DNS 서버가 이미 변경됐는지와 관계없이 코어의 DNS를 직접 테스트할 수 있습니다. 도구가 설치되어 있지 않다면 클라이언트의 DNS 진단 기능을 사용하세요. 일반 nslookup은 기본적으로 53 포트에 접속합니다.

dig @127.0.0.1 -p 1053 www.wikipedia.org A
dig @127.0.0.1 -p 1053 www.qq.com A
dig @1.1.1.1 www.wikipedia.org A

앞의 두 명령은 코어 DNS를 직접 확인합니다. 예시처럼 Fake-IP를 설정했다면 필터에 걸리지 않은 A 조회는 보통 198.18.0.0/16 범위의 매핑 주소를 반환합니다. 이 결과만으로 실제 어떤 업스트림을 사용했는지는 알 수 없습니다. 세 번째 명령은 TUN이 켜져 있고 53 가로채기가 적용된 경우 코어가 처리할 수도 있습니다. 이때 도구에 서버가 1.1.1.1로 표시되더라도 요청이 실제로 그 주소에 도달했다고 단정할 수 없습니다.

물리 네트워크 인터페이스와 실제 연결 확인

추가 확인이 필요하면 Wireshark에서 실제로 네트워크에 연결된 인터페이스를 선택하고 udp.port == 53 || tcp.port == 53 || tcp.port == 853 필터를 적용하세요. 테스트 중 예상하지 않은 평문 조회가 물리 인터페이스를 통해 나가는지 확인합니다. 이 필터는 DoH를 확인하지 못하며, 53 포트 트래픽이 보이지 않는다는 사실만으로 모든 조회가 프록시를 거쳤다고 증명할 수 없습니다. 암호화 업스트림 연결의 출구는 클라이언트 로그와 연결 패널을 함께 확인해야 합니다.

기존 캐시를 비우세요. Windows에서는 ipconfig /flushdns를 실행하고, systemd-resolved를 사용하는 Linux에서는 resolvectl flush-caches를 실행하세요. 그런 다음 테스트 브라우저를 다시 시작해 기존 연결의 영향을 없애세요.
온라인 테스트를 다시 실행하세요. 같은 노드와 브라우저 설정을 유지한 채 DNS 리졸버의 운영 주체와 기준선의 차이를 비교하세요.
실제 사용 환경에서도 다시 테스트하세요. 중국 내 웹사이트, 해외 웹사이트, 사내 네트워크, 로컬 네트워크 기기를 확인해 전용 DNS 정책이 내부 도메인 조회를 방해하지 않는지 살펴보세요.
설정 유지 여부를 확인하세요. 구독을 한 번 업데이트하고 클라이언트를 다시 시작한 뒤 실행 설정에 dns, tun 및 정책 필드가 그대로 있는지 확인하세요.