v2rayN DNS 누출 테스트 및 DNS 누출 방지 설정 가이드

이 글 미리보기

웹페이지는 열리지만 테스트 결과에 국내 통신사 DNS가 표시되는 데스크톱 사용자에게 적합합니다. 먼저 웹 트래픽과 도메인 조회 경로를 구분하고, 프록시를 끈 상태의 기준값을 기록하세요. 브라우저 보안 DNS, v2rayN의 원격·직접 연결 DNS, TUN이 처리하는 범위를 차례로 확인합니다. 마지막으로 테스트를 반복하고 로그를 살펴보되, 지역 표시만으로 누출 여부를 판단하지 마세요.

DNS 누출이란? 웹 트래픽은 프록시를 거쳐도 DNS 조회는 다를 수 있습니다

도메인에 접속하려면 앱은 보통 해당 도메인의 IP 주소를 알아내야 합니다. DNS 누출은 프록시 경로로 처리하려던 도메인 조회가 의도한 경로를 벗어나 국내 네트워크 사업자의 DNS와 같은 다른 리졸버로 전송되는 현상입니다. 웹 트래픽의 출구 IP가 바뀌었다고 해서 DNS 조회도 같은 경로를 이용한다고 볼 수는 없습니다.

앱에서 도메인 요청 리졸버 선택 DNS 라우팅 규칙 적용 대상 주소 확인 웹 연결 설정

v2rayN은 클라이언트 관리 인터페이스입니다. 실제 연결과 DNS 조회 동작은 선택한 코어, 생성된 설정, 트래픽이 유입되는 경로에 따라 달라집니다. 시스템 프록시 설정은 이를 따르는 앱에만 적용됩니다. 프로그램이 자체적으로 UDP DNS 요청을 보내거나 브라우저에서 별도의 보안 DNS를 사용하면 다른 조회 경로가 생길 수 있습니다.

일반 DNS에서 주로 사용하는 UDP/TCP 포트

443

DoH에서 주로 사용하는 HTTPS 포트

10808

아래 SOCKS 테스트에서 사용하는 로컬 포트 예시

포트는 트래픽 유형을 파악하는 데 도움이 되지만, 그 자체로 안전성을 증명하지는 않습니다. DoH는 HTTPS로 DNS 조회를 전송하는 방식입니다. 연결 자체가 프록시를 거치지 않으면 DNS 서비스도 프록시 밖에서 이용될 수 있습니다. 반대로 일반 DNS가 프록시 터널 안에서 전송된다면, 포트가 53이라는 이유만으로 누출이라고 판단할 수 없습니다.

DNS 누출 테스트: 기준값을 기록한 뒤 프록시 사용 결과와 비교

테스트 페이지는 보통 브라우저가 여러 임의 하위 도메인을 요청하게 한 다음, 권한 DNS 서버가 받은 조회를 바탕으로 재귀 리졸버의 출구를 보여줍니다. 결과는 해당 브라우저 테스트에서 발생한 DNS 조회 경로를 나타낼 뿐, PC의 모든 앱 트래픽을 검사한 결과는 아닙니다. 주소창에 dnsleaktest.com을 입력하고 Standard 및 Extended 테스트 결과를 비교해 보세요.

기준값 기록

직접 연결 테스트가 가능한 네트워크에서 v2rayN의 시스템 프록시와 TUN을 먼저 끄세요. 웹 출구 IP, 감지된 리졸버 IP와 사업자 이름을 기록합니다. 테스트 도메인에 실제 네트워크 요청이 전송되므로, 보호 기능을 끄면 안 되는 환경에서는 임의로 설정을 해제하지 마세요.
브라우저 고정

같은 브라우저와 같은 설정으로 테스트하세요. Edge를 예로 들면 ‘설정’ → ‘개인 정보, 검색 및 서비스’ → ‘보안’에서 ‘보안 DNS 사용’ 옵션을 확인합니다. 버전에 따라 메뉴 이름이 다를 수 있으므로 설정에서 ‘보안 DNS’를 검색해도 됩니다. 현재 값을 기록한 뒤 테스트할 때는 별도 DNS 조회 기능을 끄세요.
프록시 켜기

v2rayN 기본 창의 ‘시스템 프록시’ 메뉴에서 ‘시스템 프록시 자동 구성’을 선택하고, 현재 노드가 정상적으로 연결되는지 확인하세요. 먼저 시스템 프록시만 켜고 TUN, 노드, 라우팅 템플릿은 동시에 바꾸지 마세요. 그래야 어떤 변경이 결과에 영향을 줬는지 파악할 수 있습니다.
테스트 반복

테스트 페이지를 다시 열어 Standard와 Extended 테스트를 각각 실행하세요. 각 상태에서 두 번씩 반복하고 시간, 출구 IP, 리졸버, 라우팅 모드를 기록합니다. 테스트 결과에 특정 리졸버가 표시되지 않았다고 해서 다른 앱도 그 리졸버를 사용하지 않는다는 뜻은 아닙니다.
경로 비교

프록시를 켠 뒤에도 기준값에 기록한 통신사 리졸버가 나타나면 브라우저와 시스템 DNS 설정을 추가로 확인하세요. 공용 DNS 서비스만 표시되더라도 해당 서비스가 의도한 것인지, 연결이 실제로 프록시를 통과하는지 확인해야 합니다.

결론: 국가만 보지 말고 리졸버를 확인하세요

리졸버가 애니캐스트나 포워딩을 사용하거나 다른 지역을 통해 트래픽을 내보내면 지역 표시가 노드 위치와 다를 수 있습니다. 리졸버 IP와 서비스 제공자를 비교하고 라우팅 및 로그를 함께 확인하세요. 국가 이름을 일치시키려고 DNS를 계속 바꾸지는 마세요.

원격 DNS와 직접 연결 DNS의 역할

이 글에서는 v2rayN 7.x 데스크톱 인터페이스를 기준으로 설명합니다. 일반적인 설정 경로는 ‘설정’ → ‘DNS 설정’입니다. 구버전이나 다른 인터페이스 빌드에서는 관련 항목이 ‘설정’ → ‘매개변수 설정’에 있을 수 있습니다. 사용 중인 메뉴와 코어를 먼저 확인하고, 같은 이름의 항목을 찾을 수 없다고 다른 코어용 설정을 그대로 붙여 넣지 마세요.

항목	주요 용도	확인할 조건
원격 DNS	프록시를 통해 접속할 도메인 조회	DNS 조회의 아웃바운드 경로가 라우팅 규칙과 일치해야 함
직접 연결 DNS	직접 연결 사이트 및 노드 도메인 조회	광범위한 규칙 때문에 프록시 대상 도메인이 직접 연결 DNS로 넘어가지 않도록 설정
시스템 DNS	운영체제 및 프록시가 처리하지 않는 프로그램에서 사용	시스템 프록시가 모든 시스템 DNS 요청을 처리하는 것은 아님
브라우저 보안 DNS	브라우저가 DoH 등의 방식으로 별도 DNS 조회	브라우저 정책 및 연결 경로가 클라이언트 DNS 설정을 우회할 수 있음

원격 DNS에는 설정 인터페이스에서 지원하는 DoH 주소(예: https://dns.google/dns-query)를 사용할 수 있습니다. 직접 연결 DNS는 네트워크 환경에 따라 연결 가능한 리졸버(예: 223.5.5.5)를 선택할 수 있습니다. 주소는 서비스 예시일 뿐 모든 네트워크에 적용되는 정답은 아닙니다. 주소를 입력한 뒤에는 현재 코어에서 해당 형식을 지원하는지, 조회 요청이 어떤 아웃바운드를 통해 전송되는지도 확인하세요.

기존 설정 저장: 현재 원격 DNS, 직접 연결 DNS, 라우팅 템플릿, 코어 종류를 기록하세요. 사용자 지정 설정은 항목별로 되돌릴 수 있도록 사본을 보관합니다.
원격 DNS 설정: ‘설정’ → ‘DNS 설정’에서 현재 코어에 해당하는 원격 DNS 항목을 조정합니다. 인터페이스에서 DNS 트래픽의 아웃바운드를 선택할 수 있다면 프록시 아웃바운드가 선택되어 있는지 확인하세요. 해당 옵션이 없다면 실제 생성된 설정과 관련 라우팅 규칙을 확인해야 합니다.
필요한 직접 연결 유지: 직접 연결할 도메인은 직접 연결 DNS를 사용합니다. 프록시 서버 주소를 도메인으로 입력한 경우에는 프록시 자체에 의존하지 않는 초기 DNS 조회 경로도 필요합니다. 그렇지 않으면 ‘프록시에 연결해야 프록시 주소를 조회할 수 있는’ 순환 의존이 생길 수 있습니다.
적용 후 재테스트: 저장한 뒤 코어가 정상적으로 다시 로드되었는지 확인하세요. 자동으로 다시 로드되지 않았다면 연결을 중지한 다음 다시 시작합니다. 같은 테스트 페이지에서 다시 검사하고, 직접 연결해야 하는 사이트도 정상적으로 열리는지 확인하세요.

TUN과 FakeDNS: 트래픽 처리 범위와 주소 매핑을 따로 확인

시스템 프록시 모드는 브라우저처럼 프록시 설정을 따르는 프로그램에 적합하지만 모든 앱을 자동으로 처리하지는 않습니다. TUN은 가상 네트워크 어댑터로 라우팅 규칙에 맞는 IP 트래픽을 받아 시스템 프록시를 사용하지 않는 프로그램까지 처리할 수 있습니다. DNS까지 처리되는지는 DNS 하이재킹 규칙, 시스템 라우팅, IPv6 및 다른 네트워크 소프트웨어에 따라 달라집니다. TUN이 켜져 있는지만 보고 판단할 수는 없습니다.

FakeDNS는 별도의 방식입니다. 코어가 도메인에 풀에서 가져온 가상 IP를 반환한 뒤, 이후 연결에서 해당 주소를 도메인으로 다시 매핑해 도메인별 분할 라우팅을 지원합니다. Xray에서 흔히 사용하는 IPv4 FakeDNS 주소 풀은 198.18.0.0/15입니다. 가상 IP를 반환한다고 해서 암호화되는 것은 아니며, DNS 조회가 자동으로 원격 프록시를 통과한다는 뜻도 아닙니다.

지원 여부 먼저 확인: v2rayN에서 선택한 코어와 설정 모드가 FakeDNS를 지원하는지 확인하세요. 코어마다 설정 항목과 구현 방식이 다르므로 Xray의 fakedns 설정을 다른 코어에 그대로 적용하지 마세요.
DNS와 연결을 함께 처리: 가상 주소를 받은 앱의 후속 연결도 같은 매핑 메커니즘으로 처리되어야 합니다. DNS 설정만 바꾸고 연결을 처리하지 못하면 도메인 조회는 성공해도 웹페이지가 열리지 않을 수 있습니다.
IPv6 확인: IPv4 DNS나 IPv4 라우팅만 설정했다고 IPv6 경로까지 처리된다는 뜻은 아닙니다. IPv6를 무조건 끄는 대신 AAAA 조회와 IPv6 연결을 각각 확인하세요.
종료 후 캐시 삭제: FakeDNS 또는 TUN을 끈 뒤 Windows 터미널에서 ipconfig /flushdns를 실행하고 브라우저를 완전히 종료했다가 다시 여세요. 브라우저나 앱 자체의 캐시는 시스템 캐시와 함께 지워지지 않을 수 있습니다.

결론: 일반 DNS를 먼저 확인한 뒤 FakeDNS 테스트

먼저 일반 DNS로 ‘노드 연결, DNS 조회, 라우팅’이 모두 정상인지 확인한 다음 FakeDNS를 따로 켜세요. 특정 프로그램에서만 문제가 생기면 전체 노드를 바로 바꾸지 말고, 해당 프로그램의 DNS와 연결이 모두 처리되는지부터 확인합니다.

DNS 시간 초과와 연결 실패: 오류 메시지로 원인 찾기

오류는 앞뒤 로그와 함께 확인해야 합니다. 코어 버전에 따라 접두어, 도메인, 주소가 달라지므로 아래는 흔히 볼 수 있는 오류 일부이며 전체 로그가 아닙니다. 짧은 시간 안에 노드, DNS, 라우팅, 브라우저 설정을 모두 바꾸면 원인을 구분하기 어렵습니다.

오류: lookup example.com: i/o timeout

원인과 해결: 도메인 조회가 시간 초과된 경우 리졸버에 연결할 수 없거나, DNS 아웃바운드가 잘못 선택되었거나, 패킷 손실이 발생했을 수 있습니다. 먼저 리졸버 주소와 라우팅을 확인하고, DNS 설정은 한 번에 하나만 바꾼 뒤 연결을 다시 시작해 테스트하세요.

오류: no such host

원인과 해결: 조회 결과에서 사용할 수 있는 호스트 레코드를 받지 못한 상태입니다. 도메인 오타, 부정 캐시 또는 리졸버 응답이 원인일 수 있습니다. 로그에 표시된 도메인이 노드 주소인지 대상 사이트인지 확인하고, 캐시를 지운 뒤 신뢰할 수 있는 다른 DNS 경로와 비교하세요.

오류: connect: connection refused

원인과 해결: 대상 포트에서 연결을 거부했다고 해서 DNS 누출을 뜻하는 것은 아닙니다. 로컬 SOCKS 테스트에서 발생했다면 v2rayN이 실행 중인지, 실제 수신 포트가 명령에 지정한 포트와 같은지 먼저 확인하세요.

아래 명령으로 시스템 DNS 조회와 SOCKS 프록시 경로를 구분할 수 있습니다. 예시에서는 로컬 SOCKS가 127.0.0.1:10808에서 연결을 수신한다고 가정합니다. 먼저 로컬 설정이나 시작 로그에서 실제 포트를 확인하세요. 수신 주소는 로컬로 제한해야 합니다. DNS 문제를 확인하기 위해 프록시 포트를 전체 LAN에 공개할 필요는 없습니다.

# 시스템 DNS 설정 확인
ipconfig /all

# 시스템 기본 리졸버 조회. 이 명령은 시스템 HTTP 프록시를 자동으로 사용하지 않습니다
nslookup example.com

# SOCKS를 통해 대상 호스트명을 전달해 curl이 대상 도메인을 로컬에서 먼저 조회하지 않도록 합니다
curl.exe --socks5-hostname 127.0.0.1:10808 --connect-timeout 10 -I https://example.com/

# DNS 설정 변경 후 Windows DNS 캐시 삭제
ipconfig /flushdns

--socks5-hostname은 대상 호스트명을 SOCKS 프록시로 전달하지만, 프록시 측에서 실제로 어떻게 조회할지는 코어 설정에 따라 달라집니다. 명령이 성공해도 해당 요청 경로가 동작한다는 것만 확인할 수 있으며, 브라우저나 다른 프로그램의 우회 DNS 조회까지 없다는 뜻은 아닙니다. 또한 nslookup에 표시된 로컬 DNS 주소를 브라우저 누출의 증거로 단정하지 마세요.

수정 결과 확인: 테스트 결과와 사용 환경을 함께 기록

DNS 누출 수정의 목표는 ‘테스트 페이지에 결과가 하나만 표시되는 것’이 아닙니다. 프록시를 사용해야 하는 DNS 조회와 연결이 올바른 경로를 사용하면서 필요한 직접 연결도 유지되어야 합니다. Extended 테스트에서 같은 DNS 서비스의 출구 주소가 여러 개 표시될 수 있으며, 주소 개수의 변화만으로 오류라고 볼 수는 없습니다.

브라우저 재테스트: 기록해 둔 보안 DNS 설정을 유지한 상태에서 두 차례 테스트하고, 기준값에 있던 통신사 리졸버가 뜻하지 않게 다시 나타나지 않는지 확인하세요.
앱별 재테스트: 평소 사용하는 프로그램 중 시스템 프록시를 따르지 않을 수도 있는 앱을 골라 따로 확인하세요. 브라우저 테스트에 통과했다고 해당 앱까지 정상적으로 처리된다고 볼 수는 없습니다.
분할 라우팅 재테스트: 직접 연결할 사이트와 프록시를 사용할 사이트에 각각 접속해 로그의 아웃바운드 선택을 확인하세요. 로그 수준을 일시적으로 높였다면 점검이 끝난 뒤 원래대로 되돌려 불필요한 접속 정보가 장기간 기록되지 않도록 합니다.
네트워크 전환 후 재테스트: 가정용 네트워크에서 모바일 핫스팟으로 전환한 뒤 다시 테스트하세요. 새 네트워크에서 DNS, IPv6, 라우팅이 바뀌면 기존 설정의 허점이 드러날 수 있습니다.
되돌릴 수 있도록 기록: v2rayN 버전, 코어 버전, 프록시 모드, DNS 서비스 주소, 테스트 시간을 기록하세요. 로그를 공유하기 전에는 구독 링크, 인증 정보, 불필요한 접속 도메인을 삭제합니다.

웹페이지는 계속 정상적으로 열리는데 테스트 페이지에 표시된 지역만 노드와 다르다면 리졸버와 포워딩 경로를 먼저 확인하세요. DNS를 바꾼 뒤 모든 노드에 연결할 수 없다면 원래 설정으로 되돌리고 노드 도메인의 초기 DNS 조회를 점검합니다. 브라우저, DNS 아웃바운드, 시스템 트래픽 처리 순서로 하나씩 확인하면 모든 기능을 한꺼번에 켜는 것보다 원인을 찾기 쉽습니다.