2026-10-03 · 문제 해결 · 약 9분

V2Ray DNS 누수 테스트와 v2rayN DNS 설정 방법

DNS 누수 원인과 확인 방법을 살펴보고, v2rayN의 원격 DNS·도메인 정책·TUN 모드 설정과 v2rayNG 점검 항목을 안내합니다.

이 글의 핵심

웹 접속 IP는 바뀌었지만 도메인 조회는 여전히 로컬 네트워크를 거칠 수 있습니다. 브라우저, 시스템 리졸버, 프록시 코어의 세 경로를 살펴보며 테스트 기준을 세우고, 원격 DNS를 설정하고, TUN 적용 범위를 확인하는 방법을 설명합니다. 정상적인 직접 연결 DNS 조회와 의도치 않은 누수도 구분합니다. 노드 연결은 되지만 DNS 경로를 더 점검하려는 데스크톱 및 Android 사용자에게 적합합니다.

1. DNS 누수란? 먼저 프록시를 거쳐야 하는 조회를 확인하세요

DNS는 도메인을 IP 주소로 변환하지만, 웹 연결과 도메인 조회가 반드시 같은 경로를 이용하는 것은 아닙니다. 브라우저가 프록시로 웹사이트에 접속할 때 도메인 조회를 프록시 측에 맡길 수 있습니다. 반면 다른 앱은 먼저 시스템 DNS를 호출해 IP를 받은 뒤 해당 IP로 프록시 연결을 할 수도 있습니다. 이 경우 웹 트래픽의 출구는 원격지에 있어도 로컬 네트워크에서는 대상 도메인 조회를 볼 수 있습니다.

여기서 ‘누수’인지는 설정한 라우팅 목표에 따라 판단해야 합니다. 프록시를 통해 조회하도록 설정한 도메인이 실제로는 로컬 네트워크나 예상하지 않은 리졸버에 전달됐다면 수정이 필요합니다. 반면 LAN 이름이나 직접 연결할 웹사이트를 원래 로컬 DNS로 처리한다면, 로컬 리졸버가 감지됐다고 해서 전체 설정이 잘못된 것은 아닙니다.

앱 조회 조회 진입점 DNS 규칙 DNS 아웃바운드 재귀 리졸버

2. DNS 누수 테스트: 세 가지 결과를 비교하세요

먼저 프록시를 끈 상태에서 공인 IP, DNS 리졸버 운영자, 현재 네트워크를 기록한 뒤 프록시를 켜고 같은 테스트를 반복하세요. 무작위 테스트 도메인과 여러 차례 조회를 지원하는 DNS 테스트 사이트를 이용할 수 있습니다. 테스트 사이트에 표시되는 것은 보통 재귀 리졸버의 출구이며, PC가 직접 연결한 DNS 주소와 다를 수 있습니다. 공용 DNS의 애니캐스트 노드와 위치 데이터베이스에 따라 지역 표시도 달라지므로 국기만 보고 판단하지 마세요.

테스트 상태기록 항목주요 목적
프록시 끄기공인 IP, 리졸버 운영자, 네트워크 유형현재 네트워크의 기준값 확인
시스템 프록시만 켜기웹 접속 IP, 브라우저 보안 DNS 상태, 리졸버 변경 여부브라우저가 실제로 사용하는 DNS 조회 경로 확인
TUN 켜기리졸버 목록, IPv4·IPv6 연결, 코어 로그시스템 트래픽과 DNS의 처리 범위 확인

각 상태에서 최소 두 차례 테스트하고, 설정을 바꾼 뒤에는 캐시를 지운 다음 테스트 페이지를 다시 여세요. Windows에서는 터미널에서 아래 명령을 실행할 수 있습니다. 이 명령은 시스템 DNS 캐시만 지우며 브라우저 캐시를 지우거나 DNS 서버 설정을 변경하지는 않습니다.

ipconfig /flushdns
Get-DnsClientServerAddress

두 번째 명령은 PowerShell용으로, 각 네트워크 어댑터의 DNS 주소를 표시해 물리 및 가상 어댑터를 구분하는 데 도움이 됩니다. 이것만으로 누수 여부를 판단할 수는 없습니다. 어댑터에 라우터 주소가 표시되어도 모든 조회가 TUN을 우회한다는 뜻은 아닙니다. 반대로 nslookup example.com도 일반 HTTP 시스템 프록시를 거치지 않으므로, 해당 도구의 조회 경로를 살펴보는 데만 쓸 수 있습니다. 브라우저 및 전체 기기 테스트를 대신하지는 않습니다.

결론: 먼저 운영자를 비교한 뒤 실제 아웃바운드를 확인하세요

프록시를 켜기 전후에 같은 로컬 통신사 리졸버가 계속 표시되면, 먼저 예상된 직접 연결 규칙에 따른 결과인지 확인하세요. 프록시를 반드시 거쳐야 하는 도메인은 DNS 로그와 물리 네트워크 어댑터의 트래픽을 함께 확인하세요. 바로 노드를 바꾸지는 마세요.

3. v2rayN 원격 DNS 및 도메인 정책 설정

작업 전에 v2rayN 버전, 현재 서비스에 사용하는 코어, TUN에 사용하는 코어를 기록하세요. 버전에 따라 DNS 화면 배치가 달라질 수 있으므로, 아래 단계는 「설정」→「DNS 설정」 메뉴가 있는 인터페이스를 기준으로 합니다. 코어별 설정이 따로 표시된다면 현재 실제로 적용 중인 설정을 수정해야 합니다. 사용자 지정 전체 설정이 그래픽 인터페이스에서 생성한 내용을 덮어쓸 수도 있습니다.

  1. 현재 설정 기록

    「설정」→「매개변수 설정」을 열어 로컬 리스닝 포트와 관련 코어 설정을 기록하고, 기존 DNS 설정도 저장해 두세요. PC의 리스닝 포트가 10808이라면 앱에서도 실제 포트를 사용해야 합니다. 다른 가이드에 나온 10809를 그대로 적용하지 마세요.

  2. 리졸버 구분

    「설정」→「DNS 설정」에서 프록시 대상 도메인에 사용하는 원격 DNS와 직접 연결 도메인에 사용하는 로컬 DNS를 구분하세요. DoH를 지원하는 입력란에는 https://dns.google/dns-query와 같은 전체 엔드포인트를 입력할 수 있습니다. IP 주소만 받는 입력란에 URL을 넣지 마세요.

  3. 아웃바운드 확인

    DNS 설정의 아웃바운드 옵션이나 생성된 설정의 라우팅 규칙을 확인해 원격 조회 요청이 계획대로 프록시를 통과하는지 점검하세요. 로컬 DNS는 직접 연결 도메인이나 필요한 초기 조회에 사용할 수 있습니다. 입력란 이름에 ‘원격’이 들어 있다는 이유만으로 조회가 프록시를 통해 전송된다고 단정하지 마세요.

  4. 도메인 정책 확인

    「설정」→「라우팅 설정」을 열어 도메인 정책을 확인하세요. Xray 라우팅의 AsIs, IPIfNonMatch, IPOnDemand는 라우팅 규칙을 일치시킬 때 조회를 실행할지를 제어하며, DNS 암호화 설정이 아닙니다. 먼저 도메인 규칙이 제대로 적용되는지 확인한 다음, IP 규칙과 일치시키기 위해 조회가 필요한지 판단하세요.

  5. 적용 후 재테스트

    설정을 저장하고 서비스를 재시작하거나 노드에 다시 연결한 다음, 코어 시작 로그에 설정 오류가 없는지 확인하세요. 이후 DNS 캐시를 지우고 같은 테스트를 반복합니다. 한 번에 한 항목씩만 변경하고 정상 작동하던 기존 설정은 되돌릴 수 있도록 보관하세요.

4. TUN 누수 방지 점검: DNS 처리, IPv6, 브라우저

시스템 프록시를 따르지 않는 앱까지 처리해야 한다면 v2rayN 메인 화면에서 「TUN 사용」을 켜는 방법을 고려하세요. 처음 실행할 때 관리자 권한이 필요할 수 있습니다. TUN을 켠다고 모든 DNS 우회가 자동으로 차단되는 것은 아닙니다. 일부 버전은 별도의 코어가 TUN 기능을 담당하며, 해당 코어의 DNS 옵션은 일반 프록시 모드 설정과 별개일 수 있습니다.

고급 검증에서는 물리 네트워크 어댑터가 예상하지 않은 주소로 53번 포트 조회를 보내는지 관찰할 수 있습니다. 관찰 시간을 한정하고 대상 웹사이트 조회, LAN 조회, 노드 초기 조회를 구분하세요. 평문 53번 포트 트래픽이 보이지 않아도 모든 DNS가 프록시를 통과한다고 단정할 수는 없습니다. 앱이 암호화 DNS 서비스에 직접 접속할 수도 있습니다.

결론: 리졸버 목록을 완전히 일치시키기보다 대상 도메인을 테스트하세요

필요한 직접 연결 DNS는 유지하면서, 프록시 대상 도메인의 DNS 조회와 서비스 연결이 모두 규칙에 맞는지 확인하세요. 전체 기기 프록시가 명확한 목표일 때만 직접 연결 예외를 하나씩 줄이고, LAN 서비스가 정상 작동하는지도 다시 점검하세요.

5. v2rayNG Android DNS 점검 목록

v2rayNG는 Xray 코어를 사용하며, Android VPN 인터페이스가 범위에 포함된 앱의 트래픽을 전달합니다. v2flyNG는 V2Fly 코어를 사용하므로 DNS 및 라우팅 항목을 모두 서로 그대로 옮겨 쓸 수는 없습니다. 아래 점검은 v2rayNG 기준입니다. 버전에 따라 스위치 이름과 배치가 달라질 수 있으니 현재 화면의 안내를 따르세요.

특정 앱에서만 다른 리졸버가 나타난다면 먼저 앱별 프록시 설정과 앱 자체 DNS 사용 여부를 확인하세요. 모든 앱에서 문제가 발생한다면 VPN 연결, 시스템 비공개 DNS, 현재 네트워크를 점검하세요. 이렇게 하면 구독을 반복해서 초기화하거나 프로토콜을 바꾸지 않고 문제 발생 계층을 좁힐 수 있습니다.

6. DNS 설정 후 인터넷에 연결되지 않을 때: 오류 메시지로 범위 좁히기

원격 DNS를 잘못 설정하면 노드는 선택되지만 웹페이지가 열리지 않을 수 있습니다. 먼저 방금 바꾼 설정을 되돌리고 서비스가 시작되는지 확인한 다음, 로그를 바탕으로 DNS 조회 실패, 연결 시간 초과, 설정 오류를 구분하세요. 아래 메시지는 서로 다른 호출 경로에서 나타날 수 있으므로 앞뒤의 대상 주소, 아웃바운드 표시, 발생 시각과 함께 살펴봐야 합니다.

오류: no such host

원인과 해결 방법: 해당 이름을 조회했지만 유효한 결과를 얻지 못했다는 뜻인 경우가 많습니다. 오류에 나온 도메인이 노드 주소인지, DoH 엔드포인트인지, 서비스 웹사이트인지 먼저 확인한 뒤 철자, 리졸버 연결 상태, 초기 조회 경로를 점검하세요. 이런 오류를 모두 노드 장애로 돌리지는 마세요.

오류: context deadline exceeded

원인과 해결 방법: 정해진 시간 안에 작업을 완료하지 못했다는 뜻이며 DNS 요청이나 이후 연결이 원인일 수 있습니다. 로그에 DNS 교환 시간 초과가 명시돼 있다면 리졸버의 실제 아웃바운드와 네트워크 연결 상태를 확인하세요. 노드 연결 단계에서 발생했다면 노드 경로를 계속 점검해야 합니다.

오류: network is unreachable

원인과 해결 방법: 선택한 주소로 연결할 네트워크 경로가 없다는 뜻이며 IPv6, TUN 라우팅, 인터페이스 변경과 관련될 수 있습니다. 로그에 표시된 대상 주소의 IP 버전을 확인하고, 연결을 다시 설정한 뒤 라우팅을 점검하세요. 인터페이스 문제를 감추려고 DNS 설정을 무작정 바꾸지 마세요.

수정한 뒤에는 같은 브라우저, 같은 네트워크, 같은 프록시 모드로 다시 테스트하고 변경 전후 기록을 보관하세요. DNS 누수 테스트의 핵심은 조회 경로가 예상과 일치하는지 확인하는 것이며, 테스트 페이지에 서버 하나만 표시되는지가 아닙니다. 이후 코어를 바꾸거나 클라이언트를 업데이트하거나 분기 규칙을 조정할 때도 기준값과 다시 비교해야 합니다.

V2Ray 클라이언트 다운로드