V2Ray DNS 누수 테스트 및 방지 설정: v2rayN·v2rayNG 설정 방법

1. DNS 누수의 판단 기준

DNS는 도메인 이름을 IP 주소로 변환합니다. 웹사이트 연결에 프록시를 사용한다고 해서 앞서 실행된 도메인 조회까지 프록시를 통과하는 것은 아닙니다. 브라우저, 운영체제, 클라이언트 코어에서 각각 DNS 조회를 실행할 수 있습니다. 여기서 DNS 누수란 원래 프록시를 거치도록 설정한 도메인 조회가 실제로는 로컬 네트워크나 예상하지 않은 다른 경로로 전달되는 현상을 말합니다. 중국 본토 도메인을 기존 규칙에 따라 직접 연결하고 로컬 DNS를 사용하는 것은 트래픽 분기 정책에 해당합니다. 로컬 DNS가 표시됐다는 이유만으로 문제가 발생했다고 판단해서는 안 됩니다.

V2Ray와 Xray는 코어이며, v2rayN은 데스크톱 GUI 클라이언트입니다. v2rayNG는 Xray 코어를 사용하는 Android 클라이언트이고, v2flyNG는 V2Fly 코어를 사용합니다. GUI의 DNS 옵션은 선택한 코어의 실행 설정으로 변환됩니다. VMess와 VLESS는 프록시 프로토콜이며, 이것만으로 시스템 내 모든 프로그램의 DNS 경로가 결정되지는 않습니다.

2. 기준 결과 만들기: 동일 네트워크에서 세 가지 조건 비교

먼저 현재 노드, 라우팅 모드, 브라우저 보안 DNS, 시스템 DNS, 클라이언트 실행 모드를 기록합니다. 원인을 파악하기 어려워지므로 여러 항목을 한꺼번에 바꾸지 마세요. 같은 기기, 브라우저, 네트워크에서 ‘클라이언트 연결 해제’, ‘시스템 프록시만 사용’, ‘TUN 또는 VPN 적용’ 상태로 각각 테스트하고 결과를 기록합니다. 사용할 수 없는 모드는 건너뛰고, 테스트를 맞추려고 다른 네트워크 소프트웨어를 추가로 실행하지 마세요.

1. 직접 연결 기준 결과를 기록합니다. 클라이언트 연결을 끊고 DNS 테스트 페이지에서 테스트를 실행한 다음 DNS 서버 이름, 주소, 시간을 기록합니다. 테스트 페이지는 보통 임의의 하위 도메인을 사용해 캐시 영향을 줄이지만, 현재 브라우저에서 발생하는 요청만 확인할 수 있습니다.
2. 프록시 사용 결과를 기록합니다. 노드에 연결한 뒤 같은 테스트 페이지에서 이전 결과를 새로고침하는 대신 전체 테스트를 다시 실행합니다. 웹사이트 출구 IP도 함께 기록해 연결 출구 변화와 DNS 경로 변화를 구분합니다.
3. 브라우저 설정 변수를 확인합니다. 브라우저에 내장된 보안 DNS를 잠시 끄고 다시 테스트합니다. 평소 이 기능을 사용해야 한다면 설정을 복원한 뒤 HTTPS 연결도 예상한 아웃바운드 경로를 이용하는지 확인하세요.
4. 다른 앱도 확인합니다. 브라우저 테스트를 마친 뒤 실제 사용하는 프로그램도 확인합니다. 시스템 프록시가 명령줄 도구, 자체 DNS 확인 기능이 있는 프로그램, UDP를 직접 전송하는 앱까지 모두 처리하는 것은 아닙니다.

3. v2rayN: 트래픽 적용 범위를 확인한 뒤 DNS 설정

아래 내용은 일반적인 중국어 UI를 기준으로 설명합니다. 메뉴 구성은 버전과 선택한 코어에 따라 달라질 수 있습니다. 작업 전에 v2rayN 버전과 코어 종류를 기록하고 현재 설정을 백업하세요. 데스크톱의 ‘시스템 프록시 설정’은 시스템 프록시를 따르는 앱에 주로 적용됩니다. TUN은 더 넓은 범위의 네트워크 트래픽을 처리하지만 제외 항목과 DNS 적용 규칙을 별도로 확인해야 합니다. 두 모드를 혼동하지 마세요.

1. 로컬 프록시 주소 확인

   「설정」→「매개변수 설정」을 열어 로컬 수신 포트를 확인합니다. 실제 포트가 10808이라면 앱에서 올바른 프로토콜과 포트를 사용해야 합니다. SOCKS 주소를 HTTP 주소처럼 설정하면 안 됩니다. 혼합 수신을 지원하는 경우에는 화면의 설명을 따르세요.

2. 프록시 모드 확인

   메인 화면 하단의 「시스템 프록시」에서 「시스템 프록시 자동 설정」을 선택한 뒤, 시스템에 등록된 프록시 주소와 포트가 일치하는지 확인합니다. 시스템 프록시를 따르지 않는 앱까지 처리해야 한다면 메인 화면에서 「TUN 사용」을 고려하고 안내에 따라 필요한 권한을 허용하세요.

3. DNS 규칙 확인

   「설정」→「DNS 설정」으로 이동합니다. 현재 코어나 버전에서 이 항목이 매개변수 설정에 있다면 해당 DNS 페이지를 이용하세요. 프록시 대상 도메인에 사용할 원격 DNS 서버를 확인하고, DNS 서버에 연결할 때 프록시 아웃바운드를 이용하는지도 점검합니다. 서버 주소만 입력하고 끝내지 마세요.

4. 트래픽 분기 범위 확인

   라우팅 설정에서 직접 연결 도메인, 프록시 도메인, 기본 아웃바운드를 확인합니다. 문제 범위를 좁히기 위해 일시적으로 전역 프록시 라우팅을 사용할 수 있지만, 이것이 DNS 적용을 대신하거나 시스템의 모든 앱이 처리 대상임을 보장하지는 않습니다.

5. 재시작 후 재검사

   설정을 저장하고 코어를 재시작한 뒤, 시작 로그에 설정 오류가 없는지 확인하고 같은 테스트를 다시 실행합니다. 구독을 업데이트할 때마다 결과가 달라진다면 규칙을 계속 추가하기보다 구독이나 사용자 지정 설정이 DNS 또는 라우팅을 다시 생성하는지 확인하세요.

macOS와 Linux에서는 시스템 프록시의 적용 범위가 데스크톱 환경과 앱 구현에 따라 달라집니다. Windows의 시스템 설정 경로를 그대로 적용하지 마세요. 플랫폼과 관계없이 앱 트래픽이 클라이언트에 전달되는지, 코어가 어떤 DNS를 사용하는지, DNS 조회에 어떤 아웃바운드가 선택되는지를 확인해야 합니다.

4. v2rayNG: VPN 적용 범위와 원격 DNS 확인

Android에서 연결 후 VPN 아이콘이 표시되더라도 VPN 서비스가 실행 중이라는 뜻일 뿐, 모든 앱이 처리 대상이라는 보장은 없습니다. 앱별 프록시, LAN 우회, 다른 VPN 서비스, 시스템의 비공개 DNS가 결과에 영향을 줄 수 있습니다. v2rayNG의 항목은 버전에 따라 달라질 수 있습니다. 아래 단계는 설정 화면에 흔히 표시되는 「원격 DNS」와 「로컬 DNS 사용」을 기준으로 합니다. 해당 항목이 없다면 다른 스위치로 억지로 대체하지 마세요.

1. 앱 적용 범위 확인

   사이드 메뉴에서 「설정」→「앱별 프록시」를 열어 선택한 앱만 프록시를 사용할지, 선택한 앱을 프록시에서 제외할지 확인합니다. 테스트할 브라우저가 프록시 적용 범위에 포함되어야 합니다. 문제를 확인하는 동안에는 앱별 제한을 잠시 끄고 기존 목록을 기록해 두세요.

2. DNS 처리 경로 설정

   「설정」에서 DNS 관련 항목을 찾아 「원격 DNS」를 확인합니다. 「로컬 DNS 사용」 옵션이 있으면 설명을 먼저 읽고 활성화하세요. 여기서 ‘로컬’은 보통 클라이언트 내부에서 DNS를 처리한다는 뜻이며, 통신사 DNS에 조회를 맡긴다는 의미는 아닙니다.

3. 시스템 설정 변수 확인

   Android 설정에서 「네트워크 및 인터넷」→「비공개 DNS」를 열어 현재 상태를 기록합니다. 제조사에 따라 메뉴 경로가 다를 수 있으므로 시스템 설정에서 ‘비공개 DNS’를 검색해도 됩니다. 비교 테스트 중에는 잠시 끄고, 테스트가 끝나면 원래 설정으로 복원해 다시 확인하세요.

4. 재연결 후 로그 확인

   설정을 저장하고 연결을 끊었다가 다시 연결한 뒤, 사이드 메뉴의 「로그」에서 조회 시간 초과나 아웃바운드 오류를 확인합니다. Wi-Fi와 모바일 네트워크에서 각각 테스트해 선택한 DNS 서비스에 특정 네트워크에서만 접속할 수 있는 것은 아닌지 확인하세요.

브라우저 보안 DNS와 시스템 비공개 DNS를 함께 사용 중이라면, 먼저 한 번에 하나씩만 켜서 확인하세요. DoH는 HTTPS를, DoT는 주로 TCP 853을 사용합니다. 두 방식 모두 DNS 조회를 암호화하지만 프록시를 통과하는지는 트래픽 적용 범위와 라우팅에 따라 달라집니다. 네트워크를 바꾼 뒤 이미 방문한 사이트만 열리는 경우 캐시가 DNS 문제를 가리고 있을 수 있으므로 설정이 안정적이라고 단정하지 마세요.

• 비교를 위해 전역 프록시 라우팅을 사용했다면 테스트 후 기존 트래픽 분기 규칙으로 복원하고, 프록시 도메인과 직접 연결 도메인을 다시 확인하세요.
• LAN 프린터와 사내 도메인은 로컬 DNS에 의존할 수 있습니다. 별도의 명확한 규칙을 유지하고 모든 DNS 서버를 일괄적으로 공용 서비스로 바꾸지 마세요.
• v2flyNG는 다른 코어와 UI를 사용하므로 v2rayNG 실행 설정을 그대로 복사하지 마세요. 설정을 옮길 때 DNS 항목과 라우팅 기능을 다시 확인하세요.

5. 로그와 패킷 캡처로 실패 단계 찾기

먼저 문제가 조회, 연결, 수신 중 어느 단계에서 발생했는지 확인합니다. 아래 오류 문구는 코어나 하위 네트워크 오류에 표시될 수 있으며, 전체 접두어는 버전에 따라 달라집니다. 각 문구는 문제를 좁히는 단서일 뿐, 로그 한 줄만으로 DNS 누수가 발생했다고 단정할 수는 없습니다.

Windows: 시스템 DNS 확인 및 캐시 삭제

PowerShell에서 아래 명령을 실행해 시스템 네트워크 어댑터의 DNS를 확인하고, DNS 캐시를 삭제한 뒤 명령줄에서 도메인 조회를 테스트합니다. 마지막 명령은 일반적으로 시스템에 설정된 DNS 서버를 사용합니다. HTTP 시스템 프록시를 켜도 자동으로 클라이언트 경로를 이용하지 않으므로 브라우저와 결과가 달라도 이상하지 않습니다.

Get-DnsClientServerAddress
Clear-DnsClientCache
nslookup example.com

평문 DNS 및 IPv6 확인

패킷 캡처를 사용할 수 있다면 물리적 네트워크 어댑터에서 아래 필터를 적용합니다. 관련 없는 앱을 종료하고 새 도메인 조회를 한 번 실행하세요. 포트 53 트래픽이 보이는 것만으로는 충분하지 않습니다. 조회 도메인과 발생 시간을 함께 확인해 테스트 대상 앱의 요청인지 판단해야 합니다. 반대로 포트 53 트래픽이 없다고 해서 완전히 안전한 것도 아닙니다. 암호화된 DNS를 사용하거나 캐시된 결과를 썼을 수 있습니다.

udp.port == 53 || tcp.port == 53
tcp.port == 853

6. DNS 누수 방지 점검표와 설정 복구

점검 기준은 페이지에 DNS 서버 하나만 표시되는지가 아니라, 정해 둔 정책이 제대로 적용되는지입니다. 모든 서비스 조회를 프록시로 보내려면 관리 대상 앱의 DNS 경로와 아웃바운드를 확인하세요. 중국 본토와 해외 트래픽을 분기하려면 직접 연결 도메인과 프록시 도메인을 각각 검증합니다. DNS 조회와 웹사이트 연결에 서로 다른 정책을 적용할 수 있지만, 우회가 우연히 발생하는 것이 아니라 의도한 설정이어야 합니다.

• 설정 적용: 재시작 후 코어가 정상 실행되고, 로그에 DNS 설정 해석 또는 수신 오류가 없어야 합니다.
• 경로 일치: 테스트 브라우저가 트래픽 적용 범위에 포함되어 있고, 원격 DNS 연결에 예상한 프록시 아웃바운드가 선택되어야 합니다.
• 캐시 배제: 시스템 캐시를 지우거나 테스트 페이지에서 새로 생성한 조회를 사용해 과거 결과를 현재 설정의 결과로 오인하지 않도록 합니다.
• 네트워크별 확인: Wi-Fi, 모바일 네트워크, 데스크톱 네트워크를 바꿔 가며 다시 테스트하고 차이를 기록합니다. 한 번의 결과를 모든 환경에 그대로 적용하지 마세요.
• 시작 시 연결 가능: 기기를 재시작한 뒤 처음 연결할 때도 노드 주소를 조회할 수 있어야 합니다. 이전 연결에서 남은 캐시에 의존하지 마세요.
• 복구 방법 준비: 기존 DNS, 라우팅, 비공개 DNS 설정을 보관합니다. 문제가 생기면 가장 최근 변경 사항부터 되돌린 뒤 기본 연결을 확인하세요.

문제를 공유할 때는 클라이언트 버전, 코어, 라우팅 모드, 오류 발생 시각, 민감 정보를 가린 로그를 포함하면 됩니다. 구독 주소, 노드 인증 정보, 전체 실행 설정에는 계정 접근 권한이 포함될 수 있으므로 공개하지 마세요. 추가로 원인을 찾으려면 문제 진단을 참고해 시작, 수신, 연결, DNS 확인 순으로 점검하세요.