· 문제 해결 · 약 12분

DNS 누수 테스트 및 차단 설정: 원격 DNS, FakeDNS, 라우팅 규칙 가이드

DNS 요청이 프록시를 우회하는지 확인하고, v2rayN·v2rayNG에서 원격 DNS, FakeDNS, DNS 분할 라우팅을 설정하는 방법을 안내합니다.

핵심 내용

DNS 누수를 막으려면 요청이 들어오는 경로와 DNS 서버, 외부로 나가는 경로를 모두 확인해야 합니다. 노드 연결은 되지만 도메인 조회가 프록시를 통해 전달되는지 확신할 수 없는 사용자를 위한 안내입니다. 먼저 직접 연결과 프록시 연결을 비교한 뒤 v2rayN·v2rayNG의 DNS를 설정하고, FakeDNS와 브라우저 보안 DNS, 라우팅 예외를 점검합니다. 테스트 결과는 실제 규칙과 대조해야 하며, DNS 서버의 위치만으로 판단해서는 안 됩니다.

1. DNS 누수 확인: 프록시를 통해 처리할 조회부터 정하기

도메인에 접속할 때는 보통 두 가지 경로를 거칩니다. 먼저 IP 주소를 조회하고, 이어서 서비스에 연결합니다. 웹 연결이 프록시를 거친다고 해서 앞선 DNS 조회까지 프록시를 거쳤다는 뜻은 아닙니다. 시스템 프록시는 프록시를 지원하는 앱의 연결 방식만 바꾸며, 일반적으로 기기 전체의 UDP 53 조회를 가로채지 않습니다.

이 글에서는 ‘프록시를 통해 처리해야 할 도메인 조회가 로컬 네트워크에서 나가는 경우’를 점검합니다. 라우팅 정책에서 로컬 네트워크 도메인이나 지정 사이트를 직접 연결하도록 설정했다면 해당 조회가 로컬 DNS 서버를 사용하는 것은 정책에 따른 결과입니다. 모든 공용 도메인 조회를 프록시로 전달하려면 로컬 DNS로의 폴백과 앱의 우회를 추가로 제한해야 합니다.

테스트 결과이 결과만으로 단정할 수 없는 내용다음으로 확인할 사항
웹사이트에서 확인한 공인 IP가 변경됨모든 DNS 조회가 프록시를 거친다브라우저, 운영체제, 코어가 각각 어떤 DNS 서버를 사용하는지
공용 DNS 서버가 표시됨조회가 반드시 프록시를 거친다DoH 연결이 직접 연결과 프록시 중 어느 경로로 나가는지
여러 DNS 서버가 감지됨반드시 누수가 발생했다분할 라우팅, 폴백, DNS 서버 클러스터를 사용하는지
통신사 DNS 서버가 표시됨노드 설정이 반드시 잘못됐다시스템 조회, 브라우저 폴백, 직접 연결 대상 도메인이 있는지

판단 기준: 예상 경로를 먼저 정한 뒤 결과 해석하기

‘공용 도메인은 프록시를 통해 조회하고, 로컬 네트워크 이름은 로컬에서 조회한다’가 목표라면 두 종류의 요청을 따로 테스트하세요. DNS 서버 이름과 위치는 참고 자료일 뿐입니다. 연결 로그와 패킷 캡처를 대신할 수 없습니다.

2. 비교 테스트: 브라우저 검사와 로컬 패킷 캡처 함께 보기

먼저 프록시를 끄고 DNS 테스트 페이지에 표시되는 DNS 서버 정보를 기록합니다. 그런 다음 프록시를 켜고 같은 브라우저로 다시 테스트합니다. 테스트 페이지는 보통 임의의 서브도메인으로 조회를 유도해 기존 캐시의 영향을 줄이지만, 현재 브라우저의 DNS 경로만 확인할 수 있습니다. 다른 앱까지 제어되고 있다는 증거는 아닙니다.

  1. 기준 상태 기록

    현재 네트워크, 프록시 모드, 브라우저 보안 DNS 상태, 시스템 비공개 DNS 상태를 기록하세요. 먼저 직접 연결을 테스트한 뒤 프록시를 켭니다. 두 테스트 사이에 다른 설정은 변경하지 마세요.

  2. 캐시 비우기

    Windows에서는 아래 명령으로 시스템 DNS 캐시를 비울 수 있습니다. 브라우저에도 별도의 캐시가 있을 수 있으므로 관련 페이지를 닫았다가 다시 여세요. 이미 연결된 세션은 캐시를 비워도 새 경로로 자동 전환되지 않습니다.

  3. 임의 도메인으로 재테스트

    DNS 테스트 페이지에서 새 테스트를 시작하세요. 이전 결과를 새로고침하는 것만으로는 부족합니다. DNS 서버 주소와 제공업체를 기록해 직접 연결 결과와 비교하고, 페이지에 표시된 특정 지역만으로 결론을 내리지 마세요.

  4. 외부 연결 경로 확인

    실제 네트워크에 연결된 어댑터에서 UDP/TCP 53 트래픽을 확인하세요. 테스트 도메인 조회가 라우터나 통신사 DNS 서버로 직접 전송되는지 살펴보고, 코어 로그에서 원격 DNS의 연결 경로도 확인합니다.

ipconfig /flushdns
nslookup example.com

nslookup example.com은 시스템 측 조회 동작을 확인하는 명령이며 HTTP나 SOCKS 프록시 테스트가 아닙니다. 시스템 프록시만 켜져 있다면 시스템에 지정된 DNS 서버로 요청이 전송될 수 있습니다. TUN을 켰을 때 요청이 가로채지는지는 해당 모드의 DNS 하이재킹 및 라우팅 설정에 따라 달라집니다.

3. v2rayN: 시스템 프록시, TUN, 원격 DNS를 따로 설정하기

v2rayN은 데스크톱 클라이언트입니다. 실제 DNS 조회와 라우팅은 선택한 코어와 생성된 설정에 따라 달라집니다. 먼저 메인 화면에서 현재 노드가 정상적으로 작동하는지 확인한 다음 ‘설정’ → ‘DNS 설정’을 살펴보세요. 빌드마다 항목 배치가 다를 수 있습니다. 현재 화면에 해당 옵션이 없다면 실제 생성된 설정을 확인하고, 다른 버전의 화면을 고정된 메뉴로 여기지 마세요.

  1. 트래픽 가로채기 범위 확인

    브라우저만 테스트한다면 먼저 시스템 프록시를 사용할 수 있습니다. 시스템 프록시를 따르지 않는 앱까지 포함하려면 메인 화면에서 TUN 모드를 켜고 시스템 권한이 정상적으로 허용됐는지 확인하세요. TUN을 켰다고 DNS 하이재킹까지 적용되는 것은 아닙니다.

  2. 원격 DNS 주소 입력

    ‘설정’ → ‘DNS 설정’에서 현재 코어에 해당하는 원격 DNS 항목에 지원되는 서버 주소를 입력합니다. 예를 들어 https://1.1.1.1/dns-query는 DoH 주소이므로 일반 IP 주소만 받는 입력란에는 넣을 수 없습니다.

  3. DNS 라우팅 확인

    ‘설정’ → ‘라우팅 설정’과 현재 활성화된 규칙을 확인하세요. 원격 DNS 연결이 앞에 있는 직접 연결 규칙에 걸리지 않는지 확인하고, 노드 서버 주소에 필요한 부트스트랩 DNS 경로도 유지해야 합니다.

  4. 재시작 후 재테스트

    설정을 저장한 뒤 현재 서비스를 재시작하고 캐시를 비운 다음 동일한 비교 테스트를 다시 진행하세요. TUN을 전환한 뒤에는 시스템 측 조회도 따로 테스트해야 합니다. 브라우저에서만 성공한 것으로 기기 전체의 DNS가 가로채졌다고 판단하지 마세요.

시스템 프록시 모드에서는 로컬 수신 주소도 확인해야 합니다. 앱에서 사용하는 HTTP 또는 SOCKS 포트가 클라이언트에 표시된 값과 일치해야 합니다. DNS의 53번 포트는 SOCKS 접속 포트가 아닙니다. 원격 DNS 주소를 앱의 프록시 서버 입력란에 넣지 말고, DNS 문제를 해결하려고 로컬 네트워크 수신을 무작정 허용하지 마세요.

4. v2rayNG: 로컬 DNS, 원격 DNS, 앱 적용 범위 확인

v2rayNG는 Android VPN 인터페이스로 앱 트래픽을 처리하고, 코어로 Xray를 사용합니다. 여기서 ‘로컬 DNS’는 보통 DNS 정책의 로컬 측 서버를 뜻하며, 반드시 기기의 루프백 주소에서만 수신한다는 의미는 아닙니다. 설정 항목의 설명과 생성된 설정을 함께 확인하세요. 이름만 보고 데이터가 기기 외부로 나가는지 판단할 수 없습니다.

  1. 앱 적용 범위 확인

    ‘설정’ → ‘앱별 프록시’에서 선택한 앱만 프록시를 사용하는지, 아니면 선택한 앱을 프록시에서 제외하는지 확인하세요. 테스트에 사용할 브라우저가 프록시 적용 범위에 포함되지 않으면 해당 앱의 직접 연결 동작을 확인하게 됩니다.

  2. 코어 DNS 사용 설정

    ‘설정’에서 ‘로컬 DNS 사용’과 DNS 설정 항목을 찾으세요. 현재 빌드에 해당 스위치가 있다면 켠 뒤 ‘원격 DNS’와 ‘로컬 DNS’에 입력된 값을 확인합니다. 메뉴 이름은 버전에 따라 조금 다를 수 있습니다.

  3. 원격 DNS 주소 설정

    ‘원격 DNS’에 현재 코어가 지원하는 서버 주소를 입력합니다. 예를 들어 https://1.1.1.1/dns-query를 사용할 수 있습니다. 먼저 원격 서버 하나만 테스트하고, 검증되지 않은 폴백 서버를 여러 개 한꺼번에 추가하지 마세요.

  4. 시스템 DNS 확인

    Android 시스템 설정에서 ‘비공개 DNS’를 검색하세요. 기존 상태를 기록한 뒤 비교 테스트를 위해 잠시 끕니다. 테스트가 끝나면 원래대로 복구하고, 암호화 DNS 연결이 의도한 라우팅 경로를 따르는지도 확인하세요.

  5. 다시 연결하고 로그 확인

    연결을 끊었다가 다시 시작하고 도메인 조회 오류와 요청 시간 초과 여부를 확인하세요. 프록시에서 제외된 앱만 로컬 DNS 서버를 계속 사용한다면 DNS 주소를 바꾸기보다 먼저 앱 적용 범위를 수정하세요.

5. 원격 DNS 라우팅: 암호화 주소가 프록시 연결을 뜻하지는 않습니다

DoH는 전송 중인 조회 내용을 암호화하지만, 프록시 사용 여부는 연결 라우팅에 달려 있습니다. Xray 내장 DNS의 일반 https:// 조회는 코어 라우팅을 거칠 수 있습니다. 반면 https+local://은 로컬 조회 모드이므로 코어 프록시 라우팅이 필요한 환경에서 함께 사용하면 안 됩니다.

아래는 설정 항목 간 관계를 설명하기 위한 Xray 설정 예시이며, 완전한 클라이언트 설정은 아닙니다. 내장 DNS 조회에 dns-query 태그를 지정한 다음 해당 태그의 트래픽을 기존 proxy 아웃바운드로 보냅니다. 사용하기 전에 현재 코어가 해당 필드를 지원하는지, 실제 프록시 아웃바운드 태그가 proxy인지 확인해야 합니다.

{
  "dns": {
    "tag": "dns-query",
    "servers": [
      "https://1.1.1.1/dns-query"
    ],
    "queryStrategy": "UseIPv4"
  },
  "routing": {
    "rules": [
      {
        "type": "field",
        "inboundTag": ["dns-query"],
        "outboundTag": "proxy"
      }
    ]
  }
}

설정 요령: 단일 경로부터 검증한 뒤 분할 라우팅 추가

먼저 원격 DNS 서버 하나가 프록시를 통해 안정적으로 조회되는지 확인한 다음 로컬 도메인 규칙, 보조 DNS 서버, IPv6를 차례로 추가하세요. 항목을 추가할 때마다 다시 테스트해야 어떤 예외 규칙이 연결 경로를 바꿨는지 파악할 수 있습니다.

6. FakeDNS: 가상 주소 반환 후 트래픽도 처리해야 합니다

FakeDNS는 앱에 대상 사이트의 실제 IP를 반환하지 않습니다. 대신 가상 주소를 할당하고 도메인과 가상 주소의 매핑을 저장합니다. 앱이 해당 주소에 연결하면 코어가 매핑을 통해 도메인을 복원한 뒤 라우팅과 아웃바운드 처리를 진행합니다. 일부 환경에서 미리 실제 주소를 조회하지 않도록 줄일 수 있지만, 원격 암호화 DNS를 대체하지는 않습니다.

자주 사용하는 IPv4 가상 주소 대역은 198.18.0.0/15, 즉 198.18.0.0부터 198.19.255.255까지입니다. 이 주소는 대상 웹사이트의 공인 IP가 아닙니다. FakeDNS가 조회를 처리했는데 이후 연결이 가로채지지 않으면 앱은 대상에 정상적으로 도달할 수 없는 가상 주소에 접속하게 됩니다.

연결되어야 하는 단계확인할 내용누락된 경우 나타나는 현상
조회 경로앱의 DNS 조회가 실제로 FakeDNS에 전달됨실제 IP가 반환됨. 설정이 테스트 앱에 적용되지 않음
연결 트래픽 가로채기가상 주소 트래픽이 같은 코어로 돌아옴조회는 성공하지만 연결이 계속 시간 초과됨
매핑 복원인바운드에서 FakeDNS 도메인 복원을 지원함라우팅 규칙에서 원래 도메인으로 매칭할 수 없음
캐시 수명 주기재시작 후 이전 가상 주소를 계속 사용하지 않음코어 재시작 후 일부 앱이 잠시 열리지 않음

v2rayNG의 ‘설정’에 ‘가상 DNS 사용’이 있다면 해당 빌드의 요구 사항에 따라 먼저 로컬 DNS를 켠 다음 가상 DNS를 활성화하세요. ‘스니핑’ 관련 설정에서 FakeDNS 도메인 복원을 지원하는지도 확인해야 합니다. v2rayN에서는 TUN과 현재 코어의 FakeDNS 연동 방식을 확인하세요. 가상 주소 대역만 추가했다고 DNS 트래픽 가로채기와 도메인 복원이 완료된 것은 아닙니다.

7. 로그 문제 해결: DNS 조회 오류와 연결 오류 구분하기

오류가 발생한 시간과 대상 주소를 먼저 기록한 뒤 같은 시간대의 로그와 대조하세요. 아래 문자열은 로그에 나타날 수 있지만 접두어와 전체 메시지는 코어 버전에 따라 다릅니다. 시간 초과 메시지 하나만으로 누수나 DNS 서버 자체의 장애를 단정할 수 없습니다.

오류: failed to lookup ip for domain

원인: 코어가 대상 도메인의 사용 가능한 주소를 찾지 못했습니다. 원격 DNS 연결 불가, 부트스트랩 조회 실패, 조회 정책에서 필요한 레코드 제외 등이 원인일 수 있습니다.

해결 방법: 로그에 표시된 도메인을 확인하세요. 먼저 노드 도메인을 부트스트랩 조회할 수 있는지 확인한 다음 원격 DNS의 라우팅과 IPv4·IPv6 조회 정책을 살펴보세요.

오류: context deadline exceeded

원인: 작업이 제한 시간 내에 완료되지 않았습니다. DoH 요청과 관련된 오류라면 DNS 서버로의 HTTPS 연결이나 상위 서버 응답이 시간 초과됐을 수 있습니다.

해결 방법: 같은 프록시 경로를 통해 해당 DNS 주소에 연결해 보세요. 원격 DNS 서버는 한 번에 하나씩만 바꾸고, ‘DNS 조회에는 프록시가 필요하고 프록시 연결에는 DNS 조회가 필요한’ 순환 의존성이 없는지 확인하세요.

오류: network is unreachable

원인: 현재 네트워크에서 대상 주소로 가는 사용 가능한 경로가 없습니다. 도달할 수 없는 IPv6 주소에 연결하려는 경우가 한 예입니다.

해결 방법: 오류가 난 대상의 IP 버전을 확인하고 IPv4 조회 정책으로 임시 비교 테스트를 진행하세요. TUN 라우팅, 실제 네트워크, 프록시 아웃바운드의 IPv6 지원 여부도 함께 점검해야 합니다.

8. 자주 묻는 질문과 최종 재테스트

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

먼저 테스트에 사용한 브라우저가 프록시 적용 범위에 포함되는지 확인한 다음 로컬 DNS 분할 라우팅 규칙을 살펴보세요. 정책상 프록시를 사용해야 하는 테스트 도메인 조회가 물리 네트워크 어댑터에서 직접 전송된 것이 확인되어야 우회 증거로 볼 수 있습니다.

DoH 주소를 입력했는데 왜 결과가 바뀌지 않나요?

현재 코어에서 사용하는 DNS 설정을 수정했는지 확인하고 서비스를 재시작하세요. 그런 다음 브라우저 보안 DNS를 잠시 끄고 다시 테스트합니다. 브라우저가 자체적으로 DNS를 조회한다면 방금 변경한 코어 DNS 설정을 사용하지 않을 수 있습니다.

FakeDNS를 켜면 조회는 되는데 웹페이지가 열리지 않아요.

먼저 가상 주소 연결이 동일한 가로채기 경로로 들어가는지, 인바운드에서 해당 도메인 복원을 활성화했는지 확인하세요. FakeDNS를 끄고 앱 캐시를 비운 뒤 다시 테스트합니다. 문제가 해결된다면 노드를 바꾸기 전에 매핑과 트래픽 가로채기를 집중적으로 점검하세요.

53번 포트를 모두 차단하면 해결되나요?

아니요. 필요한 부트스트랩 조회까지 차단할 수 있으며, 443번 포트의 DoH나 853번 포트의 DoT는 막지 못합니다. 먼저 제어 가능한 DNS 경로를 구성한 뒤 필요에 따라 우회를 제한하고, 필요한 로컬 네트워크 서비스는 유지하세요.

마지막으로 프록시 재연결, 클라이언트 재시작, 네트워크 전환을 모두 포함해 다시 테스트하세요. Wi-Fi와 모바일 네트워크는 서로 다른 DNS 서버와 IPv6 라우팅 정보를 제공할 수 있습니다. 한 네트워크에서 확인한 결과가 다른 네트워크에서도 같다고 볼 수는 없습니다. 설정 변경 내역을 기록하고 문제가 생기면 항목별로 되돌리세요.

v2rayN 다운로드4개 플랫폼 클라이언트 보기