Clash DNS 유출 탐지 방법: fake-ip 모드와 유출 방지 설정 실전

▶DNS 유출이란 무엇이고 왜 발생하는가

프록시 소프트웨어의 핵심 작업은 두 부분으로 나뉩니다. 먼저 도메인을 IP로 해석하고, 그 다음 해당 IP로의 연결 트래픽을 터널로 보냅니다. 규칙 기반 분리(예: 도메인 기준으로 중국 본토는 직결, 해외는 프록시)는 Clash가 직접 해석을 완료하고 그 결과에 따라 라우팅한다는 전제에 의존합니다. DNS 조회가 Clash를 거치지 않고 시스템 네트워크 인터페이스에서 직접 로컬 통신사 DNS나 프록시를 거치지 않은 해석기로 전송되면, 감시자는 완전한 도메인 접속 기록을 확보할 수 있습니다——이것이 바로 DNS 유출입니다. 웹페이지가 열리는 데는 영향이 없어 쉽게 간과되지만, 프라이버시와 분리 정확도 모두에 심각한 결함이 됩니다.

흔한 유출 원인은 특별하지 않으며 대체로 다음 몇 가지에 집중됩니다:

• 브라우저에 내장된 보안 DNS(DoH)가 활성화되어 시스템 해석기를 건너뛰고 지정된 암호화 DNS 제공업체로 직접 연결되며, Clash의 관리 범위에서 완전히 벗어납니다.
• 가상머신, 컨테이너 또는 일부 샌드박스 환경은 독립적인 네트워크 스택과 resolv.conf를 사용해 호스트의 프록시 설정을 따르지 않습니다.
• TUN 모드가 켜져 있지만 DNS 하이재킹 설정이 제대로 되어 있지 않아 53번 포트의 UDP 요청이 가상 네트워크 카드를 우회해 직접 외부로 나갑니다.
• 시스템에 IPv6 네트워크 출구가 남아 있는데 Clash의 dns 항목이 IPv4 조회만 처리하고 있어 IPv6 해석이 원래 경로로 나갑니다.
• 규칙 목록에서 특정 도메인에 no-resolve를 지정해 해석을 건너뛰고 IP 대역만 매칭하려 했으나, 설정 순서가 잘못되어 해당 도메인의 해석 요청이 시스템에서 먼저 발생합니다.

▶DNS 유출 탐지의 재현 가능한 절차

탐지에는 별도 소프트웨어가 필요 없으며 4단계로 나뉘고, 어떤 플랫폼에서든 따라할 수 있습니다:

1. 먼저 "깨끗한" 결과를 기록합니다. 프록시와 VPN을 완전히 끄고 명령줄 도구로 도메인을 해석해 반환된 해석 서버 주소를 기록합니다. 이것이 통신사의 원래 DNS 출구입니다.
2. Clash를 켜고 동일한 조회를 반복합니다. 명령줄에서 nslookup이나 dig로 같은 도메인을 해석했을 때 두 번째 반환된 해석 서버 주소가 첫 번째 단계와 완전히 같다면, 이번 조회가 전혀 Clash를 거치지 않고 시스템 원래 경로로 나갔다는 뜻입니다.
3. 패킷 캡처 도구로 포트 방향을 확인합니다. tcpdump나 Wireshark로 53번 포트(그리고 DoT가 사용하는 853번 포트)의 트래픽을 캡처해 어느 네트워크 카드에서 나가는지 확인합니다. TUN 카드나 로컬 루프백(Clash 청취 주소)을 거치면 안전하고, 물리 네트워크 카드로 외부 DNS IP에 직접 연결되면 유출입니다.
4. Clash 자체의 DNS 로그를 확인합니다. 로그 레벨을 debug로 올리거나 제어판의 연결 기록을 직접 보고 대상 도메인의 해석 요청이 실제로 Clash 로그에 나타나는지 확인합니다. 나타나지 않으면 이 조회는 관리되지 않은 것입니다.

브라우저 차원에서는 더 직관적인 검증 방법도 있습니다: 다중 노드 탐지를 지원하는 온라인 DNS 유출 테스트 페이지를 열어 프록시 켜기 전후로 반환된 해석 노드의 소속 지역을 비교합니다. 프록시를 켠 후에도 소속 지역이 여전히 자신의 로컬 통신사 소재 도시로 표시된다면 유출이 있다고 거의 확신할 수 있습니다.

▶fake-ip와 redir-host: 두 향상 모드의 본질적 차이

Clash의 dns 항목에서 enhanced-mode는 도메인 해석 결과가 규칙 라우팅과 어떻게 맞물리는지를 결정하며, 유출 방지 설정에서 가장 핵심적인 필드입니다.

fake-ip 모드

Clash가 애플리케이션의 도메인 해석 요청을 받으면 실제 공용망 조회를 하지 않고, 예약된 가상 주소 풀(보통 198.18.0.0/16처럼 실제 네트워크에 등장하지 않는 대역)에서 "가짜 IP"를 할당해 애플리케이션에 반환합니다. 애플리케이션이 이 가짜 IP로 연결을 시도하는 순간, Clash는 터널을 구축하는 시점에서야 가짜 IP로부터 대응하는 도메인을 역조회하고, 규칙에 따라 직결인지 프록시 노드로 갈지 결정하며, 이때 비로소 실제 해석이 이루어집니다. 이 전체 과정에서 시스템 차원에서 관찰되는 해석 결과는 항상 가상 주소이며, 실제 대상 도메인에 대응하는 공용망 IP를 노출하지 않고, 시스템 DNS 출구에 의존할 필요도 없어 TUN 모드의 투명 프록시 시나리오와 자연스럽게 맞아떨어집니다.

redir-host 모드

Clash가 상위 DNS 서버에 직접 실제 해석을 요청해 실제 IP를 받아 애플리케이션에 반환하고, 동시에 이 조회를 기록해 이후 이 IP에 대응하는 연결을 규칙표에 따라 전달합니다. 이 모드의 문제점은 두 가지입니다: 첫째, 실제 해석 결과가 애플리케이션에 캐시되거나 시스템 차원의 다른 프로세스에 가로채질 경우 이론상 여전히 정보 노출 가능성이 있습니다. 둘째, CDN을 대량 사용하고 하나의 도메인이 여러 동적 IP에 대응하는 사이트를 만나면 규칙이 IP 대역으로 매칭할 때 오판하기 쉬워 분리가 부정확해집니다. redir-host는 구버전 클라이언트나 가상 네트워크 카드를 지원하지 않는 배포 환경에 더 적합하며, 새 설정에서는 일반적으로 우선 선택으로 권장하지 않습니다.

결론은 명확합니다: TUN 모드를 사용할 수 있는 환경이라면 일관되게 fake-ip를 선택하는 것이 유출 방지와 분리 정확도 모두에 더 유리합니다. 명확히 구버전 규칙 세트와의 호환이 필요하거나 해석 결과를 디버깅해야 할 때만 임시로 redir-host로 전환하세요.

▶dns 항목 설정 조정으로 유출 경로 차단하기

모드 선택을 확인한 후, 아래 dns 항목은 직접 대조 확인할 수 있는 체크리스트로, 각 항목이 구체적인 유출 위험 지점에 대응합니다:

dns:
  enable: true
  listen: 0.0.0.0:1053
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  fake-ip-filter:
    - "*.lan"
    - "localhost.ptlogin2.qq.com"
  default-nameserver:
    - 223.5.5.5
    - 119.29.29.29
  nameserver:
    - https://doh.pub/dns-query
    - tls://dns.rubyfish.cn:853
  nameserver-policy:
    "geosite:cn":
      - https://doh.pub/dns-query
  fallback:
    - https://1.1.1.1/dns-query
    - https://dns.google/dns-query
  fallback-filter:
    geoip: true
    geoip-code: CN
  ipv6: false

• enable / listen——DNS 서비스가 실제로 켜져 있고 지정된 포트에서 청취 중인지 먼저 확인합니다. 클라이언트 그래픽 인터페이스에서 이 스위치를 수동으로 켜지 않았다면 설정 파일에 적어도 적용되지 않습니다.
• enhanced-mode: fake-ip——앞 절의 결론에 따라 고정적으로 선택하고, fake-ip-range는 실제 공용망 주소와 충돌하지 않는 프라이빗 대역을 사용합니다.
• fake-ip-filter——LAN 기기, 내부망 서비스 같은 도메인은 가짜 IP 할당에서 제외해야 합니다. 그렇지 않으면 LAN 내 직결이 실패합니다. 여기서의 제외는 원래 내부망 접속이므로 유출을 초래하지 않습니다.
• default-nameserver——아래 nameserver와 fallback에 있는 DoH/DoT 도메인 자체를 해석하는 전용 항목으로, 반드시 순수 IP를 입력해야 합니다. 그렇지 않으면 "암호화 DNS 도메인을 해석하려는데 또 DNS가 필요한" 교착 상태가 발생합니다.
• nameserver——상위 해석에 암호화 프로토콜(DoH 또는 DoT)을 사용해 이 구간 자체가 네트워크 중간에서 평문으로 기록되는 것을 피하며, 동시에 이 조회들은 기본적으로 Clash를 거치고 시스템 네트워크로 직접 나가지 않습니다.
• nameserver-policy——특정 도메인 그룹에 전용 상위 서버를 지정합니다. 흔한 방식은 중국 본토 도메인은 로컬 해석 가속을, 해외 도메인은 암호화 상위 서버를 사용해 속도와 프라이버시를 모두 고려하는 것입니다.
• fallback / fallback-filter——기본 상위 서버가 반환한 결과가 오염되었거나 신뢰할 수 없다고 판단될 때 자동으로 대체 해석기로 전환합니다. geoip-code: CN은 반환 결과가 예상 지역에 속하는지 판단하는 데 사용됩니다.
• ipv6——시스템이나 라우터에 여전히 IPv6 출구가 남아 있는데 이에 대한 처리가 없으면, IPv6 도메인 해석이 fake-ip를 우회해 원래 경로로 직접 나갑니다. 가장 간과되기 쉬운 유출 지점입니다. IPv6 규칙을 별도로 설정하지 않았다면 직접 꺼두는 것을 권장합니다.

▶시스템 계층과 브라우저 계층의 추가 점검

설정 파일을 조정한 후에도 dns 항목에 속하지 않지만 마찬가지로 유출을 일으킬 수 있는 시스템 수준 설정 몇 가지를 하나씩 확인할 필요가 있습니다:

1. 브라우저 보안 DNS 스위치는 일괄적으로 "시스템 따르기"로 설정하고, 고정된 DoH 제공업체를 별도로 지정하지 마세요. 그렇지 않으면 브라우저 트래픽이 Clash의 DNS 관리 로직을 우회합니다.
2. 운영체제의 네트워크 어댑터 DNS 설정은 가능한 비워두거나 자동으로 유지하고, 통신사 DNS 주소를 "대체용"으로 수동 입력하지 마세요. 일부 시스템 정책에서는 대체 주소가 우선 채택될 수 있습니다.
3. 라우터나 가정용 게이트웨이가 DNS 하이재킹 기능을 켜두었다면, 기기가 암호화 DNS 요청을 보내기 전에 가로채져 대체될 수 있습니다. 이 경우 클라이언트 측에서 암호화 프로토콜(DoH/DoT)이 실제로 성립되었는지, 평문 조회로 강제 전환되지 않았는지 확인해야 합니다.
4. 멀티 사용자 또는 멀티 네트워크 프로필을 전환할 때는 2절의 탐지 절차를 다시 한 번 거치세요. 하나의 설정이 모든 네트워크 환경에서 동일하게 작동한다고 가정하지 마십시오——공용 Wi-Fi, 기업 네트워크, 모바일 데이터 네트워크의 DNS 하이재킹 정책은 완전히 다를 수 있습니다.

위 점검 항목을 모두 거치면 DNS 요청의 전체 경로가 프록시 터널에 완전히 수렴되었는지 기본적으로 확인할 수 있습니다. 유출 방지 설정은 일회성 작업이 아닙니다. 기기를 바꾸거나 네트워크를 바꾸거나 클라이언트 버전을 업그레이드한 후에도 2절의 네 가지 단계로 재검사해볼 가치가 있습니다. 비용은 낮은데, 규칙 분리가 "겉으로는 적용되지만 실제로는 새는" 상황을 미리 발견할 수 있습니다.