개인정보 및 보안 예상 읽기 시간 12분

Clash DNS 누출 점검 및 해결: DNS 조회 경로와 누출 방지 설정 가이드

브라우저 테스트와 시스템 조회로 DNS 출구를 확인하고, fake-ip·DNS 하이재킹·폴백 DNS 설정으로 누출 위험을 줄이는 방법을 안내합니다.

DNS 누출과 Clash 조회 경로

웹사이트에 접속할 때 애플리케이션은 보통 먼저 도메인을 DNS 리졸버에 전달한 뒤, 응답으로 받은 IP 주소에 연결합니다. 프록시 규칙은 이후 연결이 직접 연결인지 프록시인지 결정할 수 있지만, DNS 조회가 같은 경로를 자동으로 따르는 것은 아닙니다. 웹 트래픽은 프록시를 거치는데 도메인 조회가 로컬 라우터, 통신사 DNS 또는 예상하지 못한 서버로 전송된다면 이를 흔히 DNS 누출이라고 합니다.

여기서 말하는 ‘누출’은 의도한 동작과 함께 판단해야 합니다. 중국 본토에서 직접 연결하는 도메인을 로컬 DNS가 해석하는 것 자체는 오류가 아닐 수 있습니다. 실제로 확인할 부분은 프록시 측에서 해석해야 할 도메인이 로컬 네트워크에 노출되는지, 조회 결과가 잘못 변경되는지, 애플리케이션이 Clash의 DNS 모듈을 우회하는지입니다. 목표는 테스트 페이지에 특정 주소만 표시되게 하는 것이 아니라, 설계한 규칙과 DNS 조회 경로를 일치시키는 것입니다.

일반적인 조회 경로는 네 단계로 나눌 수 있습니다. 애플리케이션이 조회를 시작하고, 운영체제가 DNS 서버를 선택하며, Clash 또는 mihomo가 조회를 받아 처리하고, 상위 DNS 리졸버가 결과를 반환합니다. 시스템 프록시는 HTTP 또는 SOCKS 프록시 설정을 따르는 연결에만 영향을 주며, 일반적으로 운영체제가 UDP 53 포트로 보내는 DNS 요청까지 가로채지는 않습니다. TUN을 활성화하면 클라이언트가 시스템 네트워크 트래픽을 더 폭넓게 가로챌 수 있지만, 일반 UDP/TCP DNS 조회를 내장 리졸버로 보내려면 DNS 하이재킹도 설정해야 합니다.

브라우저에서 DNS over HTTPS, 즉 DoH가 활성화되어 있을 수도 있습니다. DoH는 DNS를 HTTPS 연결에 담아 브라우저가 지정한 서버로 전송합니다. 이 트래픽은 443 포트를 사용하므로 일반적인 53 포트 하이재킹으로는 식별할 수 없고, 별도의 DNS 조회 경로가 만들어집니다. 문제를 확인할 때는 Clash, 운영체제, 브라우저를 모두 점검해야 하며 클라이언트 화면의 DNS 스위치만 확인해서는 안 됩니다.

단계별 DNS 출구 점검: 브라우저, 시스템, 로그

점검 전에 시스템 프록시 활성화 여부, TUN 사용 여부, Clash DNS 활성화 여부, 브라우저 보안 DNS 사용 여부 등 현재 모드를 기록합니다. 그런 다음 Clash를 완전히 끈 상태, 시스템 프록시만 켠 상태, TUN을 켠 상태에서 각각 테스트합니다. 캐시, 네트워크 전환, 공용 DNS의 분산 처리 때문에 결과가 달라질 수 있으므로 한 번의 스크린샷보다 상태별 비교가 더 중요합니다.

1단계: 브라우저로 실제 접속 환경 테스트

  1. 이전 연결과 메모리 캐시의 영향을 피하려면 브라우저 창을 모두 닫은 뒤 다시 실행합니다.
  2. 신뢰할 수 있는 DNS 테스트 페이지에 접속해 기본 테스트와 확장 테스트를 실행하고, 리졸버 IP·네트워크 제공업체·지역을 기록합니다.
  3. Clash의 시스템 프록시 또는 TUN 상태를 전환한 뒤 다시 테스트하여 리졸버가 바뀌는지 비교합니다.
  4. 브라우저 설정에서 보안 DNS, 보안 DNS 사용 또는 DNS over HTTPS 옵션을 확인하고 별도의 서비스 제공업체가 지정되어 있는지 살펴봅니다.

테스트 페이지는 보통 무작위 서브도메인을 생성해 어떤 리졸버가 권한 있는 DNS에 요청했는지 확인합니다. 이는 해당 페이지가 조회를 유발했을 때의 출구를 보여줄 뿐, 모든 애플리케이션이 같은 경로를 사용한다는 뜻은 아닙니다. 브라우저 확장 프로그램, 기업 정책, 시스템 캐시, 네트워크의 투명 프록시도 결과를 바꿀 수 있으므로 시스템 명령과 Clash 로그를 함께 확인해야 합니다.

2단계: 운영체제에서 사용 중인 DNS 확인

Windows에서는 PowerShell에서 네트워크 어댑터의 DNS를 확인하고 캐시되지 않은 도메인을 직접 조회할 수 있습니다:

Get-DnsClientServerAddress
Resolve-DnsName example.com

macOS에서는 현재 리졸버 목록과 시스템의 DNS 조회 결과를 확인할 수 있습니다:

scutil --dns
dscacheutil -q host -a name example.com

systemd-resolved를 사용하는 Linux 배포판에서는 다음 명령을 실행할 수 있습니다:

resolvectl status
resolvectl query example.com

명령 출력에 나타나는 DNS 서버는 로컬 루프백 주소, LAN 게이트웨이 또는 TUN이 할당한 가상 주소일 수 있습니다. 로컬 주소가 표시된다고 해서 조회가 로컬에서 끝났다는 뜻은 아니며, Clash가 최종적으로 어떤 상위 DNS를 선택했는지도 확인해야 합니다. 반대로 시스템이 라우터로 직접 조회를 보내는데 Clash 로그에 해당 기록이 없다면, 요청이 Clash DNS 모듈에 들어오지 않았을 가능성이 큽니다.

3단계: 로그로 조회 경로 확인

클라이언트의 로그 수준을 일시적으로 DNS 동작을 확인할 수 있는 단계로 높인 뒤, 이전에 방문하지 않은 도메인을 조회합니다. 로그에 도메인 해석, 규칙 일치, 상위 서버 연결 또는 실패 후 재시도 기록이 있는지 확인합니다. 점검이 끝나면 평소 사용하는 로그 수준으로 되돌려 디버그 정보가 저장 공간을 계속 차지하지 않게 합니다.

로그에 조회 기록이 전혀 없다면 시스템 DNS, TUN DNS 하이재킹, 브라우저 DoH를 우선 점검합니다. 조회 기록은 있지만 상위 서버 연결이 예상과 다른 DIRECT 또는 프록시 정책으로 처리된다면, 리졸버 주소 자체가 규칙에 어떻게 매칭되는지 확인해야 합니다. 처음 접속할 때만 문제가 발생하고 이후 정상으로 돌아온다면 시스템, 브라우저, Clash 각각의 DNS 캐시도 고려해야 합니다.

Clash Meta（mihomo）DNS 설정과 fake-ip

mihomo의 DNS 모듈은 조회를 한곳에서 받은 뒤 설정에 따라 상위 DNS를 선택할 수 있습니다. 아래 예시는 필드 간 관계를 이해하기 위한 것으로, 실제 사용 시 기존 설정에 병합하고 네트워크 환경·커널 버전·구독 규칙에 맞게 조정해야 합니다. 수정 전에는 원본 설정을 저장해 YAML 들여쓰기나 필드 호환성 문제로 설정을 불러오지 못하는 상황을 방지하세요.

dns:
  enable: true
  listen: 0.0.0.0:1053
  ipv6: false
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  fake-ip-filter:
    - "*.lan"
    - "localhost"
    - "+.local"
  default-nameserver:
    - 223.5.5.5
    - 1.1.1.1
  nameserver:
    - https://dns.alidns.com/dns-query
    - https://doh.pub/dns-query
  proxy-server-nameserver:
    - https://dns.alidns.com/dns-query
  fallback:
    - tls://1.1.1.1
    - https://1.1.1.1/dns-query
  fallback-filter:
    geoip: true
    geoip-code: CN
    ipcidr:
      - 240.0.0.0/4

nameserver와 default-nameserver 이해하기

nameserver는 일반 도메인 조회에 사용하는 주요 상위 DNS입니다. 일반 DNS, DoT 또는 DoH 주소를 입력할 수 있습니다. 암호화 DNS를 사용하면 로컬 구간에서 조회 내용을 직접 읽거나 변조하기 어려워지지만, 상위 서비스 자체는 여전히 조회를 처리하므로 사용 가능하고 신뢰 범위에 맞는 서비스를 선택해야 합니다.

default-nameserver는 주로 부트스트랩 조회를 담당합니다. 예를 들어 DoH 상위 서버를 도메인으로 입력했다면, 암호화 연결을 만들기 전에 해당 DoH 도메인의 IP를 먼저 알아야 합니다. 이 필드에는 보통 직접 접속할 수 있는 IP 주소를 사용해 ‘DNS 서비스 자체를 조회할 때 같은 DNS 서비스를 먼저 사용해야 하는’ 순환을 피합니다. 부트스트랩 조회는 일반 DNS로 이루어질 수 있으므로 안정적이고 현재 네트워크 환경에 맞는 주소를 선택해야 합니다.

proxy-server-nameserver는 프록시 서버 도메인을 해석하는 데 사용합니다. 프록시 노드를 도메인으로 입력했다면 프록시 연결을 만들기 전에 노드 IP를 먼저 얻어야 합니다. 이런 조회를 별도로 설정하면 노드 도메인 조회와 일반 규칙이 서로 순환하는 문제를 줄일 수 있습니다. respect-rules 같은 새 필드를 사용할 때는 현재 mihomo 커널 버전과 클라이언트 구현을 먼저 확인하세요. 구형 커널은 해당 필드를 무시하거나 설정 오류를 보고할 수 있습니다.

fake-ip는 규칙 매칭에 어떻게 사용되나요?

fake-ip 모드에서 Clash는 예약 주소 대역의 임시 매핑 주소를 애플리케이션에 반환하고, 도메인과 가상 IP의 대응 관계를 저장합니다. 애플리케이션이 이 주소에 연결하면 커널이 원래 도메인을 복원해 도메인 규칙을 계속 적용할 수 있습니다. 이 방식은 요청을 더 일찍 가로채고, 애플리케이션이 자체 조회 결과를 이용해 직접 연결하는 상황을 줄이는 데 도움이 됩니다.

198.18.0.0/15는 벤치마크 테스트에 자주 사용하는 예약 네트워크 대역이며, 예시의 198.18.0.1/16은 이 범위에 속합니다. fake-ip 주소를 웹사이트의 실제 IP로 간주해서는 안 되며, 가상 IP에 ping을 보내 원격 서버 상태를 판단해서도 안 됩니다. 클라이언트의 매핑은 현재 커널과 캐시의 수명 동안만 유효합니다.

LAN 기기 검색, 프린터, 화면 공유, 일부 게임, 실제 IP에 의존하는 프로그램은 fake-ip와 맞지 않을 수 있습니다. 이 경우 필요한 도메인을 fake-ip-filter에 추가해 실제 조회 결과를 반환하도록 합니다. 필터 범위를 무한히 넓히면 많은 도메인이 다시 실제 IP 조회를 사용하게 되어, 통합 가로채기와 도메인 규칙 매칭의 효과가 떨어집니다.

TUN 모드와 DNS 하이재킹 설정

mihomo의 DNS 서비스만 활성화한다고 해서 시스템이 자동으로 조회를 전달하는 것은 아닙니다. 클라이언트는 시스템 DNS를 로컬 리스닝 포트로 변경하거나, TUN에서 기존 DNS 트래픽을 하이재킹할 수 있습니다. 데스크톱에서 흔히 사용하는 설정은 다음과 같습니다:

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

dns-hijack는 TUN을 통과하는 53번 포트 조회를 mihomo DNS 모듈로 보내며, 애플리케이션이 일반 DNS 서버를 직접 지정하는 경우도 대부분 처리합니다. 보통 UDP 53과 TCP 53을 처리할 수 있지만, 443 포트로 전송되는 DoH를 자동으로 식별하지는 못합니다. 자체 네트워크 스택, 특수 가상 네트워크 어댑터 또는 커널 수준 우회를 사용하는 모든 프로그램이 TUN에 들어온다고 보장할 수도 없습니다.

Windows에서 TUN을 활성화하려면 관리자 권한과 사용 가능한 가상 네트워크 어댑터 구성 요소가 필요한 경우가 많습니다. macOS는 시스템 네트워크 확장 또는 VPN 설정으로 터널을 만듭니다. Linux에서는 TUN 장치 권한, 라우팅 테이블, 방화벽 규칙이 함께 필요합니다. Android와 iOS 클라이언트는 보통 시스템 VPN 인터페이스로 트래픽을 가로채며, 일반적으로 한 번에 하나의 주요 VPN 설정만 활성 상태로 유지할 수 있습니다.

TUN을 켠 뒤 도메인이 전혀 해석되지 않는다면 먼저 TUN 라우팅이 생성되었는지 확인하고, 이어서 mihomo DNS 리스닝 포트가 사용 중인지 점검합니다. 방화벽이 커널의 상위 DNS 접근을 차단하지 않는지도 확인하고, 프록시 노드 도메인이 proxy-server-nameserver를 통해 해석되는지 살펴보세요. 노드 도메인 해석에 실패하면 프록시 터널을 만들 수 없습니다. 그런데 설정상 상위 DoH는 프록시를 통해 접속해야 한다면 시작 과정이 순환하는 문제가 발생합니다.

기업 VPN, 게임 가속기, 가상 머신 네트워크, 컨테이너 네트워크 또는 다른 프록시 도구를 동시에 실행하면 여러 프로그램이 기본 라우팅과 DNS 설정을 놓고 충돌할 수 있습니다. 문제를 확인하는 동안에는 충돌 가능성이 있는 도구를 하나씩 일시 중지하고 Clash만 실행했을 때의 결과를 확인한 뒤 라우팅 우선순위를 정하세요. 네트워크를 자주 전환한 후 DNS 설정이 남아 있다면 클라이언트를 종료하고 시스템 DNS를 자동 설정으로 되돌린 다음 TUN을 다시 활성화해 보세요.

브라우저 DoH와 앱 내장 리졸버

Chrome, Edge, Firefox 같은 브라우저는 암호화 DNS를 독립적으로 활성화할 수 있습니다. 일부 브라우저는 시스템 DNS를 해당 서비스 제공업체의 DoH로 자동 업그레이드하고, 일부는 사용자가 리졸버를 직접 지정할 수 있습니다. 지정한 서비스가 Clash 설정과 다르면 브라우저 테스트에 다른 DNS 출구가 표시될 수 있습니다. 이는 반드시 TUN이 작동하지 않는다는 뜻이 아니라, 브라우저가 별도의 HTTPS 조회 연결을 직접 만들었다는 의미입니다.

브라우저가 Clash DNS를 일관되게 사용하게 하려면 브라우저의 사용자 지정 보안 DNS를 끄고 조회를 운영체제로 돌린 다음, 시스템 DNS 또는 TUN 하이재킹을 통해 mihomo로 전달되게 할 수 있습니다. 다른 방법은 브라우저 DoH를 유지하면서 Clash 규칙으로 DoH 서비스 연결을 프록시 또는 직접 연결로 제어하는 것입니다. 다만 이 경우 도메인 조회는 원격 DoH 서비스에서 이루어지므로 mihomo가 각 조회 내용을 직접 확인할 수 없고, 도메인 기반 분기는 브라우저의 후속 연결에 포함된 도메인 정보에 의존할 수 있습니다.

일부 앱은 고정 DNS, DoH 또는 DoT를 내장하며, 백신과 자녀 보호 프로그램도 로컬 필터링 리졸버를 설치할 수 있습니다. 특정 앱에서만 결과가 이상하다면 Clash의 상위 DNS를 반복해서 바꾸기보다 해당 앱의 네트워크 설정, 실행 매개변수, 시스템 정책을 확인해야 합니다. Android의 ‘비공개 DNS’는 보통 DoT를 사용합니다. VPN 클라이언트와 함께 사용할 때 문제가 생기면 일시적으로 자동 또는 사용 안 함으로 설정해 비교 테스트를 진행하세요. 테스트 후 실제 필요에 따라 최종 설정을 결정하면 됩니다.

자주 발생하는 DNS 누출 및 조회 오류 문제 해결 순서

테스트 결과에 여전히 로컬 통신사 DNS가 표시됨

먼저 브라우저 보안 DNS가 꺼져 있는지 확인한 다음, 시스템 DNS가 클라이언트가 가로채는 주소를 가리키는지 확인합니다. 시스템 프록시만 켜고 TUN을 켜지 않았다면 시스템 수준의 UDP DNS가 라우터로 계속 전송되는 것은 흔한 현상입니다. 일관되게 가로채려면 호환되는 TUN과 DNS 하이재킹을 활성화하고, 클라이언트 로그에 조회 기록이 나타나는지 확인하세요.

fake-ip를 켠 뒤 LAN 기기에 접속할 수 없음

LAN 도메인 접미사를 fake-ip-filter에 추가하고, LAN 대역 규칙이 최종 프록시 규칙보다 앞에 있는지 확인합니다. NAS, 라우터 또는 프린터에 접속할 때는 먼저 LAN 주소로 기본 연결을 확인하세요. IP 주소로는 접속되지만 도메인으로는 안 된다면 라우터 DNS, mDNS 또는 내부 DNS가 로컬 도메인을 제공하는지 중점적으로 점검합니다.

DoH 상위 서버 연결 시간 초과

default-nameserver를 통해 DoH 도메인의 부트스트랩 조회가 가능한지 확인한 다음, 해당 IP가 잘못된 경로로 분기되지 않는지 점검합니다. 일부 네트워크는 특정 공용 DNS 서비스를 제한하므로, 접속할 수 없는 상위 서버를 무작정 추가하면 재시도 시간만 길어집니다. 검증된 상위 서버를 소수만 남기고 직접 연결과 프록시 경로를 나누어 설정하는 편이 많은 주소를 쌓는 것보다 문제를 찾기 쉽습니다.

프록시 노드는 사용 가능하지만 웹페이지에서 도메인 해석 불가라고 표시됨

노드 연결 테스트는 기존 IP나 캐시 결과를 사용할 수 있으므로 DNS 경로가 정상이라는 증거가 되지 않습니다. 노드 주소가 IP인지 도메인인지 확인하고, 도메인이라면 proxy-server-nameserver가 작동하는지 점검합니다. 그런 다음 일반 도메인을 조회하며 로그를 관찰해 ‘노드 도메인 해석 실패’, ‘상위 DNS 연결 실패’, ‘규칙에 의해 응답 거부’ 중 어떤 문제인지 구분하세요.

테스트 결과에 여러 리졸버가 표시됨

여러 리졸버가 표시되는 이유는 상위 서비스의 클러스터, 브라우저의 동시 조회, 폴백 조회, 또는 시스템과 브라우저의 두 경로가 동시에 작동하기 때문일 수 있습니다. 개수만으로 이상 여부를 판단하지 마세요. 무작위 도메인으로 테스트를 반복하고 브라우저 DoH, fallback, 다른 네트워크 도구를 각각 끈 뒤 어떤 설정이 추가 출구를 만들었는지 확인합니다. 모든 리졸버가 예상한 상위 DNS에 속하고 로컬 네트워크 리졸버가 프록시 도메인을 처리하지 않았다면 설계상 정상일 수 있습니다.

설정을 업데이트한 뒤 문제가 다시 발생함

구독 업데이트로 클라이언트의 DNS 섹션이 덮어쓰여지거나 규칙 그룹 이름이 바뀌어 기존 nameserver-policy 또는 상위 DNS 분기가 작동하지 않을 수 있습니다. 클라이언트가 구독 원본 설정, 오버라이드 설정, 병합 설정 중 무엇을 사용하는지 확인하세요. 장기간 유지해야 하는 DNS 설정은 클라이언트가 지원하는 오버라이드 방식에 저장하고, 업데이트할 때마다 최종 적용 설정을 확인해야 합니다. 구독 원본 파일만 확인해서는 충분하지 않습니다.

전체 점검은 하나의 순환 구조로 진행해야 합니다. 먼저 어떤 도메인을 로컬에서 해석하고 어떤 조회를 프록시 측에서 처리할지 정합니다. 그런 다음 브라우저 테스트로 현상을 확인하고, 시스템 명령으로 DNS 방향을 확인하며, 로그로 조회가 mihomo에 들어오는지 검증합니다. 마지막으로 fake-ip, 상위 리졸버, TUN 하이재킹, 브라우저 DoH를 조정합니다. 한 번에 변수 하나만 바꾸고 다시 테스트해야 어떤 설정이 문제를 해결했는지 판단할 수 있습니다.

설치 및 설정 계속하기

다운로드 페이지에서 현재 플랫폼에 맞는 Clash 클라이언트를 선택하거나 빠른 시작 가이드에 따라 구독 가져오기, 프록시 활성화, 연결 확인을 완료하세요.

다운로드 페이지 가이드 보기