Clash DNS 유출 검사: 유출 확인 방법과 방지 설정 실전

DNS 유출이란

프록시가 켜져 있고 웹사이트도 정상적으로 열리지만, 실제로는 시스템 DNS가 통신사 서버에 직접 도메인을 조회하는 경우가 있습니다. 이 조회는 프록시 경로를 거치지 않아 방문한 모든 도메인이 평문 그대로 통신사나 게이트웨이 로그에 남게 되는데, 이것이 바로 DNS 유출입니다.

유출은 두 가지 문제를 낳습니다. 첫째는 프라이버시입니다. 해석을 담당하는 쪽이 접속 기록 전체를 파악하게 되며, 프록시가 만든 암호화 터널로도 이 단계는 가려지지 않습니다. 둘째는 안정성입니다. 평문으로 오가는 53번 포트 조회는 중간 장비에 가로채이기 쉬워 오염되거나 잘못된 주소를 돌려받는 경우가 흔한데, 노드 상태는 정상인데 목표 사이트가 열리지 않거나 전혀 다른 페이지로 연결되는 증상이 대표적입니다.

흔한 오해 중 하나는 "시스템 프록시만 켜면 끝"이라는 생각입니다. 시스템 프록시는 애플리케이션의 HTTP 프록시 설정만 바꿀 뿐 DNS 조회를 넘겨받지 않습니다. 많은 앱이 시스템 프록시를 무시하고 직접 해석을 수행하며, 브라우저 역시 자체 암호화 DNS를 켜서 별도로 통신하기도 합니다. DNS 조회 역시 하나의 트래픽이므로 웹페이지 트래픽과 똑같이 완전히 넘겨받아야 비로소 유출을 막았다고 할 수 있습니다.

검사 절차: 유출 여부 먼저 확인하기

검사 전에 다른 프록시나 VPN 도구는 모두 끄고, Clash만 켜서 확인하려는 프록시 모드로 맞춰 둡니다. 여러 도구가 겹치면 판단이 흐트러질 수 있습니다.

IP 조회 페이지를 열어 현재 출구 주소가 이미 노드 주소로 바뀌었는지 확인합니다. 이는 프록시 경로 자체가 정상 동작함을 먼저 증명하는 단계입니다.
DNS 유출 검사 사이트를 열어 전체 테스트를 실행하고, 결과에 표시된 DNS 서버 주소와 소속 통신사, 지역을 기록합니다.
터미널에서 nslookup example.com을 실행해 반환된 서버 주소를 기록합니다. macOS와 Linux에서는 dig example.com으로 한 번 더 대조해볼 수 있습니다.
Clash의 로그 레벨을 debug로 바꾼 뒤 nslookup을 다시 실행해, 로그에 이 DNS 조회 기록이 남는지 확인합니다.
현재 시스템에 적용된 DNS를 확인합니다. Windows는 ipconfig /all, macOS는 scutil --dns, Linux는 resolvectl status를 실행하거나 /etc/resolv.conf를 직접 확인합니다.

위 결과를 모두 모아 대조하면 아래 기준으로 판단할 수 있습니다.

검사 결과	판정 결론
검사 페이지에 표시된 DNS가 로컬 통신사나 라우터 게이트웨이 소속	유출 발생, 해석이 로컬에서 직접 처리됨
debug 로그에서 방금 실행한 nslookup 기록을 찾을 수 없음	조회가 Clash를 거치지 않음, 유출 발생
nslookup에서 프록시 도메인에 대해 198.18.x.x 주소가 반환됨	조회가 fake-ip로 넘겨받아짐, 정상
검사 페이지에 표시된 DNS가 프록시 출구 소재 지역 소속	해석이 프록시를 통해 이루어짐, 유출 없음

교차 검증이 있어야 신뢰할 수 있습니다

검사 페이지 결과만으로는 부족합니다. 검사 페이지는 "최종적으로 어느 출구에서 해석이 이루어졌는가"를 보여주고, Clash 로그는 "조회가 Clash를 거쳤는가"를 보여줍니다. 두 결과가 일치할 때만 판정을 신뢰할 수 있습니다.

유출 원인: 자주 발생하는 다섯 가지

유출이 확인되면 발생 빈도가 높은 순으로 다음 다섯 가지 원인을 점검합니다.

시스템 프록시 모드만 켜둔 경우—시스템 프록시는 시스템 프록시 설정을 따르는 앱만 넘겨받으며, UDP 53번 포트의 DNS 조회는 범위 밖입니다. 많은 데스크톱 앱이 여전히 시스템 DNS에 직접 접속합니다.
브라우저의 "보안 DNS"가 켜진 경우—브라우저 내장 DoH는 시스템 프록시를 건너뛰고 도메인을 브라우저가 지정한 DoH 서버로 바로 보내므로, 시스템 단계에서는 이 조회가 전혀 보이지 않습니다.
IPv6가 넘겨받아지지 않은 경우—IPv4만 넘겨받으면 AAAA 조회와 IPv6 트래픽이 로컬에서 직접 빠져나가며, 듀얼스택 네트워크 환경에서 특히 자주 발생합니다.
규칙이 DNS를 허용해버린 경우—설정에 DST-PORT,53을 직접 연결하도록 하는 규칙이 있거나, 프록시가 필요한 도메인이 잘못 DIRECT 정책에 들어간 경우입니다.
통신사나 게이트웨이가 53번 포트를 가로채는 경우—공용 DNS를 수동으로 지정해도 평문 조회가 중간에서 변경될 수 있어, 결과적으로 유출과 동일한 증상이 나타납니다.

유출 방지 설정: 해석을 모두 Clash로 통과시키기

유출 방지의 핵심 원칙은 단 하나입니다. 모든 DNS 조회가 먼저 Clash의 DNS 모듈로 들어가고, 이후 Clash가 로컬 해석과 프록시 경유를 결정하도록 만드는 것입니다. 실행 방법은 두 단계입니다. TUN을 켜서 전체 트래픽을 넘겨받고, dns 섹션을 올바르게 설정합니다.

1단계: TUN 모드 켜기

TUN은 가상 네트워크 카드를 통해 UDP 53을 포함한 전체 트래픽을 넘겨받으며, 어떤 앱의 DNS 조회든 먼저 Clash로 들어갑니다. 유출을 가장 확실하게 막는 방식입니다. Windows는 서비스 모드를 설치하고 관리자 권한으로 실행해야 하며, macOS는 헬퍼 프로그램 설치를 승인해야 하고, Linux는 root 또는 해당 capabilities가 필요합니다. mihomo 커널 설정 예시는 다음과 같습니다.

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

여기서 dns-hijack의 any:53은 모든 목적지로 향하는 53번 포트 조회를 Clash의 DNS 모듈로 가로챈다는 의미로, 유출 방지의 핵심이 되는 한 줄입니다.

2단계: dns 섹션 설정

dns:
  enable: true
  ipv6: false
  listen: 0.0.0.0:53
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  fake-ip-filter:
    - "+.lan"
    - "+.local"
  default-nameserver:
    - 192.0.2.53
  nameserver:
    - https://192.0.2.53/dns-query
  proxy-server-nameserver:
    - https://192.0.2.53/dns-query

enable과 listen: Clash가 53번 포트에서 DNS 서비스를 제공하며, TUN의 dns-hijack과 함께 모든 조회를 넘겨받습니다.
enhanced-mode를 fake-ip로 설정: 프록시가 필요한 도메인에 198.18.0.0/16 범위의 가짜 주소를 바로 돌려줍니다. 앱은 이 가짜 주소로 연결을 시도하고, Clash가 도메인을 복원해 프록시로 넘기므로 목표 도메인이 로컬에서 전혀 해석되지 않아 유출 방지 강도가 가장 높습니다. redir-host는 먼저 로컬에서 실제 해석을 한 번 거치므로 평문 조회 구간이 남습니다.
ipv6을 false로 설정: AAAA 조회에 응답하지 않아 IPv6 우회를 막습니다. IPv6가 꼭 필요하다면 TUN이 IPv6 트래픽까지 넘겨받고 있는지 반드시 함께 확인해야 합니다.
default-nameserver: 부트스트랩 DNS로, nameserver에 지정한 DoH/DoT 서버 자체의 주소를 해석하는 용도로만 쓰이며 반드시 순수 IP를 입력해야 합니다.
nameserver: 일반 해석용 상위 서버로, DoH나 DoT 같은 암호화 방식을 권장합니다. 조회가 암호화 경로로 나가면 로컬 네트워크에서는 DoH 서버로 향하는 암호화 연결 하나만 보이게 됩니다.
proxy-server-nameserver: 노드 도메인 해석에만 사용되며, 노드 주소 해석이 신뢰할 수 없는 로컬 DNS로 넘어가는 것을 막습니다.

설정 속 주소는 예시입니다

위 예시의 192.0.2.53은 문서용으로 예약된 예시 주소이며, 실제 사용 시에는 신뢰하는 암호화 DNS 서비스로 교체해야 합니다. 구독 설정에는 보통 dns 섹션이 이미 포함되어 있으므로, 수정 전에 원본 파일을 먼저 백업해 두세요.

당장 TUN을 켤 수 없다면 차선책으로, 시스템 프록시는 켜둔 채 시스템 DNS를 127.0.0.1로 지정해 Clash의 dns 모듈이 53번 포트에서 시스템 해석을 넘겨받도록 하는 방법이 있습니다. 이 방식은 시스템 DNS를 따르는 앱은 커버하지만 자체적으로 DNS를 지정하는 앱은 막지 못해, 보호 강도가 TUN 방식보다 확실히 낮습니다.

적용 확인: 수정 후 다시 검사하기

설정을 수정한 뒤 Clash를 재시작하거나 설정을 다시 불러오고, 앞서 소개한 검사 절차를 처음부터 다시 진행하며 항목별로 대조합니다.

nslookup example.com을 실행하면 서버 주소가 127.0.0.1이나 로컬 주소로 표시되어야 하며, 이는 조회가 Clash로 넘겨받아졌음을 증명합니다.
프록시를 타는 도메인에 nslookup을 실행하면 198.18.x.x 대역의 주소가 반환되어야 하며, 이는 fake-ip가 적용되었음을 증명합니다.
debug 로그에서 방금의 조회 기록이 보이고, 매칭된 상위 서버와 정책이 함께 표시됩니다.
DNS 유출 검사 페이지를 다시 실행하면 결과에 로컬 통신사나 게이트웨이 DNS가 더 이상 나타나지 않고, 프록시 출구 지역의 해석 기록만 남아야 합니다.
국내외 여러 사이트를 연속으로 방문해, 직접 연결되는 사이트는 정상 해석되고 프록시를 타는 사이트도 정상적으로 열리는지, 설정 변경으로 새로운 문제가 생기지 않았는지 확인합니다.

최종 판정 기준

로컬 조회가 전부 Clash 로그에 잡히고, 검사 페이지에 로컬 DNS가 더는 나타나지 않으며, 프록시 도메인이 fake-ip 주소를 반환하는 세 가지가 동시에 성립하면 유출은 완전히 막힌 것입니다.

자주 묻는 질문

fake-ip를 켠 뒤 일부 로컬 네트워크 기기에 접속이 안 될 때는?

fake-ip-filter에 로컬 네트워크 도메인을 추가하세요. 예를 들어 +.lan, +.local과 라우터 관리 주소를 넣으면 이 도메인들은 fake-ip를 건너뛰고 실제 해석을 수행합니다.

TUN을 켠 뒤 시스템 전체가 인터넷에 연결되지 않을 때는?

먼저 서비스 모드나 권한이 정상적으로 설치되었는지 확인한 뒤, auto-route와 auto-detect-interface가 켜져 있는지 점검합니다. 여전히 문제가 있다면 stack을 mixed, system, gvisor 사이에서 바꿔가며 테스트하고, 로그에서 TUN 관련 오류 항목을 확인하세요.

검사 페이지에 여러 지역의 DNS가 표시되면 유출인가요?

반드시 그렇지는 않습니다. 이 DNS들이 모두 프록시 출구 지역에 속하고 로컬 조회 기록이 전부 Clash에서 확인된다면 해석이 프록시를 거쳐 정상적으로 이루어진 것입니다. 로컬 통신사나 게이트웨이 DNS가 나타날 때만 유출로 판정합니다.

브라우저의 보안 DNS는 꺼야 하나요?

TUN 모드에서는 브라우저의 DoH 트래픽도 함께 넘겨받아 규칙에 따라 분기되므로 켜둔 채로 두어도 됩니다. 시스템 프록시 모드만 사용할 때는 끄는 것을 권장하는데, 브라우저가 Clash를 건너뛰고 직접 해석하는 것을 막기 위해서입니다.

Clash 클라이언트 다운로드

사용 중인 플랫폼에 맞는 클라이언트를 선택해 설치한 뒤, 본문의 TUN과 DNS 설정을 적용하면 유출을 막을 수 있습니다.

다운로드 센터로 이동 사용 가이드 보기