DNS 누출 확인 방법: V2Ray DNS 누출 방지 설정 실전 가이드

이 글 한눈에 보기

노드에는 연결되지만 DNS 검사에서 여전히 로컬 네트워크 리졸버가 나타나는 사용자를 위한 글입니다. 정상적인 분기와 실제 누출을 구분한 뒤 v2rayN, v2rayNG, TUN 모드의 조회 경로를 조정하고 반복 가능한 비교 테스트로 수정 결과를 확인합니다.

먼저 검사 결과가 DNS 누출인지 확인하기

DNS는 도메인 이름을 IP 주소로 바꾸는 역할을 합니다. 브라우저가 웹사이트에 접속할 때는 보통 먼저 리졸버에 질의한 다음 조회 결과의 서버와 연결을 설정합니다. 프록시 연결이 정상이라고 해서 이 질의까지 프록시를 거친다는 뜻은 아닙니다. 웹 트래픽은 노드를 통해 나가도 DNS 요청은 라우터, 인터넷 서비스 제공업체의 리졸버 또는 시스템에 미리 설정된 서버로 전송될 수 있습니다.

누출 여부를 검사 페이지에 표시된 DNS 주소 개수만으로 판단해서는 안 됩니다. 공용 DNS 서비스는 전 세계 단위의 트래픽 조정을 사용하므로 페이지에 표시되는 출구 도시는 노드 도시와 다를 수 있고, 리졸버 이름 역시 공용 서비스 제공업체나 상위 네트워크를 가리킬 수 있습니다. 핵심은 연결 전 나타난 현지 통신사 리졸버가 연결 후에도 계속 나타나는지, 그리고 조회 요청이 예상한 프록시 또는 암호화 경로를 우회하는지입니다.

클라이언트를 완전히 종료하고 현재 공인 출구 지역, DNS 제공업체 수, 리졸버 지역을 기록합니다.
클라이언트를 실행하고 위치가 분명한 노드를 선택한 다음 시스템 프록시 또는 TUN을 켜고 검사 페이지를 새로 고칩니다.
브라우저와 시스템 DNS 캐시가 이전 결과를 바로 반환하지 않도록 새로운 도메인으로 다시 테스트합니다.
두 결과를 비교하되 IP만 보지 말고 통신사 이름, 네트워크 소속, 지역이 여전히 현지 접속망을 가리키는지도 확인합니다.

결론: 연결 전후를 먼저 비교하고 지도 위치만 보지 않기

노드의 출구와 DNS 리졸버가 같은 도시에 있을 필요는 없습니다. 현지 접속망이 원격에서 조회해야 하는 도메인 질의를 더 이상 받지 않고 조회 경로가 분기 설계와 일치한다면, 지역이 다르다는 이유만으로 누출로 판단해서는 안 됩니다.

DNS가 V2Ray 연결을 우회하는 이유

시스템 프록시는 주로 HTTP 또는 SOCKS 프록시를 지원하는 애플리케이션의 연결을 처리하며, 운영체제가 보내는 모든 DNS 패킷까지 자동으로 가로채지는 않습니다. 일부 애플리케이션은 먼저 시스템 조회 인터페이스를 호출해 IP를 얻은 뒤 연결을 프록시에 넘기므로 도메인 질의가 이미 물리 네트워크 카드에서 전송됩니다. 반면 SOCKS 원격 조회를 지원하는 애플리케이션은 도메인을 프록시 측에서 직접 처리하게 할 수 있어 두 방식의 결과가 다릅니다.

브라우저 자체의 보안 DNS, 라우터가 전달하는 DNS, 기업 네트워크 정책, 가상 네트워크 카드 설정도 각각 별도의 조회 경로를 만들 수 있습니다. 점검할 때는 누가 질의를 시작했는지, 누구에게 질의를 넘겼는지, 어느 아웃바운드로 패킷을 보냈는지를 나누어 봐야 합니다. DNS 주소 하나만 바꾸고 질의가 통과하는 아웃바운드를 바꾸지 않으면 대개 경로 문제는 해결되지 않습니다.

애플리케이션이 도메인 요청시스템 또는 TUN이 가로챔내장 DNS 분기리졸버 선택지정한 아웃바운드로 전송조회 결과 반환

가장 흔한 네 가지 우회 경로

시스템 프록시는 웹 연결만 처리: 시스템 DNS는 여전히 라우터의 53번 포트로 UDP 질의를 보냅니다.
브라우저가 별도로 조회: 브라우저에 설정된 보안 DNS가 클라이언트의 내장 DNS 규칙을 따르지 않아 다른 애플리케이션과 검사 결과가 달라집니다.
TUN 가로채기 범위가 불완전: 물리 네트워크 카드 우선순위, 제외 라우팅 또는 애플리케이션 우회 설정으로 일부 53번 포트 트래픽이 가상 네트워크 카드에 들어가지 않습니다.
노드 도메인을 먼저 조회해야 함: 클라이언트는 노드에 연결하기 전에 서버 IP를 알아야 하므로 이런 초기 조회는 보통 터널이 설정되기 전에 이루어집니다. 신뢰할 수 있는 직접 연결용 리졸버를 별도로 설정해야 합니다.

v2rayN에서 내장 DNS와 분기 설정하기

아래 예시는 v2rayN 7.12.5와 Xray-core 25.6.8 테스트 화면을 기준으로 합니다. 메뉴 이름은 마이너 버전에 따라 바뀔 수 있지만 순서는 같습니다. 먼저 리졸버를 정하고, 중국 본토 도메인과 원격 도메인을 각각의 규칙으로 보낸 다음, 생성된 설정과 코어 로그를 확인합니다. 시스템 프록시만 사용하는 경우 v2rayN의 로컬 SOCKS 진입점은 보통 127.0.0.1:10808이며, 애플리케이션이 프록시를 지원하거나 시스템 프록시가 연결을 가로채야 이 진입점을 사용합니다.

「설정」→「DNS 설정」을 열고 먼저 현재 내용을 백업해 수정 실패 시 복구할 수 있도록 합니다.
원격 리졸버에는 암호화 질의를 지원하는 주소(예: https://1.1.1.1/dns-query)를 설정하고, 해당 리졸버 연결이 규칙에 따라 프록시 아웃바운드로 전송되는지 확인합니다.
중국 본토 도메인에는 별도 리졸버(예: 223.5.5.5)를 남겨 두고, geosite:cn 및 geoip:cn과 함께 결과 범위를 제한합니다.
「설정」→「매개변수 설정」을 열어 코어 유형이 Xray인지 확인하고, 모든 DNS 연결이 강제로 직접 연결로 전송되도록 라우팅 모드가 설정되어 있지 않은지 점검합니다.
저장한 뒤 코어를 재시작하고 로그에서 조회 시간 초과, 노드 도메인 조회 실패 또는 DNS 아웃바운드 거부가 나타나는지 확인합니다.

사용자 지정 설정을 사용하는 경우 아래 구조를 참고해 내장 DNS 분기를 이해할 수 있습니다. 모든 구독에 그대로 적용되는 범용 파일은 아닙니다. 그래픽 인터페이스는 사용자 설정과 구독 생성 항목을 병합할 수 있으므로 입력란만 보지 말고 최종 생성 설정을 중점적으로 확인해야 합니다.

DNS 분기 구조 예시

{
  "dns": {
    "queryStrategy": "UseIPv4",
    "servers": [
      {
        "address": "223.5.5.5",
        "domains": ["geosite:cn"],
        "expectIPs": ["geoip:cn"]
      },
      {
        "address": "https://1.1.1.1/dns-query",
        "domains": ["geosite:geolocation-!cn"]
      }
    ]
  }
}

queryStrategy는 어떤 유형의 주소를 우선 조회할지 결정합니다. IPv4만 필요하다면 UseIPv4를 사용해 듀얼 스택 환경의 불확실성을 줄일 수 있습니다. 네트워크, 노드, 대상 사이트가 모두 IPv6를 안정적으로 지원하는지 확인한 뒤 IPv6가 포함된 전략을 선택하세요. 이 설정이 DNS 연결을 직접 연결로 보낼지 프록시로 보낼지 자동으로 결정하지는 않으며, 아웃바운드는 여전히 라우팅 규칙이 제어합니다.

결론: 리졸버 주소와 아웃바운드 규칙을 함께 변경하기

일반 DNS를 암호화 DNS로 바꾸는 것은 조회 프로토콜만 변경합니다. 해당 연결이 예상한 아웃바운드로 향하는지까지 확인해야 조회 요청이 로컬 네트워크에서 직접 전송되는 것을 막을 수 있습니다.

v2rayNG에서 원격 DNS 처리하기

Android에서는 VPN 모드가 가상 네트워크 인터페이스를 통해 더 많은 트래픽을 가로챈다는 점이 핵심입니다. 아래 절차는 v2rayNG 1.10.31과 Xray 코어를 기준으로 합니다. 「설정」→「VPN 설정」에서 ‘원격 DNS’, ‘로컬 DNS’ 및 로컬 DNS 활성화 상태를 확인하세요. 화면 번역은 다를 수 있으므로 실제 필드의 용도를 기준으로 판단해야 합니다.

「설정」→「VPN 설정」→「원격 DNS」에 프록시 도메인에 사용할 리졸버(예: https://1.1.1.1/dns-query)를 입력합니다.
「로컬 DNS」에는 직접 접속할 수 있는 리졸버(예: 223.5.5.5)를 남겨 중국 본토 규칙과 노드 연결 전 필요한 조회에 사용합니다.
「설정」→「라우팅 설정」으로 이동해 중국 본토 도메인 규칙이 기본 규칙보다 앞에 있는지 확인합니다. 그래야 전체 프록시 규칙에 먼저 걸리지 않습니다.
VPN 연결을 끊었다가 다시 연결합니다. 메인 화면으로 돌아오는 것만으로는 부족하며, 기존 가상 인터페이스와 DNS 캐시가 남아 있을 수 있습니다.
브라우저와 인터넷을 사용하는 다른 애플리케이션에서 각각 테스트합니다. 브라우저에서만 결과가 이상하면 브라우저 자체의 보안 DNS 설정도 확인하세요.

v2rayNG는 Xray 코어를 사용하며 VMess와 VLESS 노드 모두 내장 DNS 및 라우팅 분기와 함께 사용할 수 있습니다. 프로토콜 이름만으로 DNS 누출이 자동으로 방지되지는 않습니다. 결과를 결정하는 것은 VPN 가로채기 범위, DNS 설정, 아웃바운드 규칙입니다. v2flyNG에서 v2fly 코어를 사용할 때도 같은 방식으로 점검하지만, 지원되는 설정 필드는 클라이언트가 실제로 생성한 결과를 기준으로 해야 합니다. Xray에만 적용되는 확장 항목을 그대로 복사하지 마세요.

TUN 모드에서 추가로 확인할 위치

TUN 모드는 시스템 프록시를 직접 지원하지 않는 애플리케이션도 가상 네트워크 카드를 통해 처리하므로 DNS를 일괄 관리하는 데 적합합니다. 하지만 스위치를 켜는 것만으로 끝나지는 않습니다. 가상 네트워크 카드의 라우팅 우선순위, DNS 하이재킹 규칙, 로컬 네트워크 우회 범위, IPv6 경로가 서로 맞아야 합니다. 특히 물리 네트워크 카드에 사용 가능한 IPv6 DNS가 남아 있으면 IPv4 테스트는 정상처럼 보여도 일부 질의가 다른 경로로 전송될 수 있습니다.

애플리케이션이 조회 시작TUN 네트워크 카드가 캡처DNS 트래픽 가로채기도메인 규칙 매칭직접 연결 또는 프록시 조회

TUN 점검 목록

클라이언트가 충분한 권한으로 가상 네트워크 카드를 생성하는지, 로그에 라우팅 기록 실패가 없는지 확인합니다.
UDP와 TCP의 53번 포트가 모두 처리되는지 확인합니다. 흔한 UDP 질의만 검사해서는 안 됩니다.
로컬 네트워크 주소 우회 규칙이 사설 네트워크만 포함하는지 확인하고, 공용 DNS 주소를 실수로 직접 연결 대역에 넣지 않습니다.
당분간 IPv6를 사용하지 않는다면 클라이언트 DNS 조회 전략과 시스템 네트워크 계층을 동일하게 설정해 한쪽만 끄는 일이 없도록 합니다.
FakeDNS를 사용한다면 도메인 스니핑과 라우팅 규칙이 매핑 주소를 원래 도메인으로 복원할 수 있는지 확인합니다.

FakeDNS는 먼저 예약 주소를 반환한 뒤 코어가 ‘가상 IP와 원래 도메인’의 매핑을 저장합니다. 이를 통해 대상 IP만 포함한 연결도 가로채고 도메인 분기를 계속 적용할 수 있지만, 실제 원격 조회가 완료되었다는 뜻은 아닙니다. 최종 대상에 접속하기 전에 코어는 규칙에 따라 실제 주소를 가져와야 합니다. 매핑 풀 충돌, 너무 오래 남은 애플리케이션 캐시, 스니핑 비활성화가 연결 실패를 일으킬 수 있습니다.

코어 로그에서 DNS 오류 원인 찾기

검사 페이지는 결과만 알려 줄 뿐이고 원인 파악에는 코어 로그가 더 적합합니다. 먼저 로그 수준을 임시로 정보 또는 경고로 설정하고, 다시 연결한 뒤 이전에 열어 보지 않은 도메인에 접속합니다. 오류가 노드 주소 조회 단계에서 발생했는지, 원격 리졸버 연결 단계인지, 대상 주소를 얻은 뒤 아웃바운드 단계인지 중점적으로 확인합니다.

오류:failed to find an available destination

원인 및 해결:노드 주소 또는 대상 도메인에서 사용할 수 있는 결과를 얻지 못했습니다. 노드 도메인 철자를 확인하고, 노드에 접근 가능한 초기 DNS를 남겨 둔 뒤 코어를 재시작합니다.

오류:lookup failed: context deadline exceeded

원인 및 해결:제한 시간 안에 리졸버 연결이 응답하지 않았습니다. 암호화 DNS 주소에 접근할 수 있는지 확인하고, 해당 연결이 잘못되어 사용할 수 없는 아웃바운드로 전송되지 않았는지 점검합니다.

오류:lookup: no such host

원인 및 해결:도메인이 존재하지 않거나 잘못 입력되었거나 상위 서버가 빈 결과를 반환했습니다. 확실히 존재하는 새 도메인으로 다시 테스트하고 구독에 포함된 서버 주소를 확인합니다.

오류:failed to dial to DNS server

원인 및 해결:코어가 리졸버와 연결을 설정하지 못했습니다. 라우팅 규칙, 네트워크 권한, 리졸버 포트를 확인하고 리졸버 자체의 도메인을 순환 조회 경로에 넣지 마세요.

로그에 DNS 오류가 없는데도 검사에서 로컬 리졸버가 나타난다면 문제는 대부분 코어 외부에서 발생합니다. 애플리케이션이 시스템 조회를 사용하거나 브라우저가 별도 연결을 만들었거나 DNS 패킷이 TUN에 들어가지 않았을 수 있습니다. 이때는 VMess나 VLESS 노드를 계속 바꾸기보다 시스템 프록시와 TUN 두 모드를 비교해야 합니다.

수정 후 최종 확인 방법

최종 확인은 최소한 ‘첫 조회, 반복 조회, 연결 끊김 후 복구’ 세 가지 상태를 포함해야 합니다. 첫 조회는 실제 조회 경로를 확인하고, 반복 조회는 캐시의 안정성을 살피며, 연결 끊김 후 복구는 재연결 뒤 가상 네트워크 카드나 라우팅 규칙이 다시 로드되지 않는 문제를 찾아냅니다.

클라이언트를 종료하고 출구 지역, DNS 네트워크 소속, 리졸버 수를 포함한 기준 결과를 기록합니다.
시스템과 브라우저의 DNS 캐시를 지운 뒤 클라이언트를 실행하고 한 번도 테스트하지 않은 도메인에 접속합니다.
검사를 3회 연속 실행하되 각 회차 사이를 최소 10초 간격으로 두고 현지 통신사 리졸버가 다시 나타나는지 기록합니다.
연결을 15초간 끊었다가 다시 연결한 후 3회 검사하여 재연결 뒤에도 설정이 적용되는지 확인합니다.
Wi-Fi와 모바일 네트워크를 한 번 전환한 뒤 연결을 다시 설정하고 초기 DNS와 TUN 라우팅이 네트워크 변화에 맞게 작동하는지 확인합니다.

연결 후 DNS 주소가 여러 개 보이면 누출인가요?

아닙니다. 공용 DNS 서비스는 여러 노드를 반환할 수 있습니다. 먼저 직접 연결 결과와 비교하세요. 현지 접속망의 리졸버가 더 이상 나타나지 않고 질의가 예상한 아웃바운드로 처리된다면 개수만으로 누출을 판단할 수 없습니다.

시스템 프록시는 정상인데 DNS 검사에는 왜 로컬 네트워크가 표시되나요?

시스템 프록시가 애플리케이션의 시스템 DNS 요청을 가로채지 않았기 때문입니다. 먼저 v2rayN의 「설정」→「DNS 설정」에서 내장 리졸버를 구성한 뒤 애플리케이션이 SOCKS 원격 조회를 사용하도록 하세요. 일괄 가로채기가 필요할 때 TUN을 추가로 테스트합니다.

암호화 DNS로 바꾼 뒤 웹페이지가 오히려 열리지 않으면 어떻게 하나요?

먼저 리졸버 연결이 아직 설정되지 않은 프록시로 전송되고 있지 않은지 확인한 다음 노드 도메인에 초기 조회 경로를 남겨 두세요. 로그에 시간 초과가 나타나면 원격 DNS 주소와 라우팅 순서를 다시 확인합니다.

브라우저에서만 검사가 비정상이고 다른 애플리케이션은 정상이라면 어떻게 하나요?

브라우저 네트워크 설정에서 독립 보안 DNS를 잠시 끈 뒤 다시 검사합니다. 결과가 정상으로 돌아오면 브라우저가 클라이언트의 DNS 규칙을 우회한 것이므로 양쪽의 조회 전략을 통일해야 합니다.

재연결할 때마다 결과가 달라지는데 정상인가요?

공용 리졸버 노드가 바뀌는 것은 허용할 수 있지만, 현지 통신사 리졸버가 간헐적으로 나타난다면 계속 점검해야 합니다. TUN 재생성 로그, 물리 네트워크 카드의 DNS 우선순위, IPv6 경로를 중점적으로 확인하세요.

안정성의 목표는 검사 페이지에 항상 주소 하나만 표시되게 하는 것이 아니라 조회 경로를 설명하고 재현할 수 있게 만드는 것입니다. 중국 본토 도메인은 규칙에 따라 직접 연결용 리졸버를 사용하고, 원격 도메인은 지정한 리졸버와 아웃바운드로 처리하며, 노드 도메인에는 독립적인 초기 조회 경로가 있어야 합니다. 이 세 가지가 모두 갖춰져야 DNS 분기가 완성됩니다.