V2Ray DNS 누수 테스트 및 v2rayN DNS 누수 방지 설정

DNS 누수 판단 기준

DNS는 도메인 이름을 IP 주소로 변환합니다. 프록시 연결에 성공했다는 것은 특정 트래픽 연결이 프록시를 거쳤다는 뜻일 뿐, 모든 앱의 도메인 조회가 같은 경로를 사용한다는 의미는 아닙니다. 브라우저는 자체 암호화 DNS를 사용할 수 있고, 시스템은 라우터에 조회를 보낼 수 있으며, 프록시 코어는 노드 연결이나 라우팅 판단을 위해 별도로 이름을 해석할 수도 있습니다. 각 경로를 따로 확인해야 합니다.

이 글에서 말하는 누수란 프록시로 처리하도록 설정한 도메인 조회가 의도치 않게 로컬 네트워크의 DNS 서버로 전달되는 것입니다. 원래 한국 내 도메인은 직접 연결하고 그 밖의 도메인은 프록시로 보내도록 설정했다면, 한국 내 도메인이 로컬 DNS를 사용하는 것은 예상된 동작일 수 있습니다. 검사 결과에 로컬 지역의 서버가 표시됐다는 이유만으로 설정 전체가 잘못됐다고 판단해서는 안 됩니다.

v2rayN은 클라이언트 인터페이스이며, 실제 DNS 처리 방식은 선택한 코어와 생성된 설정, 앱 자체 옵션에 따라 달라집니다. VMess, VLESS 같은 연결 프로토콜이 시스템 DNS를 자동으로 처리해 주지는 않습니다. 검사 페이지에 표시되는 것은 보통 테스트 도메인의 권한 DNS 서버에 조회를 보낸 재귀 DNS 서버의 출구입니다. 프록시 노드 주소와 다를 수 있으며, DNS 서버가 속한 국가만으로 조회가 암호화됐는지 판단할 수도 없습니다.

비교 테스트: 먼저 출구를 확인하고 DNS를 검사하세요

같은 컴퓨터와 네트워크, 브라우저를 계속 사용하세요. 브라우저에서 DNSLeakTest 또는 BrowserLeaks를 검색해 DNS 검사 페이지를 열 수 있습니다. 검사 서비스는 테스트 요청을 받으므로 민감한 환경에서는 먼저 개인정보 처리 안내를 확인하세요. 구독 주소, 노드 인증 정보, 클라이언트 전체 설정은 업로드하지 마세요.

1. 직접 연결 상태를 기준으로 기록합니다. v2rayN의 시스템 프록시와 TUN을 끄고 브라우저에 프록시가 수동 설정되어 있지 않은지 확인하세요. 공인 IP 출구, 감지된 DNS 서버 이름, 브라우저 보안 DNS의 현재 상태를 기록합니다.
2. 시스템 프록시만 켭니다. 사용 가능한 노드를 선택한 뒤 트레이 메뉴에서 「시스템 프록시」→「시스템 프록시 자동 설정」을 선택하세요. 웹 트래픽의 출구가 예상대로 바뀌었는지 확인하고 DNS 검사를 다시 실행합니다.
3. 한 번에 변수 하나만 바꿉니다. 노드와 라우팅 모드는 그대로 둔 채 DNS 설정이나 브라우저 보안 DNS만 바꾸고 다시 검사하세요. 노드 변경, 네트워크 전환, TUN 활성화를 동시에 하면 원인을 찾기 어렵습니다.
4. TUN 상태와 비교합니다. 시스템 프록시 상태를 확인해 기록한 다음 TUN을 켜고 같은 항목을 검사하세요. 전환 후에는 브라우저를 다시 시작해 기존 연결이 재사용되지 않도록 합니다.

시스템 프록시와 브라우저 DNS: 우회 경로부터 확인

시스템 프록시는 시스템 프록시 설정을 따르는 앱에 주로 적용되며, 모든 네트워크 연결을 처리하지는 않습니다. 일부 프로그램은 자체적으로 DNS를 조회한 뒤 연결하고, 시스템 프록시를 전혀 사용하지 않는 프로그램도 있습니다. 브라우저의 보안 DNS, 즉 HTTPS 기반 DNS 조회는 별도의 연결 경로이므로 출구를 따로 확인해야 합니다. 보안 DNS를 켰다고 해서 자동으로 프록시를 통해 조회되는 것은 아닙니다.

• 수신 주소와 포트를 확인합니다. v2rayN 메인 화면에서 현재 로컬 수신 정보를 확인하세요. 설정에 「설정」→「매개변수 설정」→「기본 설정」 항목이 있다면 로컬 수신 포트도 확인합니다. 인터페이스 버전에 따라 메뉴 이름과 구성이 다를 수 있으므로 예시 포트를 그대로 사용하지 마세요.
• 브라우저의 DNS 조회 방식을 고정합니다. 브라우저 설정에서 “보안 DNS”를 검색해 제공업체와 활성화 상태를 기록하세요. 문제를 진단할 때는 이 기능을 잠시 끄고 브라우저가 시스템이나 프록시에서 제공하는 DNS 경로를 사용하게 한 뒤, 다시 켰을 때의 동작을 별도로 검사할 수 있습니다.
• 수동 SOCKS 설정을 확인합니다. 앱에 “프록시를 통해 도메인 조회” 옵션이 있다면 활성화해야 합니다. 앱이 로컬에서 먼저 도메인을 조회한 뒤 IP 주소를 SOCKS 프록시에 전달하는 경우 웹사이트 접속은 성공할 수 있지만, 도메인은 이미 로컬에서 조회된 상태입니다.
• WebRTC와 DNS를 구분합니다. WebRTC 주소 노출은 DNS와 별개의 검사 항목입니다. 같은 검사 페이지에 다른 주소가 표시됐다고 해서 모든 결과를 DNS 문제로 볼 수는 없습니다.

Windows 네트워크 어댑터의 DNS를 127.0.0.1로 바꾸는 방법을 일반적인 해결책으로 사용하지 마세요. 해당 주소의 53번 포트에서 실제로 DNS 서비스가 실행 중일 때만 의미가 있습니다. v2rayN의 로컬 HTTP 또는 SOCKS 프록시 포트는 시스템 DNS 서버의 포트가 아니므로 서로 바꿔 쓸 수 없습니다.

v2rayN DNS 설정: 서버뿐 아니라 연결 경로도 확인

변경 전에 현재 설정을 백업하고 선택한 코어를 기록하세요. 「설정」→「DNS 설정」으로 이동합니다. 일부 인터페이스에서는 관련 항목이 매개변수 설정에 있을 수 있습니다. 같은 이름의 메뉴가 보이지 않는다면 실제 인터페이스의 DNS 항목을 사용하고, 다른 코어용 JSON을 그대로 붙여 넣지 마세요. 필드 이름과 사용 가능한 템플릿, DNS 라우팅 기능은 코어마다 다릅니다.

1. 직접 연결용 DNS와 프록시용 DNS의 역할을 구분합니다. 분할 라우팅을 유지한다면 직접 연결 대상 도메인에는 직접 연결용 DNS를, 프록시가 필요한 도메인에는 원격 DNS를 사용합니다. 모든 서비스 도메인을 프록시를 통해 조회하려면 테스트 중 해당 도메인을 직접 연결용 DNS로 보내는 규칙이 남아 있어서는 안 됩니다.
2. 사용 가능한 원격 DNS를 지정합니다. DNS 서버는 일반 DNS 또는 코어에서 지원하는 암호화 방식을 사용할 수 있습니다. 공용 DNS 주소를 입력하는 것만으로는 연결 경로가 바뀌지 않습니다. 예를 들어 서버를 1.1.1.1로 변경해도 조회가 로컬 네트워크에서 직접 나간다면 “프록시를 통한 조회”라는 목표를 달성한 것이 아닙니다.
3. DNS 요청의 라우팅을 확인합니다. 원격 DNS 서버로 연결할 때 예상한 프록시 출구를 사용하는지 확인하세요. 사설 주소, 특정 지역 주소 또는 광범위한 규칙이 먼저 적용되어 직접 연결되지 않는지도 살펴봐야 합니다. DoH는 보통 443번 포트를 사용하므로 53번 포트 규칙 하나만 추가해서는 충분하지 않습니다.
4. 최초 조회에 필요한 경로를 마련합니다. 프록시 노드 주소가 도메인이라면 프록시를 연결하기 전에 노드 주소를 먼저 확인해야 합니다. DoH 서버 주소가 도메인인 경우에도 최초 조회 경로가 필요합니다. 필요한 초기 조회 경로를 명확히 설정해 “프록시를 연결하려면 DNS가 필요하지만 DNS를 쓰려면 아직 연결되지 않은 프록시에 의존해야 하는” 순환을 방지하세요.
5. 저장한 뒤 코어를 다시 시작합니다. 시작 로그가 정상인지 확인하고 새 도메인에 접속해 테스트하세요. 설정을 저장하기만 하고 다시 불러오지 않았다면 이전 설정의 결과가 계속 표시될 수 있습니다.

라우팅 규칙과 TUN: 시스템 DNS 요청도 확인

TUN은 가상 네트워크 어댑터를 통해 라우팅 조건에 맞는 IP 트래픽을 처리하므로 시스템 프록시를 따르지 않는 프로그램에 유용합니다. 하지만 TUN을 켰다고 모든 DNS 요청이 자동으로 코어의 DNS 처리기로 들어가는 것은 아닙니다. 현재 코어에서 DNS 가로채기나 강제 처리가 활성화됐는지, 적용 범위는 어디까지인지, 제외 라우팅은 없는지 확인하세요. 코어마다 이름은 같지만 의미가 다른 필드를 그대로 복사하지 마세요.

• 먼저 TUN이 정상적으로 시작됐는지 확인합니다. 인터페이스 안내에 따라 필요한 권한을 부여하고 가상 어댑터 생성 실패나 경로 추가 실패 등의 로그가 있는지 살펴보세요. 스위치가 켜져 있어도 네트워크 어댑터가 만들어지지 않았다면 트래픽이 정상적으로 처리된다는 증거가 아닙니다.
• 기존 DNS 요청이 처리되는지 확인합니다. UDP/TCP 53번 포트로 향하는 요청이 예상한 DNS 처리 경로로 전달되는지 확인하세요. UDP만 처리하면 TCP 요청이 누락될 수 있고, IPv4만 처리하면 IPv6 경로가 빠질 수 있습니다.
• 암호화 DNS의 별도 연결 경로를 확인합니다. 브라우저 내장 DoH는 HTTPS 트래픽이므로 기존 53번 포트 DNS 요청에 해당하지 않습니다. DoH 서버의 도메인이나 주소를 기준으로 라우팅을 확인하세요.
• 규칙 순서를 확인합니다. 라우팅 규칙은 보통 코어가 정한 순서대로 적용됩니다. 광범위한 직접 연결 규칙이 원격 DNS 규칙보다 먼저 적용될 수 있으므로 인터페이스에 규칙이 표시되는지만 보지 말고 생성된 설정과 로그를 확인하세요.
• IPv6와 여러 네트워크 어댑터를 확인합니다. 무선·유선 어댑터와 다른 터널이 동시에 활성화되어 있을 수 있습니다. 현재 사용 중인 인터페이스의 DNS 서버와 라우팅을 확인하세요. IPv6를 영구적으로 끄는 대신 해당 경로도 처리되도록 설정하는 것이 우선입니다.

FakeDNS는 반드시 켜야 하는 DNS 누수 방지 옵션이 아닙니다. 가상 주소를 반환하고 도메인 매핑을 유지해 트래픽 처리를 돕는 기능이므로 DNS 조회와 이후 연결이 모두 해당 코어의 처리 경로를 따라야 합니다. 시스템 캐시에 가상 주소가 남아 있는데 트래픽이 그 처리 경로를 벗어나면 오히려 접속이 되지 않을 수 있습니다. 일반 원격 DNS로 목적을 달성할 수 있다면 우선 설정을 단순하게 유지하세요.

Windows 확인 명령과 실제 오류 해결

PowerShell에서 아래 명령을 실행하면 인터페이스 DNS를 확인하고 로컬 캐시를 조회하거나 시스템 캐시를 비울 수 있습니다. 캐시를 비우면 이 컴퓨터의 다른 앱이 다음에 조회할 때도 영향을 받지만, 브라우저 자체 캐시 전체가 지워지거나 기존 연결이 자동으로 종료되지는 않습니다. 캐시를 비운 뒤에는 브라우저를 완전히 종료했다가 다시 열어 검사 페이지를 방문하세요.

Get-DnsClientServerAddress
Get-DnsClientCache
Clear-DnsClientCache
Resolve-DnsName example.com

Resolve-DnsName과 nslookup은 브라우저 프록시 테스트 도구가 아닙니다. 시스템 프록시만 켠 상태에서는 이 명령의 조회가 HTTP 또는 SOCKS 프록시를 거치지 않는 경우가 많습니다. TUN 모드에서 요청이 처리되는지는 DNS 처리 설정과 라우팅에 따라 달라집니다. 명령이 성공했다고 해서 조회 경로가 요구사항에 맞는 것은 아닙니다.

더 확실한 증거가 필요하다면 물리 네트워크 어댑터에서 기존 DNS 트래픽을 캡처하고 UDP/TCP 53의 대상 주소와 테스트 도메인을 확인하세요. 가상 어댑터의 요청만 보면 실제 외부 연결 경로를 놓치기 쉽습니다. 물리 어댑터에서 암호화된 프록시 트래픽이 보이는 것은 정상입니다. 53번 포트 트래픽이 보이지 않아도 DoH 서버로 직접 전송된 조회까지 배제할 수는 없으므로 브라우저 설정과 코어 로그도 함께 확인해야 합니다.

자주 묻는 질문과 수정 후 재검사 기준

수정한 뒤에는 “시스템 프록시 테스트, TUN 테스트, 실제 앱 테스트”를 각각 실행해 결과를 기록하세요. 매번 웹 트래픽 출구, DNS 서버, 브라우저 보안 DNS 상태, 코어 오류 로그를 확인합니다. 한국 내 도메인을 직접 연결하도록 유지한다면 직접 연결이 예상되는 조회와 프록시가 필요한 조회를 따로 기록해 정상적인 분할 라우팅을 누수로 오인하지 않도록 하세요.

• 프록시를 사용해야 하는 테스트 도메인이 로컬의 암호화되지 않은 DNS 조회에 나타나지 않아야 합니다.
• 원격 DNS 연결이 예상한 출구를 사용하고 로그에 지속적인 시간 초과나 초기 조회 순환이 없어야 합니다.
• 클라이언트와 브라우저를 다시 시작한 뒤에도 같은 결과가 나오고, 네트워크를 바꾼 후 다시 확인할 수 있어야 합니다.
• 브라우저 보안 DNS를 다시 사용해야 한다면 별도로 켜고 연결 경로를 다시 검사하세요.