노드에는 연결되지만 검사 페이지에 한국 통신사 DNS가 계속 표시되는 사용자를 위한 글입니다. 먼저 직접 연결 기준을 확인한 뒤 브라우저의 보안 DNS, 시스템 캐시, 클라이언트 라우팅으로 인한 변수를 구분합니다. 이어 v2rayN, v2rayNG 또는 v2flyNG의 DNS와 트래픽 가로채기 설정을 조정하고, 세 차례 재검사로 조회 경로가 예상대로인지 확인합니다.
DNS 누출 판단 기준
DNS는 도메인 이름을 연결 가능한 IP 주소로 변환합니다. 브라우저로 웹사이트를 열면 일반적으로 먼저 도메인을 조회한 다음 조회 결과의 주소에 연결합니다. 프록시 노드가 웹 트래픽을 전달한다고 해서 시스템의 DNS 조회까지 반드시 같은 경로를 거치는 것은 아닙니다. 두 작업은 서로 다른 구성 요소가 처리하므로 각각 직접 연결과 프록시를 사용할 수 있습니다.
DNS 누출은 검사 페이지에 여러 리졸버가 표시된다고 해서 반드시 문제가 있다는 뜻은 아닙니다. 지정한 리졸버나 프록시 경로로 보내야 할 조회가 예상한 채널을 우회했는지가 핵심입니다. 흔한 증상은 웹 출구 주소는 바뀌었는데 DNS 검사 결과에는 현재 네트워크 통신사나 라우터가 배포한 리졸버가 계속 나타나거나, 테스트 도메인이 로컬 네트워크의 53번 포트에서 직접 해석되는 경우입니다.
| 검사 결과 | 가능한 원인 | 중점 확인 사항 |
|---|---|---|
| 출구 주소는 바뀌었지만 리졸버는 여전히 로컬 통신사 소속 | 시스템 DNS 또는 UDP 53이 클라이언트에 의해 가로채지지 않음 | TUN, VPN 서비스와 로컬 DNS 옵션 확인 |
| 브라우저마다 다른 리졸버가 표시됨 | 한 브라우저에서 별도의 보안 DNS가 활성화됨 | 브라우저 설정을 통일한 뒤 기준 다시 확인 |
| 검사 결과에 가끔 라우터 주소가 나타남 | 시스템 폴백, 캐시 또는 네트워크 전환으로 보조 조회가 실행됨 | 캐시를 지우고 세 차례 연속 검사 |
| 프록시 서비스 측 리졸버만 표시됨 | 원격 리졸버 또는 지정한 리졸버가 도메인 조회를 처리함 | 라우팅이 규칙에 맞는지 계속 확인 |
결론: 예상 경로를 먼저 정한 뒤 누출 여부를 판단
검사 결과에서 중요한 것은 리졸버의 개수가 아니라 소속과 조회 경로입니다. 회사 네트워크, 가정용 라우터, 브라우저 보안 DNS는 서로 다른 결과를 만들 수 있으므로, 먼저 어떤 리졸버를 사용할지 정해야 재검사 결과를 판단할 수 있습니다.
온라인 검사와 로컬 기준 확인 방법
설정을 본격적으로 변경하기 전에 클라이언트를 완전히 끊은 상태에서 한 번, 노드에 연결한 상태에서 한 번 검사합니다. 매번 같은 브라우저, 같은 네트워크, 같은 검사 방식을 사용해 브라우저 차이를 클라이언트 문제로 오해하지 않도록 합니다. 표준 검사와 확장 검사를 지원하는 DNS 검사 페이지를 권장합니다. 확장 검사는 무작위 하위 도메인을 더 많이 조회하므로 보조 리졸버를 발견하기 쉽습니다.
직접 연결 결과 기록
v2rayN을 종료하거나 Android에서 VPN 서비스를 중지하고 브라우저 보안 DNS를 끈 다음 검사 페이지에서 확장 검사를 한 번 실행합니다. 출구 네트워크 소속, 리졸버 수와 리졸버가 속한 네트워크를 기록하되 임시 테스트 도메인은 기록하지 않아도 됩니다.
대상 노드 연결
클라이언트에서 사용할 수 있는 구성을 선택합니다. v2rayN에서는 시스템 프록시 또는 TUN 모드를 켜고, v2rayNG와 v2flyNG에서는 연결을 누른 뒤 시스템 상태 표시줄에 VPN 서비스가 실행 중인지 확인합니다.
기존 캐시 정리
데스크톱에서는 DNS 캐시를 갱신한 뒤 브라우저를 완전히 종료하고 다시 엽니다. Android에서는 먼저 클라이언트를 연결 해제했다가 다시 연결하고, 브라우저가 이전 결과를 계속 사용하면 브라우저 프로세스를 종료합니다.
세 차례 연속 검사
각 검사 사이에 최소 30초 간격을 두고 검사 페이지를 다시 불러옵니다. 세 번 모두 예상한 리졸버만 표시되어야 캐시, 보조 DNS와 일시적인 네트워크 전환을 더 확실히 배제할 수 있습니다.
출구 주소 변화 대조
웹 출구 주소가 바뀌지 않았다면 먼저 프록시가 트래픽을 가로채는지 확인합니다. 출구 주소는 바뀌었지만 리졸버가 직접 연결 기준과 같다면 클라이언트 DNS 설정을 점검합니다.
Windows 로컬 점검 명령
다음 명령은 현재 시스템 DNS를 확인하고 캐시를 삭제하며, 로컬 프로그램이 53번 포트를 수신 중인지 점검하는 데 사용합니다. 명령만으로 조회가 어떤 송신 경로를 거쳤는지 증명할 수는 없지만, 잘못된 네트워크 어댑터 설정과 포트 충돌을 찾는 데 도움이 됩니다.
ipconfig /all
ipconfig /flushdns
nslookup example.com
powershell -NoProfile -Command "Get-NetUDPEndpoint -LocalPort 53 -ErrorAction SilentlyContinue"v2rayN 데스크톱 누출 방지 설정
다음 절차는 Xray Core와 함께 사용하는 v2rayN 7.x를 기준으로 합니다. 마이너 버전에 따라 메뉴 위치는 달라질 수 있지만 점검 순서는 같습니다. 먼저 Core 종류를 확인하고 DNS를 설정한 뒤 시스템 프록시와 TUN 중 사용할 방식을 정합니다. 시스템 프록시는 HTTP 또는 SOCKS 프록시를 지원하는 앱을 주로 가로채며, 모든 프로그램의 UDP 53 조회까지 자동으로 가로채지는 않는 경우가 많습니다. 더 많은 시스템 트래픽을 처리하려면 TUN 모드를 우선 확인하세요.
코어 확인
「설정」→「매개변수 설정」→「Core 종류」를 열어 현재 구성이 Xray를 사용하는지 확인합니다. 저장한 뒤 코어를 다시 시작해 이전 프로세스가 기존에 생성된 설정을 계속 사용하지 않도록 합니다.
DNS 설정
「설정」→「DNS 설정」→「Xray DNS」로 이동해 먼저 해당 버전에서 제공하는 기본 템플릿을 선택한 다음 라우팅 요구에 맞춰 직접 연결 DNS와 프록시 DNS를 설정합니다. 직접 연결 도메인에는 로컬 네트워크에서 접근 가능한 리졸버를 사용하고, 프록시 도메인은 프록시를 통해 접근할 수 있는 리졸버로 처리합니다.
라우팅 확인
「설정」→「라우팅 설정」에서 현재 규칙을 확인합니다. 도메인이 먼저 IP로 해석되면 이후에는 IP 규칙만 적용될 수 있습니다. 도메인 기준으로 라우팅하려면 조회 정책과 라우팅 규칙이 함께 맞물리는지 확인하고 DNS 주소만 바꾸지 마세요.
TUN 활성화
시스템 프록시를 따르지 않는 프로그램까지 가로채려면 「설정」→「매개변수 설정」→「Tun 모드 설정」으로 이동해 DNS 하이재킹과 자동 라우팅 옵션을 확인한 뒤 메인 화면에서 TUN을 켭니다. 처음 활성화할 때는 시스템 안내에 따라 필요한 권한을 부여합니다.
재시작 후 재검사
기존 코어를 종료하고
ipconfig /flushdns를 실행한 다음 v2rayN을 다시 시작합니다. 먼저 일반 웹페이지를 열어 연결을 확인한 뒤 DNS 확장 검사를 세 차례 실행합니다.
시스템 프록시와 TUN의 차이
- 시스템 프록시: 브라우저와 시스템 프록시를 능동적으로 읽는 데스크톱 프로그램에 적합합니다. 앱이 DNS 패킷을 직접 전송하면 조회가 물리 네트워크 어댑터를 통해 계속 나갈 수 있습니다.
- TUN 모드: 가상 네트워크 어댑터로 더 넓은 범위의 IP 트래픽을 가로채며, UDP와 독립 업데이트 프로그램, 시스템 프록시를 읽지 않는 프로그램을 통합 처리할 때 적합합니다.
- 혼합 사용: 모드를 전환한 뒤 기존 수동 프록시가 여전히 로컬 포트를 가리키는지 확인합니다. v2rayN의 일반적인 HTTP 포트는 10809, SOCKS 포트는 10808이지만 실제 값은 「설정」→「매개변수 설정」의 로컬 수신 설정을 기준으로 합니다.
- 라우팅 우선: DNS 서버 자체에도 라우팅 규칙이 적용됩니다. DNS 서버가 잘못된 차단 출구로 분류되면 검사 결과만 이상한 것이 아니라 모든 웹사이트가 해석되지 않는 경우가 많습니다.
오류:failed to find an available destination
원인 및 해결: 출구 서버 도메인을 해석할 수 없거나 사용 가능한 주소가 라우팅 규칙에서 모두 제외되었습니다. 먼저 노드 주소의 오탈자와 시스템 시간을 확인한 뒤 기본 DNS 템플릿으로 되돌리고 코어를 다시 시작합니다.
오류:lookup server.example: no such host
원인 및 해결: 현재 리졸버가 노드 도메인 결과를 반환하지 않았거나 조회가 사용할 수 없는 출구로 잘못 전달되었습니다. 우선 노드 서버 도메인에는 직접 연결 DNS를 사용해 연결을 확인한 뒤 라우팅을 복원합니다.
오류:bind: Only one usage of each socket address is normally permitted
원인 및 해결: 로컬 DNS 또는 프록시 포트를 다른 프로세스가 이미 사용 중입니다. 포트 점검 명령으로 해당 프로세스를 찾고 충돌하는 서비스를 종료하거나 「설정」→「매개변수 설정」에서 수신 포트를 변경한 뒤 해당 포트에 의존하는 설정도 함께 수정합니다.
v2rayNG 및 v2flyNG Android 설정
Android에서는 보통 시스템 VPN 서비스가 트래픽을 가로채며, DNS가 클라이언트를 거치는지는 로컬 DNS, 가상 DNS와 라우팅 설정에 따라 달라집니다. v2rayNG는 Xray 코어를, v2flyNG는 v2fly 코어를 사용하므로 코어 기능에 따라 메뉴 이름과 사용 가능한 옵션이 다를 수 있습니다. 다른 클라이언트의 고급 JSON을 그대로 복사하지 말고 현재 버전에 내장된 DNS 옵션으로 작동하는 기준부터 설정하세요.
클라이언트 업데이트
먼저 현재 다운로드 페이지에서 제공하는 안정 버전인지 확인합니다. 업그레이드 후 앱을 다시 열어 클라이언트가 설정 마이그레이션을 완료하도록 한 다음, 연결이 확인된 노드를 선택합니다.
로컬 DNS 활성화
v2rayNG에서 「설정」→「로컬 DNS」로 이동해 클라이언트가 DNS를 처리하는 옵션을 활성화하고 수신 포트가 다른 로컬 서비스와 충돌하지 않는지 확인합니다. 일반적인 DNS 수신 포트는 53 또는 클라이언트가 할당한 높은 번호의 포트이며, 실제 값은 화면에 표시된 내용을 따릅니다.
가상 DNS 확인
「설정」→「VPN 설정」에서 FakeDNS 또는 해당 가상 DNS 옵션을 확인합니다. 도메인 기준 라우팅이 필요하고 일반 조회로 대상 도메인이 너무 일찍 노출될 수 있다면 활성화할 수 있습니다. LAN 장치나 일부 앱의 연결에 문제가 생기면 먼저 이 옵션을 끄고 차이를 비교합니다.
앱별 규칙 확인
앱별 프록시를 활성화했다면 검사에 사용하는 브라우저가 프록시 범위에 포함되어 있는지 확인합니다. 브라우저가 제외되어 있으면 웹 요청과 DNS 조회가 모두 직접 연결 경로로 처리됩니다.
연결 해제 후 재연결
설정을 저장한 뒤 홈 화면으로만 돌아가지 말고 현재 연결을 먼저 중지한 다음 5초간 기다렸다가 다시 연결합니다. 이후 브라우저 프로세스를 종료하고 검사 페이지를 다시 열어 세 차례 테스트합니다.
| 설정 항목 | v2rayNG | v2flyNG |
|---|---|---|
| 주요 코어 | Xray | v2fly |
| 트래픽 가로채기 | 시스템 VPN 서비스 | 시스템 VPN 서비스 |
| 우선 확인 | 로컬 DNS, FakeDNS, 앱별 프록시 | 로컬 DNS, 라우팅 규칙, 앱별 프록시 |
| 변경 후 동작 | 연결을 중지하고 서비스를 다시 시작 | 연결을 중지하고 서비스를 다시 시작 |
결론: 조회를 먼저 가로챈 뒤 리졸버를 선택
DNS 주소만 한 공용 리졸버에서 다른 리졸버로 바꿔서는 클라이언트를 우회하는 조회를 해결할 수 없습니다. Android에서는 먼저 검사 브라우저가 VPN과 앱별 프록시 범위에 포함되어 있는지 확인한 뒤 로컬 DNS, FakeDNS와 라우팅 규칙을 조정해야 합니다.
재검사 실패 시 결과별 점검
설정 후에도 로컬 리졸버가 보인다고 해서 노드와 DNS 주소를 계속 바꾸지 마세요. 한 번에 하나의 변수만 변경합니다. 먼저 노드와 브라우저를 고정하고 브라우저 보안 DNS, 클라이언트 가로채기 모드, 시스템 캐시와 라우팅 규칙을 차례로 확인합니다. 여러 변수가 동시에 바뀌면 결과가 잠시 정상이어도 어떤 설정이 적용된 것인지 확인할 수 없습니다.
증상: 출구는 바뀌었지만 세 차례 모두 로컬 통신사 DNS가 표시됨
원인 및 해결: 웹 트래픽은 프록시를 통과하지만 DNS는 시스템 네트워크 어댑터에서 전송되고 있습니다. 데스크톱에서는 TUN으로 전환한 뒤 확인하고, Android에서는 로컬 DNS, VPN 서비스와 앱별 프록시 범위를 점검합니다.
증상: 첫 번째 검사는 정상이지만 두 번째 검사에서 추가 리졸버가 나타남
원인 및 해결: 보조 DNS, 브라우저 보안 DNS 또는 네트워크 전환이 원인일 수 있습니다. 네트워크를 고정하고 브라우저의 독립 DNS 기능을 끈 뒤 캐시를 삭제하고 30초 간격으로 세 번 연속 검사합니다.
증상: FakeDNS를 켠 뒤 LAN 도메인에 접근할 수 없음
원인 및 해결: LAN 도메인이 가상으로 해석되어 로컬 DNS로 전달되지 않았습니다. LAN 도메인과 사설 주소에 직접 연결 규칙을 추가하거나, FakeDNS를 잠시 끄고 차이를 확인합니다.
증상: DNS 변경 후 모든 웹사이트에서 해석할 수 없다고 표시됨
원인 및 해결: 리졸버 주소에 접근할 수 없거나 DNS 출구가 차단되었거나, 현재 코어가 설정 형식을 지원하지 않을 수 있습니다. 클라이언트 내장 템플릿으로 복원해 기본 연결을 확인한 뒤 사용자 지정 규칙을 하나씩 추가합니다.
정상적인 재검사 기록에 포함할 내용
- 클라이언트 이름, 버전 계열과 코어 종류. 예를 들어 v2rayN 7.x와 Xray처럼 기록하며, 단순히 “V2Ray 연결됨”이라고만 쓰지 않습니다.
- 시스템 프록시, TUN 또는 Android VPN 서비스 중 어떤 방식으로 트래픽을 가로챘는지 기록합니다.
- 검사 브라우저에서 별도의 보안 DNS를 사용하는지, 앱별 프록시 범위에 포함되어 있는지 기록합니다.
- 직접 연결 기준과 연결 후 결과에서 리졸버 소속이 어떻게 달라졌는지, 세 차례 검사 결과가 일치했는지 기록합니다.
- 재검사 시간, 현재 네트워크 유형과 Wi-Fi 전환 여부를 기록해 네트워크 환경 변화를 배제할 수 있도록 합니다.
리졸버가 두 개 감지되면 DNS 누출인가요?
반드시 그렇지는 않습니다. 하나의 DNS 서비스가 여러 출구 주소를 사용하거나, 부하 분산으로 서로 다른 지역의 리졸버가 반환될 수 있습니다. 먼저 소속이 예상과 맞는지 확인한 다음 직접 연결 기준의 통신사 리졸버가 섞였는지 살펴보세요.
노드를 바꿨는데 DNS 결과가 달라지지 않는 이유는 무엇인가요?
DNS는 클라이언트가 지정한 고정 리졸버가 처리할 수 있으므로 노드를 바꿔도 달라지지 않을 수 있습니다. 조회가 예상한 경로를 우회하지 않았다면 리졸버가 그대로인 것은 정상입니다.
시스템 프록시를 켠 뒤에도 TUN이 필요한가요?
브라우저처럼 시스템 프록시를 따르는 프로그램만 사용한다면 먼저 시스템 프록시를 사용할 수 있습니다. 게임, 독립 업데이트 프로그램 또는 UDP 조회를 직접 보내는 프로그램까지 처리하려면 TUN을 활성화하고 DNS 하이재킹 설정을 확인하세요.
브라우저 보안 DNS는 항상 꺼 두어야 하나요?
문제를 점검하는 동안에는 클라이언트의 처리 경로를 확인할 수 있도록 끄는 것이 좋습니다. 문제가 해결된 뒤 다시 켤 수 있지만, 브라우저가 선택한 리졸버와 프록시 정책이 예상과 맞는지 세 차례 재검사해야 합니다.
구독 업데이트 실패도 DNS와 관련이 있을 수 있나요?
그럴 수 있습니다. 구독 서버 도메인을 해석하지 못하면 업데이트가 바로 시간 초과됩니다. 먼저 구독 업데이트에 사용할 수 있는 프록시를 지정하거나 해당 도메인을 직접 연결 DNS로 해석한 뒤, 코어 로그에서 lookup과 timeout 정보를 확인합니다.