DNS 누출 여부를 판단하는 기준
Clash에 프록시 연결이 표시되는데 DNS 테스트 페이지에 현재 인터넷 사업자(ISP)가 나타나는 경우는 흔한 문제 해결의 출발점입니다. 하지만 “DNS 주소가 여러 개 감지됐다”는 사실만으로 누출이라고 단정할 수는 없습니다. 먼저 목표를 정해야 합니다. 프록시를 사용해야 하는 도메인만 프록시를 통해 조회할 것인지, 아니면 노드 연결에 필요한 초기 조회를 제외한 모든 공용 도메인 조회를 지정한 경로로 보낼 것인지에 따라 정상으로 볼 수 있는 결과가 달라집니다.
여기서 DNS 누출은 도메인 조회가 설정한 정책대로 전송되지 않고 시스템, 로컬 네트워크 또는 허용되지 않은 다른 DNS 리졸버로 빠져나가는 경우를 뜻합니다. 테스트 페이지에 표시되는 것은 보통 테스트 도메인 조회를 받은 재귀 DNS 리졸버입니다. 컴퓨터에 설정된 DNS 주소나 프록시 노드 자체를 보여주는 것은 아닙니다. 따라서 DNS 리졸버의 위치와 웹 트래픽의 출구 위치가 다르다는 사실만으로 누출이라고 결론 내릴 수는 없습니다.
| 관찰 결과 | 가능한 원인 | 다음 단계 |
|---|---|---|
| 현재 인터넷 사업자(ISP)의 DNS가 표시됨 | 시스템 DNS 요청이 가로채지지 않았거나 규칙에서 직접 연결을 허용함 | DNS 정책과 53번 포트 트래픽을 대조 |
| 공용 DNS 서비스가 표시됨 | 커널 또는 브라우저가 해당 서비스를 사용 중 | 예상한 상위 DNS 및 출구인지 확인 |
| DNS 리졸버와 노드가 서로 다른 국가에 있음 | 공용 DNS의 애니캐스트, 재귀 조회 출구 또는 지리 데이터베이스 차이 | 연결 로그를 참고해 라우팅 경로 확인 |
| 매번 여러 주소가 표시됨 | 같은 서비스가 여러 재귀 DNS 출구를 사용하거나 조회 경로가 여러 개일 수 있음 | IP 개수만 세지 말고 운영 주체를 비교 |
재현 가능한 DNS 누출 테스트부터 진행
환경을 기록한 뒤 변수 하나씩 변경
- 클라이언트 이름, 커널 이름과 버전, 현재 사용 중인 시스템 프록시 또는 TUN을 기록합니다. 이 문서의 예시는 mihomo용이며, 업데이트가 중단된 구형 Clash 커널에 그대로 적용할 수 없습니다.
- 다른 VPN, 게임 가속기, 프록시 도구를 종료합니다. 먼저 클라이언트 하나만 실행해 가상 네트워크 어댑터와 DNS 설정이 서로 덮어쓰지 않도록 합니다.
- 브라우저에서
dnsleaktest.com을 직접 열고 Standard test를 실행한 다음 Extended test도 진행합니다. DNS 리졸버 IP, 운영 주체, 테스트 시간, 웹 트래픽 출구 주소를 기록하고 국가 항목만 캡처하지 마세요. - 프록시를 끄고 기준 테스트를 한 번 진행한 다음, 목표 설정을 켜고 다시 테스트합니다. 기준 테스트는 로컬 네트워크로 연결하므로 엄격한 네트워크 격리가 필요한 환경에서는 진행하지 마세요.
- 설정을 수정한 뒤 커널을 다시 불러오고 시스템 캐시를 비운 다음 브라우저를 완전히 종료했다가 다시 테스트합니다. 비교하기 쉽도록 같은 노드, 네트워크, 테스트 페이지를 사용하세요.
Windows에서는 터미널에서 ipconfig /flushdns를 실행해 시스템 DNS 캐시를 지울 수 있습니다. 이 명령으로 브라우저 자체의 DNS 캐시나 mihomo 커널의 전체 실행 상태까지 초기화되지는 않습니다. 결과가 계속 같다면 먼저 브라우저와 커널을 재시작한 뒤 설정이 적용되지 않은 것인지 확인하세요.
브라우저 테스트와 시스템 테스트 구분하기
브라우저의 보안 DNS는 HTTPS로 직접 조회해 시스템의 53번 포트 DNS 경로를 우회할 수 있습니다. 원인을 찾으려면 먼저 브라우저 설정에서 ‘보안 DNS’를 검색해 잠시 끄고 결과를 비교하세요. 커널이 정상적으로 요청을 처리하는 것을 확인한 뒤 기능을 다시 켤지 결정하고, DoH 연결에 명확한 프록시 규칙을 설정합니다. 브라우저 테스트가 정상이어도 명령줄 도구, 게임 또는 다른 앱이 같은 경로를 사용한다는 뜻은 아닙니다.
예를 들어 비교 결과를 “시스템 프록시: 통신사 DNS와 공용 DNS 감지, TUN: 설정한 공용 DNS만 감지”와 같이 기록할 수 있습니다. 이는 기록 형식의 예시일 뿐, 실제 테스트 결과가 아닙니다. 직접 확인한 결과를 보관하고 커널 연결 기록으로 변화의 원인을 검증하세요.
fake-ip와 명시적인 DNS 상위 서버 설정
수정하기 전에 현재 정상 작동하는 설정을 백업합니다. 구독 설정은 정기 업데이트로 덮어쓰일 수 있으므로 클라이언트의 오버라이드 또는 병합 기능을 사용하세요. 병합 방법을 확실히 모른다면 별도의 로컬 설정 파일에 복사해 검증합니다. 최종 적용 설정에는 최상위 dns: 항목이 하나만 있어야 합니다. 파일 끝에 같은 항목을 중복으로 붙여 넣지 마세요.
다음은 mihomo용 DNS 설정 예시입니다. 기존 노드, 그룹, 규칙이 포함된 전체 설정에 병합해야 합니다. 일반 조회는 Cloudflare DoH로 보내고 qq.com 및 하위 도메인은 중국 본토 DoH로 전달합니다. 이는 도메인별 조회 정책의 예시이며, 모든 조회가 프록시를 통과한다는 뜻은 아닙니다.
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"
respect-rules: true
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://223.5.5.5/dns-querylisten: 127.0.0.1:1053은 로컬 컴퓨터에서만 수신하며 LAN에 DNS 서비스를 공개하지 않습니다. 시스템 DNS 설정에는 보통 1053 같은 사용자 지정 포트를 지정할 수 없으므로, 뒤에서 설명하는 TUN 가로채기나 시스템에서 지원하는 로컬 포워더를 통해 연결해야 합니다.198.18.0.1/16은 이 예시에서 선택한 가상 IP 주소 풀입니다. 앱에 이 범위의 주소가 할당되는 것은 정상입니다. 네트워크에서 같은 대역을 이미 사용하고 있다면 먼저 충돌을 해결하세요.fake-ip-filter에 지정한 도메인에는 가상 주소 대신 실제 주소를 반환합니다. 주로 LAN 기기 검색 같은 기능과의 호환성을 위한 설정입니다. 이는 트래픽 분기 규칙이 아니며 해당 조회가 반드시 직접 연결된다는 뜻도 아닙니다.proxy-server-nameserver는 프록시 서버의 도메인을 전용으로 조회합니다. “노드에 연결하려면 DNS가 필요한데 DNS는 노드 연결을 기다리는” 순환 의존성을 방지합니다. 노드 주소를 IP로 지정했다면 이 조회가 발생하지 않을 수 있습니다.default-nameserver는 DNS 서버 도메인 조회와 같은 초기 연결 단계에 사용됩니다. 실제로 일반 DNS 조회가 여기서 발생하면 로컬 네트워크에서 초기 연결용 도메인을 확인할 수 있습니다. 모든 서비스 조회가 이 주소를 사용한다고 오해하지 마세요.
nameserver-policy와 규칙으로 DNS 출구 지정
nameserver-policy는 “특정 도메인을 어떤 DNS 서버에 조회할지” 지정하고, respect-rules: true는 DNS 상위 서버 연결에도 라우팅 규칙을 적용합니다. 두 설정이 해결하는 문제는 서로 다릅니다. 상위 서버를 해외 공용 DNS로 바꾸는 것만으로 요청이 프록시를 통해 전송되지는 않습니다.
기존 설정에 프록시 선택이라는 사용 가능한 그룹이 있다고 가정합니다. 아래 두 규칙을 기존 rules: 목록에 추가하되, 먼저 일치할 수 있는 규칙보다 위에 배치하세요. 이 두 줄로 전체 규칙 목록을 대체하지 마세요. 해당 그룹이 없으면 저장하지 마세요.
rules:
- IP-CIDR,1.1.1.1/32,프록시 선택,no-resolve
- IP-CIDR,223.5.5.5/32,DIRECT,no-resolve첫 번째 규칙은 예시의 1.1.1.1:443 DNS 상위 서버 연결을 지정한 프록시 그룹으로 보냅니다. 두 번째 규칙은 중국 본토 상위 서버에 직접 연결합니다. no-resolve는 IP 규칙을 판단하기 위해 추가 도메인 조회가 발생하는 것을 막습니다. 규칙은 위에서부터 순서대로 적용되므로, 위쪽에 더 넓은 직접 연결 규칙이 있으면 새 규칙이 실행되지 않을 수 있습니다.
모든 DNS를 프록시로 보내는 경우와 중국 본토 분기 정책을 각각 검증
- 중국 본토 분기 목표: 예시의
nameserver-policy를 유지하고 지정한 도메인을 중국 본토 DNS 서비스에 조회합니다. 테스트 페이지의 무작위 테스트 도메인은 보통 이 정책에 해당하지 않으므로 일반 상위 DNS 서버를 사용합니다. - 더 엄격한 프록시 DNS 목표: 중국 본토 도메인에 적용되는 예외 정책을 제거하고 다른 DNS 상위 서버, 보조 DNS, 직접 조회 설정도 확인합니다. 노드 도메인의 초기 조회는 별도로 설계해야 합니다. 규칙 한 줄을 지웠다고 모든 DNS 경로가 차단되는 것은 아닙니다.
- 기업 또는 학교 내부망 사용: 내부 도메인은 로컬 DNS로 조회해야 할 수 있습니다. 먼저 네트워크 관리자에게 확인하고 필요한 도메인별 조회 정책을 유지하세요. 내부 도메인을 한꺼번에 공용 DNS 서비스로 보내지 마세요.
검증할 때 클라이언트 연결 목록에서 1.1.1.1을 검색해 대상 포트가 443인지, 예상한 프록시 그룹이 적용됐는지 확인합니다. 클라이언트마다 DNS 내부 연결 표시 기능이 다릅니다. 목록에 나타나지 않으면 디버그 로그와 패킷 캡처도 확인하세요. “보이지 않는다”는 이유만으로 요청이 없었다고 판단하지 마세요.
TUN으로 시스템 DNS 가로채기 및 53번 포트 처리
시스템 프록시는 프록시 설정을 따르는 앱에 주로 영향을 주며 모든 시스템 DNS 요청을 자동으로 가로채지는 않습니다. 더 많은 앱의 트래픽을 처리하려면 mihomo TUN을 지원하는 클라이언트에서 가상 네트워크 어댑터를 활성화하고 아래 설정을 병합할 수 있습니다. 활성화할 때 관리자 권한이 필요하거나 가상 어댑터 서비스를 설치해야 할 수 있습니다.
tun:
enable: true
stack: mixed
auto-route: true
auto-detect-interface: true
dns-hijack:
- any:53
- tcp://any:53여기서 any:53과 tcp://any:53은 TUN을 통과하는 일반 UDP DNS와 TCP DNS를 각각 가로챕니다. 임의 앱의 HTTPS DNS 조회를 자동으로 커널 DNS로 바꾸거나 가상 어댑터를 전혀 통과하지 않는 연결까지 처리할 수는 없습니다. 실제 적용 범위는 시스템, 라우팅 테이블, 클라이언트 권한에 따라 달라집니다.
로컬 환경에서 확인하는 순서
- 클라이언트에 TUN이 시작된 것으로 표시되는지 확인하고, 로그에 권한 부족, 가상 어댑터 생성 실패, 경로 추가 실패가 없는지 살펴봅니다.
nslookup example.com 127.0.0.1을 실행하기 전에 로컬 컴퓨터의 53번 포트에서 실제로 수신 중인지 확인하세요. 이 문서의 예시는 1053번 포트에서 수신하므로 명령이 실패해도 곧바로 DNS 장애라고 판단할 수 없습니다.- 시스템에
dig가 설치되어 있다면 아래 명령으로 커널의 1053번 포트를 직접 테스트합니다. fake-ip가 적용되면 보통198.18.0.0/16범위의 응답이 표시됩니다. - 다음으로
nslookup example.com 8.8.8.8을 실행해 일반 시스템 조회가 가로채지는지 확인합니다. 로그도 함께 확인하세요. 명령에 표시되는 DNS 서버 이름만으로 가로채기 성공을 입증할 수는 없습니다. - 마지막으로 브라우저에서 확장 프로그램의 DNS 누출 테스트를 다시 실행하고 자주 사용하는 앱의 실제 네트워크 연결도 확인합니다.
dig @127.0.0.1 -p 1053 example.com A
nslookup example.com 8.8.8.8Windows 11에서는 ‘설정’ → ‘네트워크 및 인터넷’ → ‘프록시’에서 다른 도구가 설정한 수동 프록시가 남아 있는지 확인할 수 있습니다. 클라이언트 구성에 따라 TUN과 시스템 프록시를 함께 사용할 수 있지만, 문제를 찾는 동안에는 하나의 명확한 경로만 사용한 뒤 다른 기능을 하나씩 다시 활성화하세요.
IPv6, 브라우저 DoH, 캐시로 인한 잔여 위험
DNS의 IPv6 옵션과 시스템 IPv6 설정은 다릅니다
예시의 dns.ipv6: false는 커널의 AAAA 조회 처리를 제어합니다. 운영체제의 IPv6를 끄거나 앱이 자체 조회 결과로 IPv6 연결을 만드는 것을 자동으로 막지는 않습니다. 기존 캐시, 앱 내장 DoH, 고정 주소를 통해 다른 경로가 사용될 수 있습니다. IPv4와 IPv6의 출구를 각각 확인하세요. 현재 클라이언트가 IPv6를 완전히 가로채지 못한다면 테스트용 네트워크 어댑터에서 IPv6를 잠시 꺼 결과를 비교하고, 원인을 확인한 뒤 장기적인 대책을 결정하세요.
53번 포트 외의 DNS 조회는 별도로 처리
DoT는 보통 TCP 853번 포트, DoH는 주로 HTTPS 443번 포트를 사용하며 HTTP/3를 통해 UDP 443번 포트를 사용할 수도 있습니다. dns-hijack의 53번 포트 규칙으로 이런 암호화 연결을 일반 DNS로 바꿀 수는 없습니다. 브라우저나 앱에 내장된 보안 DNS는 시스템 DNS를 사용하도록 설정하거나, 해당 DNS 서비스 연결에 목표에 맞는 프록시 규칙을 지정해야 합니다.
패킷 캡처로 예상하지 않은 일반 DNS 조회 확인
패킷 캡처 도구가 있다면 물리 네트워크 어댑터에서 표시 필터 udp.port == 53 || tcp.port == 53를 사용해 테스트 중인 트래픽을 살펴보고, 조회 도메인, 대상 주소, 시간을 로그와 대조합니다. TUN 어댑터의 DNS 패킷은 가로채기 전의 내부 처리 과정일 수 있습니다. 요청이 외부로 빠져나가는지 확인하려면 물리 어댑터에서 예상하지 않은 외부 DNS로 조회가 전송되는지 중점적으로 살펴보세요.
53번 포트 트래픽이 캡처되지 않아도 DoH와 DoT는 암호화되어 있으므로 DNS 조회가 없었다고 볼 수 없습니다. 반대로 노드 초기 조회, LAN 기기 또는 다른 프로세스의 조회를 테스트 중인 웹페이지 탓으로 돌릴 수도 없습니다. 프로세스, 도메인, 시간을 기준으로 출처를 구분해야 합니다.
설정 확인 및 문제 발생 시 복구
신뢰할 수 있는 검증에는 최소한 세 가지가 필요합니다. DNS 리졸버가 예상과 일치하고, DNS 상위 서버 연결이 올바른 출구를 사용하며, 서비스 앱이 정상적으로 작동해야 합니다. 테스트 페이지에 “로컬 주소가 표시되지 않는다”는 것만으로는 내부 도메인 장애, 노드 DNS 순환 의존성, 다른 앱의 우회를 확인할 수 없습니다.
- 설정을 불러올 수 없음: YAML 들여쓰기, 중복된 최상위 항목, 지원하지 않는 옵션을 확인하세요. 실행 중인 커널이 mihomo인지 확인하고, 클라이언트의 모양만으로 커널 버전을 판단하지 마세요.
- 모든 도메인의 연결 시간이 초과됨: 먼저 노드 연결 상태와 프록시 서버 도메인의 전용 DNS 조회를 확인한 다음
1.1.1.1:443의 프록시 경로를 점검하세요. 문제가 발생했을 때 노드, DNS, 규칙을 한꺼번에 바꾸지 마세요. - 테스트는 정상이지만 내부망에 접속할 수 없음: 내부 도메인에 로컬 DNS가 필요한지 확인하고
fake-ip-filter와 도메인별 정책을 검토하세요. 실제 상위 DNS를 확인하지 않은 채 필터 목록만 넓히지 마세요. - 구독 업데이트 후 문제가 다시 발생함: 업데이트 전후의 실제 적용 설정을 비교해 DNS, TUN, 규칙 오버라이드가 유지됐는지 확인하세요. 편집기에 저장된 텍스트만 확인해서는 안 됩니다.
- 클라이언트를 종료한 뒤 인터넷에 연결할 수 없음: 시스템 DNS, 수동 프록시, 라우팅이 복원됐는지 확인하세요. 먼저 TUN을 끄고 클라이언트를 종료한 다음 백업을 사용해 네트워크 설정을 복구합니다.
fake-ip는 도메인과 IP를 연결하고, nameserver-policy는 DNS 서버를 선택하며, 라우팅 규칙은 상위 DNS 연결의 출구를 정하고, TUN은 시스템 트래픽을 더 넓게 가로챕니다. ‘누출 방지’ 옵션을 반복해서 바꾸기보다 이 네 단계를 각각 검증하면 원인을 더 쉽게 찾을 수 있습니다. 기본적인 트래픽 분기와 구독 설정은 Clash 설정 가이드에서, 각 설정 항목의 의미는 전체 문서에서 확인하세요.