Clash DNS 누수 테스트 및 해결: fake-ip·nameserver-policy 설정 가이드

DNS 누수와 리졸버 위치 차이부터 구분하기

웹 페이지 트래픽이 프록시를 거친다고 해서 DNS 요청까지 프록시를 거치는 것은 아닙니다. 시스템 프록시는 보통 프록시 설정을 따르는 앱에만 영향을 줍니다. 시스템 DNS 조회, 브라우저의 보안 DNS, 다른 프로그램에 내장된 DoH는 각각 별도의 경로를 사용할 수 있습니다. 문제를 해결하려면 ‘누가 요청하는지’, ‘어떤 리졸버를 쓰는지’, ‘리졸버 연결에 어떤 라우팅 정책이 적용되는지’를 따로 확인해야 합니다. fake-ip만 전환해서는 충분하지 않습니다.

이 문서의 설정 예시는 mihomo 코어를 기준으로 합니다. 구버전 Clash와 클라이언트별 래퍼는 지원하는 설정 항목이 서로 다를 수 있습니다. 먼저 클라이언트의 코어 정보나 시작 로그에서 코어 이름을 확인하세요. 설정 검사에서 알 수 없는 항목이 표시되면 현재 코어 문서를 참고해야 하며, 이름이 같다고 기능까지 같다고 판단하면 안 됩니다.

DNS 누수: 프록시를 통해 보내려던 도메인 조회가 로컬 네트워크를 통해 통신사 또는 의도하지 않은 다른 리졸버로 전송되는 현상입니다.
리졸버 위치 차이: 테스트 페이지에 표시되는 국가는 대개 리졸버의 출구 IP 데이터베이스를 기준으로 합니다. 프록시 노드의 실제 위치와는 다를 수 있습니다.
의도된 직접 연결: 로컬 네트워크 이름, 직접 연결할 사이트, 프록시 서버 도메인은 직접 연결로 조회할 수 있습니다. 이런 요청을 허용할지는 먼저 자신의 트래픽 분할 정책을 정한 뒤 판단해야 합니다.

기준 결과 확인: 브라우저·시스템·코어별 점검

같은 조건에서 두 결과 비교하기

다른 VPN과 프록시 프로그램을 일시 중지하고 프록시 노드 하나를 고정하세요. 시스템 프록시, TUN, 브라우저 보안 DNS의 현재 상태를 기록합니다.
DNSLeakTest를 열고 Extended test를 실행하세요. 페이지에 표시된 리졸버 IP, 운영 기관, 지역을 기록합니다.
한 차례 직접 연결 테스트를 허용할 수 있다면 프록시를 끄고 다시 테스트해 로컬 네트워크의 기준 결과를 확인하세요. 프록시를 다시 켠 뒤 새로 테스트하고, 이전 탭에 표시된 결과를 새 결과로 간주하지 마세요.
프록시를 켠 뒤에도 기준 테스트에서 확인한 통신사 리졸버가 나타나면 계속 점검하세요. 예상한 공용 리졸버만 표시되더라도 해당 리졸버 연결이 직접 연결인지 프록시 경유인지 확인해야 합니다.

테스트 사이트는 주로 재귀 리졸버가 권한 DNS에 접속할 때의 출구를 보여 줍니다. ‘컴퓨터에서 재귀 리졸버까지’의 전송 경로를 단독으로 증명하지는 못합니다. 공유 리졸버 서비스, Anycast, 캐시가 결과에 영향을 줄 수 있습니다. 따라서 테스트 페이지 결과는 클라이언트 연결 기록과 함께 확인해야 하며, 표시된 국가명만으로 결론을 내려서는 안 됩니다.

브라우저 DNS 경로를 임시로 통일하기

데스크톱 Chrome을 예로 들면 ‘설정’ → ‘개인 정보 보호 및 보안’ → ‘보안’ → ‘보안 DNS 사용’으로 이동합니다. 먼저 시스템에서 mihomo까지의 경로를 점검하려면 이 옵션을 잠시 끄고, 테스트를 마친 다음 다시 사용할지 결정하세요. 조직 정책으로 관리되는 브라우저에서는 이 옵션을 변경하지 못할 수 있습니다.

브라우저에 내장된 DoH는 HTTPS를 사용하므로 일반적으로 UDP 53 트래픽이 아닙니다. TUN을 통해 프록시로 전송될 수는 있지만, dns-hijack을 설정했다고 해서 mihomo DNS 모듈로 자동 전환되지는 않습니다. Android의 ‘비공개 DNS’도 별도로 기록해 서로 다른 DNS 경로의 결과를 혼동하지 않도록 하세요.

코어 DNS가 실제로 요청을 받는지 확인하기

아래 예시는 코어 DNS가 로컬 1053 포트를 수신하도록 설정합니다. dig가 설치된 macOS 또는 Linux에서는 해당 포트를 지정해 바로 테스트할 수 있습니다.

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

Windows에서는 PowerShell에서 다음 명령을 실행해 시스템 기본 DNS 경로를 확인할 수 있습니다. 이 방법은 로컬 1053 포트에 직접 질의하는 것과 다릅니다. TUN을 켠 뒤에는 코어 DNS 로그에서 해당 요청이 수신되는지도 함께 확인하세요.

Resolve-DnsName example.com -Type A
Get-DnsClientServerAddress

fake-ip, nameserver, 부트스트랩 DNS의 역할

항목	실제 역할	점검할 부분
`enhanced-mode`	fake-ip 또는 redir-host 등 처리 방식 선택	상위 DNS 조회가 프록시를 거치도록 보장하지 않음
`nameserver`	일반 상위 리졸버 설정	리졸버 주소, 전송 프로토콜, 아웃바운드 정책
`nameserver-policy`	조건에 맞는 도메인에 상위 리졸버 지정	도메인을 로컬 DNS로 보내는 기존 정책이 있는지
`default-nameserver`	DNS 서버 자체의 도메인 조회	부트스트랩 조회가 의도치 않게 직접 연결되는지
`proxy-server-nameserver`	프록시 노드의 서버 도메인 조회	프록시 연결 전에 프록시를 통한 DNS 조회가 필요하지 않도록 함

fake-ip는 일반적으로 앱에 매핑 주소를 반환한 뒤, 코어가 후속 연결을 원래 도메인에 연결하도록 합니다. 예시에 사용된 198.18.0.1/16은 벤치마크용 주소 대역이며 실제 웹사이트의 공인 IP 주소가 아닙니다. 이런 주소가 조회 결과에 나타난다고 해서 웹사이트 DNS가 잘못됐거나 상위 조회가 프록시로 보호된다는 뜻은 아닙니다.

fake-ip-filter는 Fake-IP 대신 어떤 도메인에 실제 주소를 반환할지 결정합니다. 일부 로컬 네트워크 서비스에서 실제 주소가 필요하면 필요한 항목만 예외로 추가하세요. 호환성 문제 하나를 해결하려고 모든 도메인을 필터 목록에 넣으면 안 됩니다. 필터는 반환 주소 처리 방식에 영향을 줄 뿐, 상위 DNS 라우팅 설정을 대신하지 않습니다.

상위 DNS 설정: 프록시 정책 명시하기

아래는 조회 경로를 설명하기 위한 mihomo 설정 예시이며 전체 설정 파일이 아닙니다. 기존 설정에 Proxy라는 정책 그룹이 정의되어 있고 사용할 수 있는 노드가 포함되어 있다고 가정합니다. 이 예시에서는 일반 조회와 example.com 테스트 도메인 조회를 프록시 상위 DNS로 보내면서, 명시적인 직접 연결 부트스트랩 경로도 유지합니다.

config.yaml · DNS 설정 예시

dns:
  enable: true
  listen: 127.0.0.1:1053
  ipv6: true
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  default-nameserver:
    - 223.5.5.5
  proxy-server-nameserver:
    - https://223.5.5.5/dns-query
  nameserver:
    - "https://1.1.1.1/dns-query#Proxy"
  nameserver-policy:
    "+.example.com":
      - "https://8.8.8.8/dns-query#Proxy"

#Proxy는 이 DNS 상위 서버에 기존 아웃바운드 정책을 지정합니다. 정책 그룹 이름은 대소문자를 포함해 정확히 일치해야 합니다. 따옴표를 사용하면 주소 전체를 YAML 문자열로 명확하게 읽을 수 있습니다.
+.example.com은 해당 도메인과 하위 도메인에 적용됩니다. 재현 가능한 테스트용 항목일 뿐 실제 서비스 도메인 목록은 아니므로, 적용 전에 필요에 따라 바꾸거나 삭제하세요.
예시의 default-nameserver는 직접 연결하는 부트스트랩 리졸버이며, proxy-server-nameserver도 의도적으로 남겨 둔 직접 연결 DNS 경로입니다. 노드 서버가 도메인 이름을 사용하면 후자의 조회 과정에서 해당 리졸버에 노드 도메인이 노출됩니다.
예시에서는 IP 형식의 DoH 엔드포인트를 사용해 상위 서버 호스트 이름을 먼저 조회해야 하는 상황을 줄입니다. 다만 네트워크 연결이 가능하고 인증서 검증이 정상이어야 하며, 프록시 노드가 해당 연결을 지원해야 합니다.

기존 설정에서 respect-rules를 사용하는 경우

mihomo의 respect-rules: true를 사용하면 DNS 연결에 라우팅 규칙을 적용할 수 있지만, ‘규칙을 따른다’고 해서 반드시 프록시를 거치는 것은 아닙니다. 규칙에서 리졸버 대상을 DIRECT에 매칭하면 연결은 직접 이루어집니다. 이 방식을 사용할 때는 적절한 proxy-server-nameserver를 설정하고, 상위 리졸버 주소에 실제로 어떤 규칙이 적용되는지 확인하세요.

먼저 검증하기 쉬운 상위 DNS 라우팅 방식을 하나 선택하고, 단계적으로 기존 설정에 통합하세요. fallback 여러 개와 다수의 정책·규칙을 한꺼번에 추가한 뒤 테스트하면 어떤 변경이 조회 출구를 바꿨는지 찾기 어렵습니다. 파일 끝에 dns:를 하나 더 추가하는 것도 피하세요. 기존 매핑을 수정해야 중복 키로 설정이 덮어쓰이거나 로드에 실패하는 일을 방지할 수 있습니다.

TUN으로 시스템 DNS 처리하기: 53번 포트 요청 받기

시스템 프록시만 켜면 프록시 설정을 사용하지 않는 프로그램이 시스템 DNS를 직접 호출할 수 있습니다. TUN은 더 많은 IP 트래픽을 처리하며, DNS 하이재킹을 함께 설정하면 기존 DNS 요청을 코어로 보낼 수 있습니다. 아래 예시는 해당 TUN 기능을 지원하는 mihomo 환경에 적용할 수 있으며, 클라이언트에 가상 네트워크 어댑터 생성 및 라우팅 변경 권한이 필요합니다.

config.yaml · TUN 설정 예시

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

any:53은 UDP DNS를 처리하고, tcp://any:53은 TCP DNS를 추가합니다. 여기서 하이재킹되는 것은 TUN 처리 경로로 들어온 연결이며, 로컬 네트워크 전체의 DNS를 강제로 변경하는 것은 아닙니다. 일부 시스템은 로컬 네트워크 DNS로 향하는 경로를 특별하게 처리할 수 있으므로, 실제 로그에서 요청이 코어에 도달하는지 확인해야 합니다.

DoH와 DoT: HTTPS DNS는 보통 443번 포트를, DoT는 보통 853번 포트를 사용하므로 위의 53번 포트 하이재킹 범위에 포함되지 않습니다. 각 연결에 적용되는 아웃바운드 정책을 확인하세요.
여러 네트워크 어댑터: 유선, Wi-Fi, 가상 머신 어댑터, 다른 VPN이 기본 출구를 바꿀 수 있습니다. TUN을 켠 뒤 네트워크가 끊기면 자동으로 선택된 출구 어댑터부터 확인하세요.
IPv6: dns.ipv6는 DNS의 AAAA 응답 동작을 제어하는 설정이지, 시스템 IPv6 전체를 켜고 끄는 옵션이 아닙니다. A 레코드만 테스트했더라도 IPv6 트래픽까지 처리되고 있다고 단정할 수 없습니다.
로컬 네트워크: NAS, 프린터, 사내 네트워크 도메인에는 전용 리졸버가 필요할 수 있습니다. 해당 도메인에 별도 정책을 지정하고, 예상된 직접 연결 조회도 테스트 기록에 포함하세요.

TUN을 사용하지 않으려면 운영체제에서 지원하는 경우 DNS를 코어의 수신 주소로 지정할 수도 있습니다. 다만 일반적인 시스템 DNS 설정에서는 사용자 지정 포트를 입력할 수 없는 경우가 많습니다. 예시의 수신 포트는 시스템에서 흔히 사용하는 53이 아니라 1053이므로 127.0.0.1만 입력해 자동으로 연결되리라 기대하면 안 됩니다. 수신 포트를 변경할 때는 권한과 포트 사용 여부도 고려하세요.

저장·캐시 삭제·재테스트: 순서대로 수정 결과 확인하기

적용된 설정을 확인한 다음 캐시 점검하기

구독 관리 클라이언트는 업데이트할 때 설정을 다시 생성할 수 있습니다. 클라이언트에서 지원하는 오버라이드 또는 병합 방식을 사용해 DNS 변경 사항을 저장하고, 다운로드한 임시 파일만 편집하지 말고 최종 적용 설정을 확인하세요. 명령줄로 배포한다면 먼저 설정을 검사할 수 있습니다. 실행 파일 이름이 mihomo인 경우 명령은 다음과 같습니다.

mihomo -t -f config.yaml

검사가 통과한 뒤 다시 불러오세요. 검사 통과는 코어가 설정을 받아들였다는 뜻일 뿐, 노드·리졸버·네트워크에 연결할 수 있다는 보장은 아닙니다. GUI 클라이언트를 사용한다면 다시 불러온 뒤 시작 로그에서 DNS 수신 실패, 권한 부족, 정책 그룹 없음 등의 오류가 있는지 확인하세요.

Windows에서는 시스템 DNS 캐시를 비운 뒤 다시 조회할 수 있습니다. 브라우저에 별도 캐시나 기존 연결이 남아 있을 수 있으므로 필요하면 브라우저를 완전히 종료한 뒤 다시 열어 테스트 페이지를 확인하세요. 모바일 기기는 현재 네트워크 연결을 끊었다가 다시 연결한 뒤 테스트할 수 있습니다.

ipconfig /flushdns
Resolve-DnsName example.com -Type A

세 가지 증거를 함께 확인하기

요청 유입 증거: 시스템에서 조회할 때 코어가 DNS 요청을 받는지 확인합니다. 1053 포트에 직접 질의하는 경우와 시스템을 통해 질의하는 경우를 따로 검증해야 합니다.
라우팅 증거: 연결 기록에서 예시 DoH 엔드포인트 1.1.1.1:443 또는 8.8.8.8:443로 향하는 연결에 예상한 프록시 정책이 적용됐는지 확인합니다. 필요하면 일시적으로 log-level: debug를 사용해 점검한 뒤 원래 로그 수준으로 되돌리세요.
외부 확인 증거: 테스트 페이지를 다시 실행해 리졸버 운영 기관이 예상과 일치하는지, 사용 계획에 없던 로컬 통신사 리졸버가 나타나지 않는지 확인합니다. 표시되는 지역이 다르다는 사실만으로 실패라고 판단할 수는 없습니다.

디버그 로그에는 방문한 도메인, 노드 주소 등 네트워크 정보가 포함될 수 있습니다. 로그를 공유하기 전에 구독 링크와 인증 정보, 공개할 필요가 없는 도메인을 삭제하세요. 전체 설정 파일을 공개 게시판에 그대로 올리지 마세요.

자주 발생하는 결과와 다음 점검 항목

증상	우선 확인할 항목
브라우저는 정상인데 시스템 조회는 계속 로컬로 연결됨	브라우저에 DoH가 내장되어 있을 수 있습니다. TUN 라우팅과 시스템 DNS 유입 경로를 확인하세요.
Fake-IP가 반환되지만 테스트 결과가 예상과 다름	상위 DNS 아웃바운드 정책을 확인하세요. Fake-IP가 반환된다고 DNS 요청까지 프록시를 거치는 것은 아닙니다.
프록시를 켜면 모든 도메인에서 시간 초과가 발생함	노드 도메인의 부트스트랩 조회, 정책 그룹 이름, DoH 연결 가능 여부를 확인하세요.
구독 업데이트 후 문제가 다시 발생함	오버라이드가 유지되는지와 최종 적용 설정의 DNS 항목을 확인하세요.
사내 네트워크나 가정용 NAS에서만 실패함	내부 도메인에 연결 가능한 로컬 리졸버를 지정하고 필요한 라우팅을 유지하세요.

최종적으로 확인할 것은 테스트 페이지에 IP 하나만 표시되는지가 아니라, DNS 조회 경로가 정한 정책을 따르는지입니다. 직접 연결로 조회할 도메인을 먼저 정한 다음 시스템 유입 경로, 코어 상위 DNS, 프록시 라우팅을 서로 맞춰야 실제 누수와 정상적인 분할 처리, 리졸버 표시 위치 차이를 구분할 수 있습니다. 각 설정 항목에 대한 자세한 내용은 고급 설정 가이드를, 기본 설정 방법은 클라이언트 설정 튜토리얼을 참고하세요.

설정 참고 자료 및 확인 링크

mihomo 문서: DNS 설정에서 상위 DNS 조회, 도메인 정책, Fake-IP, 프록시 서버 이름 조회 항목을 확인할 수 있습니다.
mihomo 문서: TUN 인바운드에서 DNS 하이재킹, 자동 라우팅, 운영체제별 차이를 확인할 수 있습니다.
DNSLeakTest 테스트 페이지에서 재귀 리졸버의 출구를 확인할 수 있습니다. 결과는 코어 로그와 함께 해석해야 합니다.