V2Ray DNS 유출 점검 및 차단 설정: v2rayN 원격 DNS와 FakeDNS 활용법

DNS 유출이란? 웹 트래픽과 DNS 조회 경로 구분하기

DNS는 도메인 이름을 IP 주소로 변환합니다. 웹 연결이 프록시를 통한다고 해서 도메인 조회 요청까지 프록시를 통하는 것은 아닙니다. 프록시를 통해 처리하려던 도메인을 앱이 로컬 네트워크의 DNS 리졸버에 먼저 보내면, 해당 네트워크에서 조회 내역을 알 수 있습니다. 바로 이런 경로 불일치를 해결해야 합니다.

v2rayN은 데스크톱 클라이언트이며, DNS 처리 방식은 사용 중인 코어와 인바운드 방식, 생성된 설정에 따라 달라집니다. VMess나 VLESS 같은 프로토콜 이름만으로 DNS 유출 여부를 판단할 수 없습니다. 프로토콜만 바꿔서는 브라우저가 자체적으로 DNS를 조회하거나 라우팅 순서가 잘못된 문제를 대개 해결하지 못합니다.

이 흐름은 문제를 진단하기 위한 모델이며 모든 요청이 반드시 같은 순서로 처리되는 것은 아닙니다. 앱이 로컬에서 먼저 DNS를 조회할 수도 있고, 코어가 IP 규칙을 적용하려고 먼저 조회할 수도 있습니다. 점검할 때는 두 가지를 확인하세요. 누가 조회를 시작했는지, 그리고 어떤 아웃바운드 경로로 요청을 보냈는지입니다.

• 원격 DNS: 프록시를 통해 조회해야 하는 도메인 요청을 처리합니다. 서버가 해외에 있다는 이유만으로 요청이 자동으로 프록시를 통하는 것은 아닙니다.
• 직접 연결 DNS: 직접 연결을 허용한 도메인의 조회를 처리하며, 로컬 접속 경로와 일치하도록 설정합니다.
• 브라우저 보안 DNS: 브라우저 자체의 암호화된 DNS 조회 경로입니다. 운영체제의 DNS 설정을 우회할 수 있지만, 프록시까지 우회하는지는 연결 경로에 따라 달라집니다.
• 노드 주소 조회: 프록시 서버에 연결하기 전에 완료해야 할 수 있습니다. 아직 연결되지 않은 동일한 프록시 경로에 의존하도록 설정하면 안 됩니다.

DNS 유출 검사: 기준 결과를 기록하고 프록시 사용 결과와 비교하기

DNSLeakTest 같은 검사 사이트에서 기본 검사 또는 확장 검사를 실행하고 리졸버의 주소, 운영 네트워크, 지역을 기록하세요. 검사 사이트에 표시되는 정보는 보통 최종 재귀 리졸버의 출구이며, 컴퓨터가 직접 연결한 DNS 주소와 다를 수 있습니다. 지역 데이터베이스도 정확하지 않을 수 있으므로 국가가 다르다는 이유만으로 결론을 내려서는 안 됩니다.

1. 기준 결과 기록: 프록시와 TUN을 끄고 브라우저를 다시 시작한 뒤, 민감한 정보가 필요 없는 DNS 검사 사이트에 접속하세요. 이때의 공인 IP와 DNS 리졸버 운영 네트워크를 기록합니다.
2. 일반 프록시 사용: 연결이 확인된 노드를 시작한 다음 v2rayN 트레이 메뉴에서 「시스템 프록시」→「시스템 프록시 자동 설정」을 선택하세요. 버전에 따라 메뉴 이름이 다를 수 있으니 실제 화면을 기준으로 진행합니다.
3. 같은 검사 반복: 먼저 웹 접속의 공인 IP가 바뀌었는지 확인한 뒤 DNS 검사를 실행하세요. 브라우저, 노드, 검사 페이지는 가능한 한 동일하게 유지합니다.
4. 브라우저 설정 분리: 현재 보안 DNS 설정을 기록하고, 잠시 끈 상태로 다시 검사하세요. 노드와 라우팅을 동시에 변경하면 어떤 조치가 효과가 있었는지 알 수 없습니다.
5. 다른 앱도 확인: 브라우저 검사에 통과한 뒤 대상 앱도 점검하세요. 시스템 프록시는 모든 시스템 트래픽을 가로채지 않습니다. 브라우저 하나의 검사 결과로 모든 프로그램을 판단할 수는 없습니다.

포트와 명령으로 확인하기: 로컬 DNS와 프록시 DNS 구분

먼저 「설정」→「매개변수 설정」에서 현재 로컬 수신 포트와 인바운드 유형을 확인하세요. 아래에서는 SOCKS 인바운드 포트로 10808을 예시로 듭니다. 모든 버전의 기본값이라고 단정하는 것은 아닙니다. 해당 포트가 SOCKS를 지원하는지 확인한 뒤에만 관련 명령을 사용하세요.

Windows에서는 PowerShell에서 다음 명령을 실행할 수 있습니다. 첫 번째 명령은 로컬 포트에 TCP 연결을 설정할 수 있는지만 확인합니다. 뒤의 두 명령은 도메인이 어디에서 조회되는지 비교할 때 사용합니다. 일부 환경에서는 curl이 다른 명령의 별칭으로 처리될 수 있으므로 curl.exe를 사용하면 이를 피할 수 있습니다.

Test-NetConnection 127.0.0.1 -Port 10808

curl.exe --socks5 127.0.0.1:10808 --connect-timeout 10 -I https://example.com

curl.exe --socks5-hostname 127.0.0.1:10808 --connect-timeout 10 -I https://example.com

• --socks5: curl이 로컬에서 대상 도메인을 조회한 뒤 대상 IP를 SOCKS 프록시에 전달합니다.
• --socks5-hostname: 도메인을 SOCKS 프록시에 전달하고, 이후 프록시 경로에서 조회를 처리합니다. 이 옵션만으로 최종적으로 어떤 DNS 서버를 사용했는지는 확인할 수 없습니다.
• 두 번째 명령만 성공한다면 우선 로컬 DNS 조회가 차단되었는지 확인하세요. 두 명령 모두 실패한다면 노드, 수신 포트, 아웃바운드 연결부터 점검합니다.
• nslookup example.com은 일반적으로 시스템에 설정된 DNS를 조회합니다. 시스템 HTTP 프록시를 켜도 v2rayN을 자동으로 통하지는 않습니다. 이 명령의 결과만으로 브라우저 검사 결과를 부정해서는 안 됩니다.

v2rayN 원격 DNS와 직접 연결 DNS: 주소와 아웃바운드 경로 함께 설정하기

변경 전에 클라이언트 설정을 백업하고 현재 노드, 라우팅 모드, DNS 설정을 기록하세요. 「설정」→「DNS 설정」에서 사용 중인 코어의 옵션을 확인합니다. 버전에 따라 DNS 설정이 매개변수 설정 화면에 있다면 해당 화면의 DNS 항목을 이용하세요. 코어마다 설정 구조가 다르므로 같은 JSON을 모든 코어에 붙여 넣으면 안 됩니다.

표의 주소는 설정 간 관계를 설명하기 위한 예시일 뿐, 반드시 사용해야 하는 서비스 목록이 아닙니다. 원격 DNS에 DoH를 사용하면 HTTPS 암호화로 전송 내용을 보호할 수 있지만, DoH 요청이 직접 연결로 나가면 로컬 네트워크에서는 DNS 서비스에 접속한 사실을 알 수 있습니다. DNS 트래픽도 로컬 출구를 벗어나게 하려면 라우팅 경로까지 함께 확인해야 합니다.

1. 먼저 범위 설정: 문제를 진단하는 동안에는 클라이언트의 전역 프록시 라우팅 모드를 임시로 사용해 분기 변수를 줄일 수 있습니다. 검사가 끝나면 평소 라우팅으로 되돌리고, 임시 모드를 최종 설정으로 착각하지 마세요.
2. 원격 조회 설정: 현재 코어가 지원하는 DNS 주소 형식으로 입력하세요. 일반 DoH와 일부 코어의 로컬 직접 연결 조회 모드는 서로 다릅니다. HTTPS라는 이유만으로 프록시를 통한다고 판단하면 안 됩니다.
3. 규칙 순서 확인: 해외 IP 직접 연결 규칙이나 리졸버 주소에 적용되는 직접 연결 규칙이 있다면 먼저 일치하는지 확인하세요. 규칙은 일반적으로 위에서부터 순서대로 적용되므로, 앞에서 직접 연결 규칙이 적용되면 뒤의 프록시 규칙으로 덮어쓸 수 없습니다.
4. 노드 도메인 초기 조회 설정: 노드 주소가 도메인이라면 프록시 연결 전에 사용할 수 있는 별도의 조회 경로를 마련하세요. 해당 노드를 통해야만 노드 도메인을 조회할 수 있도록 설정하지 마세요.
5. 저장 후 코어 재시작: 로그에 설정 오류가 없는지 확인한 다음 같은 검사를 다시 실행하세요. 라우팅을 분할 모드로 되돌렸을 때 문제가 재발한다면 도메인 규칙과 리졸버 아웃바운드 규칙을 집중적으로 확인합니다.

FakeDNS와 TUN: IP로 들어온 요청에서 도메인 식별하기

FakeDNS는 도메인에 실제 서버 주소를 직접 반환하지 않습니다. 대신 합성 IP를 할당하고 도메인과 합성 IP의 매핑을 저장합니다. 이후 해당 주소로 연결이 들어오면 코어가 도메인을 복원해 처리를 이어갈 수 있습니다. FakeDNS는 도메인 정보 전달 문제를 해결하는 기능이지, 독립적인 암호화 DNS 서비스가 아니며 프록시 아웃바운드 규칙을 대체하지도 않습니다.

Xray에서 흔히 사용하는 FakeDNS IPv4 주소 풀은 198.18.0.0/15이지만, 현재 생성된 설정을 기준으로 확인해야 합니다. 이 범위는 성능 테스트용이며 실제 웹사이트의 공인 IP 주소가 아닙니다. 요청과 후속 연결이 모두 FakeDNS를 지원하는 동일한 경로에서 처리되어야 매핑이 유효합니다.

1. 기본 프록시부터 확인: FakeDNS를 켜지 않은 상태에서 앞서 설명한 원격 DNS 검사를 완료하세요. 노드 연결이 안 되는 상황에서 여러 고급 설정을 한꺼번에 켜지 마세요.
2. 지원 여부 확인: 현재 TUN 구현과 코어가 해당 FakeDNS 또는 fake-ip 모드를 지원하는지 확인하세요. 이름이 비슷해도 설정을 서로 바꿔 쓸 수 있는 것은 아닙니다. 일반 SOCKS 환경에서는 검사를 위해 억지로 켤 필요가 없습니다.
3. DNS 가로채기 사용: 현재 클라이언트에서 제공하는 TUN 및 DNS 가로채기 옵션을 설정하세요. 가상 네트워크 어댑터만 켠다고 모든 DNS 조회가 코어로 전달되는 것은 아닙니다.
4. 도메인 복원 확인: 생성된 설정이 FakeDNS 매핑을 식별할 수 있는지 확인하고, 필요하다면 FakeDNS 스니핑 관련 설정도 점검하세요. 일반 스니핑에서 HTTP와 TLS 식별만 켜는 것으로 전체 설정이 완료되는 것은 아닙니다.
5. 캐시를 지운 뒤 재검사: 검사 대상 앱을 다시 시작하고 필요하면 아래 시스템 캐시 삭제 명령을 실행하세요. 브라우저에 별도의 캐시가 있을 수 있으므로 브라우저도 함께 재시작합니다.

ipconfig /flushdns

브라우저 내장 DoH, 앱 자체 DNS, IPv6는 흔히 놓치는 항목입니다. UDP 53만 가로채서는 모든 HTTPS 기반 DNS 조회를 처리할 수 없습니다. IPv6 라우팅이 가로채기 범위에 포함되지 않으면 앱이 다른 네트워크 경로로 접속할 수도 있습니다. 실제 지원 범위에 맞춰 IPv6를 설정하거나, 격리된 테스트에서 해당 어댑터의 IPv6를 잠시 끈 뒤 결과를 비교하세요. 임시 비활성화를 일반적인 해결책으로 간주해서는 안 됩니다.

DNS 설정 후 웹사이트가 열리지 않을 때: 로그로 실패 단계 찾기

먼저 로그에서 대상 주소, 사용된 아웃바운드, 실패 시각을 확인한 뒤 오류 키워드를 살펴보세요. 아래는 자주 보이는 오류 예시이며 매번 문구 전체가 똑같이 표시되는 것은 아닙니다. 원인을 찾기 위해 로그 상세 수준을 잠시 높일 수 있지만, 로그를 공유하기 전에 구독 주소, 노드 인증 정보, 개인적으로 접속한 도메인을 가리세요.

변경 후 일부 사이트만 접속되지 않는다면 분할 라우팅 규칙과 IPv6부터 확인하세요. 모든 사이트가 즉시 접속되지 않는다면 DNS 주소 형식, 노드의 초기 조회, TUN 라우팅을 먼저 점검합니다. 클라이언트가 설정을 정상적으로 불러오지 못한다면 규칙을 계속 추가하지 말고 이번 변경을 먼저 되돌리세요.

• 되돌리는 순서: DNS 백업을 복원하고 새로 추가한 FakeDNS 또는 TUN 설정을 끈 뒤 코어를 재시작하고 캐시를 삭제합니다.
• 상황 기록: 일반 프록시와 TUN 중 어느 모드에서 실패했는지, 어떤 리졸버를 사용했는지 기록하세요.
• 변수 통제: 매번 DNS 주소, 아웃바운드 규칙, 브라우저 보안 DNS 중 하나만 변경하세요.

자주 묻는 질문: 검사 결과와 DNS 유출 차단 설정 확인