V2Ray DNS 누출 확인 방법: 원격 DNS·FakeDNS·TUN 설정 가이드

이 글의 핵심

구독을 가져왔고 웹사이트에도 접속되지만 DNS 테스트 결과가 이상한 사용자를 위한 안내입니다. 정상적인 직접 연결 DNS와 의도치 않은 우회를 구분하고, 시스템 조회·코어 로그·네트워크 어댑터 패킷 캡처로 교차 확인합니다. 이어서 원격 DNS와 직접 연결 DNS의 역할을 나누고, TUN 적용 범위와 FakeDNS 도메인 복원 경로를 점검합니다. 예시 설정은 코어 설정 일부이며 클라이언트 설정 파일 전체를 대체할 수 없습니다.

1. DNS 누출이란? DNS 조회 경로와 접속 경로가 일치하지 않는 경우

DNS는 도메인 이름을 IP 주소로 변환합니다. 프록시 연결이 성립했다고 해서 그 전에 이루어진 도메인 조회까지 프록시를 통과한 것은 아닙니다. 예를 들어 앱이 먼저 가정용 공유기에 대상 IP를 조회한 뒤 연결을 로컬 프록시 포트로 보내면, 웹페이지 접속은 프록시를 거친 것처럼 보여도 로컬 DNS 서버에는 방문한 도메인이 남을 수 있습니다. 누출 여부는 로컬 DNS 서버가 보였는지만으로 판단하지 말고, 조회가 사전에 정한 분할 라우팅 정책을 어겼는지 확인해야 합니다.

앱에서 도메인 조회 DNS 규칙 확인 조회 경로 선택 대상 주소 반환 연결 규칙 확인

중국 본토 웹사이트를 정책에 따라 직접 연결한다면 직접 연결 DNS를 사용하는 것이 일반적입니다. 반면 프록시로 접속해야 하는 도메인의 조회가 로컬 네트워크 DNS 서버로 전송된다면, 바로 이런 우회를 차단해야 합니다. VMess와 VLESS는 프록시 전송을 담당할 뿐 시스템의 모든 DNS 요청을 자동으로 처리하지 않습니다. 구독에 노드 설정이 포함되어 있어도 로컬 DNS 정책 전체가 제공되는 것은 아닙니다.

작동 방식	놓치기 쉬운 DNS 조회 경로	확인할 항목
시스템 프록시	시스템 프록시를 사용하지 않는 프로그램은 시스템 DNS를 그대로 사용할 수 있음	앱이 로컬에서 먼저 조회하는지, 자체 DNS를 사용하는지
SOCKS 프록시	앱이 도메인 대신 IP만 전달함	앱에서 프록시 측 도메인 조회를 활성화했는지
TUN 적용	라우팅 제외 규칙·IPv6·앱 내 암호화 DNS를 통한 우회	가상 네트워크 어댑터, DNS 가로채기, 출구 규칙이 모두 적용되는지

2. DNS 누출 확인 방법: 기준 상태를 기록하고 실제 네트워크 어댑터 점검

브라우저 테스트 페이지에는 페이지가 관찰한 재귀 DNS 서버의 출구가 표시되며, 클라이언트가 직접 연결한 서버와 다를 수 있습니다. 공용 DNS는 지역별로 다른 출구를 사용할 수 있고, 표시된 도시는 오래된 IP 데이터베이스를 기반으로 할 수도 있습니다. 따라서 “DNS 서버의 도시와 노드의 도시가 다르다”는 사실만으로 누출을 단정하지 마세요. DNS 요청이 어떤 네트워크 어댑터를 거치는지와 현재 규칙에 맞는지를 함께 확인해야 합니다.

기존 DNS에서 사용하는 UDP/TCP 포트

443

DoH에서 주로 사용하는 HTTPS 포트

853

DoT에서 주로 사용하는 TLS 포트

기준 상태를 기록합니다. TUN과 시스템 프록시를 끄고 시스템 DNS 주소, 브라우저의 보안 DNS 상태, 테스트 페이지에 표시된 DNS 서버를 기록합니다. 테스트 중에는 민감한 웹사이트에 접속하지 마세요.
변수를 고정합니다. 같은 노드와 같은 라우팅 규칙을 사용해 같은 페이지를 테스트합니다. 노드를 바꾸면서 브라우저 DNS 설정까지 변경하면 결과에 영향을 준 설정을 찾기 어렵습니다.
캐시를 비웁니다. Windows 터미널에서 ipconfig /flushdns를 실행한 뒤 브라우저를 완전히 종료하고 다시 엽니다. 코어에 내장된 DNS 캐시는 코어를 재시작해야 지워지는 경우가 많습니다.
시스템 DNS 요청을 확인합니다. 아래 명령을 실행해 기본 DNS 서버와 조회 결과를 기록합니다. 이 결과는 시스템의 DNS 조회 경로를 확인하는 용도이며, 브라우저도 같은 경로를 사용한다는 뜻은 아닙니다.
실제 네트워크 어댑터를 확인합니다. 패킷 캡처 도구에서 현재 인터넷에 연결된 이더넷 또는 Wi-Fi 어댑터를 선택해 대상 DNS 요청이 로컬 DNS 서버로 직접 전송되는지 확인합니다. 가상 어댑터에 DNS 패킷이 보인다는 것만으로 패킷이 장치 밖으로 나갔다고 볼 수는 없습니다.

ipconfig /all
ipconfig /flushdns
nslookup example.com

# 패킷 캡처 표시 필터: 기존 DNS 및 일반적인 DoT 연결 확인
udp.port == 53 || tcp.port == 53 || tcp.port == 853

example.com은 조회 방법을 설명하기 위한 예시 도메인이며 DNS 누출 테스트 서비스가 아닙니다. 실제로 다시 테스트할 때는 설정상 프록시를 거쳐야 하는 도메인을 선택하세요. 브라우저 내장 DoH는 HTTPS를 사용하므로 53번 포트 필터만으로는 확인할 수 없습니다. 브라우저의 보안 DNS 설정, 연결 대상 주소, 클라이언트 라우팅 로그를 함께 살펴보세요.

결론: DNS 서버 개수가 아니라 대상 도메인의 우회 여부로 판단하세요

먼저 프록시를 사용하도록 명확히 설정된 테스트 도메인을 선택하세요. 실제 네트워크 어댑터에서 해당 도메인의 평문 DNS 요청이 로컬 DNS 서버로 전송되는 것이 확인되면 시스템 DNS, 앱 자체 DNS, TUN 제외 규칙을 차례로 점검합니다. 공용 DNS 서버가 여러 개 표시되면 먼저 같은 서비스에서 제공하는 서버인지 확인하세요.

3. v2rayN 원격 DNS와 직접 연결 DNS: DNS 서버와 요청 경로 설정

v2rayN에서 먼저 ‘설정’ → ‘매개변수 설정’을 열어 현재 코어와 수신 설정을 확인한 뒤, ‘설정’ → ‘DNS 설정’에서 해당 코어의 DNS 설정을 점검합니다. 버전에 따라 메뉴 위치와 항목 이름이 다를 수 있으므로 현재 화면과 생성된 설정을 기준으로 확인하세요. 특히 일반 프록시 코어와 TUN 코어를 구분해야 합니다. 한 코어용 DNS JSON을 다른 코어의 설정 영역에 붙여 넣지 마세요.

원격 DNS는 프록시로 접속해야 하는 도메인에, 직접 연결 DNS는 명확히 직접 접속하는 도메인에 사용합니다. 원격 DNS 서버를 설정하는 것만으로는 충분하지 않습니다. DNS 서버 연결 요청이 계속 직접 연결로 나가면 암호화 조회를 사용하더라도 “DNS 조회가 프록시 출구를 따른다”는 목표를 달성하지 못합니다. DoH는 DNS 서버까지의 연결을 보호하지만 프록시 출구를 자동으로 선택해 주지는 않습니다.

먼저 노드 도메인의 초기 조회를 해결합니다. 노드 서버 주소가 도메인 이름이라면 프록시 연결을 시작하기 전에 사용할 수 있는 IP 주소를 확인해야 합니다. 노드 도메인에 접근 가능한 초기 DNS 조회 경로를 별도로 지정해 “프록시에 연결해야 노드를 조회할 수 있고, 노드를 조회해야 프록시에 연결할 수 있는” 순환을 방지하세요.
직접 연결 DNS의 범위를 제한합니다. 직접 연결이 명확한 도메인만 직접 연결 DNS로 보내고, 모든 조회가 실패했을 때 무조건 사용하는 대체 DNS로 설정하지 마세요.
규칙 순서를 확인합니다. DNS 서버 출구 규칙은 먼저 적용될 수 있는 광범위한 직접 연결 규칙보다 앞에 배치해야 합니다. 라우팅은 일반적으로 순서대로 규칙을 확인하며, 먼저 일치한 규칙이 경로를 결정합니다.

Xray DNS 설정 예시: 직접 연결 도메인을 따로 매칭하고 나머지는 원격 조회

아래는 Xray 설정 형식의 예시입니다. geosite:cn 분류를 사용하려면 geosite.dat가 필요합니다. 규칙 데이터가 없다면 먼저 데이터 파일을 복구하거나 직접 지정한 도메인 목록을 사용하세요. 예시 주소는 역할을 설명하기 위한 것이므로 현재 네트워크에서 연결 가능한지 확인해야 합니다. disableFallbackIfMatch는 매칭된 도메인 그룹의 조회가 실패했을 때 다른 DNS 서버로 전환되는 것을 제한하지만, 브라우저나 앱이 자체적으로 보내는 조회까지 제어하지는 않습니다.

{
  "dns": {
    "queryStrategy": "UseIP",
    "disableFallbackIfMatch": true,
    "servers": [
      {
        "address": "223.5.5.5",
        "domains": ["geosite:cn"],
        "skipFallback": true
      },
      {
        "address": "https://1.1.1.1/dns-query"
      }
    ]
  }
}

다음 규칙도 기존 routing.rules에 병합해야 하며 전체 라우팅 설정을 대체하면 안 됩니다. 이 예시는 설정에 proxy와 direct라는 태그의 출구가 있다고 가정합니다. 클라이언트가 생성한 태그가 다르면 실제 태그를 사용해야 합니다. 예시는 DNS 서버 IP를 기준으로 출구를 선택하므로 해당 IP로 향하는 다른 연결에도 영향을 줍니다. 실제 설정에 적용하기 전에 기존 규칙과 함께 검토하세요.

{
  "routing": {
    "rules": [
      {
        "type": "field",
        "ip": ["1.1.1.1/32"],
        "outboundTag": "proxy"
      },
      {
        "type": "field",
        "ip": ["223.5.5.5/32"],
        "outboundTag": "direct"
      }
    ]
  }
}

4. TUN 모드로 DNS 누출 방지: 트래픽 적용 후 DNS와 IPv6도 점검

TUN은 시스템 트래픽을 가상 네트워크 어댑터로 전달하므로 시스템 프록시를 사용하지 않는 앱을 처리할 때 유용합니다. 하지만 모든 요청을 반드시 프록시로 보내는 스위치는 아닙니다. 직접 연결과 프록시 연결 중 어느 쪽을 사용할지는 여전히 라우팅 규칙에 따라 결정됩니다. DNS를 가로채 제어된 조회 경로로 보내는지도 TUN 설정에 달려 있습니다. 기존 설정을 먼저 저장한 다음 v2rayN 메인 화면에서 ‘TUN 사용’을 켜고, 시스템에서 요구하는 권한을 허용한 뒤 시작 로그를 확인하세요.

가상 네트워크 어댑터가 생성됐는지 확인합니다. 코어가 시작되지 않으면 DNS 설정을 바꿔 시작 오류를 가리려 하지 말고 권한, 드라이버 또는 설정 오류부터 해결하세요.
DNS가 TUN으로 전달되는지 확인합니다. TUN 설정에 적용 가능한 DNS 가로채기 또는 리디렉션 규칙이 있는지 확인하고, 시스템 DNS 조회와 패킷 캡처로 검증하세요. 네트워크 어댑터의 DNS 주소만 바꿔서는 DNS 서버 주소가 앱에 고정된 경우까지 제어할 수 없습니다.
라우팅 제외 규칙을 확인합니다. 필요에 따라 로컬 네트워크 연결을 직접 연결로 처리할 수 있지만, 제외 범위 때문에 프록시를 사용해야 하는 DNS 요청까지 빠져나가지 않는지 확인하세요. 원격 DNS 서버 주소가 지나치게 넓은 직접 연결 규칙에 먼저 매칭되지 않는지도 점검해야 합니다.
IPv6도 함께 확인합니다. IPv4 트래픽이 TUN으로 들어간다고 IPv6도 자동으로 적용되는 것은 아닙니다. IPv6 기본 경로와 DNS 서버를 확인하세요. IPv6가 필요하지 않다면 영향을 받는 범위를 확인한 뒤 비교 테스트를 위해 일시적으로 끌 수 있지만, IPv6 비활성화를 일반적인 해결책으로 간주해서는 안 됩니다.
네트워크 재연결과 절전 모드 복귀 후에도 확인합니다. Wi-Fi를 바꾸거나 절전 모드에서 복귀한 뒤 다시 조회하세요. 네트워크 어댑터의 DNS, 시스템 라우팅, 가상 어댑터 상태가 달라질 수 있습니다.

v2rayN의 TUN은 sing-box 코어를 사용할 수 있으며, 해당 코어의 DNS 및 FakeIP 설정 구조는 Xray의 FakeDNS와 다릅니다. 해당 설정 화면이나 코어 형식에 맞춰 구성하세요. v2rayNG는 Xray를, v2flyNG는 V2Fly를 사용하지만 Android VPN 적용 범위, 앱 제외, DNS 동작은 클라이언트 설정의 영향을 받습니다. 데스크톱용 JSON을 Android 설정 화면에 그대로 입력할 수는 없습니다.

결론: 먼저 TUN 적용 범위를 확인한 다음 DNS 기능을 추가하세요

먼저 대상 앱의 IPv4·IPv6 트래픽과 DNS 조회가 모두 예상한 처리 경로로 들어가는지 확인한 뒤 FakeDNS를 검토하세요. 브라우저만 정상이고 다른 프로그램은 계속 우회한다면 노드를 계속 바꾸기보다 앱 제외 설정, 앱에 고정된 DNS 서버, 프록시 측 도메인 조회 옵션을 점검하세요.

5. FakeDNS 설정 방법: 같은 경로에서 가상 주소를 도메인으로 복원해야 합니다

FakeDNS는 웹사이트의 실제 IP를 반환하지 않고 주소 풀에 있는 매핑 주소를 반환합니다. 앱이 이 주소로 연결하면 코어가 매핑 정보를 이용해 원래 도메인을 복원한 다음 도메인 라우팅과 프록시 연결을 수행합니다. 이 기능은 실제 IP를 미리 조회해야 하는 상황을 줄여 주지만 암호화 DNS는 아니며, 단독으로 DNS 누출을 막아 주지도 않습니다. 노드 도메인의 초기 조회, 직접 연결 대상, 제어되지 않는 앱의 DNS는 별도로 처리해야 합니다.

대상 도메인 조회 매핑 주소 할당 앱에서 연결 시작 코어에서 도메인 복원 프록시 규칙 적용

다음은 해당 기능을 지원하는 Xray 코어의 설정 예시입니다. 198.18.0.0/15는 이러한 매핑에 흔히 쓰이는 벤치마크 주소 대역으로, 웹사이트의 실제 주소가 아닙니다. 사용 전에 로컬 네트워크, 다른 VPN 또는 기존 라우팅과 충돌하는지 확인하세요. poolSize는 매핑 풀의 용량을 뜻하며 네트워크 속도나 동시 연결 수를 의미하지 않습니다.

{
  "fakedns": [
    {
      "ipPool": "198.18.0.0/15",
      "poolSize": 65535
    }
  ],
  "dns": {
    "servers": ["fakedns"]
  }
}

이후 연결을 받는 관련 인바운드에도 FakeDNS 도메인 복원 기능이 있어야 합니다. 예를 들어 아래 스니핑 필드를 해당 인바운드에 설정할 수 있습니다. 기존 인바운드 객체에 병합해야 하며 독립 인바운드로 사용할 수 없습니다. 이 예시는 ‘매핑 생성 및 복원’만 보여 주며 DNS 트래픽 유입, 노드 초기 조회, 직접 연결 도메인 예외 규칙은 포함하지 않습니다.

{
  "sniffing": {
    "enabled": true,
    "destOverride": ["fakedns"],
    "metadataOnly": true
  }
}

주소 풀 트래픽을 가로채야 합니다. 앱이 매핑 주소를 받은 뒤 연결을 실제 네트워크 어댑터로 직접 보내면, 존재하지 않는 공용 IP에 접속을 시도하게 됩니다.
매핑을 생성한 인스턴스에서 연결을 복원할 수 있어야 합니다. 한 인스턴스에서 매핑을 만들고 그 매핑 정보를 갖고 있지 않은 다른 인스턴스에 연결을 전달하면 안 됩니다.
직접 연결 트래픽에는 실제 IP 조회가 필요할 수 있습니다. 도메인을 복원한 뒤 직접 연결 출구가 실제 IP를 조회해야 한다면, 이 조회도 직접 연결 DNS 정책에 따라 처리해야 합니다.
재시작 후 캐시를 비웁니다. 코어를 다시 시작하면 기존 매핑이 사라질 수 있지만 앱에는 이전 주소가 캐시되어 있을 수 있습니다. 시스템과 앱의 캐시를 지운 뒤 다시 조회해 오래된 매핑을 노드 오류로 오해하지 않도록 하세요.

6. 자주 발생하는 DNS 오류: 어느 단계에서 실패했는지 먼저 확인

아래는 로그에 나타날 수 있는 오류 일부입니다. 전체 오류 메시지의 접두어와 표현은 코어 버전에 따라 다를 수 있으며, 한 줄의 오류만으로는 원인을 확정할 수 없습니다. 다시 테스트할 때는 한 번에 설정 하나만 바꾸고, 오류가 노드 연결·원격 DNS 연결·대상 웹사이트 연결 중 어느 단계에서 발생했는지 기록하세요.

오류: `failed to lookup ip for domain`

원인과 해결 방법: 도메인 조회에서 사용할 수 있는 주소를 얻지 못했습니다. 조회에 실패한 도메인이 노드 주소인지 접속 대상인지 먼저 확인한 다음, 해당 DNS 서버의 연결 상태와 도메인 매칭 규칙, IPv4·IPv6 조회 정책을 점검하세요.

오류: `context deadline exceeded`

원인과 해결 방법: 제한 시간 안에 작업이 완료되지 않았다는 뜻이며 DNS에만 해당하는 오류는 아닙니다. 앞뒤 로그를 확인해 DNS 조회 중에 발생했는지 파악한 다음 DNS 서버의 출구, 연결 시간 초과, 초기 조회 순환 문제를 점검하세요.

오류: `network is unreachable`

원인과 해결 방법: 현재 네트워크에서 대상 주소로 연결할 수 있는 경로를 찾지 못했습니다. 오류에 표시된 IP 주소 유형, TUN 라우팅, 출구 인터페이스를 확인하세요. 특히 IPv6 조회 결과만 있고 네트워크에는 IPv6 경로가 없는 경우를 살펴보세요.

오류: `no such host`

원인과 해결 방법: 사용한 DNS 경로에서 호스트 이름을 확인하지 못했습니다. 도메인 철자, 시스템 DNS 서버, 노드 초기 조회 경로를 확인하세요. 이 메시지만으로 원격 DNS가 차단됐다고 단정하지 마세요.

7. 재테스트 FAQ: 브라우저가 정상이어도 전체 기기가 정상인 것은 아닙니다

테스트 페이지에 로컬 DNS 서버가 표시되면 반드시 누출인가요?

그렇지는 않습니다. 테스트한 도메인이 규칙에 따라 직접 연결되는 대상인지, 브라우저의 보안 DNS 설정은 어떤지 먼저 확인하세요. 프록시를 사용해야 하는 도메인이라면 실제 네트워크 어댑터에서 해당 도메인의 평문 DNS 요청을 찾아보세요. 정책에 따라 직접 연결하도록 설정한 중국 본토 도메인의 조회는 같은 종류의 문제로 볼 수 없습니다.

DoH를 켰는데도 DNS 조회가 로컬 네트워크로 나가는 이유는 무엇인가요?

DoH는 DNS 요청을 전송하는 방식을 바꿀 뿐입니다. 원격 DNS 서버로 연결하는 HTTPS 트래픽이 프록시 출구 규칙에 매칭되는지, 브라우저가 직접 연결을 만들고 있는지, 코어 라우팅을 우회하는 조회 방식을 사용하는지 확인하세요. 먼저 연결 경로를 바로잡고 다시 테스트합니다.

TUN을 켠 뒤 구독 업데이트에 실패하면 어떻게 해야 하나요?

구독 주소와 노드 주소의 초기 DNS 조회 경로를 확인하세요. 이전에 작동하던 DNS 및 라우팅 설정을 일시적으로 복구해 업데이트가 완료되는지 확인한 다음 새 설정을 하나씩 적용합니다. 아직 생성되지 않은 프록시 연결에 의존하면서, 그 프록시 연결을 만드는 데 같은 DNS 조회 경로가 필요한 상태가 되지 않도록 하세요.

FakeDNS를 켠 뒤 일부 프로그램에서 계속 시간 초과가 발생하나요?

먼저 코어를 재시작하고 ipconfig /flushdns를 실행한 다음 대상 프로그램도 다시 시작하세요. 프로그램이 연결하는 매핑 주소가 도메인 복원 기능을 갖춘 인바운드로 전달되는지 확인합니다. 계속 호환되지 않으면 해당 앱이나 도메인에 실제 DNS 조회를 사용하도록 설정한 뒤 조회 경로를 다시 확인하세요.

네트워크를 바꿔도 수정한 설정이 유지되는지 어떻게 확인하나요?

현재 네트워크에서, 네트워크를 전환한 뒤, 절전 모드에서 복귀한 뒤 각각 다시 테스트하세요. 매번 시스템 DNS, TUN 상태, 프록시 도메인 하나와 직접 연결 도메인 하나의 결과를 기록하고 IPv6도 확인합니다. 브라우저에서 한 번 테스트한 결과만으로는 그 시점의 해당 요청 경로만 확인할 수 있습니다.

최종 점검은 전체 경로가 일관되게 이어지는지 확인하는 것입니다. 프록시 도메인은 제어된 DNS 경로를 사용하고, 원격 DNS 서버 연결은 예상한 출구를 따르며, 직접 연결 도메인은 정책에 맞게 조회되고, 노드 주소는 별도의 초기 조회로 확인할 수 있어야 합니다. TUN과 IPv6의 적용 범위도 명확해야 합니다. 기본 설정을 확인하려면 구독 가져오기 가이드, DNS 설정 문서, TUN 모드 안내를 참고하세요.