Clash DNS 누수 테스트와 fake-ip 차단 설정 가이드

먼저 DNS 누수 판단 기준부터 확인하기

DNS 누수란 DNS 조회 요청이 예상하지 않은 경로로 나가는 현상입니다.예를 들어 특정 사이트 접속과 도메인 조회를 모두 프록시로 보내려는데, 테스트 결과 DNS 조회가 여전히 현지 통신사를 통해 처리될 수 있습니다. 웹페이지가 열린다고 DNS 경로가 올바르다는 뜻은 아닙니다. fake-ip를 사용한다고 해서 DNS 누수가 없다고 단정할 수도 없습니다.

문제를 점검할 때는 세 단계를 나눠 살펴보세요. 앱이 어디에 조회를 요청하는지, Clash 코어가 요청을 어떻게 처리하는지, 코어가 어떤 연결을 통해 상위 DNS 서버에 접속하는지 확인합니다. fake-ip는 주로 두 번째 단계에 영향을 줍니다. 앱에 먼저 매핑 주소를 반환한 뒤, 코어가 연결 정보를 바탕으로 도메인을 확인해 라우팅합니다. 암호화 프로토콜이 아니며 모든 앱의 DNS를 자동으로 가로채지도 않습니다.

• 시스템 프록시: 시스템 프록시 설정을 따르는 앱에 주로 영향을 주며, 시스템의 모든 DNS 요청을 가로채는 기능은 아닙니다.
• TUN 모드: 더 많은 네트워크 트래픽을 처리할 수 있지만 라우팅, DNS 하이재킹, IPv6 및 다른 VPN의 영향도 확인해야 합니다.
• DoH: DNS 데이터를 HTTPS로 전송해 경로상의 평문 노출을 줄입니다. DoH에 직접 연결하는 것과 프록시를 통해 DoH에 접속하는 것은 서로 다른 경로입니다.

이 설정은 Clash Meta, 즉 mihomo 코어를 대상으로 합니다. 구버전 Clash나 클라이언트별 설정 덮어쓰기 기능에서는 같은 필드를 지원하지 않을 수 있습니다. 먼저 클라이언트의 ‘정보’ 또는 코어 정보 화면에서 코어 이름을 확인한 다음 설정을 수정하세요.

테스트 순서: 기준값을 기록한 뒤 프록시 사용 전후 비교

1차 테스트: 현재 네트워크의 DNS 확인

1. 신뢰할 수 있는 개인 네트워크에서 테스트하고, 여러 VPN의 규칙이 겹치지 않도록 다른 VPN은 먼저 종료하세요.
2. Clash의 시스템 프록시와 TUN을 끄세요. DNSLeakTest 같은 DNS 누수 테스트 사이트를 열어 Standard test를 실행한 뒤, DNS 서버의 IP와 운영 주체, 테스트 시간을 기록합니다.
3. 평소 프록시로 인터넷에 연결하는 경우 프록시를 끄면 테스트 페이지가 열리지 않을 수 있습니다. 이때는 이 단계를 건너뛰어도 됩니다. 기준값을 얻으려고 라우터 설정을 바꿀 필요는 없습니다.

2차 테스트: 프록시를 켜고 다시 확인

현재 설정을 실행하고 프록시 정책 그룹에서 사용할 수 있는 노드가 선택되어 있는지 확인하세요. 같은 테스트를 다시 실행하고 Extended test도 진행해 1차 테스트에서 확인한 현지 통신사 DNS가 나타나는지 살펴봅니다. 별도의 웹페이지를 열어 외부 IP도 확인하고 ‘웹 접속 출구’와 ‘DNS 서버’를 따로 기록하세요. 두 결과를 하나의 지표로 취급하지 마세요.

테스트 페이지에서 확인되는 것은 해당 페이지의 테스트 도메인을 재귀 조회한 DNS 서버입니다. 이것만으로 모든 앱이 같은 경로를 사용한다고 증명할 수는 없습니다. 브라우저를 바꾸거나 네트워크를 전환하거나 다른 VPN을 켜면 결과도 달라질 수 있습니다. 한 번의 테스트에서 초록색 표시가 나왔다고 점검을 끝내지 마세요.

fake-ip 설정: 정책 그룹을 확인한 뒤 DNS 설정 병합

아래는 기존 mihomo 설정에 병합할 수 있는 DNS 설정이며, 완성된 구독 파일이 아닙니다. 기존 설정에 PROXY라는 프록시 정책 그룹이 있고, 이 그룹에서 DIRECT가 아닌 사용 가능한 프록시 노드를 선택한 상태여야 합니다. 실제 그룹 이름이 ‘노드 선택’이라면 #PROXY 두 곳을 #노드 선택으로 바꾸세요. 이 접미사는 상위 DNS 연결에 사용할 아웃바운드 정책을 지정합니다.

먼저 기존 설정을 백업한 다음 최상위 dns: 항목을 교체하세요. 같은 이름의 항목을 두 개 추가하면 안 됩니다. 구독 업데이트로 수정 사항이 덮어써지지 않도록 클라이언트의 설정 덮어쓰기 또는 병합 기능으로 저장하고, 저장 후 실행 중인 설정에서 최종 결과를 확인하세요.

dns:
  enable: true
  listen: 127.0.0.1:1053
  ipv6: false
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  fake-ip-filter:
    - "*.lan"
    - "*.local"
    - "localhost"
  default-nameserver:
    - 223.5.5.5
    - 119.29.29.29
  proxy-server-nameserver:
    - https://dns.alidns.com/dns-query
  nameserver:
    - "https://1.1.1.1/dns-query#PROXY"
  fallback:
    - "https://9.9.9.9/dns-query#PROXY"
  fallback-filter:
    geoip: false
    ipcidr:
      - 0.0.0.0/8
      - 127.0.0.0/8

이 예제에서는 일반 서비스 도메인의 상위 DNS 조회를 PROXY로 보내지만, 부트스트랩 조회와 노드 도메인 조회는 직접 연결로 유지합니다. 따라서 모든 DNS가 프록시를 통과한다고 보장하는 설정은 아닙니다. 로컬 네트워크에 평문 DNS가 전혀 노출되지 않게 하려면 부트스트랩 조회 경로를 별도로 설계하고, 콜드 스타트 때도 노드 연결을 설정할 수 있는지 검증해야 합니다.

enable, listen 및 enhanced-mode

enable: true는 코어의 DNS 기능을 켭니다. listen: 127.0.0.1:1053은 로컬 루프백 주소의 1053번 포트에서만 요청을 수신해 LAN에 실수로 DNS 서비스를 공개하지 않도록 합니다. 이 주소를 지정하는 것만으로 시스템 DNS가 자동으로 해당 주소를 사용하지는 않습니다. 대부분의 운영체제에서는 DNS 서버 주소만 설정할 수 있고 1053번 포트까지 함께 지정할 수 없습니다.

enhanced-mode: fake-ip는 매핑 모드를 활성화합니다. 예제의 주소 풀 198.18.0.0/16은 벤치마크용으로 예약된 주소 공간이며 실제 웹사이트의 공인 IP가 아닙니다. 일반 도메인 조회 결과로 198.18.0.2와 같은 주소가 반환되는 것은 정상일 수 있습니다. 이 주소는 예시일 뿐이며 실제 할당값은 달라집니다.

nameserver와 노드 도메인 조회

nameserver는 일반 DNS 조회에 사용할 상위 서버입니다. 예제에서는 상위 서버 주소를 다시 도메인 조회할 필요가 없도록 IP 형식의 DoH 주소를 사용하고, #PROXY로 프록시 정책을 지정합니다. 특수 문자가 포함된 값이 YAML에서 잘못 해석되지 않도록 따옴표를 유지하세요.

proxy-server-nameserver는 프록시 노드 서버의 도메인을 조회할 때 사용합니다. 노드 연결이 아직 설정되지 않았는데 그 노드에 의존해 도메인을 조회하도록 하면 순환 의존이 발생합니다. 예제에서는 이 단계에 직접 연결 DoH를 사용합니다. default-nameserver는 조회가 필요한 DNS 서버 도메인의 부트스트랩 조회를 담당합니다. 두 설정이 노출되는 범위는 일반 웹사이트 도메인 조회와 다르므로 각각 따로 평가해야 합니다.

fallback은 단순한 시간 초과 대체 서버가 아닙니다

fallback과 fallback-filter는 어떤 결과를 선택할지 결정합니다. ‘기본 DNS가 시간 초과된 뒤에야 조회를 시작한다’는 뜻으로 이해하면 안 됩니다. 코어의 처리 방식에 따라 두 상위 서버 그룹이 동시에 조회할 수 있습니다. 예제에서는 예상하지 못한 직접 연결 경로가 생기지 않도록 두 그룹 모두 PROXY를 지정했습니다.

여기서는 GeoIP 필터를 끄고 지정된 비정상 주소 대역에 대한 결과 필터만 유지해 기본 지리 정보 판정으로 설정이 달라지지 않도록 했습니다. 이 짧은 목록은 완전한 오염 탐지 방법이 아닙니다. fake-ip가 매핑 주소를 반환한다고 해서 조회할 때마다 실제 주소 조회가 모두 즉시 발생하는 것도 아닙니다. 신뢰할 수 있는 상위 서버 하나만 필요하다면 fallback과 fallback-filter를 삭제해 경로를 단순화하세요.

TUN과 DNS 하이재킹: 시스템 조회를 코어로 전달

DNS 설정을 준비한 뒤에는 요청이 코어에 실제로 전달되는지도 확인해야 합니다. 시스템의 일반 DNS 요청을 가로채려는 데스크톱 환경에서는 지원되는 mihomo 클라이언트에서 TUN을 활성화할 수 있습니다. 아래 설정은 기존 최상위 tun: 항목에 병합하세요. 클라이언트 UI에서 TUN을 관리한다면 UI가 생성한 최종 설정을 기준으로 삼으세요.

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

• auto-route는 코어가 트래픽을 가로채는 데 필요한 라우트를 설정합니다. 보통 관리자 권한이나 클라이언트의 시스템 서비스가 필요합니다.
• dns-hijack는 TUN으로 들어온 일반 UDP·TCP 53번 포트 요청을 내부 DNS로 전달합니다. 임의의 DNS 프로토콜을 모두 가로채는 범용 기능은 아닙니다.
• strict-route는 일부 우회 동작을 제한할 수 있지만 운영체제마다 효과가 다릅니다. LAN 접속에 영향을 주거나 다른 VPN과 호환되지 않을 수도 있습니다.
• 브라우저의 DoH는 HTTPS를 사용하고 DoT는 보통 853번 포트를 사용하므로 일반적인 53번 포트 DNS 조회와는 다릅니다. 각 연결의 라우팅도 따로 확인해야 합니다.

네트워크 어댑터가 여러 개이거나 가상 머신, 회사 VPN, 우회 라우터를 사용하는 환경에서는 자동 라우팅 설정을 그대로 적용하지 마세요. 기본 출구 어댑터를 먼저 확인하고 로그에 라우팅 루프가 나타나는지 살펴보세요. 설정 후 네트워크 전체가 끊기면 TUN을 꺼서 연결을 복구한 다음 항목별로 점검하세요. DNS, 라우팅, 노드를 한꺼번에 변경하지 마세요.

설정 검증: 포트, 매핑 주소, 실제 출구를 따로 확인

먼저 코어의 1053번 포트에 직접 조회

dig가 설치된 macOS 또는 Linux 터미널에서 아래 명령을 실행하세요. 시스템 DNS가 현재 어디를 가리키는지와 관계없이 로컬 코어를 직접 지정합니다. Windows에서는 대화형 nslookup에서 포트를 설정해 테스트할 수도 있습니다.

dig @127.0.0.1 -p 1053 example.com A

nslookup
server 127.0.0.1
set port=1053
set type=A
example.com
exit

필터 규칙에 해당하지 않는 일반 도메인은 보통 주소 풀의 A 레코드를 반환합니다. 시간 초과가 발생하면 코어가 정상적으로 로드되었는지, 1053번 포트가 사용 중인지, 로그에 알 수 없는 필드가 표시되는지 먼저 확인하세요. 직접 조회는 정상이지만 시스템 앱이 여전히 코어를 우회한다면 문제는 상위 DNS가 아니라 트래픽을 가로채는 경로에 있습니다.

캐시를 비우고 연결 상태 확인

1. Windows에서는 ipconfig /flushdns를 실행해 시스템 DNS 캐시를 비울 수 있습니다. 브라우저에도 자체 캐시와 연결이 남아 있을 수 있으므로 다시 테스트하기 전에 브라우저를 완전히 종료한 뒤 다시 여세요.
2. Chrome에서 ‘설정’ → ‘개인 정보 보호 및 보안’ → ‘보안’으로 이동해 ‘보안 DNS 사용’을 확인하세요. 변수를 분리하기 위해 잠시 끈 상태로 테스트한 뒤 원하는 정책에 따라 다시 설정하면 됩니다.
3. 클라이언트의 연결 패널에서 1.1.1.1:443, 9.9.9.9:443로 향하는 상위 서버 연결이 예상한 프록시를 사용하는지 확인하세요. 로그에 표시되는 방식은 클라이언트마다 다를 수 있으며, 조회할 때마다 새 연결 로그가 생길 필요는 없습니다.
4. DNS 누수 테스트를 다시 실행하세요. 지도상의 위치만 보지 말고 DNS 운영 주체를 먼저 비교한 뒤 출구와 로그를 함께 확인하세요.

시스템과 브라우저 설정이 조직 정책으로 관리될 수 있습니다. 업무용 기기라면 먼저 관리 정책을 확인하고, 테스트를 위해 보안 정책을 강제로 끄지 마세요. 일반 DNS 테스트는 WebRTC 테스트와 다릅니다. 웹페이지에서 로컬 또는 공인 IP가 노출되는 문제는 별도로 확인해야 합니다.

자주 묻는 질문: IPv6, LAN, 구독 설정 덮어쓰기

ipv6: false로 설정했는데 IPv6 트래픽이 계속 발생하는 이유는 무엇인가요?

DNS 설정의 ipv6: false는 주로 코어가 AAAA 조회를 처리하는 방식에 영향을 줍니다. 운영체제의 IPv6 전체를 끄는 스위치가 아닙니다. 앱 캐시, 코드에 직접 입력된 IPv6 주소, 브라우저 자체 DNS 조회, 가로채지지 않은 네트워크 인터페이스로 인해 IPv6 연결이 발생할 수 있습니다. IPv6를 유지하려면 트래픽 가로채기를 완전히 설정하고 테스트하세요. 당분간 사용하지 않더라도 DNS 필드 하나만 바꾸지 말고 시스템과 클라이언트 설정을 함께 확인해야 합니다.

프린터, NAS 또는 LAN 도메인에 접속할 수 없으면 어떻게 하나요?

먼저 도메인 조회 문제인지 라우팅 문제인지 구분하세요. fake-ip-filter는 일치하는 도메인에 매핑 주소를 반환하지 않게 할 뿐, 해당 도메인을 라우터 DNS로 자동 전달하지는 않습니다. LAN의 실제 DNS 서버가 192.168.1.1이라면 사용 중인 네트워크 대역을 확인한 뒤 내부 도메인에 nameserver-policy를 설정할 수 있습니다. 아래는 병합할 필드만 보여주는 예시입니다. 최상위 DNS 항목을 새로 만들지 마세요.

  nameserver-policy:
    "+.lan":
      - 192.168.1.1

이 설정은 의도적으로 로컬 DNS 조회를 유지하는 것으로, 공용 웹사이트의 의도치 않은 DNS 누수와 혼동하면 안 됩니다. .local은 mDNS에 자주 사용되므로 라우터의 일반 DNS가 반드시 조회해 준다고 볼 수 없습니다. NAS의 LAN IP로 직접 접속해도 실패한다면 먼저 TUN 라우팅과 방화벽을 확인하세요.

구독을 업데이트한 뒤 결과가 달라지는 이유는 무엇인가요?

클라이언트가 설정을 다시 생성하거나 구독에 nameserver-policy, 추가 DNS 상위 서버 또는 다른 분기 라우팅 필드가 포함될 수 있습니다. 편집기에서 파일을 수정했다고 해서 실행 중인 코어가 그 설정을 사용한다고 볼 수는 없습니다. 업데이트할 때마다 실제 적용 설정의 DNS, TUN, 정책 그룹 이름을 확인하고 간단히 다시 테스트하세요. DNS가 규칙을 따르도록 respect-rules를 사용한다면 관련 규칙과 노드 부트스트랩 조회 경로를 별도로 설계하세요. 여기서 설명한 명시적 아웃바운드 지정 방식과 섞어 놓고 감으로 판단하면 안 됩니다.

점검 완료: 반복 가능한 테스트 기록 보관

마지막으로 네 가지를 기록하세요. 사용 중인 코어와 설정, 브라우저 보안 DNS 상태, 프록시 출구, 테스트에서 확인된 DNS 운영 주체입니다. 정상적인 결과는 사전에 정한 기준과 일치해야 합니다. 일반 서비스 조회는 지정된 프록시 상위 서버로 전달되고, 필요한 로컬 조회는 명확한 목적이 있으며, 노드 부트스트랩 경로를 설명할 수 있어야 합니다. fake-ip는 주소를 매핑하고 TUN은 트래픽을 가로채며, 상위 서버와 아웃바운드 정책은 DNS 경로를 결정합니다. 세 요소가 함께 작동해야 검증 가능한 설정이 됩니다.