DNS 누수 판단하기: DNS 조회와 연결을 구분하세요
웹페이지가 프록시를 통해 열렸다고 해서 도메인 조회까지 프록시를 거쳤다는 뜻은 아닙니다. 앱이 먼저 라우터나 통신사 DNS에 주소를 조회한 뒤 HTTPS 연결만 Clash에 맡길 수도 있고, 도메인을 프록시에 전달해 원격으로 조회할 수도 있습니다. 두 경우 웹페이지의 동작은 같지만 DNS가 노출되는 범위는 다릅니다. 문제를 확인할 때는 앱의 DNS 조회 방식, 요청을 가로채는 주체, 상위 DNS로 향하는 경로를 함께 살펴봐야 합니다.
이 글에서 말하는 ‘DNS 누수’는 프록시나 지정된 암호화 DNS를 거쳐야 하는 조회가 의도치 않게 로컬 네트워크 또는 예상하지 못한 DNS 서버로 전송되는 경우를 뜻합니다. 중국 본토 사이트를 설정에 따라 직접 연결하고 로컬 DNS를 사용하는 것은 분할 라우팅 정책의 일부입니다. 테스트 페이지에 로컬 DNS가 표시됐다는 이유만으로 오류라고 판단해서는 안 됩니다. 먼저 보호 대상이 프록시를 이용하는 도메인뿐인지, 노드 도메인처럼 필요한 조회를 제외한 모든 앱의 DNS인지 정하세요.
자주 발생하는 우회 경로 네 가지
- 시스템 프록시만 사용: 앱이 시스템 프록시 설정을 따르지 않으면 UDP 53 조회가 라우터로 직접 전송될 수 있습니다.
- 브라우저 보안 DNS: 브라우저가 자체 DoH 서비스에 HTTPS 요청을 보내 커널 DNS 모듈을 우회합니다. 이 연결이 프록시를 거치는지는 가로채기 설정과 규칙에 달려 있습니다.
- 여러 DNS 설정이 동시에 적용: 구독 설정, 클라이언트 오버라이드, 시스템 네트워크 설정이 함께 적용되어 수정한 파일이 실제 실행 설정과 다를 수 있습니다.
- IPv6 또는 다른 VPN: 별도의 네트워크 어댑터, IPv6 경로, VPN DNS 정책이 가로채기 대상에서 빠진 경로를 만들 수 있습니다.
확인 절차: 테스트 페이지, 커널 로그, 시스템 조회 결과 비교
테스트 전에 클라이언트 이름, 커널 종류, 시스템 프록시 상태, TUN 상태, 현재 모드를 기록하세요. 아래의 respect-rules, proxy-server-nameserver 예시는 해당 필드를 지원하는 mihomo 커널용입니다. 구버전 Clash에 그대로 적용하면 안 됩니다. 그래픽 클라이언트 버전과 커널 버전은 별도 정보이므로 클라이언트의 ‘정보’ 페이지와 시작 로그에서 각각 확인하세요.
1단계: 같은 네트워크에서 비교 기준 만들기
- 다른 VPN, 네트워크 가속기, 프록시 확장 프로그램을 모두 끄고 브라우저의 보안 DNS가 켜져 있는지 기록하세요.
- Clash의 트래픽 가로채기를 잠시 끈 뒤
dnsleaktest.com에서 Extended test를 실행하고 DNS 서버 IP, 네트워크 소속, 테스트 시간을 기록하세요. - 확인할 설정을 켜고 브라우저 설정은 그대로 둔 상태에서 같은 테스트를 다시 실행하세요.
browserleaks.com/dns로 교차 확인할 수도 있습니다. - 그런 다음 브라우저 보안 DNS를 잠시 끄고 다시 테스트하세요. 이렇게 하면 ‘브라우저 자체 DNS 경로’와 ‘시스템 및 커널 DNS 경로’를 구분할 수 있습니다. 테스트가 끝나면 필요에 따라 설정을 복원하세요.
테스트 사이트는 보통 브라우저가 임의의 하위 도메인에 접속하게 한 뒤, 권한 DNS 서버에서 재귀 DNS 서버를 확인합니다. 결과에 표시되는 IP는 DNS 서버의 출구이며 프록시 노드 IP와 다를 수 있습니다. 공용 DNS를 사용하면 DNS 서버가 있는 도시와 프록시 출구 도시가 다른 경우가 흔합니다. Anycast 또는 전달 구조를 사용하는 서비스는 한 번의 테스트에 여러 주소가 표시될 수도 있습니다. 국가명만 비교하지 말고 운영 주체와 예상한 DNS 경로를 확인하세요.
2단계: DNS 모듈이 실제로 응답하는지 확인
아래 조회는 이 글의 예시에서 사용한 로컬 수신 포트 1053을 대상으로 합니다. 커널 DNS만 확인하며 시스템과 브라우저가 모두 이 포트를 사용한다는 뜻은 아닙니다. fake-ip가 켜져 있고 도메인이 필터링 대상이 아니라면 A 조회는 일반적으로 198.18.0.0/16 범위의 매핑 주소를 반환해야 합니다.
# Windows PowerShell 또는 명령 프롬프트
nslookup -port=1053 example.com 127.0.0.1
# macOS / Linux, 시스템에 dig가 설치되어 있어야 합니다
dig @127.0.0.1 -p 1053 example.com A이어서 클라이언트의 ‘로그’ 페이지에서 로그 수준을 잠시 debug로 설정하고 조회와 웹페이지 접속을 다시 실행하세요. 그런 다음 ‘연결’ 페이지에서 대상 도메인, 매칭된 규칙, 최종 정책을 확인합니다. 로그 형식은 커널 버전에 따라 다르지만 DNS 조회 실패, 연결 시간 초과, 순환 조회 관련 메시지가 있는지 살펴보면 됩니다. 확인이 끝나면 info로 되돌려 불필요한 도메인 정보가 계속 기록되지 않도록 하세요.
3단계: 캐시와 실제 우회 구분하기
설정을 바꿨는데도 이전 DNS 서버가 표시되면 먼저 설정을 다시 불러오고 시스템 DNS 캐시를 비운 다음 테스트 브라우저를 재시작하세요. Windows에서는 ipconfig /flushdns를 실행합니다. systemd-resolved를 사용하는 Linux에서는 resolvectl flush-caches를 실행하세요. 이 명령으로 모든 앱의 내부 캐시가 지워지는 것은 아니므로 임의 도메인을 사용하는 테스트를 다시 실행해야 합니다.
더 자세히 확인하려면 물리 네트워크 어댑터에서 패킷을 캡처하고 Wireshark 표시 필터 dns || tcp.port == 853 || udp.port == 853로 일반 DNS, DoT, DoQ 관련 트래픽을 확인할 수 있습니다. DoH는 보통 443 포트를 사용하므로 이 필터만으로 식별할 수 없습니다. 목적지 주소와 커널 연결 기록도 함께 확인하세요. 네트워크 어댑터에서 프록시 서버 연결이 보이는 것은 정상이며, 모든 외부 트래픽을 누수로 판단해서는 안 됩니다.
설정 항목 비교: nameserver, fallback, respect-rules
| 항목 | 기능 | 확인할 점 |
|---|---|---|
enable | 커널 DNS 모듈을 활성화합니다. | 활성화한 뒤 앱의 조회가 모듈에 도달하는지도 확인해야 합니다. |
listen | 로컬 DNS 수신 주소를 제공합니다. | 127.0.0.1:1053을 설정해도 시스템 DNS가 자동으로 변경되지는 않습니다. |
enhanced-mode | fake-ip 등의 처리 모드를 선택합니다. | 주소 매핑 방식과 상위 DNS 연결 경로는 별개입니다. |
nameserver | 기본으로 사용할 상위 DNS를 지정합니다. | 프로토콜과 연결 가능 여부, 최종 연결 경로가 직접 연결인지 프록시인지 확인하세요. |
fallback | 별도의 상위 DNS 그룹을 지정합니다. | 필터 조건에 따라 결과를 선택하는 용도이며, 기본 상위 DNS가 실패할 때만 조회하는 설정은 아닙니다. |
fallback-filter | 주소나 도메인 등의 조건에 따라 결과를 필터링합니다. | 결과를 필터링해도 다른 상위 DNS가 조회를 받지 않는 것은 아닙니다. |
respect-rules | DNS 상위 서버 연결에 라우팅 규칙을 적용합니다. | true만 설정해서는 부족합니다. 노드 도메인 조회를 설정하고 규칙 순서도 확인해야 합니다. |
proxy-server-nameserver | 프록시 서버 도메인 전용 조회에 사용합니다. | 프록시를 연결하기 전에 같은 프록시에 노드 조회를 의존하는 순환 구조를 방지합니다. |
default-nameserver | DNS 상위 서버의 도메인을 조회할 때 사용합니다. | 초기 연결에 필요한 조회용 설정이지 기본 서비스 조회용 상위 DNS는 아닙니다. 개인정보 보호 범위에도 포함해 고려해야 합니다. |
예를 들어 통신사 UDP DNS와 해외 fallback을 함께 설정하면 최종적으로 해외 DNS 결과를 사용하더라도 통신사가 조회를 전혀 받지 않았다는 뜻은 아닙니다. 로컬 일반 DNS에 업무 도메인이 노출되는 것을 줄이려면 fallback-filter만 조정하지 말고 불필요한 평문 상위 DNS부터 제거하세요.
nameserver-policy를 사용하면 특정 도메인에 별도의 상위 DNS를 지정할 수 있습니다. 기존 구독에 이 항목이 있으면 일부 도메인은 수정한 기본 nameserver를 사용하지 않을 수 있습니다. 새 설정 조각만 보지 말고 실제 적용된 최종 설정을 확인하세요. 암호화 DNS는 기기와 DNS 서비스 사이의 조회 내용을 보호하지만, DNS 서비스 자체는 도메인을 처리하고 확인할 수 있습니다.
mihomo fake-ip 설정: 상위 DNS와 프록시 경로 지정
아래는 기존 mihomo 설정에 병합해 사용할 DNS 설정 조각이며, 완성된 구독 설정이 아닙니다. Cloudflare DoH 상위 DNS를 IP 주소로 지정해 DNS 서비스 도메인을 조회하기 위한 초기 조회를 줄입니다. 사용하기 전에 해당 DNS 서비스가 네트워크 정책에 맞는지, 프록시 노드에서 접속할 수 있는지 확인하세요. 기존 설정에 fallback 또는 nameserver-policy가 있다면 함께 검토해야 합니다. 이 조각을 붙여 넣는다고 기존 항목이 자동으로 삭제되지는 않습니다.
# 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"
- "localhost"
respect-rules: true
nameserver:
- https://1.1.1.1/dns-query
proxy-server-nameserver:
- https://1.1.1.1/dns-query여기서 ipv6: false는 우선 커널 DNS의 AAAA 응답을 문제 원인에서 제외하기 위한 설정입니다. 시스템 IPv6를 끄는 것은 아니며 다른 앱이 IPv6 주소를 직접 조회하는 것도 막지 않습니다. IPv6가 필요하면 트래픽 가로채기와 출구 지원을 확인한 뒤 설정을 복구하고 IPv6 경로를 별도로 테스트하세요.
업무용 DNS 상위 연결을 실제 프록시 정책으로 보내기
respect-rules: true를 설정하면 업무용 DNS 상위 서버 연결에 라우팅 규칙이 적용됩니다. 중국 본토 직접 연결, 기타 직접 연결, 기본 직접 연결 규칙이 있다면 해당 상위 서버의 연결 경로를 명확히 지정해야 합니다. 아래 규칙은 기존 rules 목록의 앞부분에 추가해 넓은 범위의 IP 규칙과 MATCH보다 먼저 적용되게 하세요. 예시에서는 기존 정책 그룹 이름이 PROXY라고 가정합니다. 실제 이름이 다르면 사용 중인 정책 그룹 이름으로 바꾸고 rules 키를 새로 추가하지 마세요.
# 규칙 조각: 기존 rules 목록에 추가하고 나머지 규칙은 유지하세요
- IP-CIDR,1.1.1.1/32,PROXY,no-resolve‘프록시’ 페이지에서 PROXY의 현재 선택 항목이 DIRECT가 아니라 프록시 노드인지도 확인하세요. 위 규칙은 업무용 DNS 상위 서버 연결에 적용됩니다. proxy-server-nameserver는 프록시 연결에 필요한 노드 도메인 조회 경로이므로, 아직 연결되지 않은 동일한 프록시에 의존하도록 설정할 수 없습니다. 이 예시에서는 노드 초기 조회에 직접 연결 방식의 암호화 DoH를 사용합니다. 로컬 네트워크에서는 DNS 서비스로 향하는 연결을 볼 수 있고, DNS 서비스는 노드 도메인을 처리합니다.
fake-ip-filter에는 꼭 필요한 도메인만 추가
실제 주소가 필요한 로컬 네트워크 기기나 특정 앱은 fake-ip-filter에 추가할 수 있습니다. 필터에 포함된 도메인은 실제 주소를 반환하지만, 이것이 자동으로 직접 연결된다는 뜻은 아니며 DNS 누수 방지 스위치도 아닙니다. 한 기기의 문제를 해결하려고 모든 도메인을 필터에 넣지 마세요. fake-ip가 도메인 매핑을 유지하는 주요 이점을 잃게 됩니다.
TUN과 브라우저 설정: DNS 조회를 가로채기 범위에 포함
시스템 프록시는 해당 설정을 따르는 앱에 주로 적용되며 UDP DNS를 모든 앱에서 가로채지는 못합니다. 더 많은 앱의 트래픽을 가로채려면 시스템 권한을 갖춘 상태에서 TUN을 사용할 수 있습니다. Windows에서는 보통 클라이언트 서비스 모드나 관리자 권한이 필요합니다. macOS와 Linux에서도 해당하는 권한 또는 권한 설정이 필요합니다. 먼저 가상 네트워크 어댑터가 정상적으로 생성됐는지 확인한 뒤 DNS 가로채기를 점검하세요. 화면에서 스위치만 켰다고 가로채기가 완료된 것은 아닙니다.
# 선택 사항인 TUN 설정 조각: 위 dns 섹션과 함께 사용
tun:
enable: true
stack: system
auto-route: true
auto-detect-interface: true
dns-hijack:
- any:53
- tcp://any:53이 설정은 TUN으로 들어오는 일반 UDP 및 TCP 53 조회를 커널 DNS로 전달합니다. 실제 동작은 운영체제, 라우팅, 커널 지원 여부에 따라 달라집니다. 시스템 DNS 설정에는 보통 서버 IP만 입력할 수 있으므로 127.0.0.1:1053처럼 포트가 포함된 주소를 지정할 수 없습니다. TUN을 사용하지 않고 시스템에서 로컬 DNS를 직접 이용하려면 53 포트 수신을 별도로 구성하고 권한 및 포트 충돌 문제도 해결해야 합니다.
- Chrome: ‘설정’ → ‘개인 정보 보호 및 보안’ → ‘보안’ → ‘보안 DNS 사용’. 문제를 진단하는 동안에는 잠시 끄고 테스트 결과를 비교하세요.
- Firefox: ‘설정’ → ‘개인 정보 및 보안’ → ‘DNS over HTTPS’. 보호 수준과 지정된 제공자를 확인하세요. 메뉴 이름은 버전에 따라 조금 다를 수 있습니다.
- Android: 시스템 ‘설정’에서 ‘비공개 DNS’를 확인하세요. 메뉴 위치는 제조사마다 다르며, 암호화된 조회는 일반 UDP 53 가로채기 대상이 아닙니다.
브라우저 DoH와 시스템 DoT는 별도의 암호화 연결을 사용하므로 dns-hijack으로 일반 커널 DNS처럼 분해해 처리할 수 없습니다. 이 기능을 계속 사용해도 되지만 해당 연결이 예상한 경로로 프록시를 통과하는지 확인해야 합니다. 기능을 끄는 것은 진단 방법일 뿐 유일한 장기 해결책은 아닙니다.
설정 변경 후 인터넷에 연결되지 않을 때: 의존 관계에 따라 점검
| 증상 | 먼저 확인 | 해결 방향 |
|---|---|---|
| 로컬 1053 조회 시간 초과 | 설정 로드 오류, DNS 활성화 상태, 포트 사용 여부 | 먼저 로컬 조회를 성공시킨 다음 웹 테스트 결과를 확인하세요. |
| 노드 도메인 사용 시 연결 실패 | proxy-server-nameserver에 접속할 수 있는지 확인하세요. | 노드 초기 조회를 복구해 DNS 조회와 프록시가 서로 의존하는 상황을 피하세요. |
| 노드 연결은 정상이지만 도메인 접속이 시간 초과됨 | DoH 상위 DNS의 라우팅과 현재 선택된 정책 그룹 | 상위 DNS 연결이 프록시를 통과하고 프록시에서 DNS 서비스에 접속할 수 있는지 확인하세요. |
| 일부 로컬 네트워크 앱만 오작동 | fake-ip를 받았는지, 실제 로컬 네트워크 주소가 필요한지 확인하세요. | 필요한 범위만 필터링하고 로컬 네트워크 우회 규칙을 추가하세요. |
| 테스트에 예상하지 못한 DNS 서버가 계속 표시됨 | 브라우저 DoH, 비공개 DNS, 다른 VPN, IPv6 | 항목별로 하나씩 끄고 비교해 우회 경로를 찾은 뒤 사용할 설정을 결정하세요. |
한 번에 한 계층만 변경하세요. 먼저 상위 DNS, 다음으로 규칙, TUN, 마지막으로 브라우저와 시스템의 별도 DNS 조회를 점검합니다. 노드 변경, TUN 활성화, 시스템 DNS 변경을 동시에 하면 어떤 설정이 효과가 있었는지 판단하기 어렵습니다. TUN을 켠 뒤 기기 전체가 오프라인이 되면 먼저 TUN을 꺼서 네트워크를 복구한 다음 기본 경로, 권한, 다른 VPN과의 충돌을 확인하세요. 서로 다른 DNS 주소를 계속 추가하지 마세요.
최종 재테스트 체크리스트
- 로컬
1053조회가 예상한 매핑 주소를 반환하고 커널 로그에 지속적인 DNS 조회 시간 초과가 없습니다. - 업무용 DoH 연결이 지정된 프록시 정책에 매칭되고 노드 도메인 조회에는 별도로 작동하는 초기 조회 경로가 있습니다.
- 웹 테스트에 표시된 DNS 서비스가 예상한 서비스와 일치합니다. DNS 서버 IP가 노드 IP와 같아야 한다고 판단하지 마세요.
- 브라우저 보안 DNS, 시스템 비공개 DNS, IPv6, 로컬 네트워크 앱을 각각 테스트했습니다.
- 클라이언트를 재시작하고 구독을 업데이트한 뒤 다시 테스트해 오버라이드 설정이 유지되는지 확인하세요.
DNS 누수 방지 설정의 핵심은 특정 항목을 true로 바꾸는 것이 아니라 트래픽 가로채기, 주소 매핑, 상위 DNS, 라우팅이 검증 가능한 경로를 이루도록 하는 것입니다. 네트워크, 노드, 클라이언트 커널을 변경한 뒤에는 이 비교 절차를 다시 진행하세요. 포트, 정책 그룹, 시작 설정은 고급 설정 매뉴얼의 포트 안내와 도움말 센터의 문제 해결을 참고하세요.