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

이 글의 핵심

웹페이지는 프록시를 통해 열리지만 DNS 누수 검사에서 여전히 현지 통신사가 표시되는 경우를 다룹니다. 먼저 같은 검사 페이지에서 직접 연결과 프록시 연결 결과를 비교한 뒤, 브라우저 보안 DNS, Windows 시스템 DNS, 코어 DNS의 세 경로를 구분합니다. 마지막으로 TUN 트래픽 처리, 원격 DNS 연결의 아웃바운드, 트래픽 탐지를 점검합니다. 판단 기준은 검사 페이지에 표시된 국가가 아니라 DNS 요청이 실제로 거친 경로입니다.

1. DNS 누수 판단: DNS 조회와 연결을 구분하기

DNS는 도메인 이름을 IP 주소로 변환합니다. 웹 연결이 프록시를 거친다고 해서 앞서 수행된 도메인 조회까지 프록시를 통과하는 것은 아닙니다. 예를 들어 애플리케이션이 먼저 라우터의 192.168.1.1:53에 DNS 조회를 보낸 뒤, 응답으로 받은 IP를 로컬 프록시에 전달할 수 있습니다. 이 경우 페이지는 열리지만 도메인 조회는 이미 로컬 네트워크에 전달된 상태입니다. 바로 이런 경로 분리를 점검해야 합니다.

애플리케이션의 도메인 요청DNS 조회 경로 선택DNS 조회 아웃바운드대상 주소 반환웹 연결 수립

온라인 DNS 누수 테스트는 보통 브라우저가 무작위 하위 도메인에 접속하게 한 다음, 테스트 운영자의 권한 DNS 서버가 어떤 재귀 DNS 서버에서 조회를 받는지 확인합니다. 페이지에 표시되는 것은 대개 재귀 DNS 서버나 해당 서버의 출구이며, 컴퓨터 네트워크 어댑터에서 나간 모든 패킷을 직접 보여 주는 것은 아닙니다. DNS 서버가 위치한 국가가 프록시 출구 국가와 다르다는 사실만으로는 누수라고 단정할 수 없습니다.

주의가 필요한 경우: 프록시를 사용해야 하는 도메인을 로컬 통신사의 재귀 DNS 서버가 계속 조회하거나, 패킷 캡처에서 관련 평문 DNS 요청이 물리 네트워크 어댑터를 통해 직접 전송되는 경우입니다.
반드시 이상은 아닌 경우: 공용 DNS가 애니캐스트를 사용해 검사 페이지에 다른 지역의 DNS 서버로 표시되거나, 같은 서비스에서 여러 DNS 출구가 확인되는 경우입니다.
분할 라우팅 예외: 로컬 네트워크 이름이나 직접 연결로 지정한 도메인은 로컬 DNS를 사용하도록 설정했을 수 있으며, 이는 의도한 동작일 수 있습니다. 먼저 원격 DNS를 사용해야 하는 도메인을 명확히 정하세요.

2. 온라인 테스트: 재현 가능한 세 가지 조건 비교

브라우저에서 dnsleaktest.com을 열고 Standard test를 실행한 뒤 Extended test로 다시 확인할 수 있습니다. 검사 페이지는 테스트에 필요한 네트워크 정보를 수집하므로 입력란에 구독 주소, 노드 인증 정보 또는 사내 도메인을 입력하지 마세요. 아래 내용은 기록용 양식이며, 실제 테스트 결과가 아닙니다.

테스트 조건	기록할 내용	확인 목적
TUN 끄기, 시스템 프록시 해제	공인 IP, DNS 서버 IP, 통신사 이름	현재 네트워크의 직접 연결 기준값 확인
시스템 프록시 켜기, 같은 노드 유지	공인 IP 변경 여부, 기준 DNS 서버가 계속 표시되는지	브라우저 프록시 경로 확인
TUN 켜기, 같은 노드 유지	DNS 서버 목록, 코어 로그, 브라우저 DNS 상태	트래픽 처리 범위와 DNS 아웃바운드 확인

기준값 기록
신뢰할 수 있는 네트워크에서 먼저 메인 창의 「TUN 사용」을 끈 다음 「시스템 프록시」→「시스템 프록시 해제」를 선택합니다. 검사 결과를 기록하세요. 이 단계에서는 인터넷 연결이 현재 네트워크를 통해 직접 이루어집니다.
변수 고정
작동하는 노드 하나와 같은 브라우저 프로필을 계속 사용하세요. 브라우저의 ‘보안 DNS’가 켜져 있는지도 기록합니다. 비교하는 동안 노드, DNS 서버, 라우팅 규칙을 동시에 바꾸지 마세요.
캐시 비우기
관리자 권한으로 PowerShell을 열고 Clear-DnsClientCache를 실행합니다. 브라우저를 완전히 종료한 뒤 다시 열어 브라우저 캐시와 연결 재사용의 영향을 줄이세요.
조건별 테스트
시스템 프록시를 먼저 테스트한 다음 TUN을 테스트합니다. 각 상태에서 두 차례씩 검사하고 시간과 DNS 서버 IP를 기록하세요. 국가 표시만 캡처하거나 이전 탭의 결과를 새 결과로 간주하지 마세요.

결론: 반복해서 나타나는 로컬 DNS 서버부터 확인

프록시 출구가 바뀌었는데도 두 차례 검사에서 직접 연결 기준값에 있던 통신사 DNS 서버가 반복해서 나타난다면 로컬 DNS 경로를 우선 점검하세요. 공용 DNS 서버의 지역 정보만 다른 경우에는 노드를 바꾸기 전에 해당 DNS 서비스의 운영 주체와 서버 위치부터 확인하세요.

3. 시스템 프록시와 TUN: 트래픽 처리 범위의 차이

v2rayN의 「시스템 프록시」→「시스템 프록시 자동 설정」은 주로 Windows 프록시 설정을 따르는 애플리케이션에 적용됩니다. 시스템 전체의 DNS 트래픽을 처리하는 기능은 아닙니다. 시스템 프록시를 무시하는 애플리케이션도 있고, Windows에서 도메인을 먼저 조회한 뒤 프록시 포트에 연결하는 애플리케이션도 있습니다. SOCKS를 사용하는 앱은 프록시 주소가 올바른지만 확인하지 말고 ‘프록시를 통해 도메인 조회’ 옵션을 선택했는지도 점검하세요.

이 문서에서는 v2rayN 7.x의 일반적인 데스크톱 화면을 기준으로 메뉴 경로를 안내합니다. 이후 버전에서는 메뉴 이름이 달라질 수 있습니다. 메인 창의 「TUN 사용」은 가상 네트워크 어댑터를 통한 트래픽 처리를 켭니다. 실제 TUN 구현, DNS 가로채기 규칙, 라우팅 동작은 실행 중인 코어에 따라 달라집니다. 노드가 Xray를 사용한다고 해서 TUN 계층까지 Xray가 제공하는 것은 아니므로, 실행 로그를 확인하세요.

시작 전: 라우팅이나 DNS를 가로채는 다른 네트워크 도구를 종료하세요. 가상 네트워크 어댑터나 경로 생성에 실패하지 않도록 클라이언트 안내에 따라 관리자 권한을 허용합니다.
시작 후: 로그에 권한, 네트워크 어댑터 생성, 라우팅 충돌 관련 오류가 없는지 확인하세요. 스위치가 켜진 상태로 표시되는 것은 화면상의 상태일 뿐, 실제 트래픽이 처리되고 있다는 증거는 아닙니다.
DNS 처리: 현재 TUN 설정에서 일반 UDP/TCP 53번 포트 DNS 요청을 코어가 처리하도록 되어 있는지 확인하세요. 브라우저가 직접 보내는 DoH는 HTTPS를 사용하므로 53번 포트 가로채기만으로는 감지할 수 없습니다.
IPv6: 물리 네트워크에서 IPv6를 제공한다면 IPv6 경로도 함께 처리되는지 확인하세요. IPv4 테스트만 통과했다고 해서 듀얼 스택 애플리케이션의 모든 트래픽이 예상한 출구를 거친다고 볼 수는 없습니다.

4. 원격 DNS: DNS 서버와 연결 경로를 함께 설정하기

v2rayN에서 「설정」→「DNS 설정」을 열고 현재 수정 중인 설정이 실제 사용하는 코어의 설정인지 먼저 확인하세요. Xray DNS 설정과 sing-box DNS 설정은 형식이 서로 다르므로 한 코어의 JSON 전체를 다른 코어 설정 화면에 붙여 넣으면 안 됩니다. 사용자 지정 설정은 그래픽 인터페이스의 일부 옵션을 우회할 수도 있으므로 실제 생성되어 로드된 설정을 기준으로 확인하세요.

원격 DNS에는 서비스 제공자가 안내하는 DoH 주소를 사용할 수 있습니다. 예: https://1.1.1.1/dns-query. DoH는 클라이언트와 DNS 서버 사이의 조회 내용을 암호화하지만, 연결이 프록시를 통과하도록 보장하지는 않습니다. DNS 서비스가 프록시 출구를 보도록 하려면 URL이 HTTPS인지 확인하는 데 그치지 말고 해당 HTTPS 연결의 아웃바운드도 확인해야 합니다.

설정 항목	확인할 내용	놓치기 쉬운 문제
DNS 서버 주소	DoH 경로 `/dns-query` 전체가 포함되어 있는지 확인	서비스 홈페이지 주소만 입력하면 DNS 응답 대신 웹페이지가 반환됨
조회 연결의 아웃바운드	원격 DNS 연결이 프록시 아웃바운드를 사용하도록 설정	DoH는 암호화되어도 로컬 인터넷 회선으로 직접 연결될 수 있음
시작 시 DNS 조회	노드 도메인과 DNS 서버 도메인에 필요한 부트스트랩 경로 확보	프록시는 DNS에 의존하고 DNS는 아직 연결되지 않은 프록시에 의존하는 순환 문제
실패 시 대체 경로	시스템 DNS나 통신사 DNS로 대체되는지 확인	원격 DNS 실패 후 별도 안내 없이 로컬 DNS로 전환됨

Xray 내장 DNS의 일반 https:// 모드를 사용한다면 라우팅을 함께 확인해 DNS 연결의 출구를 확인하세요. https+local://은 로컬 모드이므로 ‘프록시 강제 사용’을 대신하는 표기로 사용할 수 없습니다. IP 주소 형식의 DoH 엔드포인트를 사용한다면 서버 인증서가 해당 IP 주소를 실제로 포함하는지 확인하세요. 연결 오류를 해결하려고 인증서 검증을 끄지 마세요.

원격 DNS의 정확한 대상과 일치하는 규칙을 해당 대상을 포함할 수 있는 광범위한 직접 연결 규칙보다 앞에 배치하세요. 위 엔드포인트를 선택했다면 1.1.1.1/32가 최종적으로 어떤 아웃바운드 규칙과 일치하는지 확인해야 합니다.
로컬 도메인에는 별도의 DNS 규칙을 사용할 수 있지만, 알 수 없는 모든 도메인을 기본 대체 경로로 로컬 DNS에 보내지 마세요.
노드 서버 주소가 도메인이라면 필요한 부트스트랩 DNS 조회를 유지하고, ‘노드 주소 조회’와 ‘접속 대상 도메인 조회’를 구분하세요. 전자의 요청이 로컬에서 발생한다고 해서 후자의 조회까지 모두 누수되는 것은 아닙니다.

5. 트래픽 탐지: 도메인 복원 기능이며 DNS 처리 기능은 아님

「설정」→「매개변수 설정」에서 ‘트래픽 탐지’ 관련 옵션을 찾으세요. 버전에 따라 ‘트래픽 탐지 사용’ 또는 ‘트래픽 탐지 활성화’로 표시될 수 있습니다. 이 기능은 HTTP Host, TLS 핸드셰이크 등에서 확인할 수 있는 정보를 바탕으로 대상 도메인을 알아내 라우팅 규칙 적용을 돕습니다. 하지만 애플리케이션이 이미 로컬 DNS 서버로 보낸 조회를 취소할 수는 없습니다.

아래 예시는 Xray 인바운드의 탐지 필드만 보여 줍니다. 설정 항목의 의미를 이해하기 위한 것으로, 완성된 설정 파일이 아니며 sing-box DNS 설정에 그대로 붙여 넣을 수도 없습니다.

{
  "sniffing": {
    "enabled": true,
    "destOverride": ["http", "tls"],
    "routeOnly": true
  }
}

enabled: 해당 인바운드의 트래픽 탐지를 활성화합니다. 애플리케이션 트래픽이 실제로 이 인바운드에 들어와야 작동합니다.
destOverride: 탐지를 시도할 프로토콜을 지정합니다. 확인 가능한 도메인 정보가 없는 연결에서는 도메인을 알아낼 수 있다고 보장할 수 없습니다.
routeOnly: 탐지 결과를 라우팅에만 사용하고 원래 대상 주소를 탐지된 도메인으로 바꾸지 않습니다. DNS 암호화 옵션이 아닙니다.

브라우저 보안 DNS도 별도로 점검해야 합니다. Chrome에서는 「설정」→「개인 정보 보호 및 보안」→「보안」으로 이동해 ‘보안 DNS 사용’을 확인할 수 있습니다. Edge에서는 설정에서 ‘보안 DNS’를 검색하세요. 문제를 점검할 때는 먼저 이 기능을 끄고 비교 테스트를 한 다음, 최종 정책에 따라 사용할지 결정합니다. 최종 확인은 실제로 계속 사용할 설정 상태에서 진행해야 합니다. 테스트 중에 끄고 테스트 후 다시 켰다면 반드시 재검사하세요.

6. 로그 오류와 명령줄로 원인 찾기

코어 로그의 오류는 특정 단계가 실패했다는 뜻일 뿐, DNS 누수가 발생했다는 의미는 아닙니다. 대상 주소와 발생 시각, 아웃바운드 태그를 함께 확인하세요. 아래는 자주 보이는 오류 예시입니다. 앞뒤 문구는 코어 버전에 따라 달라질 수 있으므로 로그 전체가 예시와 완전히 일치해야 하는 것은 아닙니다.

오류: lookup example.com: no such host

원인 및 해결: DNS 응답에서 도메인을 찾지 못했거나 현재 DNS 경로에서 도메인을 확인할 수 없는 상태입니다. 먼저 도메인 철자를 확인하고, 정상 작동하는 도메인과 비교한 뒤 DNS 규칙이 잘못된 서버로 조회를 보내는지 점검하세요.

오류: context deadline exceeded

원인 및 해결: 작업이 제한 시간 안에 끝나지 않았습니다. DNS 요청이나 프록시 연결 모두 원인일 수 있습니다. 같은 로그의 대상 주소를 확인하고, DoH 엔드포인트라면 라우팅, 프록시 연결 상태, 시작 시 DNS 조회에 필요한 경로를 점검하세요.

오류: x509: certificate has expired or is not yet valid

원인 및 해결: 시스템 시간이 잘못되었거나 서버 인증서의 유효 기간에 문제가 있을 수 있습니다. 먼저 Windows 날짜와 시간을 동기화한 다음 엔드포인트 인증서 상태를 확인하세요. TLS 인증서 검증은 끄지 마세요.

Windows가 현재 사용하는 DNS 주소를 확인하려면 PowerShell에서 아래 명령을 실행할 수 있습니다. 이 명령은 네트워크 어댑터 설정을 확인하고 시스템 DNS 조회를 테스트하는 용도이며, 프록시를 사용하는 브라우저 테스트와 같지 않습니다. 특히 DNS 서버를 직접 지정한 조회는 TUN이 처리하지 않는 경우 지정한 주소로 바로 전송될 수 있습니다.

Get-DnsClientServerAddress -AddressFamily IPv4
Get-DnsClientServerAddress -AddressFamily IPv6
Clear-DnsClientCache
Resolve-DnsName example.com -Type A
Resolve-DnsName example.com -Type AAAA

네트워크 어댑터 목록에 라우터 DNS가 남아 있어도 그것만으로 누수라고 할 수는 없습니다. TUN이 해당 주소로 향하는 요청을 가로챌 수 있기 때문입니다. 반대로 목록에 공용 DNS가 표시되어도 조회가 프록시를 통과한다는 뜻은 아닙니다. 추가로 패킷을 캡처해야 한다면 물리 네트워크 어댑터에서 UDP/TCP 53번과 TCP 853번 포트로 직접 연결되는 트래픽을 확인하세요. HTTPS 기반 DoH는 포트 443만으로 일반 웹 트래픽과 구분할 수 없으므로 대상 주소와 코어 로그도 함께 살펴봐야 합니다.

결론: 누수 여부보다 실패한 연결 경로부터 복구

원격 DNS에 시간 초과가 발생한다면 먼저 지정한 아웃바운드를 통해 안정적으로 작동하도록 해결한 다음 정책에 맞지 않는 로컬 대체 경로를 끄세요. 원인을 해결하지 않고 대체 경로만 삭제하면 ‘가끔 발생하는 누수’가 ‘모든 도메인을 조회할 수 없는 상태’로 바뀔 뿐, 라우팅 문제는 그대로 남을 수 있습니다.

7. 최종 점검표: 평소 사용하는 상태까지 확인

변경 사항을 저장하고 클라이언트 안내에 따라 코어를 다시 시작하세요. TUN 라우팅이나 가상 네트워크 어댑터를 변경했다면 TUN을 껐다가 다시 켭니다. 최종 점검은 웹페이지 하나만 확인해서는 부족합니다. 재시작, 네트워크 전환, IPv6도 함께 테스트하세요. 검사 페이지 하나의 결과는 해당 시점의 브라우저 요청만 보여 주며 백그라운드 프로그램 전체를 보장하지 않습니다.

브라우저: 평소 사용할 보안 DNS 설정으로 확장 테스트를 두 차례 실행합니다. 공인 IP와 DNS 서버가 예상한 값이어야 하며, 원격 DNS를 사용하도록 지정한 테스트 경로에 로컬 통신사 DNS 서버가 다시 나타나지 않아야 합니다.
시스템 애플리케이션: 프록시를 사용해야 하는 실제 프로그램으로 확인해 시스템 프록시를 따르는지 또는 TUN이 트래픽을 처리하는지 점검하세요. 브라우저 테스트 통과를 모든 프로그램의 통과로 간주하지 마세요.
듀얼 스택 네트워크: A와 AAAA 레코드 조회, IPv4 및 IPv6 연결을 각각 확인해 트래픽의 일부만 처리되는 상황이 없는지 점검하세요.
장애 상황: 노드를 잠시 비활성화하고 원격 DNS 실패 후 정책에 맞지 않는 로컬 조회로 전환되는지 확인하세요. 테스트를 마치면 노드를 즉시 복구합니다.
재시작 후 확인: 클라이언트를 재시작한 뒤 다시 검사하세요. 무선 네트워크나 유선 네트워크로 전환한 다음에도 TUN 라우팅과 DNS 트래픽 처리가 유지되는지 확인합니다.

안정적인 설정은 세 부분으로 이루어집니다. 애플리케이션 트래픽이 의도한 인바운드로 들어오고, 도메인 조회가 지정한 DNS 서버를 사용하며, DNS 연결이 예상한 아웃바운드를 통과해야 합니다. TUN, DoH, 트래픽 탐지는 각각 다른 단계를 처리합니다. 공용 DNS 주소를 계속 바꾸기보다 세 항목을 하나씩 확인하면 문제를 찾기 쉽고 클라이언트 업그레이드 후에도 다시 점검하기 편합니다.