DNS 누수 테스트 및 차단 설정: v2rayN·v2rayNG DNS 설정 가이드

1. DNS 누수 판단 기준

DNS 누수는 DNS 조회가 예상한 네트워크 경로를 따르지 않는 현상입니다. 프록시로 접속해야 하는 도메인을 현지 통신사 DNS가 조회하면 조회 정보가 현지 DNS 경로에 노출될 수 있습니다. 웹사이트에 표시되는 외부 IP가 프록시 서버의 주소라면 해당 웹 연결이 프록시를 통과했다는 뜻일 뿐, DNS 조회도 프록시를 통과했다는 의미는 아닙니다.

v2rayN의 시스템 프록시는 시스템 프록시 설정을 따르는 앱에만 적용되며 컴퓨터 전체의 DNS를 가로채지는 않습니다. v2rayNG의 VPN 모드는 더 많은 앱의 트래픽을 처리할 수 있지만, 앱별 제외 설정, 브라우저 보안 DNS, Android 비공개 DNS, IPv6 라우팅에 따라 실제 경로가 달라질 수 있습니다. TUN이나 VPN을 켜는 것은 검증의 끝이 아니라 시작입니다.

2. 직접 연결과 프록시 결과 비교

DNS 테스트 사이트는 보통 임의의 하위 도메인을 생성한 뒤 권한 DNS 서버에서 재귀 조회를 요청한 리졸버를 확인합니다. 결과는 최종적으로 재귀 조회에 참여한 DNS 서비스를 나타내며, 클라이언트에 입력한 주소와 반드시 일치하지는 않습니다. 공용 DNS의 전달 방식과 애니캐스트도 위치 판정에 영향을 주므로 DNS 제공업체, 테스트 모드, 현재 클라이언트 설정을 함께 기록하세요.

1. 기준 결과 기록

   클라이언트 연결을 끄고 같은 브라우저에서 DNS 테스트 사이트를 여세요. 예를 들어 주소창에 dnsleaktest.com을 직접 입력할 수 있습니다. 웹 외부 IP, DNS 제공업체, IPv4/IPv6 상태, 브라우저 보안 DNS 사용 여부를 기록하세요.

2. 프록시 연결 켜기

   v2rayN 또는 v2rayNG를 실행하고 현재 노드와 라우팅 프리셋을 확인하세요. 같은 네트워크, 브라우저, 테스트 사이트를 유지한 채 전체 테스트를 다시 실행합니다. 두 테스트 사이에 Wi-Fi와 모바일 네트워크를 전환하지 마세요.

3. 변수 분리

   브라우저의 사용자 지정 보안 DNS를 잠시 끄고 테스트한 다음, 다시 켜서 별도로 테스트하세요. 매회 한 가지 설정만 변경하고 ‘시스템 프록시’, ‘TUN’, ‘VPN’ 결과를 구분해 기록해야 서로 다른 연결 방식의 결과가 섞이지 않습니다.

4. 반복 검증

   각 설정으로 최소 2회 테스트하고 클라이언트 로그도 확인하세요. DNS를 변경한 뒤에는 코어 또는 VPN 연결을 재시작해야 합니다. 일반 웹페이지 새로고침은 기존 캐시를 사용할 수 있으므로 새 임의 도메인 테스트를 대신할 수 없습니다.

Windows에서는 다음 명령으로 물리 및 가상 네트워크 어댑터의 DNS 주소를 확인하고 시스템 캐시를 비울 수 있습니다. 시스템 캐시를 비워도 브라우저 자체 캐시는 삭제되지 않으며 앱이 선택한 DNS도 자동으로 바뀌지 않습니다.

Get-DnsClientServerAddress -AddressFamily IPv4
Get-DnsClientServerAddress -AddressFamily IPv6
ipconfig /flushdns

3. v2rayN: 원격 DNS와 직접 연결 DNS 분리 설정

v2rayN에서는 세 가지 용도를 구분해야 합니다. 프록시 대상 도메인 조회, 직접 연결 대상 도메인 조회, 프록시 서버 주소 조회입니다. 프록시 서버가 도메인으로 지정된 경우 프록시 연결을 만들기 전에 서버 IP를 알아야 합니다. 이 조회까지 아직 연결되지 않은 프록시를 통해 강제로 처리하면 DNS 조회가 서로를 기다리는 순환 의존성이 생길 수 있습니다.

v2rayN의 DNS 설정 화면은 버전, UI 유형, 코어에 따라 다릅니다. 여기서는 ‘설정’ → ‘DNS 설정’ 메뉴가 있는 화면을 기준으로 설명합니다. DNS 템플릿이나 JSON 편집기가 표시되면 먼저 기존 설정을 백업한 다음 해당 코어의 용도별 항목만 수정하세요. 다른 코어용 필드를 그대로 붙여 넣지 마세요.

1. 현재 설정 백업

   먼저 메인 화면의 현재 노드, 라우팅 프리셋, 시스템 프록시 및 TUN 상태를 기록하세요. 그런 다음 ‘설정’ → ‘DNS 설정’으로 이동해 기존 내용을 저장합니다. 구독 정보에는 노드 매개변수가 포함되지만, 구독이 이 기기의 모든 DNS 연결 규칙까지 설정한다고 단정해서는 안 됩니다.

2. DNS 조회 용도 구분

   원격 DNS는 프록시를 통해 조회해야 하는 도메인에, 직접 연결 DNS는 로컬 또는 직접 연결 도메인에 사용합니다. 예를 들어 https://1.1.1.1/dns-query는 DoH 서비스 주소입니다. 주소 형식과 서비스 예시일 뿐이며 실제 연결이 프록시를 통과하는지는 라우팅에 따라 달라집니다.

3. DNS 연결의 출구 확인

   DNS 설정과 라우팅 규칙을 확인해 원격 DNS 연결은 프록시 출구로, 직접 연결 DNS는 직접 연결 출구로 나가도록 설정하세요. 로컬 직접 연결을 의미하는 주소 형식이나 특수 DNS 모드를 사용하기 전에는 현재 코어의 처리 방식을 확인해야 합니다. ‘원격 DNS’라는 표시만으로 판단하지 마세요.

4. 트래픽 연결 방식 확인

   브라우저만 프록시를 사용하면 먼저 시스템 프록시로 테스트하세요. 앱이 시스템 프록시를 따르지 않는 경우에만 TUN을 검토합니다. TUN을 켠 뒤에는 DNS 가로채기, 네트워크 어댑터 라우팅, IPv6를 확인하고 서로 충돌하는 가상 네트워크 어댑터 설정을 여러 개 유지하지 마세요.

5. 재시작 후 다시 테스트

   설정을 저장하고 코어를 재시작한 뒤 앞 절의 방법으로 다시 테스트하세요. 노드 서버 주소를 조회할 수 없다면 프록시 규칙을 더 추가하기보다 먼저 작동하는 초기 DNS 조회 경로를 복구해야 합니다.

DNS 암호화와 DNS 프록시는 서로 다른 개념입니다. DoH는 DNS 서비스까지의 조회 내용을 암호화하지만, DoH 연결이 현지 네트워크를 통해 직접 나가면 ‘DNS 트래픽이 프록시 출구를 통과한다’는 목표를 충족하지 못합니다. 반대로 프록시 터널 안에서 일반 DNS를 사용한다고 해서 조회가 로컬 네트워크로 평문 전송됐다고 볼 수도 없습니다.

4. v2rayNG: 로컬 DNS, VPN, 앱 범위 확인

v2rayNG는 Xray 코어를 사용하며 Android VPN 인터페이스를 통해 앱 트래픽을 연결합니다. ‘로컬 DNS 사용’에서 ‘로컬’은 일반적으로 클라이언트 내부의 DNS 처리 기능을 뜻하며, 모든 도메인 조회를 현지 통신사로 보낸다는 의미는 아닙니다. 최종 경로는 DNS 설정, 라우팅, VPN 적용 범위에 따라 결정됩니다.

1. DNS 설정 확인

   사이드 메뉴에서 ‘설정’을 열고 ‘원격 DNS’, ‘직접 연결 DNS’, ‘로컬 DNS 사용’을 찾으세요. 항목은 설정 화면의 서로 다른 그룹에 있을 수 있습니다. 현재 버전에 항목이 없다면 클라이언트 버전과 코어를 확인하고, 존재하지 않는 스위치를 찾으려 하지 마세요.

2. 앱 적용 범위 확인

   ‘설정’ → ‘앱별 프록시’에서 브라우저와 테스트 대상 앱이 제외되어 있는지 확인하세요. 테스트 중에는 앱별 제한을 잠시 끄고 VPN이 정상적으로 트래픽을 처리하는지 확인한 뒤 제외 항목을 하나씩 복구할 수 있습니다.

3. Android 비공개 DNS 분리 테스트

   Android의 일반적인 메뉴 경로는 ‘설정’ → ‘네트워크 및 인터넷’ → ‘비공개 DNS’이며, 제조업체에 따라 이름이 다를 수 있습니다. 기존 값을 기록한 뒤 지정된 서비스 호스트 이름을 잠시 끄고 결과를 비교하세요. 기업 기기나 관리형 네트워크에서는 먼저 관리 정책을 확인해야 합니다.

4. VPN 연결 재설정

   v2rayNG VPN 연결을 끊었다가 다시 시작한 다음 브라우저 보안 DNS, IPv6, 네트워크 전환 후 결과를 확인하세요. 설정만 바꾸고 기존 VPN 세션을 유지하면 새 설정이 반영되지 않을 수 있습니다.

v2rayNG의 IPv6 문제도 단계별로 확인해야 합니다. DNS가 AAAA 레코드를 반환했다는 사실은 IPv6 주소를 조회했다는 의미일 뿐입니다. 이후 IPv6 연결이 VPN에서 처리되는지 확인해야 합니다. 비교를 위해 IPv6를 잠시 끌 수는 있지만, 최종적으로는 AAAA 레코드 탓으로만 돌리지 말고 트래픽 처리나 라우팅 정책을 바로잡아야 합니다.

5. DNS 라우팅과 TUN: 규칙 간 충돌 방지

Xray의 내장 DNS, 도메인 라우팅 정책, 스니핑은 각각 다른 역할을 합니다. 내장 DNS는 도메인을 조회하고, 라우팅 규칙은 트래픽 출구를 선택하며, 스니핑은 연결에서 도메인 정보를 보완하려고 합니다. 도메인 라우팅 정책의 값을 바꿔도 시스템 DNS가 자동으로 모두 프록시를 통과하지는 않습니다. 스니핑을 켜도 브라우저가 직접 만드는 DoH 연결을 가로채지는 못합니다.

• 범위가 넓은 직접 연결 규칙부터 확인: DNS 서비스 주소가 우선순위가 높은 직접 연결 IP 규칙에 포함되면 뒤쪽의 프록시 규칙이 적용되지 않을 수 있습니다. 실제 생성된 코어 설정에서 규칙 순서를 확인하세요.
• 초기 DNS 조회 경로 유지: 프록시 서버와 DoH 서비스가 모두 도메인으로 지정된 경우, 처음에 각각 어떤 DNS가 조회하는지 명확히 설정해 시작 단계의 순환 의존성을 방지하세요.
• 사내 도메인 확인: 내부 도메인은 기업 DNS에서만 조회될 수 있으므로 모든 요청을 공용 DNS로 강제 전송하지 마세요. 도메인 범위와 연결 가능한 경로를 별도로 설정해야 합니다.
• TUN의 DNS 가로채기 확인: 요청이 가상 네트워크 어댑터에 들어온 뒤 누가 처리하는지, 직접 연결 출구가 TUN으로 다시 들어가는 순환을 어떻게 피하는지 확인하세요. 수정하기 전에 복구할 수 있도록 기존 설정을 보관하세요.
• FakeDNS는 신중하게 사용: FakeDNS는 도메인 매핑을 유지하기 위해 가상 주소를 반환하며, 독립적인 암호화 DNS 서비스가 아닙니다. 트래픽 가로채기가 완전하지 않으면 앱이 가상 주소를 받아도 제대로 연결하지 못할 수 있습니다.

6. 자주 발생하는 오류와 최종 점검

DNS 문제라고 해서 반드시 누수가 발생하는 것은 아닙니다. 원격 DNS 연결이 잘못 직접 연결되거나 DNS 주소에 도달할 수 없거나 노드 주소를 초기 조회하지 못해도 웹페이지가 열리지 않을 수 있습니다. 로그 문구는 코어와 시스템에 따라 다르므로 아래 실제 오류 문구를 확인할 때는 주변 로그의 대상 주소와 시간도 함께 살펴보세요.

DNS 패킷 캡처는 웹 테스트를 보완할 수 있지만 UDP 53만 필터링하면 TCP 53, DoT, DoH를 놓칩니다. 물리 네트워크 어댑터를 확인할 때는 대상 DNS 서비스 주소와 연결 방향을 살펴보세요. 443 연결이 발견되면 대상도 확인해야 합니다. 모든 HTTPS 트래픽이 DNS인 것은 아닙니다. 53번 포트 트래픽이 보이지 않는다는 사실만으로 DNS가 모두 예상대로 작동한다고 입증할 수도 없습니다.

• 용도에 맞는 DNS 리졸버: 프록시 대상 도메인이 더 이상 현지 DNS 경로를 예기치 않게 사용하지 않고, 사내 또는 직접 연결 도메인은 정상적으로 조회됩니다.
• 출구와 연결 방식 일치: 시스템 프록시, TUN, Android VPN을 각각 테스트하고 한 방식의 결과로 다른 방식의 동작을 판단하지 않습니다.
• 캐시 영향 배제: 새로 생성된 테스트 도메인을 사용하고 설정 변경 후 관련 연결을 재시작한 다음 최소 2회 다시 테스트합니다.
• 네트워크 전환 후에도 정상 작동: Android에서 Wi-Fi와 모바일 네트워크를 전환하거나 데스크톱이 절전 모드에서 깨어난 뒤 VPN, 가상 네트워크 어댑터, DNS 상태를 다시 확인합니다.
• 복구를 위한 설정 기록: 원격 DNS, 직접 연결 DNS, 라우팅 프리셋, 브라우저 보안 DNS의 최종 값을 기록해 두고 문제가 발생하면 항목별로 되돌립니다.

v2rayN과 v2rayNG의 DNS 누수 방지 설정에서 중요한 것은 DNS 조회와 대상 연결이 각각 명확한 규칙을 따르도록 하는 것입니다. 웹페이지가 열리는지, 외부 IP가 바뀌었는지, 공용 DNS에 다른 위치가 표시되는지만으로는 경로를 검증할 수 없습니다. 비교 테스트를 마치고 설정을 기록해 두면 노드나 네트워크를 바꾼 뒤에도 변경 사항을 쉽게 찾을 수 있습니다.