Clash DNS 누수 테스트 및 해결: 점검 방법과 유출 방지 설정

DNS 누수 판단 기준

DNS 누수란 도메인 조회가 예상한 DNS 경로를 벗어나는 현상입니다. 예를 들어 모든 공용 도메인을 프록시 측에서 조회하도록 설정했는데, 실제로는 로컬 라우터가 통신사 DNS로 요청을 전달할 수 있습니다. 웹 트래픽의 출구 IP가 바뀌었다고 해서 DNS 조회 경로까지 바뀐 것은 아닙니다. 앱이 먼저 시스템 리졸버에 조회를 요청한 뒤, 받은 IP 주소를 프록시에 전달할 수도 있습니다.

먼저 목표를 정한 다음 결과를 판단하세요. 이 글에서는 두 가지 목표를 구분합니다. 첫째, 시스템의 DNS 요청을 모두 Clash 코어로 보내 지정한 암호화 DNS를 사용하는 것. 둘째, 한 단계 더 나아가 상위 DNS 서버로 향하는 연결도 프록시 출구를 통과시키는 것입니다. 첫 번째 목표는 암호화 DNS에 직접 연결하는 것을 허용하지만, 두 번째 목표는 허용하지 않습니다. 두 경우를 같은 ‘테스트 통과’ 결과로 판단해서는 안 됩니다.

• 시스템 프록시: 시스템 프록시 설정을 따르는 앱에만 적용되며, 모든 UDP DNS 요청을 자동으로 처리하지는 않습니다.
• TUN: 가상 네트워크 인터페이스를 통해 라우팅 조건에 맞는 IP 트래픽을 처리합니다. 다만 경로 제외 설정, 권한, 다른 VPN의 영향을 받습니다.
• fake-ip: 앱에 매핑 주소를 반환해 코어가 도메인 정보를 유지하도록 합니다. DNS 암호화 프로토콜은 아닙니다.
• DoH / DoT: DNS 리졸버까지의 연결을 암호화합니다. 다만 연결은 직접 이루어질 수도 있고 프록시를 거칠 수도 있습니다.

기준 상태 기록: 출구와 DNS 리졸버를 함께 확인

테스트 조건 고정

1. 현재 클라이언트와 코어 버전, 운영체제, 사용 중인 네트워크 인터페이스, 다른 VPN의 동시 실행 여부를 기록하세요.
2. 다른 프록시 앱을 종료하고 브라우저의 ‘보안 DNS’를 잠시 끄세요. 두 가지 DNS 조회 방식이 섞이지 않도록 하고, 이후 각각 다시 켜서 별도로 테스트합니다.
3. 프록시를 끈 상태, 시스템 프록시만 켠 상태, TUN을 켠 상태에서 각각 웹 출구 IP와 DNS 테스트 결과를 기록하세요.
4. 매 테스트 전에 시스템과 브라우저 캐시를 비우고 새 테스트를 시작하세요. 같은 도메인을 반복 조회하지 말고, 테스트 페이지에서 새로 생성한 도메인을 사용해야 합니다.

브라우저에서 https://www.dnsleaktest.com/ 또는 https://browserleaks.com/dns를 직접 열어 확인할 수 있습니다. 이 서비스는 현재 접속 IP와 테스트 조회 정보를 수집하므로 외부 테스트 서비스에 해당합니다. 일반적으로 테스트 결과는 재귀 리졸버가 권한 DNS 서버에 조회할 때의 출구를 보여줍니다. 앱과 리졸버 사이에 어떤 전송 프로토콜을 사용했는지는 이것만으로 확인할 수 없습니다.

DNS IP가 여러 개 표시된다는 사실만으로는 누수를 입증할 수 없습니다. 공용 DNS 서비스는 여러 출구를 사용할 수 있고, 설정된 상위 서버 여러 곳에서 조회가 이뤄질 수도 있습니다. 중요한 것은 표시된 리졸버가 예상한 대상인지, 그리고 조회가 계획한 프록시 경로를 우회했는지 여부입니다.

시스템 점검: 인터페이스 DNS, 캐시, 포트 53

Windows: Wi-Fi뿐 아니라 모든 인터페이스 확인

PowerShell에서 다음 명령을 실행하세요. 첫 번째 명령은 인터페이스 DNS를 확인하고, 두 번째는 캐시를 비우며, 세 번째는 DNS 조회를 실행합니다. 이더넷, Wi-Fi, 가상 네트워크 인터페이스가 있다면 현재 활성 상태인 인터페이스를 모두 확인하세요.

Get-DnsClientServerAddress
Clear-DnsClientCache
Resolve-DnsName example.com -Type A

Resolve-DnsName이 성공했다는 것은 응답을 받았다는 뜻일 뿐, 프록시를 사용했다는 증거는 아닙니다. nslookup example.com에 표시되는 기본 서버도 투명 가로채기 이후의 최종 상위 DNS 서버와 같다고 볼 수 없습니다. 코어 로그와 라우팅 정보, 물리 인터페이스의 트래픽을 함께 확인해야 합니다.

macOS 및 Linux: 로컬 DNS 스텁 확인

# macOS: 각 범위의 DNS 설정 확인
scutil --dns
# macOS: 시스템 DNS 캐시 비우기
sudo dscacheutil -flushcache
sudo killall -HUP mDNSResponder

# systemd-resolved를 사용하는 Linux
resolvectl status
resolvectl flush-caches
resolvectl query example.com

Linux의 /etc/resolv.conf가 127.0.0.53을 가리킨다면 대개 systemd-resolved의 로컬 스텁을 사용한다는 뜻이지, 상위 DNS 서버도 로컬에 있다는 뜻은 아닙니다. resolvectl status에서 각 링크의 DNS Servers와 DNS Domain을 추가로 확인하세요. systemd-resolved가 없는 배포판에서는 해당 네트워크 관리 도구를 사용해야 합니다.

패킷 캡처 시 물리 인터페이스 선택

Wireshark에서 표시 필터 dns || tcp.port == 853를 사용하면 일반 DNS와 흔히 쓰이는 DoT 연결을 찾을 수 있습니다. macOS와 Linux에서는 아래 명령을 사용할 수도 있습니다. en0을 실제 인터넷 연결에 사용하는 인터페이스 이름으로 바꾸세요.

sudo tcpdump -ni en0 '(udp port 53 or tcp port 53 or tcp port 853)'

물리 인터페이스에서 라우터나 통신사로 향하는 공용 도메인 평문 조회가 보이면, 어떤 프로세스에서 발생했는지 추적해야 합니다. DoH는 보통 포트 443을 사용하므로 위 필터만으로는 찾을 수 없습니다. TUN 가상 인터페이스에서 보이는 조회는 가로채기 전 트래픽일 수 있으므로, 이를 물리 네트워크로 이미 유출된 것으로 단정하지 마세요.

mihomo 설정: TUN, fake-ip, DNS 가로채기

아래는 기존 설정에 병합할 조각이며, 구독 설정 전체가 아닙니다. 기존 proxies, proxy-groups, rules는 유지하세요. 이미 tun이나 dns가 있다면 해당 섹션을 수정해 YAML 키가 중복되지 않도록 합니다. 구독 업데이트 때 수정 사항이 덮어써지지 않도록 클라이언트의 오버라이드 또는 병합 기능을 사용해 설정을 저장하세요.

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

dns:
  enable: true
  listen: 127.0.0.1:1053
  ipv6: false
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  nameserver:
    - https://1.1.1.1/dns-query
  proxy-server-nameserver:
    - https://1.1.1.1/dns-query

주요 설정 항목의 역할

• auto-route: true: TUN 자동 라우팅을 설정합니다. 데스크톱 클라이언트에서는 관리자 권한이나 서비스 모드가 필요할 수 있습니다.
• strict-route: true: 라우팅 동작을 더 엄격하게 제한합니다. Windows에서는 여러 네트워크 인터페이스에서 발생하는 DNS 우회를 줄이는 데 도움이 될 수 있지만, 가상 머신, 로컬 네트워크, 다른 VPN에 영향을 줄 수 있습니다. 운영체제에 따라 동작도 다릅니다.
• dns-hijack: TUN으로 들어오는 TCP/UDP 포트 53 대상 DNS 트래픽을 코어의 리졸버로 전달합니다. 임의의 HTTPS 요청을 가로채거나 앱 내 DoH를 모두 자동으로 식별하지는 않습니다.
• listen: 127.0.0.1:1053: 로컬 루프백 주소의 1053 포트에서만 수신합니다. 일반적으로 시스템 DNS 설정은 표준이 아닌 포트를 지정할 수 없으므로 시스템 DNS 주소 입력란에 ‘127.0.0.1:1053’을 그대로 입력할 수 없습니다.
• ipv6: false: 내장 DNS에서 AAAA 조회를 처리할지 제어합니다. 시스템 전체의 IPv6를 끄거나 IPv6 누수를 막는 설정은 아닙니다.
• proxy-server-nameserver: 프록시 노드 도메인을 조회할 때 사용합니다. 노드에 연결하려고 해당 노드를 통해 노드 주소를 먼저 조회하는 순환 의존성을 방지합니다.

fake-ip에서 흔히 반환하는 주소는 198.18.0.0/16 대역에 속합니다. 이 주소가 보인다면 매핑 기능이 적용된 것이지, 원격 웹사이트의 실제 주소가 예약된 대역으로 바뀐 것은 아닙니다. 앱이 fake-ip를 받은 뒤 코어를 우회해 직접 연결하면 연결이 실패할 수 있습니다. 이때는 트래픽 가로채기를 점검해야 하며, 곧바로 fake-ip-filter를 넓히지 마세요. 도메인을 필터 목록에 추가해도 반환 주소 방식만 바뀔 뿐, 상위 DNS 서버의 출구는 자동으로 변경되지 않습니다.

상위 DNS 연결도 프록시로 보내기: 라우팅 규칙과 초기 조회

공용 도메인 조회의 상위 DNS 연결까지 노드를 통과시키려면 DNS 아웃바운드 정책을 추가로 설정해야 합니다. mihomo에서는 respect-rules: true를 사용해 DNS 상위 서버 연결이 라우팅 규칙을 따르도록 할 수 있습니다. 이 옵션을 사용할 때는 노드 도메인을 별도의 경로로 먼저 조회할 수 있도록 proxy-server-nameserver도 설정해야 합니다.

아래 예시는 기존 설정에 PROXY라는 이름의 정책 그룹이 있고, 해당 그룹에서 DIRECT가 아닌 프록시 노드를 선택한 상태를 가정합니다. 앞의 설정 조각에서 dns 섹션에 첫 항목을 추가하고, 기존 rules 목록의 앞쪽에 규칙을 넣으세요. 기존 규칙 목록을 덮어쓰지 마세요.

# 기존 dns 섹션에 병합
dns:
  respect-rules: true

# 기존 rules 목록에서 먼저 매칭될 수 있는 규칙보다 앞에 추가
rules:
  - IP-CIDR,1.1.1.1/32,PROXY,no-resolve

이 규칙은 1.1.1.1로 향하는 연결에 PROXY를 선택하며, 같은 IP를 대상으로 하는 다른 트래픽에도 영향을 줍니다. 예시에 나온 IPv4 상위 서버에만 적용되므로 다른 DNS 주소를 사용한다면 규칙을 다시 설계하세요. 저장한 뒤 코어의 연결 기록에서 DNS 상위 서버 연결에 예상한 정책이 적용됐는지 확인해야 합니다. 설정 파일에 respect-rules가 있다고 해서 실제 적용이 입증되는 것은 아닙니다.

노드 도메인의 초기 조회 경로도 별도로 점검해야 합니다. 업무용 도메인은 프록시를 통해 조회하더라도 시작 시 노드 도메인은 직접 연결하는 DNS로 조회될 수 있습니다. 시작 단계의 직접 조회도 막아야 한다면 서비스 제공자가 지원하는 안정적인 노드 IP나 통제된 초기 조회 방식을 사용하고, 필요한 TLS 서버 이름 설정은 유지하세요. 임시 조회로 얻은 IP를 장기간 고정하면 노드 주소가 바뀔 때 연결이 끊길 수 있습니다.

시스템 DNS 우회와 별도 조회 경로 차단

fallback을 시스템 DNS 우회 차단 옵션으로 오해하지 마세요

Clash의 fallback은 코어에서 사용하는 별도의 상위 DNS 서버 그룹이며, fallback-filter와 함께 조회 결과의 사용 방식을 결정합니다. 운영체제의 보조 DNS를 뜻하지 않습니다. 이 항목을 삭제해도 시스템이 DHCP로 받은 리졸버에 요청을 보내는 것을 막을 수는 없습니다. 반대로 fallback 주소를 무작정 추가하면 조회 정보가 전달되는 DNS 서비스의 범위가 넓어질 수 있습니다.

• 모든 상위 DNS 설정 확인: nameserver뿐 아니라 default-nameserver, fallback, nameserver-policy, direct-nameserver와 각 항목의 실제 용도도 점검하세요. 목록 하나만 수정해서는 안 됩니다.
• Windows의 여러 인터페이스 확인: ‘설정’ → ‘네트워크 및 인터넷’에서 현재 활성화된 인터페이스의 DNS 할당을 하나씩 확인하세요. 그룹 정책이 적용되는 관리형 기기라면 ‘스마트 멀티홈 이름 확인 사용 안 함’ 등의 정책은 관리자가 검토해야 합니다. 회사 네트워크 설정을 임의로 변경하지 마세요.
• 브라우저 설정 확인: Chrome의 ‘설정’ → ‘개인정보 보호 및 보안’ → ‘보안’ → ‘보안 DNS 사용’에서 별도의 DNS 서비스를 선택할 수 있습니다. 문제를 점검할 때는 이 옵션을 끄고, 다시 켠 뒤에는 해당 연결이 예상한 출구를 거치는지 확인하세요.
• Android 설정 확인: 시스템 설정에서 ‘비공개 DNS’를 검색하세요. 지정한 비공개 DNS 제공업체는 일반적으로 암호화 연결을 사용하므로 포트 53 가로채기가 자동으로 처리한다고 기대해서는 안 됩니다. 제조사마다 설정 메뉴 위치와 VPN 동작 방식이 다를 수 있습니다.
• IPv6 및 분할 라우팅 확인: 물리 인터페이스의 IPv6 DNS, TUN 제외 경로, 앱별 우회 설정, 다른 VPN이 별도 경로를 만들 수 있습니다. 원인을 찾기 위해 일시적으로 기능을 끌 수는 있지만, 장기적으로 사용할 설정은 필요한 IPv4 및 IPv6 경로를 모두 처리해야 합니다.

프록시를 사용할 수 없을 때 DNS 조회도 차단하는 엄격한 정책이 필요하다면, DNS 경로를 확인한 후 통제된 라우팅 또는 방화벽 규칙으로 직접 연결되는 출구를 제한하세요. 노드 연결과 필수 네트워크 서비스는 명시적으로 허용해야 합니다. TUN을 켜는 것만으로 네트워크 차단 보호가 설정되는 것은 아닙니다. 원격 시스템, 기업 내부망, 포털 인증이 필요한 네트워크에서는 특히 먼저 복구 방법을 준비하세요.

단계별 재검증 및 문제 해결

1. 설정 적용 확인: 설정을 다시 적용하고 알 수 없는 항목, 중복 키, YAML 들여쓰기 오류가 없는지 확인하세요. 시작 로그에서 TUN이 정상적으로 설정됐는지도 확인합니다.
2. 이전 응답 삭제: 시스템 캐시를 비우고 브라우저를 완전히 종료한 뒤 다시 실행하세요. 매번 새 테스트 도메인을 사용해 캐시가 실제 경로를 가리지 않도록 합니다.
3. 시스템 DNS 조회 확인: 먼저 시스템 명령으로 조회한 다음 브라우저 DNS 누수 테스트를 실행하세요. 한 테스트 페이지에서만 정상으로 표시되는 것이 아니라 두 결과 모두 현재 설정으로 설명할 수 있어야 합니다.
4. 상위 DNS 출구 확인: 코어 연결 정보와 로그에서 DNS 대상, 매칭된 규칙, 최종 선택된 정책 그룹을 확인하세요. 프록시를 통과해야 하는 경우 DIRECT가 선택되지 않았는지 확인합니다.
5. 물리 네트워크 확인: TCP/UDP 포트 53과 필요한 암호화 DNS 연결을 캡처하세요. 알 수 없는 포트 443 연결은 프로세스 정보와 함께 판단해야 하며, ‘평문 패킷이 보이지 않는다’는 사실만으로 충분한 증거라고 볼 수 없습니다.
6. 상태 변화 후에도 확인: Wi-Fi 전환, 절전 모드 해제, 노드 변경, 구독 업데이트 후에도 테스트를 반복하세요. 오버라이드가 유지되고 라우팅 경로가 다시 설정됐는지 확인합니다.
7. 장애 시 동작 확인: 복구 가능한 로컬 환경에서 선택한 프록시를 잠시 사용할 수 없게 만든 뒤, 시스템이 예상대로 실패하는지 아니면 다른 DNS 경로로 조용히 우회하는지 확인하세요.

웹페이지가 전혀 열리지 않을 때

먼저 DNS 시간 초과인지 프록시 연결 실패인지 구분하세요. 로그에 상위 DoH 연결 실패가 표시되면 1.1.1.1:443로 향하는 아웃바운드 정책과 노드 상태를 확인합니다. 노드 도메인 자체를 조회할 수 없다면 초기 조회 경로를 점검하세요. fake-ip를 받았지만 연결 시간이 초과된다면 TUN 경로, 제외된 프로세스, 다른 VPN과의 충돌을 확인합니다. 한 번에 한 항목만 변경하고 변경 전 설정을 보관해 여러 변경 사항이 서로의 원인을 가리지 않도록 하세요.