DNS 유출 점검 및 해결 실전: v2rayN·v2rayNG DNS 유출 방지 설정 가이드

프록시 노드가 연결됨으로 표시된다고 해서 모든 도메인 조회가 프록시 경로를 통과하는 것은 아닙니다. 브라우저, 시스템 서비스, 일반 앱은 보통 웹사이트에 접속하기 전에 도메인을 DNS에 조회합니다. 이 과정이 현재 네트워크의 기본 리졸버에서 처리되고 이후 웹 트래픽만 VMess, VLESS 등의 프록시 아웃바운드로 나가면, 흔히 말하는 DNS 유출이 발생합니다. 점검할 때는 ‘도메인을 누가 조회하는가’와 ‘웹 데이터가 어디로 나가는가’를 별도의 경로로 나누어 확인해야 하며, 출구 주소만 확인해서는 안 됩니다.

이 글 한눈에 보기

노드에는 연결되었지만 점검 페이지에 현지 통신사의 DNS가 계속 표시되거나, TUN으로 전환한 뒤 도메인 시간 초과가 발생하는 v2rayN·v2rayNG 사용자를 위한 글입니다. 점검을 마치면 결과가 실제 유출인지 판단하고, 원격 DNS와 DNS 아웃바운드를 일관되게 설정한 뒤 두 차례 비교 테스트로 해결 여부를 확인할 수 있습니다.

DNS 유출 경로와 판단 기준

일반적인 접속은 도메인 조회, 주소 반환, 라우팅 매칭, 프록시 아웃바운드의 네 단계로 나눌 수 있습니다. 시스템 프록시는 프록시 설정을 지원하는 앱의 트래픽을 주로 처리하지만, 시스템이 UDP 53 포트로 보내는 조회까지 자동으로 가로채지는 않을 수 있습니다. TUN 모드는 가상 네트워크 인터페이스 계층에서 더 많은 연결을 포착할 수 있지만, 명확한 DNS 규칙이 없으면 조회가 잘못 직결 출구로 전송되거나 로컬 DNS와 원격 DNS 사이를 순환할 수 있습니다.

앱이 도메인 요청 DNS 조회 가로채기 원격 조회 규칙 매칭 프록시 아웃바운드

핵심은 리졸버의 소유가 현재 설정과 일치하는지 확인하는 것입니다. 예를 들어 클라이언트에 원격 DNS를 명확히 지정하고 프록시를 통해 점검 페이지에 접속했는데도 현재 유선 또는 이동통신망이 제공하는 리졸버가 반복해서 표시된다면 추가 점검이 필요합니다. 반대로 점검 결과에 서로 다른 도시가 여러 곳 나타난다고 해서 반드시 유출은 아닙니다. 공용 DNS는 애니캐스트 노드를 사용할 수 있고, 점검 사이트가 같은 서비스를 서로 다른 데이터센터로 식별할 수도 있습니다.

시스템 프록시 환경: 브라우저 웹 트래픽은 로컬 HTTP 또는 SOCKS 포트를 통과할 수 있지만, 다른 앱의 UDP 53 조회는 직결될 수 있습니다.
TUN 환경: 가상 네트워크 인터페이스, DNS 하이재킹, 라우팅 규칙, 원격 DNS를 함께 확인해야 하며, 스위치 하나만 켜는 것으로는 충분하지 않습니다.
브라우저 암호화 DNS: 브라우저 자체의 조회 설정이 클라이언트 설정을 우회해 점검 결과와 시스템 설정이 일치하지 않을 수 있습니다.
캐시 환경: 시스템, 브라우저, 클라이언트 모두 이전 응답을 저장할 수 있으므로 설정을 바꾼 직후 한 번 새로 고치는 것만으로는 결론을 내리기 어렵습니다.

온라인 점검: 기준선 확인 후 프록시와 비교하기

점검 전에 네트워크 경로를 바꿀 수 있는 다른 프록시 프로그램을 종료하고 테스트할 클라이언트 하나만 남깁니다. 프록시를 연결하지 않았을 때의 기준선과 노드 연결 후의 비교 결과, 두 가지를 준비하세요. 표준 테스트와 확장 테스트를 각각 실행하는 것이 좋습니다. 확장 테스트는 일반적으로 무작위 서브도메인 조회를 여러 차례 연속으로 수행하므로, 여전히 직결되는 리졸버를 더 쉽게 드러냅니다.

v2rayN 또는 v2rayNG 연결을 해제하고 현재 출구 주소, DNS 서비스 이름, 국가 또는 지역, 감지된 서버 수를 기록합니다.
DNS 캐시를 삭제한 다음 브라우저를 종료했다가 다시 열어 이전 조회 결과가 그대로 사용되지 않게 합니다.
안정적인 노드에 연결하고 일반 웹페이지에 접속할 수 있는지 확인한 뒤 첫 번째 표준 점검을 실행합니다.
확장 점검을 실행하고 모든 조회가 완료될 때까지 기다립니다. 페이지를 막 열었을 때 표시되는 첫 번째 기록만으로 판단하지 마세요.
30초 간격을 두고 한 번 더 테스트해 두 차례 결과가 안정적인지 비교합니다. 이전 기록이 한 건이라도 간헐적으로 나타나면 캐시를 다시 삭제하고 재점검하세요.

관찰 결과	일반적인 의미	다음 단계
설정한 공용 DNS만 표시됨	조회 경로가 대체로 예상과 일치함	브라우저와 다른 앱에서 다시 테스트
기준선에 있던 로컬 리졸버가 표시됨	일부 조회가 여전히 직결될 가능성	DNS 가로채기와 아웃바운드 규칙 확인
브라우저마다 결과가 다름	브라우저의 조회 정책이 별도로 적용될 가능성	브라우저 암호화 DNS 설정 통일
점검 페이지는 시간 초과지만 웹페이지는 정상	무작위 서브도메인 조회가 차단되었을 가능성	코어 로그에서 DNS 시간 초과 확인

재현 가능한 실측 기록에는 시간, 클라이언트 버전, 작동 모드, 결과 수가 포함되어야 합니다. 예를 들어 v2rayN 7.15.4의 시스템 프록시 모드에서 연결 전 로컬 리졸버 2개가 감지되었고, 연결 후에도 같은 2개가 나타났다고 기록할 수 있습니다. TUN으로 전환하고 코어를 재시작한 뒤 두 차례 확장 점검에서 원격 DNS 서비스 한 그룹만 나타났다면, 이러한 전후 비교가 스크린샷 한 장의 결과보다 훨씬 유용합니다.

결론: 유출 여부는 ‘기준선 리졸버가 다시 나타나는지’로 판단

서버 수와 지리적 위치는 보조 지표일 뿐입니다. 가장 직접적인 신호는 프록시 연결 후에도 연결 해제 상태에서 기록한 동일한 로컬 DNS 그룹이 계속 나타나는지 여부입니다.

v2rayN: 원격 DNS, DNS 아웃바운드 및 TUN 설정

다음 단계는 v2rayN 7.15.4 인터페이스를 기준으로 설명합니다. 7.x의 세부 버전에 따라 메뉴 문구가 조금 다를 수 있지만 목표는 같습니다. Xray 코어에 원격 리졸버를 지정하고, DNS 조회가 전용 아웃바운드와 매칭되도록 설정하며, 프록시를 인식하지 못하는 앱까지 처리해야 할 때 TUN을 활성화합니다. 변경 전에 「서버」→「선택한 서버 내보내기」 또는 설정 백업 기능으로 현재 작동하는 설정을 저장하세요.

1단계: 로컬 리스너와 시스템 프록시 확인

「설정」→「매개변수 설정」을 열고 로컬 혼합 리스닝 포트를 기록합니다. 일반적인 기본값은 10808이며, 이미 변경했다면 화면에 표시된 값을 기준으로 하세요.
포트가 다른 프로그램에서 사용 중이지 않은지 확인한 다음 메인 화면으로 돌아가 「시스템 프록시 자동 설정」을 선택합니다.
코어 로그를 열어 인바운드 리스너가 시작되었고 bind 또는 access denied와 같은 오류가 없는지 확인합니다.
먼저 시스템 프록시 모드에서 한 차례 점검을 완료합니다. 브라우저는 정상인데 다른 앱에서 여전히 유출된다면 TUN 설정으로 넘어가며, 모든 옵션을 동시에 변경하지 마세요.

2단계: 원격 리졸버 지정

「설정」→「DNS 설정」으로 이동해 현재 사용하는 Xray DNS 설정을 선택합니다. 원격 DNS는 암호화 조회를 지원하는 주소나 일반 IP 리졸버를 사용할 수 있습니다. 중요한 것은 이후 라우팅이 해당 조회를 예상한 프록시 아웃바운드로 전달하도록 하는 것입니다. 다음 예시는 필드 관계를 이해하기 위한 것이며, 실제 저장 시에는 클라이언트가 생성한 구조를 기준으로 하세요.

{
  "dns": {
    "hosts": {
      "dns.google": "8.8.8.8"
    },
    "servers": [
      {
        "address": "https://1.1.1.1/dns-query",
        "domains": [
          "geosite:geolocation-!cn"
        ]
      },
      "223.5.5.5"
    ],
    "queryStrategy": "UseIP"
  }
}

queryStrategy는 반환할 주소 체계의 우선순위를 제어합니다. 안정적인 IPv4만 사용할 수 있는 네트워크라면 UseIPv4를 사용하고, 듀얼 스택 환경이라면 UseIP를 유지할 수 있습니다. 연결할 수 없는 IPv6 정책을 선택하면 ‘유출 감지’가 아니라 도메인 조회 지연, 로그의 시간 초과, 일부 웹사이트 접속 불가로 나타나는 경우가 많습니다.

3단계: DNS 아웃바운드와 TUN 확인

라우팅 설정에서 DNS 조회가 기본 직결 규칙에 들어가지 않는지 확인합니다. 전용 DNS 아웃바운드를 사용할 때는 해당 인바운드 태그 또는 포트 규칙이 그 아웃바운드를 가리키도록 설정해야 합니다.
「설정」→「매개변수 설정」→「TUN 모드」로 이동해 가상 네트워크 인터페이스를 활성화한 뒤 코어를 다시 시작합니다. 처음 활성화할 때는 시스템 권한 확인이 필요할 수 있습니다.
DNS 하이재킹이 53 포트를 대상으로 하는지 확인하고, 로컬 네트워크에 필요한 조회 범위는 유지하세요. 기업 내부 도메인을 무조건 공용 DNS로 보내서는 안 됩니다.
로그에서 DNS 요청이 원격 서버의 응답으로 처리되는지 확인합니다. 완료 후 캐시를 삭제하고 확장 점검을 두 차례 실행하세요.

오류:failed to find an available destination

원인 및 해결: 노드 도메인 또는 DNS 서버 주소에서 사용할 수 있는 결과를 얻지 못했습니다. 먼저 노드 주소의 철자를 확인하고 조회 정책을 일시적으로 UseIPv4로 변경한 뒤 저장하고 Xray 코어를 재시작하세요.

오류:lookup dns.google: i/o timeout

원인 및 해결: 원격 리졸버 연결이 시간 초과되었습니다. DNS 요청이 잘못 직결 출구로 전달될 때 흔히 발생합니다. DNS 아웃바운드 태그와 라우팅 매칭 순서를 확인한 뒤 안정적인 다른 경로로 다시 테스트하세요.

오류:bind: Only one usage of each socket address is normally permitted

원인 및 해결: 로컬 리스닝 포트가 이미 사용 중입니다. 「설정」→「매개변수 설정」에서 혼합 포트를 10808에서 사용하지 않는 포트로 변경하고 시스템 프록시도 함께 갱신한 뒤 코어를 재시작하세요.

v2rayNG: 안드로이드 VPN DNS 및 로컬 DNS 설정

v2rayNG는 시스템 VPN 인터페이스를 통해 트래픽을 처리하며, DNS가 터널을 통과하는지는 VPN DNS, 로컬 DNS, 원격 DNS, 라우팅 설정에 따라 달라집니다. 다음은 v2rayNG 1.10.16을 기준으로 설명합니다. 시작 전에 구독을 한 번 업데이트하고 사용할 수 있는 노드를 선택한 뒤, 코어 유형이 Xray인지 확인하고 현재 라우팅 모드를 기록하세요. 노드 불량을 DNS 문제로 잘못 판단하는 일을 피할 수 있습니다.

1단계: VPN DNS 입력

오른쪽 상단 메뉴의 「설정」→「VPN DNS」로 이동해 사용할 리졸버 주소를 입력합니다. 예: 1.1.1.1
「설정」→「원격 DNS」로 이동해 프록시 도메인 조회에 사용할 서버를 설정합니다. 암호화 DNS 주소를 사용할 때는 해당 도메인 자체가 초기 조회를 완료할 수 있는지 확인하세요.
네트워크 환경에 맞춰 「도메인 전략」을 확인합니다. 안정적인 IPv4만 사용할 수 있다면 IPv4를 우선해 연결할 수 없는 AAAA 주소로 인해 접속이 느려지지 않도록 하세요.
메인 화면으로 돌아가 연결을 해제한 후 다시 연결해 VPN 인터페이스와 DNS 매개변수를 새로 생성합니다.

2단계: 로컬 DNS 사용 여부 결정

「로컬 DNS 활성화」는 모든 조회를 단순히 기기에 남겨 두는 기능이 아닙니다. 클라이언트가 설정에 따라 앱 요청을 처리한 뒤 원격 또는 직결 리졸버를 선택하도록 하는 기능입니다. 활성화한 뒤에는 국내 DNS, 원격 DNS, 도메인 규칙을 함께 확인해야 합니다. 스위치만 켜고 충돌하는 라우팅을 그대로 두면 같은 도메인이 두 리졸버에 차례로 요청될 수 있습니다.

설정 항목	권장 확인값	이상 증상
VPN DNS	현재 네트워크에서 연결 가능한 주소 입력	연결 후 모든 도메인을 조회할 수 없음
원격 DNS	프록시 도메인 규칙과 함께 설정	점검 결과에 로컬 리졸버가 계속 표시됨
도메인 전략	실제 IPv4·IPv6 연결 상태와 일치	처음 웹페이지를 여는 데 5~10초 소요
라우팅 모드	테스트 중에는 규칙을 고정	모드 전환 후 결과를 비교할 수 없음

설정을 마친 뒤 먼저 연결을 10초간 해제했다가 다시 시작합니다. 코어 로그에서 DNS timeout이 계속 나타나는지 확인하세요. 웹페이지가 열리면 같은 브라우저로 두 차례 연속 점검을 실행하고, 이어서 다른 일반 앱에서 새 도메인에 접속해 브라우저 자체의 암호화 DNS만 작동한 것이 아닌지 확인합니다.

해결 후 검증 및 흔한 이상 현상

검증 단계에서는 노드, 라우팅, DNS를 계속 변경하지 마세요. 한 경로, 한 브라우저, 한 점검 절차를 고정해야 어떤 설정이 효과를 냈는지 확인할 수 있습니다. 매번 결과를 ‘모드, 리졸버 수, 기준선 리졸버 표시 여부, 첫 접속 시간’ 네 가지로 기록하는 것이 좋습니다.

시스템 DNS 캐시를 삭제합니다. 데스크톱에서는 네트워크를 다시 연결하거나 시스템에서 제공하는 새로 고침 작업을 실행할 수 있습니다. 안드로이드에서는 VPN 연결을 해제한 뒤 네트워크를 한 번 전환하고 다시 연결하세요.
브라우저의 모든 창을 닫았다가 다시 열고, 먼저 이전에 열어 보지 않은 도메인에 접속해 캐시가 바로 사용되지 않도록 합니다.
표준 점검과 확장 점검을 각각 두 차례 실행하고, 테스트 간격은 최소 30초로 둡니다.
코어 로그에서 연속적인 조회 시간 초과, 순환 조회, 잘못된 아웃바운드로 라우팅된 기록이 없는지 확인합니다.
다른 네트워크 환경으로 전환한 뒤 테스트를 반복합니다. 특정 네트워크에서만 유출된다면 해당 네트워크의 DNS 하이재킹 또는 IPv6 경로를 확인하세요.

오류:context deadline exceeded

원인 및 해결: 제한 시간 내에 암호화 DNS 요청이 완료되지 않았습니다. 먼저 현재 프록시 아웃바운드를 통해 해당 주소에 접속할 수 있는지 확인하고, 병렬로 설정한 리졸버 수를 줄인 뒤 코어를 재시작해 다시 테스트하세요.

오류:network is unreachable

원인 및 해결: 설정에서 현재 네트워크로 연결할 수 없는 주소 체계를 반환했습니다. 도메인 전략을 실제 네트워크에 맞게 조정하고 TUN 라우팅이 로컬 네트워크 대역을 잘못 가로채고 있지 않은지 확인하세요.

연결은 정상인데 왜 점검 페이지에는 로컬 DNS가 표시되나요?

먼저 브라우저에서 별도로 사용하는 암호화 DNS를 끄고 캐시를 삭제한 뒤 다시 테스트하세요. 결과가 그대로라면 v2rayN의 DNS 아웃바운드와 TUN 하이재킹, 또는 v2rayNG의 VPN DNS와 원격 DNS가 동시에 적용되고 있는지 확인합니다.

TUN을 켠 뒤 모든 웹페이지에서 주소를 찾을 수 없다고 표시되나요?

코어 로그에 DNS timeout이 나타나는지 확인하고, 53 포트를 가로챈 뒤 사용할 수 있는 아웃바운드가 있는지 확인합니다. v2rayN에서는 가상 네트워크 인터페이스 권한도 확인한 뒤 변경 후 코어를 종료하고 다시 시작하세요.

공용 DNS가 세 개 감지되었는데 여전히 유출인가요?

반드시 그렇지는 않습니다. 프록시를 연결하지 않았을 때의 기준선과 비교했을 때 로컬 리졸버가 지속적으로 다시 나타나지 않고, 세 결과가 모두 설정에서 사용하는 공용 리졸버 서비스라면 개수만으로 유출을 판단할 수 없습니다.

구독 업데이트는 성공했는데 노드 연결 시 도메인 조회 실패가 표시되나요?

구독 주소와 노드 서버 주소는 서로 독립적으로 조회됩니다. 노드 도메인의 철자, 원격 DNS 연결 가능성, 도메인 전략을 확인하고 필요하면 먼저 UseIPv4로 전환한 뒤 코어를 재시작하세요.

브라우저 점검은 정상인데 다른 앱도 확인해야 하나요?

확인해야 합니다. 브라우저가 자체 암호화 DNS를 사용할 수 있기 때문입니다. TUN 연결을 유지한 상태에서 다른 앱으로 새 도메인에 접속하고 코어 로그에 해당 조회가 나타나는지 확인해야 시스템 전체가 조회를 가로채는지 알 수 있습니다.

설정 선택: 분할 라우팅, 내부 도메인, 안정성

DNS 유출을 막는다고 해서 모든 도메인을 하나의 공용 리졸버로 강제할 필요는 없습니다. 가정용 스토리지, 프린터, 기업 내부 서비스는 로컬 DNS에 의존할 수 있으며, 이를 모두 원격 서버로 보내면 이름 조회에 실패합니다. 더 안정적인 방법은 도메인과 네트워크 대역을 그룹으로 나누는 것입니다. 내부 도메인은 로컬 리졸버로, 프록시 도메인은 원격 리졸버로 보내고, 조회 요청은 해당 라우팅 규칙에 따라 직결 또는 프록시 아웃바운드로 전달합니다.

내부 도메인에는 명확한 로컬 조회 규칙을 유지하고, 모든 접미사를 포괄하는 광범위한 규칙은 사용하지 마세요.
GeoSite 규칙은 도메인 집합 매칭을, GeoIP 규칙은 대상 주소 매칭을 담당하며, 둘 다 DNS 아웃바운드 설정을 대신할 수 없습니다.
VMess와 VLESS는 노드 연결 방식을 설명할 뿐, 시스템 DNS를 누가 처리할지 자동으로 결정하지 않습니다.
v2rayN은 먼저 시스템 프록시로 단일 앱을 검증한 다음 TUN으로 처리 범위를 넓히는 방식이 적합합니다.
v2rayNG에서는 VPN DNS, 원격 DNS, 도메인 전략, 라우팅 모드를 하나의 설정 묶음으로 함께 확인해야 합니다.

결론: 먼저 DNS 경로를 고정한 뒤 분할 라우팅을 최적화

먼저 두 차례의 점검에서 기준선 리졸버가 더 이상 나타나지 않고 로그에도 시간 초과가 없는지 확인하세요. 그다음 국내외 도메인 분할 라우팅과 로컬 네트워크 예외를 추가하면 문제 해결 경로가 짧아집니다.

해결 후 첫 조회 시간이 약 200ms에서 수 초로 늘었다면 원격 DNS가 우회 경로를 사용하는지, 암호화 DNS 주소를 다시 조회해야 하는지, 라우팅이 순환하는지를 우선 확인하세요. 안정적인 설정은 세 가지를 동시에 만족해야 합니다. 점검 결과를 재현할 수 있고, 자주 사용하는 도메인의 조회 속도가 정상이며, 네트워크를 전환한 뒤에도 올바른 DNS 경로를 다시 구성할 수 있어야 합니다. 점검 페이지에 특정 지역이 표시되는 것만 좇고 시간 초과와 호환성을 무시하면 DNS 유출 문제가 접속 장애로 바뀔 수 있습니다.