v2rayN DNS 누수 확인 방법: 3가지 점검법과 누수 방지 설정

먼저 DNS 누수 판단 기준 확인

DNS는 도메인 이름을 IP 주소로 변환합니다. 애플리케이션이 캐시에 없는 도메인에 접속하면 보통 먼저 DNS 조회 요청을 보낸 뒤 조회된 주소로 연결합니다. 프록시 연결이 정상이라고 해서 DNS 요청까지 반드시 프록시를 통과하는 것은 아닙니다. 시스템 프록시는 주로 HTTP 또는 SOCKS를 지원하는 애플리케이션의 트래픽을 처리하며, Windows DNS Client가 보내는 UDP 53 조회는 현재 네트워크 어댑터의 DNS 서버로 계속 전송될 수 있습니다.

누수 여부는 검사 페이지에 표시된 서버 수만으로 판단할 수 없습니다. 먼저 프록시를 사용하지 않을 때의 DNS 제공업체, 도시와 서버 수를 기록한 다음 v2rayN을 켜고 다시 테스트하세요. 프록시 사용 후에도 동일한 통신사와 지역의 DNS 서버가 계속 나타나고, 로그에서 조회가 Xray으로 들어가지 않은 것이 확인될 때 누수로 처리할 충분한 근거가 있습니다.

브라우저에 내장된 보안 DNS도 테스트 결과를 바꿀 수 있습니다. 브라우저가 지정한 DoH 서비스로 HTTPS 조회를 직접 보낼 수 있기 때문에 검사 페이지에 표시되는 DNS 서버가 시스템 DNS나 v2rayN에서 온 것이라고 단정할 수 없습니다. 점검 중에는 브라우저의 「설정」→「개인정보 및 보안」→「보안」→「보안 DNS 사용」을 열어 현재 설정을 기록하세요. 동일한 기준을 세우려면 해당 기능을 잠시 끈 뒤 테스트를 완료하고 원래 설정으로 되돌리는 것이 좋습니다.

방법 1: 브라우저 검사 사이트에서 두 차례 비교

먼저 다른 프록시 도구를 모두 종료하고 v2rayN만 남겨 두세요. v2rayN 메인 창 하단에서 현재 서버가 선택되어 있는지 확인한 뒤 시스템 프록시를 「시스템 프록시 자동 설정」으로 전환합니다. 브라우저 테스트는 접속 위치와 DNS 위치가 뚜렷하게 다른 문제를 빠르게 발견하는 데 유용하지만, 어떤 프로세스가 실제로 조회를 보냈는지 단독으로 증명할 수는 없습니다.

1. 기존 캐시 삭제

   모든 브라우저 창을 닫고 관리자 권한 터미널에서 ipconfig /flushdns를 실행합니다. “DNS 확인자 캐시를 성공적으로 플러시했습니다”라는 메시지가 표시되면 브라우저를 다시 여세요.

2. 직접 연결 기준 기록

   v2rayN 시스템 프록시를 「시스템 프록시 해제」로 전환하고 dnsleaktest.com에 접속한 다음 Standard test를 실행합니다. 서버 이름, 국가 또는 지역과 결과 수를 기록하세요.

3. 시스템 프록시 활성화

   v2rayN으로 돌아가 「시스템 프록시 자동 설정」을 선택하고 지연 시간 테스트가 정상인지 확인하세요. 그런 다음 새 시크릿 창을 열어 기존 연결과 DNS 캐시가 결과에 영향을 주지 않도록 합니다.

4. 검사 두 번 반복

   Standard test를 연속으로 두 차례 실행하고 각 테스트 사이에 약 30초를 둡니다. 프록시 출구 위치는 바뀌었는데 DNS에 직접 연결 기준에서 확인한 통신사 이름이 계속 표시되면 명령줄 검사를 진행하세요.

검사 페이지에는 여러 공용 DNS 노드가 함께 표시될 수 있습니다. 공용 DNS는 Anycast를 사용하는 경우가 많아 하나의 서비스가 여러 도시로 분산될 수 있습니다. 따라서 “DNS 도시와 프록시 출구 도시가 다르다”는 사실만으로는 누수라고 할 수 없습니다. 해당 제공업체가 한국 국내의 가정용 인터넷 또는 이동통신망에 속하는지, 프록시를 끌 때 표시된 서버가 그대로 남는지를 중점적으로 비교하세요.

한 브라우저에서만 이상이 나타나고 다른 브라우저의 테스트 결과가 정상이라면 해당 브라우저의 보안 DNS, 확장 프로그램과 백그라운드 연결을 먼저 확인하세요. 이때 곧바로 v2rayN 전역 설정을 변경하면 브라우저 자체의 DNS 동작을 코어 문제로 오인할 수 있습니다.

방법 2: nslookup으로 시스템 DNS와 프록시 DNS 구분

nslookup은 기본적으로 시스템에 설정된 DNS 서버를 직접 호출합니다. 일반 HTTP 시스템 프록시를 켰다고 해서 자동으로 프록시를 통해 요청을 보내지는 않습니다. 따라서 「시스템 프록시 자동 설정」만 활성화한 상태에서 명령 결과에 공유기 주소나 통신사 DNS가 표시되는 것은 정상입니다. 이는 시스템 수준의 UDP 53 요청이 일반 프록시에 의해 처리되지 않았다는 뜻입니다.

Windows 터미널을 열고 먼저 서버를 지정하지 않은 조회를 실행하세요. 출력 상단의 Server와 Address는 현재 시스템 리졸버를 나타냅니다. 흔히 가정용 공유기의 192.168.1.1, 로컬 네트워크 게이트웨이 또는 네트워크 어댑터가 전달한 DNS 주소가 표시됩니다. 그다음 특정 DNS 서버를 지정해 다시 조회하여 현재 네트워크에서 해당 경로가 허용되는지 확인하세요.

ipconfig /flushdns
nslookup example.com
nslookup example.com 1.1.1.1
nslookup -type=AAAA example.com

• 기본 조회에 공유기 주소가 표시됨: 시스템 DNS가 여전히 로컬 네트워크 게이트웨이로 전달되고 있으며, 일반 시스템 프록시가 해당 요청을 처리하지 않은 것입니다.
• 지정한 서버 조회가 시간 초과됨: 네트워크에서 UDP 53을 제한하거나 방화벽이 터미널 요청을 차단했을 수 있습니다. 이것만으로 프록시 노드 장애라고 판단할 수는 없습니다.
• A 레코드는 정상이고 AAAA만 시간 초과됨: 로컬 IPv6 사용 가능 여부와 v2rayN의 조회 정책을 확인하세요. IPv4 DNS만 바꾸어서는 안 됩니다.
• 결과가 짧은 시간 동안 변하지 않음: Windows, 브라우저 또는 Xray 캐시가 사용되었을 수 있습니다. 캐시를 새로 고치고 이전에 방문하지 않은 도메인으로 다시 테스트하세요.

TUN이 시스템 조회를 처리하는지 확인하려면 먼저 TUN을 활성화한 뒤 기본 nslookup을 다시 실행하세요. 이때 Server 필드만 봐서는 안 됩니다. 여전히 기존 네트워크 어댑터 주소가 표시될 수 있기 때문입니다. v2rayN 로그도 함께 열어 UDP 53 요청이 TUN 인바운드로 들어와 DNS 규칙과 매칭되고 예상한 아웃바운드로 전달되는지 확인하세요.

방법 3: v2rayN과 Xray 로그로 경로 확인

로그에서는 두 가지 핵심 사항을 확인할 수 있습니다. 조회가 코어로 들어갔는지, 들어간 뒤 어느 아웃바운드로 나갔는지입니다. v2rayN의 「설정」→「매개변수 설정」→「기본 설정」을 열고 로그 수준을 잠시 info로 조정하세요. 저장한 뒤 코어를 재시작하고 「도움말」→「로그 보기」를 여세요. 버전에 따라 로그 메뉴가 「로그」 또는 「실행 로그 보기」로 표시될 수 있지만, 현재 Xray 인스턴스의 실시간 출력을 확인해야 합니다.

1. 코어 재시작

   메인 창에서 「서버」→「서비스 재시작」을 실행하여 방금 변경한 DNS와 로그 수준이 현재 생성된 설정에 반영되도록 하세요.

2. 새 조회 만들기

   ipconfig /flushdns를 실행한 뒤 이전에 열어 보지 않은 도메인에 접속하세요. 캐시 때문에 로그에 조회 기록이 남지 않는 상황을 피할 수 있습니다.

3. 포트 검색

   로그에서 :53, udp, dns와 대상 도메인을 검색하여 요청이 TUN 인바운드 또는 애플리케이션 프록시 인바운드에서 시작되었는지 확인하세요.

4. 아웃바운드 확인

   로그의 outbound 또는 detour가 예상한 프록시 태그를 가리키는지 확인하세요. direct에 매칭되었다면 라우팅 설정으로 돌아가 DNS 서버 IP와 포트 규칙을 점검합니다.

시스템 프록시 모드에서 브라우저가 SOCKS 또는 HTTP 인바운드로 도메인을 전송하면 Xray이 코어 측에서 해당 도메인을 조회할 수 있습니다. 그러나 애플리케이션이 로컬에서 먼저 도메인을 조회한 뒤 IP 주소를 프록시에 전달하면 로그에는 대상 IP만 표시되어 프록시 요청만으로 원래 도메인을 복원할 수 없습니다. TUN 모드는 더 많은 시스템 트래픽을 처리할 수 있지만 DNS 하이재킹과 라우팅을 올바르게 설정하지 않으면 UDP 53이 일반 트래픽처럼 직접 연결될 수 있습니다.

시스템 프록시 모드에서 원격 DNS와 DNS 아웃바운드 설정

주로 브라우저와 프록시를 명시적으로 지원하는 데스크톱 애플리케이션을 사용한다면 시스템 프록시 모드를 유지해도 됩니다. v2rayN의 「설정」→「DNS 설정」을 열고 Xray에 해당하는 DNS 설정 페이지를 선택하세요. 한국 국내 도메인과 해외 도메인은 나누어 조회할 수 있지만 원격 DNS 서버는 연결 가능성과 라우팅 방향을 모두 충족해야 합니다. 주소만 입력하고 트래픽 경로를 확인하지 않아서는 안 됩니다.

원격 DNS에서 DoH를 사용하면 보통 TCP 443으로 HTTPS 연결을 수립하므로 일반 UDP 53보다 프록시 라우팅에 포함하기 쉽습니다. 설정 후에는 원격 DNS 도메인 자체가 최초 조회를 어떻게 수행하는지도 확인해야 합니다. 해당 도메인의 주소를 찾기 위해 로컬 DNS가 먼저 필요하다면 부트스트랩 의존성이 생깁니다. 안정적으로 연결되는 부트스트랩 리졸버를 사용하거나 관련 DNS 서버 주소가 명확한 규칙에 따라 아웃바운드되도록 설정하세요.

• 조회 정책: 사용 가능한 IPv6가 없는 네트워크에서는 IPv4 우선 정책을 선택하여 AAAA 조회 시간 초과로 최초 연결이 지연되지 않도록 하세요. 듀얼 스택이 필요하다면 A와 AAAA 조회를 모두 유지하고 각각 확인합니다.
• 도메인 정책: 라우팅이 geosite 규칙에 의존한다면 도메인 정보를 최대한 유지하여 조회된 IP만으로 너무 일찍 매칭하지 않도록 하세요.
• DNS 아웃바운드: 내장된 dns-out은 매칭된 DNS 트래픽을 코어의 DNS 모듈로 전달하는 용도이며, 임의의 공용 DNS 주소를 가리키는 별칭이 아닙니다.
• 포트 규칙: 기존 DNS 조회를 처리하려면 UDP/TCP 53을 매칭하세요. DoH는 HTTPS 트래픽이므로 대상 도메인, 대상 IP와 443 포트를 기준으로 프록시 또는 직접 연결을 결정해야 합니다.

「설정」→「라우팅 설정」으로 이동하여 DNS 서버 IP를 direct로 강제하는 높은 우선순위 규칙이 있는지 확인하세요. 원격 DNS를 프록시로 연결할 계획이라면 이러한 규칙이 설정 목표와 충돌합니다. 규칙은 현재 코어와 생성된 설정의 순서에 따라 매칭되므로 변경 후 서비스를 재시작하고 로그에서 최종 아웃바운드 태그를 확인하세요.

TUN 모드로 시스템 수준 DNS 요청 처리

게임 런처, 명령줄 도구와 일부 데스크톱 프로그램은 HTTP 시스템 프록시를 따르지 않습니다. 이러한 프로그램까지 처리하려면 v2rayN 메인 창에서 「Tun모드」를 활성화한 뒤 「설정」→「매개변수 설정」→「Tun모드 설정」을 여세요. v2rayN 7.13.3을 기준으로 TUN 구현, 엄격한 라우팅 모드, MTU와 DNS 처리 관련 옵션을 확인하고 저장한 뒤 코어를 완전히 재시작하세요.

1. 충돌하는 네트워크 어댑터 끄기

   먼저 가상 네트워크 어댑터를 생성하는 다른 네트워크 프로그램을 종료하여 기본 경로, 인터페이스 메트릭과 DNS 처리 규칙이 서로 덮어쓰지 않도록 하세요.

2. 엄격한 라우팅 활성화

   「설정」→「매개변수 설정」→「Tun모드 설정」에서 엄격한 라우팅을 활성화하세요. 그러면 관리 대상 트래픽이 TUN 라우팅 테이블에 따라 처리되어 기존 물리 네트워크 어댑터로 DNS 조회가 우회할 가능성이 줄어듭니다.

3. MTU 확인

   먼저 기본값을 사용하세요. 웹페이지 일부가 로드되지 않으면 1500에서 1400으로 조정한 뒤 다시 테스트할 수 있습니다. MTU는 패킷 전송에 영향을 주므로 DNS 누수의 첫 번째 수정 항목으로 삼아서는 안 됩니다.

4. TUN 다시 생성

   「Tun모드」를 껐다가 다시 켜고 상태 영역에 시작 오류가 없는지 확인하세요. Windows 네트워크 어댑터 목록에 현재 가상 인터페이스가 표시되는지도 확인합니다.

5. UDP 53 확인

   새 nslookup 조회를 실행하고 실시간 로그에서 UDP 53이 TUN 인바운드로 들어와 DNS 처리 규칙에 매칭되는지 확인하세요.

TUN을 켠 뒤 조회가 전혀 되지 않더라도 노드를 계속 바꾸지는 마세요. 방화벽이 v2rayN과 Xray의 네트워크 접근을 허용하는지, 가상 인터페이스에 유효한 경로가 설정되었는지 확인하고 로그에서 조회 시간 초과인지, 규칙 거부인지, TUN 시작 실패인지 구분하세요. 노드 IP에는 연결되지만 노드 도메인을 조회할 수 없다면 부트스트랩 DNS를 중점적으로 점검해야 합니다.

TUN 모드에서 브라우저는 정상인데 nslookup이 시간 초과된다면 DNS 하이재킹이 일부 프로토콜만 처리하거나 엄격한 라우팅이 조회를 차단했을 수 있습니다. UDP 53, TCP 53과 DoH 443을 각각 테스트하고 DNS 규칙이 일반 직접 연결 규칙보다 앞에 있는지 확인하세요. 변경을 완료한 뒤 브라우저 검사도 두 차례 다시 실행해야 하며 TUN 상태 표시만 믿어서는 안 됩니다.

결과를 기준으로 캐시·IPv6·규칙 충돌 확인

DNS를 변경해도 검사 결과가 바로 달라지지 않는 가장 흔한 원인은 캐시입니다. Windows DNS Client, 브라우저, Xray 코어와 상위 리졸버는 각각 독립적인 캐시를 사용합니다. 먼저 브라우저를 닫고 ipconfig /flushdns를 실행한 다음 v2rayN 코어를 재시작하고 방문한 적 없는 도메인으로 테스트하세요. 웹페이지 새로 고침만으로는 새로운 DNS 조회가 발생하지 않을 수 있습니다.

IPv6도 별도로 확인해야 합니다. 시스템이 IPv4로 프록시에 연결하면서도 물리 네트워크 어댑터를 통해 AAAA 조회를 계속 보낼 수 있습니다. 또는 IPv6 주소를 먼저 받았지만 현재 네트워크에 완전한 IPv6 경로가 없어 시간 초과될 수도 있습니다. nslookup -type=AAAA 결과를 로그와 비교하여 조회가 처리되었는지와 반환된 주소에 연결할 수 있는지 확인하세요.

• 브라우저에서만 이상이 발생함:보안 DNS와 브라우저 캐시를 확인하고 전역 라우팅은 먼저 변경하지 마세요.
• nslookup에 로컬 DNS가 표시되고 로그에는 기록이 없음:일반 시스템 프록시가 시스템 조회를 처리하지 않은 것입니다. 전역 처리가 필요하다면 TUN을 확인하세요.
• 로그에 조회가 있지만 direct로 매칭됨:DNS 서버 도메인, IP와 포트에 해당하는 라우팅 우선순위를 조정하세요.
• 로그에 조회가 있고 proxy를 사용하지만 검사 결과가 여전히 이상함:검사 페이지가 브라우저 독립 DoH를 사용하는지 확인하고 다른 브라우저로 비교하세요.
• TUN 활성화 후 모든 요청이 시간 초과됨:가상 네트워크 어댑터, 방화벽, 엄격한 라우팅과 부트스트랩 DNS를 확인하고 노드 지연 시간만을 유일한 판단 기준으로 삼지 마세요.

최종 확인에는 세 가지가 포함되어야 합니다. 브라우저 검사에서 직접 연결 기준에 있던 통신사 리졸버가 더 이상 반복해서 나타나지 않아야 하고, TUN 환경의 새로운 nslookup 조회가 로그에서 추적되어야 하며, Xray 로그에서 DNS 트래픽이 예상한 아웃바운드에 매칭되어야 합니다. 세 결과가 일치하면 임시로 높였던 로그 수준을 원래대로 되돌려 장기적인 로그 용량을 줄이세요.