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

DNS 누출 판단 기준

도메인에 접속하려면 일반적으로 먼저 IP 주소를 확인한 다음 연결을 시작합니다. DNS 조회와 웹 연결은 서로 다른 경로를 사용할 수 있으므로, 웹 트래픽이 프록시 노드를 통과한다고 해서 DNS 조회도 노드를 통과하는 것은 아닙니다. 여기서 DNS 누출은 프록시 경로로 보내려던 DNS 요청이 여전히 로컬 네트워크나 예상하지 못한 리졸버에 전달되는 상황을 뜻합니다.

앱에서 도메인 요청 리졸버 선택 DNS 라우팅 규칙 적용 아웃바운드 연결 접속 결과 반환

먼저 각 소프트웨어의 역할을 구분해야 합니다. v2rayN은 구독, 노드, 라우팅, 코어 설정을 관리하는 데스크톱 클라이언트이며, V2Ray와 Xray 같은 코어가 실제 네트워크 처리를 담당합니다. VMess 또는 VLESS 노드를 사용한다고 해서 Windows의 모든 앱이 사용할 DNS 경로까지 자동으로 정해지는 것은 아닙니다. 코어가 도메인을 직접 조회하는지는 앱이 도메인을 전달하는지 이미 조회된 주소를 전달하는지, 그리고 시스템 프록시나 TUN이 어디까지 트래픽을 처리하는지에 따라 달라집니다.

웹 트래픽 출구 IP: 현재 웹 연결이 어디를 통해 나가는지 보여 주며, DNS 리졸버 주소와는 다릅니다.
감지된 DNS 서버: 일반적으로 재귀 리졸버가 외부에 조회할 때 사용하는 주소를 뜻하며, 설정 화면에 입력한 주소와 다를 수 있습니다.
직접 연결 도메인 조회: 분할 라우팅에서는 로컬 도메인에 직접 연결 DNS를 사용하도록 의도할 수 있습니다. 이런 설계를 모두 누출로 판단해서는 안 됩니다.
리졸버 위치: 공용 리졸버의 애니캐스트와 요청 분산에 따라 달라질 수 있으므로 국가나 도시 표시는 참고 자료로만 활용하세요.

온라인 검사: 기준 결과를 기록하고 비교하기

같은 네트워크, 브라우저, 테스트 사이트를 계속 사용하세요. 브라우저 주소창에 dnsleaktest.com을 입력하고 표준 테스트를 실행한 다음 확장 테스트도 진행할 수 있습니다. 테스트 페이지는 새로운 도메인 조회를 발생시키며, 권한 DNS 서버에서 재귀 리졸버를 확인합니다. ‘감지된 서버 수’만 기록하지 말고 서비스 제공업체와 웹 트래픽 출구도 함께 적어 두세요.

직접 연결 기준 결과를 기록합니다. 잠시 직접 연결해도 안전하고 민감한 작업을 하지 않는 환경이라면 TUN을 끄고 v2rayN에서 ‘시스템 프록시 지우기’를 선택한 뒤, 현재 네트워크에서 일반적으로 사용하는 리졸버를 기록합니다. 직접 연결을 허용할 수 없다면 기준 테스트를 생략하세요. 테스트를 위해 업무 트래픽을 노출하지 마세요.
프록시 사용 결과를 비교합니다. 사용 가능한 노드를 선택하고 ‘시스템 프록시 자동 설정’을 선택한 뒤 동일한 라우팅 규칙을 유지하면서 테스트를 다시 실행합니다. 브라우저 확장 프로그램의 프록시가 시스템 설정과 충돌하지 않는지도 확인하세요.
테스트 도메인의 라우팅을 확인합니다. 테스트 사이트나 도메인이 직접 연결 대상으로 지정돼 있다면 결과가 프록시 DNS 경로를 보여 주지 않습니다. 테스트 트래픽을 프록시로 보내는 규칙을 잠시 적용해 다시 테스트한 다음 원래 규칙으로 되돌릴 수 있습니다.
새로고침 대신 재검사합니다. 설정을 변경한 뒤 코어를 재시작하고 기존 테스트 탭을 닫은 다음 새로운 테스트를 실행하세요. 변경 전후 결과를 기록하고 캐시된 결과를 새 설정의 효과로 오인하지 마세요.

프록시 사용 중에도 직접 연결 기준 결과와 동일한 현지 통신사 리졸버가 계속 표시된다면 원인을 더 찾아야 합니다. 같은 공용 DNS 서비스에 속한 주소가 여러 개 표시되는 것은 부하 분산일 수 있습니다. 반대로 리졸버가 하나만 표시된다고 모든 앱의 DNS가 제대로 처리된다는 뜻은 아닙니다.

결론: 리졸버의 소속과 예상 라우팅을 기준으로 판단

먼저 테스트 도메인이 프록시를 사용해야 하는지 확인하고, 리졸버가 여전히 로컬 네트워크에 속하는지 비교하세요. 서버 수나 국가 표시만으로 통과 여부를 판단하지 마세요.

v2rayN 원격 DNS 및 직접 연결 DNS 설정

현재 설정을 백업하고 사용 중인 코어를 기록하세요. ‘설정’ → ‘DNS 설정’을 열어 현재 코어에 적용된 DNS 구성을 확인합니다. 버전에 따라 관련 옵션이 ‘설정’ → ‘매개변수 설정’의 DNS 탭에 있을 수 있습니다. 필드 이름과 템플릿, 지원 주소 형식도 코어마다 다릅니다. 옵션을 찾을 수 없다면 현재 화면과 코어를 먼저 확인하세요. 다른 코어용 JSON을 통째로 붙여 넣지 마세요.

53

기존 DNS에서 주로 사용하는 UDP/TCP 포트

443

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

10808

로컬 프록시 포트 예시: 실제 설정을 확인하세요

포트 번호는 서비스를 구분하기 위한 값이며 서로 대체할 수 없습니다. 127.0.0.1:10808이 프록시 연결을 받고 있더라도 그 주소가 자동으로 DNS 서버가 되는 것은 아닙니다. DNS 수신 서비스가 실제로 실행 중인 경우에만 해당 주소를 시스템 DNS 설정에 입력하세요.

원격 DNS를 설정합니다. 해당 형식을 지원하는 필드에는 https://dns.google/dns-query와 같은 DoH 주소를 사용할 수 있습니다. 이는 설정 예시일 뿐이며 현재 네트워크에서 반드시 접속할 수 있다는 뜻은 아닙니다. 원격 조회 요청이 프록시를 통해 나가도록 설정해야 합니다. 그렇지 않으면 DNS를 암호화했을 뿐 로컬 네트워크를 통해 전송하게 됩니다.
직접 연결 DNS를 설정합니다. 직접 연결할 도메인에는 네트워크 관리자가 제공하는 DNS처럼 로컬에서 접근 가능한 리졸버를 지정하세요. 223.5.5.5는 공용 IPv4 리졸버 주소의 예시지만, 현재 네트워크에 적합한지는 테스트해야 합니다. 내부 도메인을 사용하는 경우 해당 네트워크의 설정을 우선 따르세요.
초기 조회 설정을 확인합니다. DoH 주소에는 도메인 이름이 포함되어 있어 처음 연결할 때 해당 도메인을 조회해야 합니다. 프록시 노드 주소도 도메인이라면 먼저 조회해야 할 수 있습니다. 현재 코어에서 제공하는 초기 조회 또는 도메인 조회 설정을 사용해, 아직 연결되지 않은 프록시에 노드 조회가 의존하지 않도록 하세요.
저장한 뒤 코어를 재시작합니다. 로그에 조회 실패가 나타나는지 확인하고 동일한 온라인 테스트를 다시 실행하세요. 한 번에 변수 하나만 바꾸면 리졸버에 연결할 수 없는 문제인지 아웃바운드 라우팅 문제인지 구분하기 쉽습니다.

분할 라우팅: DNS 조회와 연결에 동일한 기준 적용하기

‘설정’ → ‘라우팅 설정’을 열고 선택되지 않은 규칙 모음이 아니라 현재 활성화된 규칙을 확인하세요. 분할 라우팅에서는 최소한 두 가지를 따져야 합니다. 대상 도메인을 어떤 리졸버로 조회하는지, 주소를 얻은 뒤 어떤 아웃바운드로 연결하는지입니다. 서로 연관돼 있지만 같은 설정은 아닙니다.

접속 유형	예상 DNS 조회 경로	중점 확인 사항
프록시 사용이 명시된 외부 도메인	원격 DNS	DNS 조회와 서비스 연결 모두 예상대로 프록시 사용
직접 연결이 명시된 도메인	직접 연결 DNS	로컬 네트워크에 적합한 조회 결과인지, 원격 경로로 잘못 전송되지 않는지 확인
로컬 네트워크 또는 사내 도메인	내부 DNS	내부 조회를 유지하고 공용 리졸버로 전송되지 않도록 확인
프록시 노드 서버 도메인	사용 가능한 초기 조회	프록시 연결 전에도 노드 주소를 확인할 수 있어야 함

Xray 도메인 규칙에서 geosite는 도메인 목록이고 geoip는 IP 목록입니다. 도메인 규칙은 이름을 직접 비교하지만, 일부 IP 기반 규칙은 먼저 주소를 조회해야 할 수 있습니다. DNS 조회 정책을 변경하기 전에 현재 규칙이 언제 조회를 시작하는지 파악하세요. IP 규칙을 적용하려다 불필요한 로컬 조회를 추가하지 않도록 주의해야 합니다.

규칙 우선순위를 확인합니다. 범위가 넓은 직접 연결 규칙이 앞에 배치되면 프록시를 사용해야 하는 테스트 도메인까지 처리할 수 있습니다.
아웃바운드 태그를 확인합니다. 사용자 지정 설정에서 DNS 아웃바운드와 서비스 아웃바운드가 실제로 존재하는 태그를 참조하는지 확인하세요. 예시의 태그 이름을 그대로 사용해서는 안 됩니다.
‘전체’의 두 가지 의미를 구분합니다. 라우팅을 모두 프록시로 변경하면 코어에 전달된 트래픽의 경로만 바뀝니다. 시스템 프록시를 우회하는 앱까지 자동으로 처리하지는 않습니다.
내부 DNS를 보호합니다. 사내 네트워크에서 사용하는 내부 도메인은 공용 DNS로 조회할 수 없을 수 있습니다. 모든 조회를 원격으로 보내기 전에 필요한 예외를 유지하세요.

기본 개념을 더 알아보려면 라우팅 안내와 프록시 모드 안내를 참조하세요. 구독 그룹을 변경해도 DNS 라우팅은 자동으로 수정되지 않습니다. 구독을 업데이트한 뒤에도 현재 노드와 규칙이 의도한 조합인지 확인하세요.

브라우저, TUN, IPv6 우회 경로 점검

시스템 프록시는 프록시 설정을 참조하는 앱을 대상으로 합니다. 브라우저가 별도의 보안 DNS를 사용할 수 있고, 다른 프로그램이 시스템 리졸버를 직접 호출하거나 자체적으로 DNS 요청을 보낼 수도 있습니다. 시스템 프록시를 켰는데도 검사 결과가 이상하다면 노드가 고장 났다고 바로 판단하지 말고, 요청이 v2rayN이 관리하는 경로로 들어오는지 먼저 확인하세요.

브라우저 보안 DNS 설정을 고정합니다. Edge에서 ‘설정’ → ‘개인 정보, 검색 및 서비스’ → ‘보안’을 열어 ‘보안 DNS 사용’ 관련 옵션을 확인하세요. 문제를 진단하는 동안에는 변수를 줄이기 위해 별도의 보안 DNS를 잠시 끌 수 있습니다. 조직 정책으로 관리되는 설정이라면 정책을 우회하지 말고 관리자에게 DNS 경로를 확인하세요.
필요할 때 TUN을 테스트합니다. 시스템 프록시를 사용하지 않는 앱도 처리해야 한다면 v2rayN을 관리자 권한으로 실행한 다음 화면에서 ‘Tun 활성화’를 켜세요. 가상 네트워크 어댑터, 기본 경로, DNS 처리 설정을 확인합니다. TUN의 동작은 사용하는 코어에 따라 달라지므로 스위치가 켜졌다는 이유만으로 모든 조회가 처리된다고 판단할 수 없습니다.
IPv6을 확인합니다. AAAA 조회 자체는 누출을 의미하지 않습니다. IPv6 서비스 연결과 DNS 요청이 같은 프록시 정책을 따르는지 확인하세요. IPv4만 처리하고 우회된 IPv6 경로를 남겨 두면 트래픽 출구가 일치하지 않을 수 있습니다.
다른 네트워크 구성의 영향을 확인합니다. 다른 가상 네트워크 어댑터, 사내 터널, 보안 소프트웨어가 라우팅과 DNS 우선순위를 바꿀 수 있습니다. 현재 상태를 기록한 뒤 하나씩 테스트하고 여러 네트워크 설정을 한꺼번에 바꾸지 마세요.

시스템 프록시 모드에서만 문제가 생기고 제대로 설정한 TUN 모드에서는 결과가 예상과 맞다면, 우선 앱이 시스템 프록시를 우회하는지 확인하세요. 두 모드 모두 문제가 있다면 DNS 아웃바운드, 초기 조회, 브라우저 자체 조회를 점검합니다. 구체적인 처리 범위는 TUN 설정 안내를 참조하세요.

명령어와 로그: DNS 조회 실패와 경로 이상 구분하기

PowerShell을 열어 각 네트워크 어댑터의 DNS 설정을 확인한 뒤 시스템 캐시를 비우세요. 아래 명령어는 Windows의 DNS 조회 환경을 확인하기 위한 것으로, v2rayN의 HTTP 또는 SOCKS 프록시를 자동으로 통과하지 않습니다. 명령이 성공해도 해당 Windows DNS 경로가 작동한다는 의미일 뿐, 브라우저 DNS 누출 검사를 대신할 수는 없습니다.

Get-DnsClientServerAddress
ipconfig /flushdns
Resolve-DnsName example.com -Type A
Resolve-DnsName example.com -Type AAAA

ipconfig /flushdns는 Windows DNS 클라이언트 캐시만 지우며 브라우저나 코어의 모든 캐시를 삭제하지는 않습니다. 테스트 전후에 브라우저 테스트 페이지를 새로 열고, 코어의 DNS 설정을 바꾼 뒤에는 코어를 재시작하세요. 로그에 오류가 없다고 해서 DNS 요청이 우회하지 않는다는 뜻은 아닙니다.

오류: no such host

원인 및 해결 방법: 로그에 표시된 대상 호스트의 이름을 조회하지 못했습니다. 노드 도메인의 오타나 사용할 수 없는 리졸버가 원인일 수 있습니다. 먼저 오류에 나온 도메인을 확인한 뒤 초기 DNS와 현재 리졸버를 점검하세요.

오류: context deadline exceeded

원인 및 해결 방법: 작업이 제한 시간 안에 완료되지 않았습니다. 같은 로그 항목이 DNS 요청을 가리킨다면 리졸버 연결 상태와 아웃바운드 경로를 우선 확인하세요. 연결 단계에서도 발생할 수 있는 오류이므로 앞뒤 맥락 없이 DNS 문제로 단정해서는 안 됩니다.

오류: connection refused

원인 및 해결 방법: 대상 포트에서 연결을 받지 않았습니다. 설정이 로컬 DNS 서비스를 참조한다면 해당 서비스가 실행 중인지, 수신 주소와 포트가 일치하는지 확인하세요. 프록시 수신 포트를 DNS 포트로 잘못 입력하지 마세요.

결론: 검사 결과로 경로를 확인하고 로그로 실패 원인을 파악

웹페이지는 열리지만 DNS 리졸버가 예상과 다르면 트래픽 처리와 분할 라우팅을 확인하세요. 도메인을 조회할 수 없다면 리졸버, 노드 도메인, 초기 조회 경로부터 점검합니다. 두 문제를 구분하지 않은 채 노드만 계속 바꾸지 마세요.

자주 묻는 질문 및 최종 점검

웹 트래픽 출구는 바뀌었는데 DNS는 왜 여전히 현지 통신사를 사용하나요?

먼저 테스트 도메인이 직접 연결 규칙에 걸리지 않는지 확인하고, 브라우저가 로컬에서 먼저 조회하는지도 점검하세요. 브라우저 보안 DNS 설정을 고정하고 ‘설정’ → ‘DNS 설정’에서 원격 조회 아웃바운드를 확인한 뒤 코어를 재시작해 다시 테스트합니다.

DoH로 바꾼 뒤 웹페이지가 열리지 않는데 주소를 계속 바꿔야 하나요?

먼저 마지막으로 작동했던 설정을 복원하고 DoH 서비스 도메인의 초기 조회가 가능한지, 원격 DNS가 아직 연결되지 않은 노드에 의존하는지 확인하세요. ‘리졸버에 연결할 수 없음’과 ‘노드 도메인을 조회할 수 없음’을 구분해 처리해야 합니다.

검사에서 DNS 주소가 세 개 나왔는데 누출이 세 번 발생한 건가요?

아닙니다. 여러 주소가 하나의 재귀 DNS 서비스에 속할 수 있습니다. 리졸버 소속, 직접 연결 기준 결과, 설정상 예상 경로를 비교하세요. 예상과 다른 경로가 확인된 경우에만 추가로 원인을 찾으면 됩니다. 주소 개수만으로 결론을 내릴 수 없습니다.

TUN을 켰다면 브라우저 설정은 무시해도 되나요?

아니요. 브라우저의 별도 DoH 요청이 일반 HTTPS 연결로 TUN에 들어가더라도 다른 리졸버를 사용할 수 있습니다. 지정한 리졸버로 조회를 통일하려면 브라우저 보안 DNS와 코어 DNS 정책을 함께 조정하고 IPv6 경로도 확인해야 합니다.

설정을 마친 뒤에는 되돌릴 수 있도록 현재 노드, 코어 유형, 시스템 프록시 또는 TUN 상태, 원격·직접 연결 DNS, 라우팅 규칙 이름, 두 차례의 검사 결과를 기록해 두세요. 구독 주소, 노드 인증 정보, 민감한 도메인이 포함된 전체 로그는 공개하지 마세요.

프록시 대상 도메인의 리졸버가 예상과 일치하고 직접 연결 도메인과 내부 도메인에도 정상적으로 접속되는지 확인합니다.
v2rayN을 재시작한 뒤에도 설정이 유지되는지 확인합니다. 현재 브라우저 세션에서만 정상 작동하는 것은 아닌지 점검하세요.
Wi-Fi, 유선 네트워크, 핫스팟으로 전환한 뒤 다시 확인하세요. 각 어댑터의 DNS와 IPv6 상태를 특히 점검해야 합니다.
클라이언트를 업그레이드하거나 코어를 바꾸거나 라우팅 템플릿을 교체한 뒤에는 다시 테스트하세요. 이전 환경에서 얻은 결론을 그대로 적용하지 마세요.