DNS 유출 방지 및 탐지

DNS 기초 복습

DNS 유출을 이해하기 전에, DNS의 작동 방식을 간략히 살펴볼 필요가 있습니다. DNS(Domain Name System, 도메인 이름 시스템)는 인터넷의 '전화번호부'입니다. 브라우저에 www.google.com을 입력하고 엔터를 누르면, 기기는 해당 도메인이 어떤 서버의 IP 주소에 해당하는지 바로 알 수 없으므로, 먼저 DNS 서버에 쿼리를 보냅니다: 「www.google.com의 IP 주소는 무엇인가요?」. DNS 서버가 IP 주소를 반환한 후에야 기기가 실제 연결을 시작합니다.

이 DNS 쿼리 요청은 전통적인 설정에서 ISP(인터넷 서비스 제공업체)가 지정한 DNS 서버로 평문으로 전송됩니다. 이는 ISP(및 네트워크 트래픽을 감청할 수 있는 모든 사람)가 어떤 도메인을 쿼리했는지 완전히 기록할 수 있다는 의미입니다 — 프록시를 통해 해당 사이트에 접속했더라도, DNS 쿼리 자체가 이미 접속 의도를 유출한 것입니다.

DNS over HTTPS(DoH)와 DNS over TLS(DoT)는 DNS 쿼리를 암호화하는 두 가지 표준 방법으로, ISP가 전송 과정에서 DNS 요청을 감청하는 것을 방지합니다. 그러나 암호화된 DNS만으로는 충분하지 않습니다 — 프록시 환경에서는 DNS 요청이 프록시 터널을 통해 전송되어야 하며, 프록시를 우회하여 해외 DNS 서버로 직접 전송되어서는 안 됩니다.

DNS 유출이란?

DNS 유출(DNS Leak)이란: 프록시를 이미 활성화하여 웹사이트 콘텐츠가 프록시 터널을 통해 전송되고 있지만, DNS 쿼리 요청은 프록시를 거치지 않고 국내 ISP의 DNS 서버로 직접 전송되거나, 심지어 해외 DNS 서버(예: 8.8.8.8)로 전송되어 도메인 쿼리 기록이 프록시 보호 밖에 노출되는 상황을 말합니다.

Clash의 전통적인 작동 방식(Redir-Host 모드)에서 DNS 유출은 구조적인 문제입니다:

www.google.com에 접속할 때, 운영체제는 먼저 로컬 DNS 서버에 실제 IP를 쿼리하고, IP를 받은 후 Clash가 직접 연결할지 프록시로 연결할지 판단합니다. 문제는 이 DNS 쿼리가 Clash가 연결을 처리하기 전에 발생하며, 시스템 기본 DNS 서버(보통 ISP 서버)를 사용하여 전체 쿼리 과정이 프록시를 완전히 우회한다는 것입니다. 프록시를 통해 Google에 접속했더라도, Google에 접속했다는 사실 자체는 이미 ISP DNS 서버에 기록되어 있습니다.

더 심각한 상황은 '전역 프록시' 설정에서 발생합니다: 일부 사용자가 해외 DNS(예: 8.8.8.8)를 설정했지만 프록시를 통해 접근하지 않는 경우, 이 DNS 요청은 암호화 없이 그대로 ISP 망을 지나가면서 평문으로 기록되고, Google DNS 서버에도 쿼리 기록이 남으며, 추가 지연까지 발생하여 아무런 이점도 없습니다.

유출의 위험성

프라이버시 노출: DNS 유출의 가장 직접적인 위험은 프라이버시 침해입니다. 연결 콘텐츠가 암호화되어 있더라도, DNS 쿼리 자체가 이미 제3자에게 어떤 사이트를 방문했는지 알려줍니다. ISP, 정부 기관, 카페 Wi-Fi 관리자 모두 이 정보를 기록할 수 있습니다.

정확도 저하: DNS 쿼리가 프록시를 거치지 않으면, 해외 DNS 서버(예: 8.8.8.8)는 국내 출구 IP를 기반으로 국내 사용자에게 최적화된 해석 결과를 반환합니다. 이는 프록시 출구 지역에 최적화된 결과가 아니므로, 특정 사이트 접속 시 연결되는 서버의 지리적 위치가 맞지 않아 오히려 속도가 느려질 수 있습니다.

DNS 응답 변조 위험: 일부 ISP나 공공 Wi-Fi 네트워크는 DNS 응답에 광고를 끼워 넣거나, 특정 도메인에 대해 실제와 다른 IP를 반환하는 'DNS 스푸핑'을 수행하기도 합니다. DNS 요청이 프록시를 거치지 않으면, 프록시 노드가 완전히 정상 작동하더라도 이런 DNS 변조로 인해 해외 스트리밍·게임 서버에 정상적으로 접속하지 못할 수 있습니다.

Fake-IP 유출 방지 원리

Clash의 Fake-IP 모드는 DNS 유출 문제를 근본적으로 해결하는 최적의 방법으로, Mihomo 코어에서 권장 설정으로 널리 사용됩니다.

Fake-IP의 작동 방식은 전통적인 DNS 모드와 완전히 다릅니다: 앱이 DNS 쿼리를 시작하면, Clash의 내장 DNS 서버는 즉시 '가짜' 내부 IP 주소(예약 주소 대역인 198.18.0.0/15)를 반환하고, 실제로 외부 서버에 DNS 요청을 보내지 않습니다. 앱은 이 가짜 IP를 받아 TCP/UDP 연결 수립을 시작하고, Clash는 연결 레이어에서 해당 연결을 가로채어 가짜 IP로부터 원래 도메인을 역추적한 후, 규칙에 따라 이후 처리 방법을 결정합니다:

규칙에서 해당 도메인이 프록시가 필요하다고 판단되면, Clash는 '도메인 + 포트'를 프록시 터널을 통해 직접 프록시 서버로 전송하고, 프록시 서버 측에서 실제 DNS 해석이 완료됩니다 — 이렇게 DNS 쿼리는 해외 프록시 서버에서 발생하여 국내 ISP에 기록이 남지 않습니다.

규칙에서 해당 도메인이 직접 연결(국내 도메인)이라고 판단되면, Clash는 해당 도메인에 대해 실제 DNS 해석을 수행하며, 설정 파일에 지정된 국내 DNS 서버(예: KT의 168.126.63.1)를 사용하여 쿼리합니다. 결과가 정확하고 속도도 빠릅니다.

전체 과정에서 시스템 기본 DNS 서버로의 DNS 쿼리 유출이 없으며, 암호화되지 않은 해외 DNS 요청도 없습니다 — 이것이 Fake-IP의 근본적인 장점입니다.

Mihomo DNS 설정 방법

다음은 대부분의 시나리오에 적합한 Mihomo DNS 설정으로, Fake-IP를 활성화하고 국내외 트래픽 분류를 적절히 처리합니다:

dns:
  enable: true
  listen: 0.0.0.0:53        # 로컬 53번 포트 수신
  enhanced-mode: fake-ip    # Fake-IP 모드 활성화
  fake-ip-range: 198.18.0.1/16

  # Fake-IP 필터 목록: 이 도메인들은 Fake-IP를 사용하지 않고 실제 해석
  # NTP, Apple 푸시 등 시스템 서비스가 영향받지 않도록 보장
  fake-ip-filter:
    - "*.lan"
    - "*.local"
    - "*.localhost"
    - "time.*.com"
    - "time.*.gov"
    - "ntp.*.com"
    - "+.stun.*.*"
    - "+.stun.*.*.*"

  # 국내 도메인 해석을 위한 nameserver
  # DoH/DoT 암호화 쿼리 우선 사용
  nameserver:
    - https://cloudflare-dns.com/dns-query   # Cloudflare DoH
    - https://dns.google/dns-query           # Google DoH
    - 168.126.63.1                           # KT DNS (백업)
    - 1.1.1.1                                # Cloudflare DNS (백업)

  # 프록시 노드 도메인 해석용 (프록시 서버 자체의 도메인은 직접 해석 필요)
  proxy-server-nameserver:
    - https://cloudflare-dns.com/dns-query
    - 1.1.1.1

이 설정의 핵심 포인트: Fake-IP 필터 목록은 일반적인 시스템 서비스 도메인의 실제 해석을 유지하여, NTP 시간 동기화, mDNS 등 로컬 서비스가 Fake-IP로 인해 방해받지 않도록 합니다; 국내 nameserver는 DoH 암호화 쿼리를 사용하여 ISP의 DNS 응답 하이재킹을 방지합니다; 프록시 노드 도메인은 신뢰할 수 있는 국내 DNS로 해석하여 프록시 서버 주소가 DNS 오염되는 것을 방지합니다.

유출 여부 확인

설정 완료 후, 다음 단계로 DNS 유출이 해소되었는지 확인합니다:

방법 1: 온라인 탐지 도구 사용. dnsleaktest.com 또는 ipleak.net을 방문하여 「Extended test(확장 테스트)」를 클릭합니다. 테스트 완료 후, 페이지에 DNS 쿼리를 처리한 서버가 표시됩니다. 목록에 프록시 노드 지역(예: 미국, 홍콩)의 DNS 서버만 나타난다면 유출이 없는 것입니다; 국내 ISP의 DNS 서버(KT, SKT, LG U+ 등)가 나타난다면 유출이 있는 것으로 설정을 확인해야 합니다.

방법 2: 커맨드라인 확인. 터미널에서 다음 명령을 실행하고, 어떤 서버가 쿼리에 응답하는지 확인합니다:

# 해외 도메인을 쿼리하여 SERVER 필드 확인
nslookup google.com

# 또는 dig 사용 (더 자세한 결과)
dig google.com

SERVER가 127.0.0.1#53(즉, Clash 로컬 DNS)으로 표시되면, 시스템 DNS가 이미 Clash를 가리키고 있으며 Fake-IP가 정상 작동 중입니다. 192.168.x.x(라우터 DNS) 또는 ISP IP가 표시되면, 시스템 DNS 설정이 Clash를 올바르게 가리키지 않는 것이므로 TUN 모드가 활성화되어 있는지 또는 DNS 수신이 정상인지 확인해야 합니다.

흔한 오해

오해 1: 「8.8.8.8로 변경하면 유출을 방지할 수 있다」. 시스템 DNS를 Google의 8.8.8.8 또는 Cloudflare의 1.1.1.1로 설정해도 DNS 유출을 방지할 수 없으며, 오히려 상황이 더 나빠질 수 있습니다: 이 해외 DNS 서버로 보내는 쿼리 요청 자체가 프록시를 거치지 않고 평문으로 ISP 망을 지나가면서 그대로 기록되고, 지연도 더 높아집니다. 유출 방지의 핵심은 DNS 쿼리가 Clash를 통해 처리되도록 하는 것이지, 특정 DNS 서버를 선택하는 것이 아닙니다.

오해 2: 「프록시를 켜면 DNS가 자동으로 프록시를 통한다」. 전통적인 시스템 프록시 모드에서는 DNS 쿼리가 프록시와 완전히 독립적으로 작동하며, 자동으로 프록시를 통하지 않습니다. Clash의 DNS 수신이 활성화(enable: true)되고 시스템 DNS가 Clash를 가리킬 때(TUN 모드로 자동 완료되거나 시스템 DNS를 127.0.0.1로 수동 수정)에만 DNS가 Clash에 의해 통합 관리됩니다.

오해 3: 「Fake-IP 모드는 모든 사이트가 프록시를 통하게 한다」. Fake-IP는 DNS 해석 방식의 변경일 뿐이며, 트래픽 분류 결정은 여전히 규칙 집합에 의해 결정됩니다. GEOIP,KR,DIRECT 규칙이 설정된 경우, Fake-IP를 사용하더라도 국내 트래픽은 여전히 직접 연결되어 국내 사이트 속도에 영향을 미치지 않습니다.

요약: Clash Plus를 사용하고, TUN 모드를 활성화하며, Fake-IP DNS를 설정하는 것이 현재 가장 완전한 DNS 유출 방지 방법입니다. 세 가지가 함께 작동하여 프록시가 진정으로 「원활하고, 안전하며, 유출 없는」 상태를 실현합니다.