V2Ray DNS 유출 검사 및 차단 설정 가이드: 검사 방법, 원인 분석과 해결 단계

프록시 연결이 정상으로 표시된다고 해서 모든 애플리케이션 트래픽이 V2Ray 또는 Xray 코어를 거친다는 뜻은 아닙니다. 도메인은 연결을 시작하기 전에 보통 IP 주소로 변환됩니다. 이 과정이 시스템 네트워크의 기본 DNS에서 계속 처리되면 조회 기록이 로컬 네트워크를 통해 별도로 전송될 수 있습니다. DNS 유출을 점검할 때는 노드를 반복해서 바꾸기보다 누가 조회를 시작했는지, 어떤 경로를 거쳤는지, 최종적으로 어떤 리졸버가 응답했는지를 확인해야 합니다. 이 글의 기준 환경은 v2rayN 7.14.x 및 v2rayNG 1.10.x입니다. 낮은 버전에서는 메뉴명이 조금 다를 수 있지만 점검 순서는 같습니다.

DNS 유출이란? 도메인 조회 경로부터 이해하기

도메인에 접속할 때 애플리케이션이 직접 조회할 수도 있고, 도메인을 시스템 리졸버에 넘길 수도 있으며, 전체 도메인을 HTTP 또는 SOCKS 프록시에 전달할 수도 있습니다. 이 세 경로의 차이에 따라 DNS 조회가 프록시 코어로 들어가는지가 결정됩니다. 시스템 프록시를 사용하면 시스템 프록시 설정을 따르는 애플리케이션의 트래픽만 넘겨집니다. 백그라운드 프로그램, 일부 명령줄 도구, 자체적으로 UDP 조회를 보내는 애플리케이션은 네트워크 인터페이스에 설정된 DNS에 직접 접속할 수 있습니다.

DNS 유출은 검사 페이지에 여러 리졸버가 표시되는 현상과 같지 않습니다. 공용 DNS 서비스는 애니캐스트 노드를 사용하는 경우가 많아 하나의 조회가 여러 출구 위치로 표시될 수 있습니다. 브라우저에서 암호화 DNS를 사용하면 운영체제 설정을 우회해 브라우저가 지정한 DNS 서비스와 직접 통신할 수도 있습니다. 실제로 확인해야 할 점은 검사 결과에 현재 유선 또는 모바일 네트워크 사업자의 리졸버가 나타나는지, 프록시 연결 전후의 리졸버 목록이 완전히 같은지, 조회가 UDP 또는 TCP 53번 포트를 통해 평문으로 로컬 인터페이스를 빠져나가는지입니다.

V2Ray 및 Xray 설정의 dns 객체는 코어 내부 조회를 담당하지만, 운영체제에서 발생하는 모든 DNS 요청을 자동으로 가로채지는 않습니다. 도메인이 이미 코어에 들어왔거나 시스템 DNS 트래픽이 TUN, 투명한 인바운드 등의 방식으로 캡처된 경우에만 내장 DNS 설정이 적용될 수 있습니다. 이것이 “DNS 설정을 이미 추가했는데 검사 결과가 그대로인” 가장 흔한 이유입니다.

검사 기준 세우기: 한 번의 테스트로 결론 내리지 않기

검사 전에 브라우저에서 독립적으로 작동할 수 있는 보안 DNS를 끄고 다른 네트워크 프록시 도구도 잠시 비활성화하세요. 현재 네트워크 연결은 유지한 채 시스템 DNS 주소, v2rayN 또는 v2rayNG 작동 모드, 선택한 노드와 라우팅 모드를 기록합니다. 그래야 브라우저 자체의 조회 결과와 클라이언트가 인계받은 뒤의 결과를 구분할 수 있습니다.

1. 직접 연결 결과 기록

   클라이언트를 완전히 종료한 뒤 DNS 검사 페이지를 열고 표준 테스트와 확장 테스트를 각각 실행합니다. 리졸버 수, 소속 네트워크, 국가 또는 지역을 기록하고 확장 테스트는 2회 연속 실행하는 것이 좋습니다.

2. 시스템 프록시 활성화

   v2rayN 7.14.x에서 「시스템 프록시」→「시스템 프록시 자동 설정」을 선택합니다. 기본 로컬 SOCKS 포트 10808과 HTTP 포트 10809는 그대로 둔 뒤 새 브라우저 창에서 테스트를 반복합니다.

3. TUN 모드 전환

   「설정」→「매개변수 설정」→「TUN 모드 설정」으로 이동해 DNS 가로채기 범위를 확인한 뒤 TUN을 활성화합니다. 노드를 다시 연결하고 10초간 기다린 다음 같은 테스트를 실행합니다.

4. 세 그룹 데이터 비교

   직접 연결, 시스템 프록시, TUN 세 그룹의 결과를 비교합니다. 시스템 프록시에서는 로컬 리졸버가 계속 표시되지만 TUN에서는 사라진다면 문제는 대개 노드가 아니라 시스템 DNS 캡처 범위에 있습니다.

5. 연결 해제 후 재검사

   클라이언트를 종료한 뒤 검사 페이지를 새로고침해 시스템 네트워크가 기준 결과로 돌아오는지 확인합니다. 종료 후에도 비정상적인 DNS가 남아 있다면 네트워크 어댑터에 수동 주소가 남아 있는지 확인하고 네트워크 연결을 끊었다가 다시 연결하세요.

한 번의 확장 테스트에서는 20~50개의 조회가 발생할 수 있으며, 공용 DNS 서비스는 이를 여러 노드에 분배합니다. 더 신뢰할 수 있는 방법은 약 15초 간격으로 3회 연속 테스트하고 매번 반복해서 나타나는 리졸버를 안정적인 결과로 보는 것입니다. 특정 회차에만 다른 주소 하나가 나타났다면 캐시, 네트워크 전환, 리졸버의 부하 분산을 먼저 배제하고 전체 설정을 바로 변경하지 마세요.

시스템에 내장된 네트워크 모니터링 도구로 53번 포트도 확인할 수 있습니다. 테스트 중에는 검사 페이지 하나만 열고, 물리 네트워크 어댑터에서 목적지 포트가 53인 UDP 또는 TCP 연결이 발생하는지 관찰합니다. TUN을 활성화했는데도 직접 연결된 53번 포트 트래픽이 계속 보인다면 어떤 애플리케이션이 인계를 우회했거나 DNS 가로채기 규칙이 해당 프로토콜 계열을 포함하지 않는 것입니다.

테스트 상태	예시 결과	우선 확인할 사항
직접 연결	로컬 네트워크 리졸버 3개, 소요 시간 42~68ms	기준 데이터로 보관하여 비교
시스템 프록시	동일한 리졸버 3개가 계속 표시됨	브라우저 또는 시스템 DNS가 코어로 들어가지 않음
TUN 모드	설정한 공용 리졸버만 표시됨, 소요 시간 85~120ms	DNS 캡처와 프록시 아웃바운드가 적용됨
TUN 모드	공용 리졸버와 로컬 리졸버가 함께 표시됨	우회 조회가 있거나 프로토콜 계열이 적용 대상에서 빠짐

v2rayN 해결 방법: 내장 DNS와 라우팅 규칙을 함께 설정하기

v2rayN 데스크톱 클라이언트는 일반적으로 Xray 코어를 사용합니다. 문제를 해결할 때는 먼저 코어 종류와 설정 출처를 확인하세요. 일반 구독 노드는 클라이언트가 실행 설정을 생성하고, 사용자 지정 JSON은 사용자가 직접 관리합니다. 같은 필드를 양쪽에서 동시에 수정하지 마세요. 구독을 갱신하거나 코어를 다시 시작하면 수동으로 입력한 내용이 새로 생성된 설정으로 덮어써질 수 있습니다.

1. 코어 종류 확인

   「설정」→「매개변수 설정」→「Core 유형」을 열어 현재 노드가 Xray를 사용하는지 확인합니다. 저장 후 코어를 다시 시작하고 로그 상단에서 실제로 로드된 코어 이름과 버전을 확인하세요.

2. 로컬 포트 확인

   「설정」→「매개변수 설정」→「기본 설정」에서 SOCKS 포트 10808과 HTTP 포트 10809를 다른 프로그램이 사용하고 있지 않은지 확인합니다. 포트 충돌이 발생하면 브라우저가 직접 연결로 전환할 수 있습니다.

3. 도메인 정책 설정

   「설정」→「라우팅 설정」으로 이동해 현재 규칙 세트의 도메인 정책을 확인합니다. 조회 결과를 기준으로 IP 규칙을 매칭해야 한다면 IPIfNonMatch를 사용할 수 있습니다. 도메인 규칙만으로 분기한다면 모든 도메인을 무조건 미리 조회하지 마세요.

4. DNS 캡처 활성화

   「설정」→「매개변수 설정」→「TUN 모드 설정」으로 이동해 DNS 가로채기를 활성화하고 UDP 53을 포함하는지 확인합니다. 저장한 뒤 클라이언트를 종료하고 다시 시작해 가상 네트워크 어댑터와 라우팅 테이블을 완전히 재생성하세요.

5. 실행 로그 확인

   노드를 연결한 뒤 로그를 열고 이전에 조회한 적 없는 도메인에 접속합니다. 정상이라면 도메인이 라우팅 판단 단계로 들어가야 하며, 로컬 조회 시간 초과나 대상 주소 조회 실패가 반복해서 나타나서는 안 됩니다.

다음 구조는 내장 DNS의 핵심 필드를 설명하기 위한 것이며, 클라이언트가 생성한 전체 설정을 그대로 덮어쓰는 용도로 사용하면 안 됩니다. queryStrategy는 반환할 주소 계열을 제어하고 servers는 후보 리졸버를 결정합니다. 현재 네트워크의 IPv6 라우팅이 불안정하다면 먼저 UseIPv4로 재현 가능한 기준을 세우세요. 연결이 정상임을 확인한 뒤 실제 필요에 따라 주소 계열 정책을 조정합니다.

{
  "dns": {
    "queryStrategy": "UseIPv4",
    "servers": [
      {
        "address": "https://1.1.1.1/dns-query",
        "domains": [
          "geosite:geolocation-!cn"
        ]
      },
      "223.5.5.5"
    ]
  }
}

서버 주소만 추가해서는 충분하지 않습니다. 코어가 보내는 DNS 요청도 명확한 아웃바운드 경로를 거쳐야 하며, 그렇지 않으면 암호화 DNS 연결이 기본 규칙에 따라 직접 연결될 수 있습니다. 중국 본토와 해외 도메인을 나누는 설정에서는 특정 리졸버의 도메인 또는 주소가 의도한 아웃바운드와 매칭되도록 하고, 최종 DNS 규칙은 이를 먼저 가로챌 수 있는 광범위한 규칙보다 앞에 배치해야 합니다.

{
  "routing": {
    "domainStrategy": "IPIfNonMatch",
    "rules": [
      {
        "type": "field",
        "network": "udp",
        "port": 53,
        "outboundTag": "proxy"
      }
    ]
  }
}

v2rayNG 및 v2flyNG: 모바일 네트워크에서 VPN 인계 확인

v2rayNG는 Xray 코어를 사용하고 v2flyNG는 v2fly 코어를 사용합니다. 두 클라이언트는 DNS 필드의 지원 범위와 기본 동작이 완전히 같지 않으므로 데스크톱에서 사용자 지정한 설정을 그대로 복사해 바로 활성화하지 마세요. 모바일에서 점검할 때는 먼저 VPN 연결이 실제로 수립되었는지 확인하고, 이어서 로컬 DNS, 원격 DNS, 도메인 정책과 애플리케이션별 프록시 범위를 확인해야 합니다.

1. 네트워크 유형 기록

   Wi-Fi와 모바일 네트워크에서 각각 테스트하고, 네트워크를 전환한 뒤 연결을 중지했다가 다시 시작하세요. 새 테스트에 이전 결과의 캐시가 섞이지 않도록 전환 전 검사 탭을 재사용하지 마세요.

2. VPN 설정 확인

   v2rayNG 1.10.x에서 「설정」→「VPN 설정」을 열어 현재 VPN 모드를 사용 중인지 확인하고, 애플리케이션별 프록시 목록에서 검사 중인 브라우저가 빠져 있지 않은지 확인합니다.

3. DNS 항목 확인

   「설정」→「VPN 설정」→「DNS 설정」으로 이동해 로컬 DNS와 원격 DNS를 확인합니다. 원격 DNS는 현재 네트워크에서 접근 가능한 주소를 선택해야 하며, 변경 후 연결을 중지했다가 다시 시작하세요.

4. 도메인 정책 확인

   「설정」→「라우팅 설정」으로 이동해 도메인 정책과 사전 정의 규칙을 확인합니다. 대상 IP를 기준으로 판단하는 규칙이라면 조회 결과가 해당 규칙에 사용될 수 있는지 확인해 도메인이 잘못된 아웃바운드에서 먼저 조회되지 않도록 하세요.

5. 두 네트워크에서 재검사

   두 네트워크에서 각각 15초 간격으로 확장 테스트를 3회 실행합니다. 모바일 네트워크에서만 로컬 리졸버가 나타난다면 네트워크 전환 후 VPN 재구성과 IPv6 라우팅을 우선 확인하세요.

애플리케이션별 프록시는 모바일에서 자주 빠뜨리는 항목입니다. 검사 브라우저가 프록시 목록에 없으면 페이지와 DNS 조회가 모두 네트워크에 직접 접속하므로 결과가 로컬 상태로 유지됩니다. 반대로 브라우저는 VPN에 포함되어 있어도 다른 백그라운드 애플리케이션이 제외되어 있으면 해당 애플리케이션의 DNS 요청은 기본 네트워크를 계속 사용할 수 있습니다. 이 경우 시스템 수준의 모니터링에는 우회 트래픽이 보이지만 브라우저 검사 페이지에는 백그라운드 애플리케이션의 조회가 표시되지 않을 수 있습니다.

v2flyNG에서 v2fly 코어를 사용할 때는 해당 코어가 실제로 지원하는 설정 필드를 기준으로 삼아야 합니다. 가져온 구독에 노드 프로토콜, 주소와 포트만 포함되어 있다면 DNS와 라우팅은 보통 클라이언트의 로컬 설정이 결정하며, 단순한 노드 링크만으로 전체 정책을 자동으로 가져오지는 않습니다. 설정을 이전할 때는 VMess 또는 VLESS 노드 매개변수, 전송 설정, DNS와 라우팅 규칙을 각각 확인해야 하며 노드 이름만 비교해서는 안 됩니다.

• Wi-Fi는 정상이고 모바일 네트워크만 문제: VPN 연결을 재구성하고 IPv6 연결 가능 여부와 모바일 네트워크가 제공하는 리졸버를 계속 호출하는지 확인하세요.
• 모든 네트워크에서 로컬 리졸버가 표시됨: 브라우저가 제외되어 있는지, 원격 DNS가 적용되는지, 클라이언트가 VPN 모드인지 확인하세요.
• 검사 결과는 정상이나 일부 도메인 접속 실패: 도메인 정책, DNS 분기 규칙, 리졸버가 대상 도메인에 반환하는 결과를 확인하세요.
• 노드 IP로는 연결되지만 노드 도메인으로는 실패: 서버 도메인에 독립적이고 도달 가능한 부트스트랩 조회 경로를 확보해 프록시 연결 전에 순환 의존성이 생기지 않도록 하세요.

수정 후 검수: 조회, 라우팅, 실패 시 대체 경로를 함께 확인

수정이 끝난 뒤 검사 페이지를 한 번만 확인하지 마세요. 전체 검수에는 콜드 스타트, 네트워크 전환, 노드 전환, 클라이언트 종료의 네 가지 상태가 포함되어야 합니다. 콜드 스타트는 부트스트랩 조회를, 네트워크 전환은 VPN과 라우팅 테이블 재구성을, 노드 전환은 서로 다른 서버 주소의 조회 경로를, 클라이언트 종료는 시스템 설정이 복구되는지를 확인하는 데 사용합니다.

간단한 검수 기록을 남겨 두는 것이 좋습니다. 예시 기준은 다음과 같이 작성할 수 있습니다. v2rayN 7.14.x, Xray 코어, TUN 모드, HTTPS 연결을 사용하는 원격 DNS, 로컬 네트워크 리졸버가 나타나지 않은 3회 연속 검사, 물리 네트워크 어댑터에서 지속적인 UDP 53 직접 연결 없음. “해결됨”이라고만 적는 것보다 구체적인 상태를 기록하는 편이 클라이언트 업그레이드나 규칙 변경에 따른 변화를 비교하기 쉽습니다.

검수 항목	통과 조건	실패 후 확인할 사항
콜드 스타트 조회	10초 안에 노드 도메인 조회를 완료하고 연결 수립	부트스트랩 DNS, 서버 도메인과 아웃바운드 순환
연속 검사	3회 결과가 안정적이며 로컬 네트워크 리졸버가 나타나지 않음	브라우저 보안 DNS, 시스템 캐시와 우회 애플리케이션
53번 포트 관찰	물리 네트워크 어댑터에서 지속적인 DNS 직접 조회 없음	TUN 캡처 범위, UDP 및 TCP 규칙
네트워크 전환	재연결 후 조회 결과가 전환 전과 동일함	VPN 재구성, IPv6 라우팅과 원격 DNS 연결 가능 여부
종료 후 복구	시스템 DNS가 변경 전 기준으로 돌아옴	네트워크 어댑터의 수동 DNS와 남아 있는 프록시 설정

검사 결과가 계속 불안정하다면 “애플리케이션 진입점, 시스템 인계, 코어 DNS, DNS 아웃바운드, 최종 라우팅”의 다섯 계층으로 나누어 범위를 좁히세요. 원격 DNS, 도메인 정책, 라우팅 규칙과 작동 모드를 한꺼번에 바꾸지 말고 한 번에 한 항목만 변경한 뒤 같은 테스트를 반복해야 실제로 어느 계층이 영향을 주었는지 알 수 있습니다.

자주 묻는 질문