DNS 누수 테스트와 v2rayN·v2rayNG DNS 유출 방지 설정

1. DNS 누수는 국가 표시가 아니라 조회 경로의 문제

DNS는 도메인 이름을 IP 주소로 변환합니다. 앱은 먼저 시스템에 도메인 조회를 요청한 다음 IP 주소를 프록시에 전달할 수도 있고, 도메인 이름을 로컬 프록시에 직접 전달해 코어 또는 원격 서버가 처리하게 할 수도 있습니다. 두 방식 모두 웹페이지를 열 수 있지만, 전자의 조회는 로컬 네트워크의 DNS 서버로 먼저 전달될 수 있습니다. 누수 여부는 설정한 규칙을 기준으로 판단해야 합니다. 프록시를 거치도록 지정한 도메인이 로컬 출구에서 조회되는 경우가 여기서 해결할 문제입니다.

중국 본토 도메인을 계획에 따라 로컬 DNS로 조회하는 것 자체는 누수가 아닙니다. VLESS와 VMess는 프록시 프로토콜이고 REALITY는 연결 보안 관련 방식입니다. 운영체제가 DNS 요청을 보내는 방법을 이들이 자동으로 결정하지는 않습니다. 구독에 노드 정보가 포함되어 있어도 DNS 처리와 라우팅 정책까지 모두 설정된 것은 아닙니다.

2. 온라인 DNS 테스트: 세 가지 조건을 비교한 뒤 판단

온라인 DNS 테스트는 보통 브라우저에서 임의의 하위 도메인을 여러 개 요청한 다음 어떤 재귀 DNS 서버가 조회하는지 확인합니다. 결과에는 DNS 서버의 출구가 표시될 뿐, 기기에서 연결한 상위 DNS 주소나 프록시 노드와 같은 도시에 있는 서버가 반드시 표시되는 것은 아닙니다. 공용 DNS는 애니캐스트와 전달 클러스터를 사용하므로 지도나 국가 이름만 보고 누수 여부를 판단할 수 없습니다.

1. 직접 연결 결과 기록

   프록시를 먼저 끈 뒤 브라우저에서 dnsleaktest.com에 접속해 표준 테스트와 확장 테스트를 실행합니다. 네트워크 유형, 테스트 시간, DNS 서버 IP, 운영 기관을 기록해 로컬 네트워크의 비교 기준으로 삼으세요.

2. 프록시 연결 테스트

   클라이언트를 실행하고 테스트에 사용할 브라우저가 프록시에 포함되어 있는지 확인한 뒤 다시 테스트합니다. 같은 노드와 같은 네트워크를 유지하고 DNS, 라우팅, 브라우저 설정을 한꺼번에 바꾸지 마세요.

3. 브라우저 변수 분리

   브라우저 설정에서 ‘보안 DNS’를 검색해 기능을 잠시 끈 뒤 다시 테스트합니다. 테스트 후 기능을 다시 켤지는 브라우저의 암호화 DNS 경로를 별도로 관리할지에 따라 결정하세요.

4. 연결 끊김 상태 재테스트

   잠시 네트워크가 끊겨도 괜찮은 환경에서 프록시 노드 연결을 끊고 새 테스트를 실행합니다. 연결 실패 시 접속도 차단하려는 설정이라면, 연결이 끊긴 뒤에도 새 도메인을 조회하고 열 수 있는 경우 시스템 직접 연결, VPN 우회, 앱의 대체 동작을 확인하세요.

3. v2rayN PC: 시스템 프록시와 TUN을 나눠 점검

아래 내용은 v2rayN 7.x의 설정 구성을 기준으로 합니다. 세부 버전에 따라 메뉴 이름이 달라질 수 있으므로 현재 실행 중인 코어를 먼저 확인하고 생성된 설정도 살펴보세요. 특히 TUN 모드에서 실제 사용하는 구성 요소와 DNS 설정은 일반 시스템 프록시 모드와 다를 수 있습니다. Xray의 DNS 항목을 바꿔도 현재 TUN 경로에는 적용되지 않을 수 있습니다.

1. 실행 모드 확인

   ‘설정’ → ‘매개변수 설정’에서 코어 관련 항목을 확인하고, 메인 화면에서 ‘시스템 프록시’와 ‘TUN 사용’의 실제 상태를 살펴보세요. 시스템 트레이에서 시스템 프록시가 켜져 있다고 해서 모든 프로그램이 터널을 통과하는 것은 아닙니다.

2. DNS 상위 서버 확인

   ‘설정’ → ‘DNS 설정’에서 현재 코어에 해당하는 항목을 각각 확인하세요. 원격 DNS 서버 테스트에는 https://1.1.1.1/dns-query를 사용할 수 있습니다. DoH URL을 입력하는 것만으로는 충분하지 않으며, 해당 주소로 향하는 연결이 프록시를 통과하는지 확인해야 합니다.

3. 로컬 포트 확인

   ‘설정’ → ‘매개변수 설정’에서 로컬 수신 포트를 확인한 뒤 브라우저나 앱의 프록시 주소와 대조하세요. 예를 들어 실제 수신 주소가 127.0.0.1:10808이면 앱에도 해당 포트와 맞는 프록시 유형을 설정해야 합니다. 예시 포트가 현재 설정을 대신하지는 않습니다.

4. 이전 DNS 캐시 지우기

   Windows 터미널을 열고 ipconfig /flushdns를 실행한 다음 브라우저를 완전히 종료했다가 다시 열어 새 도메인을 테스트하세요. 이미 연결된 세션과 브라우저 자체 캐시까지 이 명령으로 모두 지워지는 것은 아닙니다.

Windows에서 네트워크 어댑터가 여러 개라면 Wi-Fi, 유선 어댑터, 가상 어댑터도 확인해야 합니다. 그룹 정책을 지원하는 시스템에서는 ‘컴퓨터 구성’ → ‘관리 템플릿’ → ‘네트워크’ → ‘DNS 클라이언트’에서 ‘스마트 멀티홈 이름 확인 끄기’를 ‘사용’으로 설정할 수 있습니다. 병렬 조회를 줄이는 보조 설정일 뿐 TUN을 대체하지 않으며, 모든 시스템 DNS 대체 동작을 끄는 기능도 아닙니다. 변경 후에는 실제 테스트 결과를 확인하세요.

4. v2rayNG Android: 먼저 VPN으로 트래픽을 처리하고 비공개 DNS 점검

아래 내용은 v2rayNG 1.9.x에서 흔히 볼 수 있는 설정 구성을 기준으로 합니다. v2rayNG는 Xray 코어를 사용하지만 시스템 VPN 적용, Android 비공개 DNS, 브라우저 보안 DNS는 서로 다른 계층입니다. v2flyNG는 V2Fly 코어를 사용하므로 여기의 설정 항목과 구성 필드를 모두 그대로 적용할 수는 없습니다.

1. 앱 적용 범위 확인

   사이드 메뉴에서 ‘설정’ → ‘앱별 프록시’를 열고 테스트 브라우저가 제외되지 않았는지 확인하세요. 문제를 찾는 동안에는 앱별 프록시를 잠시 끄면 테스트 범위를 명확히 할 수 있습니다. 허용 목록을 사용한다면 브라우저가 목록에 포함되어야 합니다.

2. 로컬 DNS 확인

   사이드 메뉴에서 ‘설정’을 열고 ‘로컬 DNS 사용’을 찾아 켠 다음 ‘원격 DNS’와 ‘중국 국내 DNS’ 항목을 확인하세요. 일부 버전에서는 이 항목들이 DNS 설정 그룹에 있습니다. 원격 및 중국 국내 상위 DNS 주소를 각각 확인하고, 항목 이름만 보고 최종 아웃바운드를 추측하지 마세요.

3. 비공개 DNS 테스트

   Android 기본 설정에서 ‘설정’ → ‘네트워크 및 인터넷’ → ‘비공개 DNS’로 이동합니다. 먼저 현재 값을 기록한 다음, 코어 DNS의 기준을 확인하기 위해 일시적으로 ‘사용 안 함’으로 설정하세요. 제조사별 설정에서는 ‘프라이빗 DNS’로 표시될 수 있으니 시스템 설정에서 이름을 검색해 보세요.

4. VPN 다시 연결

   설정을 저장한 뒤 연결을 중지하고 다시 시작해 시스템에 VPN 연결 상태가 표시되는지 확인하세요. Wi-Fi와 모바일 네트워크로 각각 전환해 테스트합니다. 한 네트워크에서만 문제가 발생한다면 해당 네트워크의 IPv6, DNS 연결 가능 여부, VPN 재연결 상태를 중점적으로 확인하세요.

5. 연결 끊김 보호 테스트

   연결에 실패하면 접속을 차단하려는 경우 Android ‘설정’ → ‘네트워크 및 인터넷’ → ‘VPN’ → ‘v2rayNG’에서 ‘항상 켜짐 VPN’과 ‘VPN을 사용하지 않는 연결 차단’을 확인하세요. 이 옵션은 기기와 앱 상태에 따라 제공되지 않을 수 있습니다. 설정을 켠 뒤에는 앱별 규칙이 여전히 의도대로 작동하는지 테스트해야 합니다.

5. FakeDNS: 사전 조회를 줄이되 원격 DNS 서버는 별도로 설정

FakeDNS는 합성 주소를 반환한 뒤 후속 연결에서 해당 주소를 도메인 이름에 다시 매핑합니다. 이를 통해 코어가 도메인 정보를 유지하고 라우팅 규칙 적용과 프록시 전달에 사용할 수 있습니다. FakeDNS 자체는 암호화 DNS 서비스가 아니며 모든 실제 DNS 조회를 자동으로 프록시에 보내지도 않습니다. 실제 IP 주소가 필요한 직접 연결 트래픽에는 적절한 DNS 상위 서버가 여전히 필요합니다.

v2rayNG ‘설정’에서 ‘Fake DNS 사용’을 찾아 활성화하세요. 먼저 ‘로컬 DNS 사용’이 적용되는지 확인하고 저장한 뒤 VPN을 다시 시작합니다. PC에서는 현재 TUN 구성 요소의 FakeIP/FakeDNS 지원 방식에 맞춰 설정해야 합니다. Xray의 FakeDNS 객체를 다른 형식의 설정에 그대로 복사하면 안 됩니다.

• 활성화 후 웹페이지에 문제가 생기면 설정을 되돌리기 전에 앱을 다시 시작하고 이전 DNS 캐시를 지우세요.
• 앱이 합성 주소를 받은 뒤 VPN을 우회하면 해당 주소가 예상대로 작동하지 않을 수 있습니다. 트래픽 적용 범위를 수정해야 합니다.
• 일부 앱은 실제 주소를 자체 검증하거나 독립적인 DNS 조회를 사용합니다. 이런 트래픽에는 FakeDNS가 맞지 않을 수 있으므로 앱별로 테스트하세요.

6. 대체 동작 끄기와 라우팅 대체 규칙: 두 설정 계층을 따로 처리

‘시스템 DNS 대체 동작 끄기’라는 공통 버튼은 모든 플랫폼에 존재하지 않습니다. 클라이언트 코어의 대체 DNS 서버, Windows의 다중 네트워크 어댑터 조회, Android 네트워크 전환, 브라우저 자체 보안 DNS를 각각 점검해야 합니다. Xray의 disableFallback은 내장 DNS의 대체 조회 동작만 제어하며 운영체제의 직접 연결을 차단하지 않습니다.

아래는 Xray DNS와 라우팅 설정의 일부 예시이며 완성된 설정이 아닙니다. 원격 DNS 서버와 해당 연결의 아웃바운드 제한만 보여 줍니다. 기존 설정에 proxy라는 태그의 프록시 아웃바운드가 이미 정의되어 있고 앱의 DNS 조회가 코어에 전달되어야 합니다. 클라이언트가 자동 생성한 설정은 해당 편집 메뉴에서 수정하고 최종 결과를 확인하세요. 기존 설정을 덮어쓴 뒤 그대로 실행하면 안 됩니다.

{
  "dns": {
    "servers": [
      "https://1.1.1.1/dns-query"
    ],
    "queryStrategy": "UseIPv4",
    "disableFallback": true
  },
  "routing": {
    "domainStrategy": "AsIs",
    "rules": [
      {
        "type": "field",
        "ip": [
          "1.1.1.1/32"
        ],
        "port": "443",
        "network": "tcp",
        "outboundTag": "proxy"
      }
    ]
  }
}

여기서 DoH 주소를 IP 형식으로 쓰는 이유는 상위 DNS 서버의 도메인 이름을 조회할 때 필요한 부트스트랩 의존성을 줄이기 위해서입니다. UseIPv4는 이 내장 DNS 조회의 주소 계열만 제한하며 시스템 IPv6를 끄지 않습니다. 이 예시에는 도메인별 라우팅이나 앱 DNS 적용 규칙이 없으므로 전체 DNS 누수 방지를 완료했다고 볼 수 없습니다.

• 원격 상위 서버 규칙을 먼저 적용: 원격 DNS 연결 규칙은 직접 연결 규칙에 걸릴 가능성이 있는 항목보다 앞에 배치하세요. Xray 라우팅은 순서대로 규칙을 확인하며 앞에서 일치하면 뒤의 규칙은 검사하지 않습니다.
• 기본 아웃바운드 확인: Xray가 일치하는 규칙을 찾지 못하면 첫 번째 아웃바운드를 사용합니다. 기본적으로 프록시를 사용하려면 첫 번째 아웃바운드가 직접 연결인데도 이를 모르고 지나치는 일이 없도록 하세요.
• 로컬 모드를 일반 설정과 혼용하지 않기: 상위 서버를 선택할 때 https+local://처럼 로컬 접근 의미가 포함된 주소 형식에 유의하세요. 이를 일반적인 원격 DoH 설정처럼 동일한 라우팅 제어를 받는다고 간주해서는 안 됩니다.
• 일반 DNS도 처리 대상에 포함: 적절한 인바운드 및 라우팅 구성에서는 UDP/TCP 53 트래픽을 DNS 아웃바운드로 전달할 수 있습니다. 포트 53만 차단하면 일부 앱의 DNS 조회가 실패할 수 있으며 853이나 HTTPS로 전달되는 조회도 처리하지 못합니다.
• 노드 도메인이 연결 시작 전에 조회 가능해야 함: 프록시 서버 주소가 도메인이라면 프록시 연결 전에 부트스트랩 조회가 필요할 수 있습니다. 이 예외를 어떻게 처리할지 명확히 정해 DNS가 프록시에 의존하고 프록시가 다시 DNS에 의존하는 순환을 방지하세요.

7. 최종 점검: 브라우저 결과와 로그, 연결 끊김 동작을 함께 확인

설정을 바꾼 뒤 테스트 페이지 스크린샷만 남기지 마세요. 클라이언트 버전, 실행 모드, 네트워크 유형, 원격 DNS 서버, 테스트 앱을 기록해야 합니다. 단일 상위 서버와 전체 프록시 설정부터 확인한 다음 중국 본토 도메인 분할 라우팅, 브라우저 보안 DNS, 앱별 규칙을 하나씩 복구하세요. 항목을 복구할 때마다 다시 테스트해야 DNS 경로가 바뀐 계층을 찾을 수 있습니다.

물리 네트워크 어댑터에서 포트 53 트래픽이 보이지 않더라도 해당 유형의 평문 DNS를 관찰하지 못했다는 뜻일 뿐입니다. 브라우저 DoH는 443을 통해 직접 연결될 수 있습니다. 암호화된 조회는 상위 서버 대상, 연결 경로, 로그를 함께 확인해야 합니다. 로그 수준을 임시로 높였다면 평소 설정으로 복구하세요. 로그를 공유하기 전에 구독 주소, 사용자 식별 정보, 방문 도메인을 삭제해야 합니다.