프록시 클라이언트에 연결 성공이라고 표시되어도 노드 핸드셰이크와 일부 아웃바운드 트래픽을 사용할 수 있다는 뜻일 뿐, 도메인 조회까지 같은 프록시 경로로 들어갔다는 의미는 아닙니다. 브라우저가 웹사이트에 접속하기 전에는 보통 도메인을 IP 주소로 변환해야 합니다. 이 과정이 로컬 네트워크, 라우터 또는 통신사 DNS에 맡겨져 있다면 콘텐츠는 프록시를 거쳐도 어떤 도메인을 조회했는지는 다른 경로로 전송될 수 있습니다.
DNS 유출을 점검할 때 검사 페이지에 어느 국가나 지역이 표시되는지만 봐서는 안 되며, 모든 로컬 리졸버를 이상으로 간주해서도 안 됩니다. 애플리케이션 트래픽을 가로채는 방식, 시스템 DNS, 브라우저 보안 DNS, 클라이언트 원격 DNS와 라우팅 규칙을 함께 확인한 뒤, 변경 전후 결과를 비교해 경로가 실제로 하나로 수렴했는지 판단해야 합니다.
이 글은 VMess, VLESS 등의 노드에는 연결되지만 DNS 검사 결과에 여전히 로컬 리졸버가 표시되거나, 웹페이지에서 간헐적으로 이름 조회가 실패하거나, 분할 라우팅 결과가 이상한 사용자를 위한 내용입니다. 검사 기준선을 세운 뒤 v2rayN과 v2rayNG를 각각 설정하고, 로그·시스템 명령·반복 테스트로 해결 결과를 확인합니다.
DNS 유출은 경로의 어디에서 발생할까
일반적인 웹 요청에는 최소한 ‘애플리케이션의 도메인 요청, DNS의 주소 응답, 애플리케이션의 대상 주소 연결, 라우팅 규칙의 아웃바운드 선택’ 단계가 포함됩니다. 시스템 프록시는 주로 HTTP 또는 SOCKS 프록시를 지원하는 애플리케이션의 연결을 가로채지만, 운영체제가 생성한 UDP 53 조회가 자동으로 프록시를 거친다고 보장할 수는 없습니다. Xray 코어에 원격 DNS를 설정했더라도 애플리케이션이 시스템 리졸버를 직접 호출하면 코어가 해당 조회를 아예 보지 못할 수 있습니다.
TUN 모드는 가상 네트워크 어댑터로 더 넓은 범위의 IP 트래픽을 가로채므로 시스템 프록시 설정을 읽지 않는 프로세스와 DNS 패킷도 라우팅에 포함할 수 있습니다. Android의 v2rayNG는 보통 시스템 VPN 인터페이스를 이용해 비슷한 방식으로 트래픽을 가로챕니다. 하지만 가로채기는 첫 단계일 뿐이며, 이후에도 53·853·443 포트의 DNS 트래픽이 직접 연결 규칙에 의해 먼저 허용되지 않는지 확인해야 합니다.
브라우저에 내장된 보안 DNS도 또 다른 변수입니다. 브라우저가 시스템 DNS를 우회해 지정된 DoH 서비스로 HTTPS 요청을 직접 보낼 수 있으며, 이 요청은 검사 페이지에서 다른 DNS 서비스로 표시됩니다. 유출 여부는 익숙한 DNS 이름이 표시되는지가 아니라 해당 HTTPS 연결이 최종적으로 직접 연결되는지 프록시를 거치는지에 따라 결정됩니다.
재현 가능한 DNS 검사 기준선 만들기
먼저 설정을 서둘러 변경하지 마세요. 수정 전 상태를 기록해야 실제 개선과 검사 페이지 캐시를 구분할 수 있습니다. 같은 브라우저·네트워크·노드를 사용해 세 차례 테스트하고, 매번 검사 탭을 닫은 뒤 약 30초 기다리는 것이 좋습니다. 표준 테스트는 리졸버를 빠르게 확인하고, 확장 테스트는 더 많은 무작위 도메인 조회를 발생시켜 로컬 DNS와 원격 DNS가 동시에 사용되는 상황을 발견하는 데 유리합니다.
-
현재 모드 기록
클라이언트 이름, 코어 종류, 노드 프로토콜과 트래픽 가로채기 모드를 기록하세요. 예: v2rayN 7.x, Xray 코어, VLESS 노드, 시스템 프록시 모드. ‘프록시 켜짐’이라고만 적지 마세요.
-
다른 네트워크 도구 일시 종료
동시에 실행 중인 다른 프록시, 기업 네트워크 접속 도구와 별도 DNS 도구를 종료하세요. 여러 가상 네트워크 어댑터나 로컬 수신 포트가 결과에 함께 영향을 주는 것을 막을 수 있습니다.
-
브라우저 DNS 확인
브라우저의 개인정보 보호 또는 보안 설정에서 ‘보안 DNS 사용’ 옵션과 제공업체를 기록하세요. 첫 기준선 측정에서는 시스템과 클라이언트 경로를 구분하기 위해 이 기능을 잠시 꺼도 됩니다.
-
확장 검사 실행
신뢰할 수 있는 DNS 유출 검사 페이지를 열고 표준 테스트와 확장 테스트를 진행하세요. 리졸버 이름, 주소 수, 지역과 첫 조회에 걸린 시간을 기록합니다.
-
연결 해제 후 비교
클라이언트 연결을 끊고 네트워크 연결을 새로 고친 다음 한 번 더 테스트하세요. 연결 전후 리졸버가 완전히 같은데 웹 출구 주소만 크게 달라진다면 DNS가 프록시 경로를 따라가지 않았을 가능성이 큽니다.
Windows에서는 시스템 명령으로 현재 네트워크 어댑터가 받은 DNS 주소를 확인할 수 있습니다. 이 방법은 시스템이 어디로 조회하려는지만 보여 줄 뿐 패킷이 최종적으로 어느 아웃바운드를 거쳤는지는 단독으로 증명하지 못합니다. 그래도 라우터 주소, 오래된 가상 어댑터와 수동으로 입력한 리졸버를 찾는 데 유용합니다.
Get-DnsClientServerAddress -AddressFamily IPv4
Resolve-DnsName example.com
ipconfig /flushdns목록에 물리 네트워크 어댑터, 가상 어댑터와 연결이 끊긴 오래된 어댑터가 함께 보이면 먼저 기본 경로를 가진 현재 어댑터를 확인하세요. 설정을 바꾼 뒤 캐시를 비우고 무작위 도메인을 다시 조회합니다. 같은 도메인을 반복 조회하면 시스템·브라우저·클라이언트 캐시에서 바로 응답할 수 있어 새로운 외부 요청이 발생하지 않습니다.
오류:DNS request timed out.
원인 및 해결: 시스템에 설정된 DNS에 연결할 수 없거나 현재 네트워크가 53 포트를 차단하고 있습니다. 먼저 접근 가능한 리졸버로 복구한 뒤 TUN 라우팅이 DNS를 가로채는지 확인하세요.
오류:server failed
원인 및 해결: 리졸버가 SERVFAIL을 반환했습니다. 업스트림 장애, 도메인 검증 실패 또는 전달 경로 설정 오류가 원인일 수 있습니다. 원격 DNS를 변경하고 캐시를 비운 뒤 다시 테스트하세요.
v2rayN 해결 경로: 시스템 프록시와 TUN을 나누어 처리하기
v2rayN에서 시스템 프록시를 사용하면 브라우저의 HTTP/HTTPS 요청은 보통 로컬 프록시 포트로 들어가지만, Windows DNS는 여전히 네트워크 어댑터에 설정된 리졸버로 직접 전송될 수 있습니다. 흔히 사용하는 로컬 수신 포트 조합은 SOCKS 10808과 HTTP 10809이며, 정확한 값은 「설정」→「매개변수 설정」의 로컬 포트를 기준으로 확인하세요. 포트가 정상적으로 수신 중이어도 UDP 53이 가로채졌다는 뜻은 아닙니다.
목표가 프록시를 지원하는 브라우저에서 지정한 조회 경로를 사용하게 하는 것이라면 브라우저 보안 DNS도 조정하고 해당 DoH 요청이 프록시를 통해 전송되는지 확인하세요. 더 많은 데스크톱 프로그램, 명령줄 도구와 시스템 조회 요청까지 포함하려면 TUN을 사용하고 DNS 하이재킹 및 라우팅 규칙을 점검해야 합니다. 두 방식의 적용 범위는 다르므로 시스템 프록시 모드의 검사 결과를 TUN과 동일하게 보면 안 됩니다.
-
코어 종류 확인
「설정」→「매개변수 설정」→「Core 유형」으로 이동해 현재 사용하는 코어가 노드 프로토콜과 호환되는지 확인하세요. 코어를 변경했다면 이전 프로세스가 설정을 계속 사용하는 일이 없도록 클라이언트를 한 번 재시작합니다.
-
원격 DNS 설정
「설정」→「DNS 설정」을 열고 원격 DNS에 명확한 DNS 서비스를 입력하세요. 먼저 1.1.1.1 또는 8.8.8.8로 단일 변수 테스트를 진행한 뒤 안정성이 확인되면 네트워크 환경에 맞게 조정할 수 있습니다.
-
TUN 가로채기 활성화
메인 화면에서 TUN 모드를 활성화하고 가상 네트워크 어댑터 생성에 필요한 시스템 권한을 허용하세요. 활성화 후 가상 어댑터가 존재하고 기본 경로가 다른 네트워크 도구에 의해 덮어쓰이지 않았는지 확인합니다.
-
DNS 분할 확인
라우팅 규칙에서 DNS 서버 주소, UDP 53, TCP 853과 사용하는 DoH 도메인에 적용되는 규칙을 확인하세요. 프록시로 보내야 하는 조회가 ‘로컬 네트워크 직접 연결’이나 지나치게 넓은 IP 규칙에 의해 먼저 처리되어서는 안 됩니다.
-
캐시를 비운 뒤 재시작
브라우저를 닫고
ipconfig /flushdns를 실행한 다음 v2rayN 코어를 재시작하고 검사 페이지를 다시 여세요. 새 무작위 도메인으로 조회를 발생시켜 이전 캐시를 읽지 않도록 합니다.
Xray의 DNS 모듈은 라우팅 판단을 위해 도메인을 조회하거나 요청을 지정한 업스트림에 전달할 수 있지만, 모든 시스템 요청을 자동으로 가로채지는 않습니다. 요청이 코어에 들어와야 DNS 설정이 적용될 수 있습니다. 로그에 대상 연결 기록만 있고 해당 DNS 조회가 없다면 업스트림 주소를 계속 바꾸기보다 먼저 트래픽 가로채기 모드를 확인하세요.
오류:failed to lookup ip
원인 및 해결: 코어가 현재 DNS 설정으로 노드 또는 대상 주소를 가져오지 못했습니다. 서버 주소 오탈자, 원격 DNS 연결 가능 여부와 DNS 아웃바운드 규칙을 확인한 뒤 코어를 재시작하세요.
오류:no such host
원인 및 해결: 도메인이 존재하지 않는다는 응답을 받았거나 로컬 캐시에 실패 결과가 남아 있습니다. 구독의 서버 도메인이 완전한지 확인하고 시스템 DNS 캐시를 비운 뒤 다른 원격 리졸버로 다시 테스트하세요.
오류:context deadline exceeded
원인 및 해결: 업스트림 DNS가 제한 시간 안에 응답하지 않았습니다. DoH 연결이 직접 연결 규칙에 의해 차단될 때 흔히 발생합니다. 443 포트 아웃바운드와 도메인 규칙을 확인하고, 필요하면 먼저 일반 원격 DNS로 바꿔 원인을 좁히세요.
v2rayNG 해결 경로: VPN 가로채기와 프라이빗 DNS 함께 점검하기
v2rayNG가 시스템 VPN 인터페이스로 트래픽을 가로채면 DNS가 데스크톱 시스템 프록시보다 터널에 들어가기 쉬운 편이지만, ‘프라이빗 DNS’, 앱별 프록시, 로컬 네트워크 우회와 라우팅 규칙의 영향을 받을 수 있습니다. v2rayNG에서 Xray 코어를 사용할 때 원격 DNS, 도메인 정책과 FakeDNS는 서로 다른 설정 항목입니다. 유출을 점검할 때는 먼저 일반 원격 DNS의 안정적인 기준선을 만든 뒤 FakeDNS 사용 여부를 결정하세요.
시스템 프라이빗 DNS는 보통 DoT, 즉 TCP 853을 사용합니다. 프라이빗 DNS에 특정 호스트 이름이 지정되어 있으면 시스템은 계속 해당 서비스에 연결을 시도합니다. 이 연결이 현재 노드를 통과하는지는 VPN 가로채기 범위와 분할 라우팅 규칙에 따라 달라집니다. 변수를 분리하려면 첫 점검에서 시스템 「설정」→「네트워크 및 인터넷」→「프라이빗 DNS」를 ‘자동’ 또는 ‘사용 안 함’으로 잠시 설정한 뒤 v2rayNG 검증을 마치고 항목별로 원래 설정을 복원하세요.
-
실행 모드 확인
v2rayNG에 VPN 연결 상태가 표시되고 상태 표시줄에 시스템 VPN 아이콘이 있는지 확인하세요. 설정만 변경하고 연결을 시작하지 않았다면 원격 DNS가 다른 애플리케이션의 요청을 가로채지 못합니다.
-
원격 DNS 입력
왼쪽 상단 메뉴에서 「설정」→「원격 DNS」를 열고 연결 가능한 DNS 주소를 하나 입력하세요. 테스트 단계에서는 동작이 불분명한 업스트림을 여러 개 동시에 입력하지 마세요. 결과의 원인을 파악하기 어려워집니다.
-
로컬 DNS 확인
「설정」에서 「로컬 DNS」와 「로컬 DNS 사용」을 확인하세요. 로컬 DNS는 주로 클라이언트 측 조회 진입점을 처리하고, 원격 DNS는 코어에 들어온 뒤 사용할 업스트림 경로를 결정합니다. 두 항목을 하나로 혼동해서는 안 됩니다.
-
앱별 우회 끄기
점검 중에는 앱별 프록시를 잠시 끄거나 브라우저와 검사 도구가 프록시 목록에 포함되어 있는지 확인하세요. 제외된 앱은 물리 네트워크를 직접 사용하므로 검사 결과가 노드 출구와 달라지는 것이 정상입니다.
-
다시 연결하고 재검사
연결을 중지하고 약 10초 기다린 뒤 다시 시작하세요. 브라우저를 강제 종료한 후 다시 열고 확장 검사를 두 차례 진행한 다음, 모바일 네트워크와 Wi-Fi에서 각각 기록한 결과를 비교합니다.
v2rayNG와 v2flyNG는 코어 구현이 다르며 설정 이름과 사용 가능한 기능도 버전에 따라 달라질 수 있습니다. v2rayNG의 Xray DNS 설정을 v2flyNG의 v2fly 코어 설정에 그대로 사용할 수는 없습니다. 구독을 옮겨도 기기의 DNS·라우팅·앱별 설정까지 자동으로 복사되지는 않으므로 클라이언트를 바꾼 뒤에는 기준선을 다시 만들어야 합니다.
오류:Unable to resolve host
원인 및 해결: 애플리케이션 또는 코어가 도메인 결과를 받지 못했습니다. 먼저 VPN 연결을 확인한 뒤 원격 DNS, 시스템 프라이빗 DNS와 현재 네트워크가 해당 포트를 차단하는지 점검하세요.
오류:network is unreachable
원인 및 해결: DNS 업스트림이 사용할 수 없는 인터페이스로 라우팅되었습니다. Wi-Fi 전환 후 이전 VPN 경로가 갱신되지 않았을 때 흔히 발생합니다. v2rayNG를 중지하고 네트워크를 한 번 전환한 뒤 다시 연결하세요.
재검사 결과가 어떤 상태여야 해결된 것일까
해결이 완료되었다고 해서 검사 페이지에 주소 하나만 표시되어야 하는 것은 아닙니다. 공용 DNS 서비스는 애니캐스트를 사용하므로 같은 서비스가 조회마다 여러 출구를 반환할 수 있고, 일부 검사 페이지는 리졸버 프런트엔드와 실제 재귀 노드를 나누어 표시합니다. 더 신뢰할 수 있는 기준은 클라이언트 연결 후 가정용 라우터, 현재 네트워크 사업자 또는 예상하지 않은 로컬 리졸버가 더 이상 나타나지 않고, 클라이언트·브라우저·기기를 재시작한 뒤에도 결과가 유지되는 것입니다.
분할 라우팅도 검증해야 합니다. 중국 본토 도메인은 규칙에 따라 직접 연결하고 그 외 도메인은 프록시로 보내는 경우, DNS도 도메인 그룹별로 서로 다른 업스트림을 사용할 수 있습니다. 이는 설계에 따른 결과이므로 ‘리졸버 하나만 표시되게 하기’를 단순한 목표로 삼아서는 안 됩니다. 중요한 것은 각 조회 그룹과 해당 아웃바운드가 일치하는지, 로컬 DNS로 네트워크의 영향을 받은 주소를 먼저 얻은 뒤 연결만 프록시로 넘기는 일이 없는지입니다.
출구 주소는 바뀌었는데 DNS 결과는 왜 그대로일까?
시스템 프록시는 웹 연결만 가로채고 시스템 DNS는 여전히 물리 네트워크 어댑터를 통해 전송하고 있습니다. v2rayN에서 TUN으로 전환하고 DNS 라우팅을 확인하세요. 변경 후 캐시를 비우고 다시 테스트합니다.
검사 페이지에 원격 리졸버 두 개가 표시되는데 정상일까?
정상일 수 있습니다. 두 리졸버가 모두 선택한 업스트림 또는 그 재귀 노드에 속하는지 확인하고 세 차례 반복 테스트를 진행하세요. 프록시 연결을 끊은 뒤에도 하나가 계속 고정되어 나타난다면 로컬 네트워크 설정을 점검하세요.
FakeDNS를 켜면 반드시 해결될까?
그렇게 단정할 수 없습니다. FakeDNS는 가상 주소에 도메인 매핑을 저장하며 TUN 및 도메인 분할 라우팅과 함께 사용하기 좋지만, 가로채지 못한 조회를 해결하지는 않습니다. 먼저 DNS 패킷이 코어에 들어가는지 확인해야 합니다.
노드를 바꿔도 다시 점검해야 할까?
네, 필요합니다. 노드마다 적용되는 라우팅, 출구 지역과 DNS 업스트림이 다를 수 있습니다. 최소 한 번은 표준 테스트를 실행하고, 리졸버 변화가 이상하면 확장 테스트도 진행하세요.
웹페이지는 정상인데 구독 업데이트가 실패하면 어떻게 할까?
구독 업데이트 프로세스가 별도의 네트워크 경로를 사용할 수 있습니다. 구독 설정에서 프록시를 통한 업데이트가 허용되어 있는지 확인하고, 코어 로그에서 도메인 조회 시간 초과나 연결 시간 초과 기록을 찾으세요.
최종 확인 체크리스트
- 클라이언트를 재시작한 뒤 노드에 정상적으로 연결되고, VMess 또는 VLESS 핸드셰이크 로그에 지속적인 조회 오류가 없습니다.
- 표준 테스트와 확장 테스트 모두 현재 가정용 라우터나 예상하지 않은 통신사 리졸버를 표시하지 않습니다.
- Windows의 물리 네트워크 어댑터, TUN 가상 어댑터와 오래된 가상 어댑터 사이에 충돌하는 기본 경로가 없습니다.
- Android의 프라이빗 DNS, 앱별 프록시와 v2rayNG 원격 DNS 설정이 현재 트래픽 가로채기 목표에 맞습니다.
- 브라우저 보안 DNS 옵션을 기록했으며, 다시 활성화한 뒤 HTTPS 요청이 예상한 아웃바운드를 통과하는지 확인했습니다.
- 노드와 Wi-Fi·모바일 네트워크를 전환한 뒤 각각 최소 한 번씩 재검사했으며, 결과가 로컬 조회 경로로 돌아가지 않습니다.
재검사 결과가 여전히 불안정하다면 ‘애플리케이션이 가로채졌는가, DNS 요청이 코어에 들어가는가, 업스트림에 연결할 수 있는가, 라우팅 규칙이 적용되는가, 캐시를 비웠는가’ 순서로 확인하세요. TUN·DNS·라우팅·브라우저 설정을 동시에 바꾸지 말고 매번 변수 하나만 변경해 결과를 저장해야 실제 경로에 영향을 준 설정을 찾을 수 있습니다.