NT-03.1DNS 유출이란 무엇이고, 프록시가 연결됐는데도 왜 발생하는가
DNS 유출이란 트래픽 전달은 프록시를 거치지만, 도메인을 IP로 바꾸는 조회 요청은 프록시를 거치지 않고 기존에 쓰던 로컬 DNS 서버(대개 통신사 또는 공유기가 할당한 주소)로 그대로 나가는 상황을 말합니다. 이 경우 웹 콘텐츠 자체는 프록시를 통해 전송되더라도, 어떤 도메인에 접속했는지에 대한 정보는 로컬 네트워크에 그대로 노출됩니다. 또한 해석 결과가 일관되지 않아 연결이 불안정해지거나 DNS 스푸핑에 걸릴 수도 있습니다.
원인은 대개 두 층위에서 발생합니다. 첫째, 시스템 프록시 모드에서는 운영체제가 애플리케이션 계층의 HTTP/HTTPS 트래픽만 넘겨받기 때문에, DNS 요청은 별도의 UDP 53번 포트로 나가며 클라이언트가 이 경로를 따로 처리하지 않으면 프록시를 건너뛴 채 그대로 발송됩니다. 둘째, 클라이언트가 DNS를 넘겨받았더라도 dns 설정의 nameserver가 여전히 로컬이나 통신사 주소를 가리키고 있다면 해석 결과는 여전히 로컬 네트워크 환경의 영향을 받습니다. "도메인 요청이 프록시를 타는가"와는 별개로 확인해야 하는 문제입니다.
Clash와 Clash Meta(mihomo) 코어는 모두 설정 파일에 독립된 dns 항목을 두고, enhanced-mode로 해석 요청 처리 방식을 결정합니다. 이 필드의 동작 원리를 이해하는 것이 유출을 점검하고 고치는 전제 조건입니다.
NT-03.2점검 절차: 먼저 문제를 확인하고, 그다음 설정을 손댄다
설정을 손대기 전에 재현 가능한 절차로 실제 유출이 있는지 먼저 확인하고, 감으로 파라미터를 조정하는 일은 피해야 합니다. 아래 단계는 어떤 플랫폼의 클라이언트에서도 그대로 적용됩니다.
- 프록시를 끄고 현재 사용 중인 DNS 출구 주소를 한 번 기록합니다(시스템 네트워크 설정에서 현재 네트워크 어댑터가 쓰는 DNS 서버를 확인할 수 있습니다).
- 프록시를 연결하고 정책 그룹이 사용 가능한 노드를 선택했는지 확인한 뒤, 클라이언트 로그 패널을 열어
DNS또는resolve키워드로 필터링해 해석 요청 출력을 관찰합니다. - 요청 출처 정보를 그대로 되돌려주는 점검용 페이지에 접속해 두 결과를 비교합니다. 프록시를 켜기 전과 후에 반환되는 해석 서버 주소가 같은지 확인하세요. 프록시를 켠 뒤에도 여전히 로컬 통신사 DNS 출구가 표시된다면 유출입니다.
- 클라이언트의 연결(Connections) 패널에서 현재 활성 연결의 목적지 주소를 확인해, 해석된 IP가 예상하는 프록시 대역 안에 있는지, 아니면 로컬 네트워크에서 바로 도달 가능한 주소로 해석돼 버린 것은 아닌지 판단합니다.
- TUN 모드로 전환해 위 단계를 다시 실행하고, 시스템 프록시 모드일 때 결과와 비교해 특정 접수 방식에서만 유출이 나타나는지 판단합니다.
프록시를 켠 후에도 해석 요청의 출구 주소가 프록시를 꺼둔 상태와 똑같다면, 해당 요청이 dns 설정의 처리 로직을 거치지 않았다는 뜻입니다. 이때는 enhanced-mode와 시스템 레벨 DNS 설정이 다른 프로그램에 의해 덮어써지고 있는지 확인해야 합니다.
NT-03.3enhanced-mode의 두 가지 값과 동작 차이
dns 설정의 핵심 필드는 enhanced-mode이며, 클라이언트가 도메인 해석을 일괄 처리 흐름에 통합하는 방식을 결정합니다. 흔히 쓰는 값은 fake-ip와 redir-host입니다.
| 모드 | 해석 동작 | 적용 상황 |
|---|---|---|
fake-ip | 클라이언트가 가상 대역의 가짜 IP를 즉시 반환하고, 실제 해석은 연결이 맺어질 때 도메인 매칭 규칙에 따라 처리 | 기본 권장값, TUN 모드와 규칙 기반 분기와 함께 쓰면 호환성이 가장 좋음 |
redir-host | 상위 nameserver에 실제 IP를 직접 요청해 애플리케이션에 그대로 반환 | 일부 애플리케이션이 반환된 IP를 엄격히 검증해 가짜 IP를 쓸 수 없을 때의 대안 |
실제로 쓸 수 있는 dns 설정 예시는 다음과 같습니다. 핵심은 nameserver를 암호화 전송을 지원하는 주소로 바꾸는 것이지, 기존에 쓰던 로컬 해석 서버를 그대로 두는 것이 아닙니다:
dns:
enable: true
ipv6: false
enhanced-mode: fake-ip
fake-ip-range: 198.18.0.1/16
fake-ip-filter:
- "*.lan"
- "*.local"
- "+.market.xiaomi.com"
nameserver:
- https://1.1.1.1/dns-query
- https://dns.google/dns-query
fallback:
- tls://8.8.4.4:853
여기서 nameserver는 기본 해석 목록이며, DoH(DNS over HTTPS)나 DoT(DNS over TLS) 프로토콜을 쓰는 주소로 통일해 바꾸는 것을 권장합니다. 이렇게 하면 해석 요청 자체도 암호화되어 전송되므로 로컬 네트워크에서 평문으로 가로챌 수 없습니다. fallback 목록은 기본 nameserver 결과가 스푸핑됐다고 판단될 때 작동하며, 마찬가지로 암호화 프로토콜 주소를 쓰는 것이 좋습니다.
NT-03.4fake-ip-filter 설정 오류로 발생하는 로컬 네트워크 접속 문제
fake-ip를 켠 뒤 흔히 나타나는 부작용은 공유기 관리 페이지, NAS, 프린터 같은 로컬 네트워크 기기의 이름 해석도 가짜 IP로 바뀌어 접속이 안 되는 현상입니다. fake-ip-filter 필드는 어떤 도메인을 가짜 IP 해석 로직에서 제외하고 실제 결과를 그대로 쓸지 지정하는 용도입니다:
dns:
fake-ip-filter:
- "*.lan"
- "*.local"
- "localhost.ptlogin2.qq.com"
- "+.msftconnecttest.com"
- "+.msftncsi.com"
여기서 +. 접두사는 해당 도메인과 그 모든 하위 도메인을 매칭하고, *는 와일드카드 매칭입니다. 특정 로컬 네트워크 기기나 정확한 출구 IP가 필요한 서비스(예: 회사 내부 업무 시스템)가 프록시를 켠 뒤 접속되지 않는다면, 우선 해당 도메인을 이 필터 목록에 추가해야 하는지 확인하고, fake-ip를 바로 꺼버리지는 않는 것이 좋습니다.
enhanced-mode를 바로 redir-host로 바꾸면 가짜 IP로 인한 호환성 문제는 피할 수 있지만, 도메인 기반 규칙 분기 능력이 약해져 SNI나 IP 대역 매칭에 의존하는 일부 정책 그룹 규칙이 제대로 동작하지 않을 수 있습니다. 호환성 문제가 생기면 먼저 fake-ip-filter를 보완해보고, 모드 전체를 바꾸는 것은 마지막 수단으로 남겨두세요.
NT-03.5시스템 프록시 모드와 TUN 모드의 차이 점검
시스템 프록시 모드는 애플리케이션이 능동적으로 시스템 프록시 설정을 읽어들이는 트래픽만 넘겨받습니다. 일부 명령줄 도구, 일부 UDP 통신, 시스템 프록시 설정을 따르지 않는 프로그램은 DNS 요청이 클라이언트를 완전히 건너뛸 수 있습니다. 이런 유출은 dns 설정만 조정해서는 해결되지 않으며, TUN 모드를 켜서 가상 네트워크 어댑터가 네트워크 계층에서 DNS 조회를 포함한 모든 트래픽을 일괄 넘겨받도록 해야 합니다.
TUN 모드를 켠 뒤에는 다음 두 가지도 함께 확인해야 "트래픽만 넘겨받고 해석은 넘겨받지 못한" 절반짜리 상태를 피할 수 있습니다:
tun설정의dns-hijack필드가 켜져 있는지 확인합니다(흔히 쓰는 값은0.0.0.0:53또는any:53). 이 항목은 네트워크 계층에서 53번 포트로 오가는 모든 DNS 요청을 가로채 내장 DNS 서비스로 넘기는 역할을 합니다.- Windows와 macOS에서는 기존 네트워크 어댑터의 DNS 설정이 그대로 남아 있으면 일부 프로그램이 시스템 해석 캐시를 먼저 참조할 수 있습니다. TUN 모드가 제대로 적용됐는지 확인한 뒤 로컬 DNS 캐시를 한 번 비우고 다시 테스트하는 것을 권장합니다.
TUN 모드를 켜는 구체적인 절차와 플랫폼별 차이는 사이트 내 가상 네트워크 어댑터로 트래픽을 넘겨받는 방법을 다룬 전문 글을 참고하시고, 여기서는 반복하지 않습니다. dns-hijack과 enhanced-mode 설정을 마쳤다면 이 글 2부의 점검 절차를 다시 실행해, 프록시를 켜기 전과 후의 해석 출구 주소가 더 이상 같지 않을 때까지 확인하면 검증 한 바퀴가 완료됩니다.
NT-03.6설정 변경 후 재확인 권장 사항
dns 설정을 바꾸는 작업은 영향 범위가 넓은 편이므로, 다음 순서로 다시 확인해 설정 오류로 인한 연결 이상을 줄이는 것을 권장합니다:
- 먼저 테스트 환경이나 별도의 설정 파일에서 수정하고, 문제가 없음을 확인한 뒤에야 실제로 사용하는 Profile에 적용하세요. 사용 중인 구독 설정을 바로 덮어쓰지 않도록 주의합니다.
nameserver주소 형식이 맞는지 하나씩 확인합니다(DoH 주소는 완전한 URL 형태여야 하고, DoT 주소는tls://접두사와 포트 번호가 붙어야 합니다).- 이 글 2부의 점검 절차를 다시 실행해 해석 출구 주소의 변화를 기록합니다.
- 일정 기간 정상적으로 사용해보며 로컬 네트워크 기기 접속, 회사 내부 서비스 등 시나리오에 영향이 없는지 확인합니다.
DNS 유출 점검의 본질은 트래픽 전달뿐 아니라 "도메인 해석" 단계까지 프록시 경로에 포함됐는지 확인하는 것입니다. enhanced-mode, nameserver, fake-ip-filter 세 가지를 짝지어 꼼꼼히 점검하면 대부분의 유출 문제는 설정 단계에서 해결됩니다.