V2Ray DNS 누출 테스트 및 v2rayN DNS 설정 방법

1. DNS 누출은 지역이 아니라 조회 경로로 판단하세요

DNS는 도메인 이름을 IP 주소로 변환합니다. 프록시를 사용해도 웹 연결과 DNS 조회는 서로 다른 경로를 이용할 수 있습니다. 브라우저는 프록시로 웹사이트에 접속하지만, 운영체제는 라우터나 인터넷 서비스 제공업체에 도메인 조회를 요청할 수 있습니다. 이런 조회도 프록시를 통과해야 하는데 예기치 않게 직접 연결되는 상황이 이 글에서 확인할 DNS 누출입니다.

v2rayN은 데스크톱 클라이언트이며, 실제 DNS 조회 방식은 선택한 코어, 생성된 설정, 앱 자체 설정과 시스템 네트워크에 따라 달라집니다. 원격 DNS 주소 하나만 바꿔서는 모든 프로그램의 동작을 제어할 수 없습니다. 시스템 프록시를 켜도 모든 UDP 트래픽이 자동으로 처리되는 것은 아닙니다. 브라우저에 내장된 암호화 DNS가 시스템 리졸버를 우회해 별도의 세 번째 경로를 만들 수도 있습니다.

2. 온라인 테스트: 프록시를 끈 상태의 기준 결과부터 확인

https://www.dnsleaktest.com/을 열고 Standard test 또는 Extended test를 실행할 수 있습니다. 테스트 페이지는 브라우저가 임시 도메인들을 조회하도록 한 뒤, 해당 도메인의 권한 DNS 서버에 질의한 재귀 리졸버를 표시합니다. 이 결과는 보통 컴퓨터 네트워크 어댑터의 DNS 주소가 아니며, 컴퓨터에서 리졸버까지의 전체 네트워크 경로를 보여주는 것도 아닙니다.

1. 기준 결과 기록

   TUN을 잠시 끄고 v2rayN의 「시스템 프록시」 메뉴에서 「시스템 프록시 해제」를 선택하세요. 테스트를 실행한 뒤 시간, 웹 트래픽 출구 IP, 리졸버 IP와 운영 기관을 기록합니다. 이때 테스트 트래픽은 현재 네트워크를 통해 직접 전송되므로, 이를 감안할 수 있을 때 진행하세요.

2. 브라우저 환경 통일

   같은 브라우저 프로필과 네트워크를 사용하세요. 브라우저 「설정」에서 「보안 DNS」 또는 「DNS over HTTPS」를 검색해 현재 설정을 기록합니다. 먼저 클라이언트 경로를 확인하려면 브라우저의 사용자 지정 암호화 DNS를 잠시 끄고 테스트하세요. 테스트 후에는 해당 기능을 따로 확인하면 됩니다.

3. 프록시 켜기

   사용 가능한 노드를 선택하고 「시스템 프록시」에서 「시스템 프록시 자동 설정」을 선택하세요. 먼저 테스트 사이트의 웹 트래픽 출구가 실제로 바뀌었는지 확인합니다. 출구가 바뀌지 않았다면 시스템 프록시, 브라우저 확장 프로그램 또는 우회 규칙을 점검하세요.

4. 테스트 반복

   Standard test를 먼저 실행한 다음 Extended test를 실행하세요. 각 모드를 최소 2회 반복하고 기준 결과와 비교합니다. 모드를 바꾼 뒤에는 테스트 페이지를 새로 열어 이전 결과만 확인하는 일이 없도록 하세요. 이후 항목별 비교를 위해 화면을 캡처해 두면 좋습니다.

3. v2rayN 원격 DNS와 로컬 DNS의 역할

수정하기 전에 v2rayN 버전, 현재 코어, 라우팅 모드와 기존 DNS 값을 기록하고 현재 설정을 백업하세요. 일반적인 버전에서는 「설정」→「DNS 설정」에서 관련 페이지를 열 수 있으며, 코어별로 설정 항목이 나뉘는 경우가 많습니다. 버전에 따라 필드 이름과 배치가 달라질 수 있습니다. 아래의 ‘원격 DNS’와 ‘로컬 DNS’는 기능상의 역할을 가리키므로, 현재 버전에 실제로 표시되는 항목을 기준으로 설정하세요. 한 코어의 설정 형식을 다른 코어에 그대로 붙여 넣지 마세요.

• 원격 DNS: 프록시를 사용해야 하는 도메인을 조회할 때 사용합니다. https://1.1.1.1/dns-query와 같은 DoH 주소를 입력하려면 해당 필드가 DoH를 지원해야 하며, DNS 서비스로 향하는 연결이 의도한 아웃바운드로 전달되어야 합니다.
• 로컬 DNS 또는 직접 연결 DNS: 직접 연결 도메인과 일부 초기 조회에 사용합니다. 실제 네트워크 환경에 맞는 신뢰할 수 있는 로컬 리졸버를 사용하세요. 예를 들어 223.5.5.5는 특정 공용 리졸버 주소지만, 적합한지는 네트워크 연결 가능 여부와 개인정보 보호 요구 사항에 따라 달라집니다.
• 노드 도메인 조회: 노드에 연결하려면 보통 먼저 노드 서버의 IP 주소를 알아야 합니다. 아직 연결되지 않은 노드를 통해 모든 조회를 처리하려고 하면 시작 단계에서 의존성 순환이 발생할 수 있습니다. 모든 직접 연결 DNS를 억지로 없애기보다는 코어가 지원하는 별도 조회 방식을 사용하세요.
• DNS 아웃바운드 규칙: DNS 요청 연결을 직접 연결로 보낼지 프록시로 보낼지 결정합니다. 암호화 DNS는 전송 내용을 보호하지만, DoH 연결 자체가 직접 연결되면 DNS 서비스에는 로컬 공인 IP가 보입니다. ‘암호화’와 ‘프록시 경유’는 서로 다른 설정 목표입니다.

한 번에 한 항목씩 바꾸고 저장하세요

먼저 「설정」→「DNS 설정」에서 사용 중인 코어의 설정 페이지를 선택하고, 원격 리졸버와 직접 연결 리졸버의 용도를 확인하세요. 해당 필드가 지원하는 경우에만 위 주소를 입력한 뒤, 라우팅 설정에 DNS 서비스 연결을 강제로 직접 연결하는 규칙이 있는지 점검합니다. 저장 후 서비스나 코어를 재시작하고 설정을 불러오는 중 오류가 없는지 로그에서 확인한 다음 온라인 테스트를 다시 실행하세요. 사용자 지정 설정 텍스트만 보인다면 해당 코어의 형식에 맞는지 먼저 확인하세요. 이름이 비슷하다는 이유만으로 옵션을 추가하지 마세요.

4. TUN 모드에서 DNS 가로채기와 IPv6 확인

시스템 프록시는 주로 프록시 설정을 따르는 앱에 사용됩니다. TUN은 가상 네트워크 인터페이스를 통해 트래픽을 처리하므로 시스템 프록시를 따르지 않는 프로그램을 확인할 때 유용합니다. 하지만 TUN을 켰다고 DNS가 모두 자동으로 처리되는 것은 아닙니다. TUN 라우팅, DNS 처리 규칙과 코어 로그를 함께 확인해야 합니다.

1. 현재 TUN 설정 찾기. 일반적인 데스크톱 버전에서는 「설정」→「매개변수 설정」에서 「Tun 모드 설정」을 찾을 수 있으며, 버전에 따라 별도 페이지에 있을 수 있습니다. 자동 라우팅, 엄격한 라우팅, DNS 관련 항목의 기존 값을 먼저 기록하세요. 현재 버전에 명시적으로 제공되는 항목만 수정합니다.
2. 일반 DNS 처리 확인. 페이지에 DNS 가로채기 또는 DNS 처리 옵션이 있다면 의도한 UDP/TCP 53 조회가 적용 대상인지 확인하세요. 이 기능은 일반 DNS 요청을 코어의 DNS 처리 과정으로 전달하는 것이며, 임의의 암호화 연결을 모두 DNS로 바꾸는 기능은 아닙니다.
3. 암호화 DNS는 별도로 처리. DoH는 보통 TCP 443을 사용하며 HTTP/3를 통해 UDP 443을 사용할 수도 있습니다. DoT는 일반적으로 TCP 853을 사용합니다. 53 포트만 가로채서는 이 연결을 처리할 수 없으므로 앱 설정과 라우팅도 확인해야 합니다.
4. IPv6 경로 확인. 시스템에 IPv6 DNS가 설정되어 있는지, TUN에 IPv6 라우팅이 구성되어 있는지, 프록시 아웃바운드가 대상에 접속할 수 있는지 확인하세요. AAAA 레코드를 조회하는 것과 조회 자체가 IPv6로 전송되는 것은 다릅니다. AAAA 조회만 차단해서 문제가 해결됐다고 판단하지 마세요.
5. 네트워크를 바꿔 다시 테스트. 설정을 저장한 뒤 현재 네트워크에서 먼저 테스트하고, 유선이나 무선 등 실제로 사용하는 환경에서도 다시 연결해 확인하세요. 네트워크를 전환하면 시스템 DNS와 기본 경로가 바뀔 수 있으므로 이전 결과를 새 테스트 대신 사용할 수 없습니다.

TUN을 수정한 뒤 네트워크 전체가 작동하지 않으면 먼저 TUN을 끄고 기준 상태로 되돌린 다음 권한, 가상 인터페이스와 라우팅 충돌을 확인하세요. IPv6를 끄는 방법은 일시적인 비교 테스트로 사용할 수 있지만, 시스템 네트워크 동작을 바꾸므로 일반적인 해결책으로 삼아서는 안 됩니다. IPv6를 계속 사용해야 하는 환경에서는 DNS 처리와 라우팅을 올바르게 구성하세요.

5. 시스템 명령으로 캐시, 프록시, DNS 오류 구분하기

아래는 Windows PowerShell 기준입니다. 첫 번째 명령은 로컬 DNS 캐시를 비우고 시스템 DNS 조회를 실행합니다. 시스템 DNS 경로를 확인하는 테스트이며, 클라이언트의 원격 DNS를 별도로 검증하는 방법은 아닙니다. 브라우저와 코어에 별도 캐시가 있을 수 있으므로 필요한 경우 브라우저를 완전히 종료하고 코어도 재시작하세요.

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

이어서 SOCKS를 지원하는 curl로 ‘대상 도메인 조회를 프록시에 맡기는’ 연결을 테스트할 수 있습니다. 아래 예시는 v2rayN의 SOCKS 또는 혼합 리스닝 포트가 10808이라고 가정합니다. 실행 전에 「설정」→「매개변수 설정」에서 로컬 리스닝 포트를 확인하고 실제 값에 맞게 수정하세요. 숫자로 된 주소 127.0.0.1은 로컬 프록시에 연결해 프록시 호스트 이름을 추가로 조회하지 않도록 합니다.

curl.exe --socks5-hostname 127.0.0.1:10808 --connect-timeout 10 -I https://example.com/

--socks5-hostname은 대상 호스트 이름의 조회를 SOCKS 프록시에 맡깁니다. 반면 --socks5는 일반적으로 대상 호스트 이름을 로컬에서 조회합니다. 첫 번째 명령이 성공해도 명시적으로 지정한 프록시 경로를 사용할 수 있다는 뜻일 뿐, 브라우저나 백그라운드 서비스에 DNS 누출이 없다는 의미는 아닙니다.

6. 재테스트 체크리스트: 트래픽 분기를 유지하고 예상 경로 확인

설정을 변경한 뒤 프록시 끔, 시스템 프록시만 사용, TUN 사용 상태를 각각 나눠 기록하세요. 모든 상태에서 같은 브라우저 설정을 사용하고, 리졸버의 국가나 지역뿐 아니라 운영 기관도 기록합니다. 결과가 예상과 다르면 가장 최근에 바꾼 설정으로 돌아가 되돌린 뒤 테스트를 반복하세요.

• 브라우저: 프록시를 사용해야 하는 테스트 요청이 예상한 출구로 나가고 DNS 결과도 설정과 일치하는지 확인합니다. 브라우저 보안 DNS를 다시 켰다면 별도로 한 차례 더 테스트하세요.
• 터미널: SOCKS를 명시한 연결이 성공하고 시스템 DNS 테스트에서도 타당한 결과가 나오는지 확인합니다. 두 결과를 같은 경로로 기록하지 마세요.
• 트래픽 분기: 직접 연결 도메인은 계속 접속할 수 있어야 하며, 원격 조회 실패로 프록시가 필요한 도메인이 예기치 않게 직접 연결되는지 확인합니다.
• 로그: DNS 시간 초과, 연결 순환 또는 설정 불러오기 실패가 계속 발생하지 않는지 확인하세요. 원인을 찾는 동안에는 잠시 로그 상세 수준을 높이고, 점검을 마치면 평소 수준으로 되돌립니다.
• 설정 기록: 버전, 코어, DNS 주소, TUN 상태와 테스트 날짜를 저장하세요. 외부에 도움을 요청하기 전에 구독 주소, 노드 인증 정보와 공개를 원하지 않는 공인 IP를 가리세요.

7. DNS 누출 방지 설정 관련 자주 묻는 질문