· 문제 해결 · 약 10분

V2Ray DNS 누수 확인 및 v2rayN DNS 설정 방법

DNS 누수 원인과 확인 방법을 살펴보고, 원격 DNS·로컬 DNS 분할 설정과 FakeIP 옵션을 단계별로 구성해 프록시를 우회하는 도메인 조회를 줄입니다.

핵심 내용

노드에 연결할 수 있지만 도메인 조회도 프록시를 통하는지 확실하지 않은 사용자를 위한 안내입니다. 먼저 브라우저·시스템·코어의 DNS 경로를 구분한 뒤 비교 테스트로 조회 경로를 확인하고, 원격 DNS와 로컬 DNS 분할, TUN 환경의 FakeIP를 설정합니다. 검사 페이지에 주소 하나만 표시되게 하는 것이 아니라, 프록시가 필요한 도메인 조회가 예상한 경로로 전송되도록 하는 것이 핵심입니다.

DNS 누수 판단 기준

DNS는 도메인을 IP 주소로 변환합니다. 웹 연결이 프록시를 이용하더라도 도메인 조회까지 프록시를 통한다는 뜻은 아닙니다. 앱이 먼저 라우터에 주소를 조회한 다음 그 결과를 프록시에 전달할 수 있습니다. 프록시를 통해 조회하려던 도메인이 로컬에서 조회됐다면, 이 경로 이탈을 확인해야 합니다.

앱에서 도메인 요청 조회 경로 선택 DNS 규칙 적용 조회 트래픽 출구 선택 대상 연결 설정

v2rayN은 클라이언트 인터페이스이며, 실제 트래픽 전달과 DNS 조회 방식은 현재 코어와 설정에 따라 달라집니다. 브라우저의 ‘보안 DNS’, Windows 네트워크 어댑터 DNS, 코어 내장 DNS는 서로 다른 조회 경로입니다. 한 곳에만 공용 DNS 주소를 입력해도 나머지 경로까지 같은 방식으로 동작한다고 보장할 수 없습니다.

조회 경로일반적인 경로확인할 사항
Windows 시스템 DNS네트워크 어댑터에 설정된 DNS를 사용하며, 라우터를 먼저 거칠 수 있음시스템 프록시는 일반 UDP DNS를 보통 처리하지 않음
브라우저 보안 DNS브라우저 자체 DoH 서비스클라이언트 DNS 규칙을 우회하는지, 연결 자체가 프록시를 통하는지
코어 내장 DNS설정에 지정된 로컬 또는 원격 DNS 서버DNS 서버 선택과 조회 트래픽 출구가 모두 올바른지
TUN을 통한 DNS 처리가로챈 DNS 요청이 코어로 전달됨DNS 가로채기, 라우팅 범위, 예외 규칙이 적용되는지

일반 DNS는 주로 UDP 또는 TCP의 53 포트를 사용합니다. DoH는 보통 HTTPS의 443 포트, DoT는 일반적으로 853 포트를 사용합니다. 암호화는 전송 내용을 읽기 어렵게 하고 프록시는 트래픽의 출구 경로를 바꿉니다. 둘은 서로 대신할 수 없습니다.

확인 방법: 먼저 비교 기준을 만든 뒤 DNS 서버 확인

DNS 서버 주소와 소속 네트워크를 보여주는 검사 페이지를 준비합니다. 테스트하는 동안 같은 페이지와 브라우저를 사용하고, 한 번에 설정 하나만 변경하세요. 검사 페이지에 표시되는 것은 보통 재귀 DNS 서버가 테스트 도메인에 접속한 출구입니다. 컴퓨터의 공인 IP나 노드의 출구와 반드시 같지는 않습니다.

  1. 기준 결과 기록

    일시적으로 직접 연결해도 되는 환경이라면 먼저 프록시를 끄고 검사 페이지에 표시된 DNS 서버 주소와 통신사를 기록합니다. 직접 연결하기 어렵다면 이 단계는 건너뛰어도 됩니다. 다만 이후 판단은 라우팅 로그를 기준으로 해야 하며, 위치 정보만으로 결론을 내리면 안 됩니다.

  2. 브라우저 설정 분리

    브라우저 설정에서 ‘보안 DNS’를 검색해 사용자 지정 보안 DNS를 잠시 끄고 기존 설정을 기록합니다. 브라우저 자체 DoH가 클라이언트 테스트에 영향을 주는 상황을 줄일 수 있습니다. 테스트가 끝나면 필요에 따라 설정을 복원하세요.

  3. 시스템 프록시 테스트

    v2rayN 트레이 메뉴의 「시스템 프록시」에서 「시스템 프록시 자동 설정」을 선택합니다. 노드와 라우팅 규칙은 그대로 두고 검사를 다시 실행하세요. DNS 서버가 달라지는지 기록하되, 웹페이지가 열린다는 사실만으로 DNS가 처리되고 있다고 판단하지 마세요.

  4. TUN과 비교

    다른 트래픽 가로채기 프로그램을 끈 다음 메인 화면에서 「TUN 사용」을 켭니다. 시스템 안내에 따라 권한을 부여하고 코어가 정상 실행되는지 확인하세요. 캐시를 지운 뒤 다시 검사해 시스템 프록시와 TUN 상태의 조회 결과를 비교합니다.

  5. 로그 확인

    클라이언트 로그에서 테스트 시간대의 DNS 및 라우팅 기록을 확인합니다. 필요한 경우 로그 수준을 잠시 높여 어떤 DNS 서버와 출구를 사용했는지 살펴보세요. 확인 후에는 설정을 원래대로 되돌려 도메인 조회 기록이 장기간 남지 않게 합니다.

Windows PowerShell에서 다음 두 명령으로 시스템 DNS 조회 경로를 확인할 수 있습니다. 첫 번째 명령은 Windows DNS 캐시를 지우고, 두 번째 명령은 일반 DNS 조회를 실행합니다. 이 명령은 v2rayN의 HTTP 또는 SOCKS 프록시를 자동으로 사용하지 않습니다. 브라우저와 코어에 별도 캐시가 남아 있을 수 있으므로 각각 다시 시작하거나 캐시를 지워야 합니다.

ipconfig /flushdns
nslookup example.com

결론: DNS 서버의 지역은 판단 기준이 아닙니다

검사 결과에 현지 통신사 네트워크가 나타나면, 먼저 의도적으로 직접 연결한 도메인 조회인지 확인한 뒤 출구 로그를 살펴보세요. 공용 DNS 서비스는 여러 지역에 분산 배치되므로 가까운 지역이 표시된다는 사실만으로 누수라고 단정할 수 없습니다.

v2rayN 원격 DNS 설정: 주소와 출구를 함께 확인

데스크톱 인터페이스와 코어에 따라 DNS 설정 항목이 다를 수 있습니다. 먼저 「설정」→「DNS 설정」을 열고 현재 사용하는 코어와 해당 설정 화면을 확인하세요. 현재 인터페이스에 이 메뉴가 없다면 설치 패키지의 인터페이스와 설정 메뉴를 먼저 확인해야 합니다. 다른 코어용 설정 텍스트를 그대로 붙여 넣지 마세요.

원격 DNS를 설정하는 목적은 프록시가 필요한 도메인을 예상한 DNS 서비스로 조회하는 것입니다. 예를 들어 https://1.1.1.1/dns-query는 특정 DoH 주소이며 구독 주소나 노드 주소가 아닙니다. 이 주소를 입력한 뒤에도 해당 서비스에 연결하는 트래픽이 프록시 출구를 이용하는지 확인해야 합니다.

  1. 기존 설정 저장

    「설정」→「DNS 설정」의 기존 값과 현재 코어, 라우팅 설정을 기록합니다. 되돌릴 수 있도록 설정 사본을 보관하고, 테스트 전에 기존 DNS 규칙을 삭제하지 마세요.

  2. 원격 DNS 설정

    현재 코어에 해당하는 원격 DNS 항목에 지원되는 DNS 서비스 주소를 입력합니다. 위의 DoH 주소를 사용한다면 입력란에서 IP 주소만이 아니라 전체 HTTPS URL을 받을 수 있는지 확인하세요.

  3. DNS 조회 출구 확인

    DNS 조회의 출구 선택이나 관련 라우팅 규칙을 확인해 원격 DNS 연결이 프록시를 사용하도록 설정합니다. Xray 설정의 https+local://에는 로컬 직접 연결 의미가 있으므로 ‘프록시 강제’ 설정으로 사용하면 안 됩니다.

  4. 재시작 후 다시 테스트

    설정을 저장하고 코어를 재시작한 다음 캐시를 지우고 다시 검사합니다. 웹페이지가 오히려 열리지 않는다면 DNS 시간 초과와 노드 도메인 조회 로그부터 확인하세요. 노드, DNS, 라우팅 모드를 한꺼번에 바꾸지 마세요.

코어 DNS를 올바르게 설정해도 앱이 도메인을 프록시에 전달하는지 확인해야 합니다. 일부 앱은 시스템에서 먼저 도메인을 조회한 뒤 대상 IP를 전달하므로 해당 조회에는 코어 DNS 설정이 적용되지 않을 수 있습니다. 이런 앱까지 처리해야 한다면 원격 DNS 주소를 계속 바꾸기보다 TUN과 DNS 가로채기 설정을 추가로 확인하세요.

로컬 DNS 분할 설정: 직접 연결과 프록시 경계 구분

로컬 DNS가 항상 잘못된 설정은 아닙니다. 로컬 네트워크 기기, 내부 도메인, 직접 연결할 사이트는 접속 가능한 주소를 얻기 위해 로컬 DNS가 필요할 수 있습니다. 중요한 것은 적용 범위를 명확히 제한해 프록시가 필요한 도메인을 로컬 DNS로 조회하지 않도록 하면서 모든 조회를 원격 DNS로 무조건 보내지도 않는 것입니다.

도메인 용도조회 정책확인 방법
로컬 네트워크 기기 및 내부 도메인현재 네트워크의 DNS를 사용하고 로컬 네트워크 직접 연결 유지내부 이름이 올바른 사설 IP 주소로 조회되는지 확인
직접 연결하도록 지정한 사이트도메인 규칙에 따라 로컬 DNS 사용조회와 연결 모두 직접 연결 규칙을 따르는지 확인
프록시를 사용하도록 지정한 사이트원격 DNS를 사용하고 조회 연결은 프록시로 전송DNS 서버 선택과 프록시 출구 로그를 함께 확인
노드 서버 도메인해당 노드 연결에 의존하지 않는 초기 DNS 조회 사용코어 재시작 후 첫 연결이 완료되는지 확인

예를 들어 223.5.5.5는 일부 네트워크 환경에서 로컬 공용 DNS 후보로 사용할 수 있지만, 기업 내부 도메인을 조회하지 못하며 모든 네트워크에 적합한 기본값도 아닙니다. 내부 이름은 현재 네트워크가 제공하는 DNS 서버로 먼저 조회해야 합니다. 내부 도메인을 다룰 때는 해당 네트워크의 사용 규칙도 따라야 합니다.

결론: 검사 결과를 꾸미기보다 도메인 용도에 따라 분할

필요한 로컬 DNS 조회는 유지하고 프록시 대상 도메인의 조회 경로만 제한하세요. 모든 DNS 조회를 프록시로 보내야 하는 환경이라면 해당 로컬 대체 경로를 명확히 끈 뒤 노드 초기 조회와 로컬 네트워크 접속이 여전히 정상인지 확인합니다.

FakeIP와 TUN: 기능 이름보다 실제 처리 범위가 중요

FakeIP는 먼저 앱에 합성 주소를 반환하고, 코어가 도메인과 주소의 매핑을 저장한 뒤 후속 연결을 도메인 기준으로 처리하는 방식입니다. 앱이 실제 IP를 미리 얻어 도메인 정보가 사라지는 문제를 줄일 수 있지만, 독립적인 ‘누수 방지 스위치’는 아닙니다. DNS 조회가 가로채지거나 후속 연결이 코어로 돌아오지 않으면 결과에 영향을 줍니다.

Xray의 관련 기능은 보통 FakeDNS라고 부르며, 다른 코어는 FakeIP 설정 구조가 다릅니다. v2rayN의 TUN 기능에서 사용하는 코어가 일반 프록시 연결에 쓰는 코어와 다를 수도 있으므로 현재 설정과 실행 로그를 기준으로 확인하세요. Xray의 fakedns 필드를 다른 코어의 DNS 설정에 복사하지 마세요.

자주 발생하는 오류와 확인 목록

로그 문구는 코어에 따라 달라집니다. 아래는 자주 보이는 오류 예시입니다. 원인을 찾을 때는 앞뒤 로그도 함께 보고 오류 대상이 DNS 서버인지, 노드 서버인지, 대상 사이트인지 구분하세요. 오류 한 줄만으로 DNS 누수를 확정할 수는 없습니다.

오류: lookup example.com: i/o timeout

원인:도메인 조회가 제한 시간 안에 완료되지 않았습니다. DNS 서버에 연결할 수 없거나 조회 트래픽의 출구가 잘못됐을 수 있습니다.

해결:먼저 현재 DNS 서버 주소와 조회 경로를 확인한 다음 해당 연결이 방화벽이나 라우팅에 차단됐는지 살펴보세요. 인증서 검증을 바로 끄지 마세요.

오류: no such host

원인:현재 조회 경로에서 사용할 수 있는 도메인 결과를 얻지 못했습니다. 도메인 오타, 부정 캐시 또는 잘못된 분할 규칙이 원인일 수 있습니다.

해결:도메인이 유효한지 확인하고 캐시를 지운 뒤 로컬 DNS와 원격 DNS의 결과를 비교하세요. 내부 도메인은 공용 DNS로 잘못 전송되고 있지 않은지 먼저 확인합니다.

오류: network is unreachable

원인:현재 네트워크 스택에 대상 주소로 가는 경로가 없습니다. IPv6, TUN 라우팅 또는 합성 주소 연결 문제일 수 있습니다.

해결:오류에 표시된 대상 주소를 확인하고 네트워크 어댑터와 라우팅 범위를 점검하세요. FakeIP 주소 풀에 속한다면 기존 매핑을 지우고 TUN이 정상 실행 중인지 확인합니다.

설정을 마친 뒤 아래 네 항목을 확인하세요. 브라우저 검사는 현재 브라우저에서 발생한 테스트 트래픽만 확인하며 다른 앱 검사를 대신할 수 없습니다. v2rayNG는 Xray 코어를, v2flyNG는 V2Fly 코어를 사용합니다. Android로 옮길 때는 각 앱의 DNS와 트래픽 처리 설정을 다시 확인해야 하며, 데스크톱 시스템 프록시 테스트 결과를 그대로 적용하면 안 됩니다.

v2rayN 다운로드4개 플랫폼 설치 파일 보기