FakeDNS 작동 원리와 사용 사례: v2rayNG에서 언제 켜야 할까

핵심 내용

FakeDNS는 연결은 정상적으로 되지만 도메인 식별과 DNS 경로를 개선하려는 v2rayNG 사용자에게 적합합니다. 먼저 가상 주소가 어떻게 복원되는지 이해하고, Android VPN의 트래픽 처리 범위와 도메인 라우팅, 앱 자체 DNS를 확인하세요. 이후 한 번에 한 가지씩 설정을 바꾸며 검증하면 됩니다. 연결할 수 없는 노드를 복구하거나 모든 앱의 DNS 조회가 프록시를 거치도록 보장하는 기능은 아닙니다.

FakeDNS 원리: 가상 주소로 도메인 정보 보존

일반 DNS 조회에서는 도메인이 서버의 실제 IP 주소로 변환되고, 앱은 해당 IP에 연결합니다. 투명 프록시 경로로 트래픽을 넘기면 프록시 코어가 대상 IP만 보고 앱이 처음 조회한 도메인을 알 수 없는 경우가 있습니다. 그러면 도메인 기반 라우팅 규칙이 적용되지 않아 스니핑이나 IP 매칭을 시도하거나 기본 아웃바운드로 넘어갈 수 있습니다.

FakeDNS는 ‘도메인과 가상 IP’의 매핑 테이블을 관리합니다. 앱이 도메인을 조회하면 풀에서 주소를 하나 할당하고, 앱이 해당 주소에 연결할 때 코어가 도메인을 찾아 라우팅 규칙에 따라 직접 연결하거나 프록시를 사용합니다. 이 주소는 웹 서버 주소가 아니므로 인터넷으로 직접 전송해서는 안 됩니다.

도메인 조회 가상 주소 할당 앱 연결 시작 대상 도메인 복원 아웃바운드 규칙 적용

Xray의 FakeDNS에서 흔히 사용하는 IPv4 풀은 198.18.0.0/15이며, 범위는 198.18.0.0부터 198.19.255.255까지입니다. 이 대역은 원래 네트워크 장비 성능 테스트용으로 예약된 주소이며, 접속 가능한 웹사이트의 공인 IP도 일반적인 가정용 사설 IP 대역도 아닙니다. DNS 응답에 이 범위의 주소가 포함되어 있어도 그 자체로 DNS 변조를 의미하지는 않습니다.

DNS 유출과 조회 지연: 개선되는 점과 보장할 수 없는 점

FakeDNS는 처리 대상인 조회에 로컬에서 응답을 생성하므로, 이 단계에서 실제 IP를 알아내기 위해 외부 DNS에 요청할 필요가 없습니다. 따라서 로컬 DNS가 대상 도메인을 직접 알게 될 가능성이 줄고, 앱이 외부 조회 결과를 기다리는 시간도 단축됩니다. 다만 웹사이트에 연결하려면 결국 실제 서버 주소를 알아야 합니다. 프록시 서버 측에서 조회할 수도 있고, 직접 연결이 필요한 경우에는 직접 연결 경로에서 조회할 수도 있습니다.

트래픽 경로	FakeDNS의 역할	추가 확인 사항
코어로 들어오는 일반 DNS 조회	로컬에서 가상 주소를 반환하고 도메인 매핑을 보존	UDP/TCP 53 조회가 실제 처리 경로에 들어오는지
도메인 정보와 함께 프록시 아웃바운드로 전달	복원된 도메인을 후속 연결 절차에 전달	서버 측 조회 정책과 DNS 출구
규칙에 따라 직접 연결 선택	규칙 적용을 위해 도메인을 먼저 복원	직접 연결 측에서 실제 주소를 조회하는 방식
앱 자체 암호화 DNS	해당 DNS 조회가 처리되지 않을 수 있음	앱 내 DoH 및 보안 DNS 설정
앱이 고정 IP에 직접 연결	조회가 없으면 도메인을 알아낼 수 없음	IP 규칙과 기본 아웃바운드

‘DNS 유출’ 여부는 설정 의도에 따라 판단해야 합니다. 규칙상 일부 도메인의 직접 연결을 허용했다면 해당 도메인이 직접 연결 경로에서 조회되는 것은 설정 오류가 아닐 수 있습니다. 확인할 점은 프록시로 처리해야 하는 도메인이 여전히 로컬 네트워크의 DNS 서버로 전달되는지 여부입니다. 검사 페이지에 표시된 DNS 서비스만으로 기기의 모든 앱이 같은 경로를 사용하는지 판단할 수는 없습니다.

정리: DNS 경로를 확인한 뒤 로딩 속도를 비교하세요

같은 노드와 라우팅 규칙을 유지한 채 대상 앱을 설정 전후로 비교하세요. 조회가 FakeDNS에 도달하고 후속 연결에서도 도메인이 제대로 복원되어야 최초 연결 대기 시간을 비교할 수 있습니다. 가상 주소를 더 빨리 받는다고 웹사이트 전체 로딩도 빨라지는 것은 아닙니다.

v2rayNG에서 켜기 전 확인할 사항: VPN, DNS, 도메인 복원

Android의 v2rayNG는 보통 시스템 VPN 서비스를 통해 가상 네트워크 인터페이스를 만들고 트래픽을 코어로 전달합니다. 데스크톱에서 말하는 TUN 트래픽 처리와 비슷한 방식이지만, 화면에 ‘TUN 모드’라는 별도의 스위치가 반드시 있는 것은 아닙니다. 먼저 VPN이 실행 중인지, 대상 앱이 제외되어 있지 않은지 확인한 뒤 FakeDNS를 설정하세요. v2rayN 데스크톱 메뉴를 그대로 적용하면 안 됩니다.

클라이언트 설정 위치 확인

기능 위치: 사이드바 ‘설정’ → ‘FakeDNS 사용’
관련 옵션: ‘로컬 DNS 사용’ 및 DNS 설정 항목
트래픽 처리 범위: ‘앱별 프록시’에서 앱 선택 확인
설정 적용 방법: 연결을 중지한 뒤 VPN 다시 시작

버전에 따라 메뉴 이름과 분류가 달라질 수 있습니다. 설치된 버전을 기준으로 확인하고, 이름이 비슷한 스위치를 같은 기능으로 간주하지 마세요.

코어 처리 경로 확인

DNS 응답: 조회가 FakeDNS로 전달되는지
주소 풀: 일반적인 IPv4 범위는 198.18.0.0/15
도메인 복원: fakedns에 맞는 스니핑 설정 확인
라우팅 기준: 도메인을 복원한 뒤 도메인 규칙 적용

자동 생성 설정은 보통 클라이언트가 관련 항목을 함께 처리합니다. 사용자 지정 설정은 주소 풀 하나만 추가했다고 해서 구성이 끝난 것이 아닙니다.

먼저 ‘설정’에서 DNS, 트래픽 스니핑, 라우팅 옵션을 기록한 다음 ‘FakeDNS 사용’을 켜세요. 현재 버전에서 관련 의존 항목을 안내하면 해당 설정도 함께 적용하세요. 안전을 위해 모든 DNS 옵션을 동시에 켜지는 마세요. 사용자 지정 설정은 화면에서 자동 생성되는 항목과 다를 수 있으므로, 스위치 상태만 보지 말고 실제 실행 설정을 확인해야 합니다.

일반 설정: 클라이언트에서 제공하는 FakeDNS 관련 설정을 우선 사용하고, 출처가 불분명한 DNS 설정을 따로 조합하지 마세요.
사용자 지정 설정: DNS에서 fakedns를 사용하는지 확인하고, 해당 인바운드의 sniffing과 destOverride에 필요한 FakeDNS 복원 처리가 포함되어 있는지 점검하세요.
앱별 프록시: 테스트할 앱이 VPN 트래픽 처리 범위에 포함되어야 합니다. 설정을 변경한 뒤 VPN을 다시 연결하고 앱도 종료 후 재실행하세요.
시스템 DNS: Android ‘설정’에서 ‘비공개 DNS’를 검색해 현재 상태를 기록하세요. 사용자 지정 암호화 DNS를 사용 중이라면 VPN과 실제로 어떻게 연동되는지 확인하고, UDP 53 규칙이 모든 조회를 처리한다고 가정하지 마세요.

도메인 라우팅과 IP 라우팅: 규칙 순서도 함께 확인

FakeDNS의 주요 이점 중 하나는 도메인을 복원해 도메인 규칙이 매칭할 대상을 제공하는 것입니다. 예를 들어 코어가 대상 도메인을 복원한 다음 지정된 도메인 규칙을 먼저 적용하고 나머지 규칙을 처리할 수 있습니다. 그러나 어떤 사이트를 직접 연결할지는 대신 결정해 주지 않으며, 누락된 규칙 리소스를 자동으로 보완하지도 않습니다.

라우팅 규칙은 보통 설정된 순서대로 적용됩니다. 사용자 지정 규칙에서 가상 주소 풀 전체를 너무 앞에서 직접 연결로 지정하고, 그 시점에 대상 도메인이 제대로 복원되지 않았다면 접속할 수 없는 주소로 트래픽이 전송될 수 있습니다. 또 흔한 오해는 ‘IP가 어느 지역에 속하는지’를 ‘도메인이 어떤 분류에 속하는지’와 동일시하는 것입니다. 가상 IP는 로컬 매핑을 나타낼 뿐이므로 실제 서버의 위치를 판단하는 데 사용할 수 없습니다.

먼저 도메인 복원을 확인하세요. 사용 가능한 로그나 실행 설정을 통해 인바운드에서 FakeDNS 주소를 복원하는지 확인하세요. 198.18.0.0/15에 먼저 직접 연결 규칙을 추가하지 마세요.
그다음 도메인 규칙을 확인하세요. 지정 도메인, 도메인 목록, 기본 아웃바운드의 순서가 의도한 대로인지 확인하세요. 특히 지나치게 포괄적인 규칙이 너무 일찍 적용되지 않는지 살펴보세요.
마지막으로 IP 판정을 확인하세요. IPIfNonMatch나 IPOnDemand 같은 도메인 조회 정책을 사용하면 라우팅 단계에서 실제 DNS 조회가 발생할 수 있습니다. 이것만으로 FakeDNS가 작동하지 않는다고 볼 수는 없습니다.
LAN 연결은 별도로 테스트하세요. 프린터, 라우터 관리 페이지, 내부 도메인은 로컬 DNS에 의존할 수 있습니다. 필요한 LAN 접근 규칙을 유지하고 VPN 라우팅이 해당 주소까지 적용되는지 확인하세요.

켜기와 되돌리기: 같은 앱으로 한 번에 한 가지만 검증

노드 연결은 정상인데 투명 프록시 처리 후 도메인 규칙이 자주 적용되지 않거나, 처리 대상인 일반 DNS 조회가 눈에 띄게 지연된다면 FakeDNS를 시도해 볼 수 있습니다. 현재 DNS 조회와 라우팅이 안정적이라면 켜도 체감되는 차이가 없을 수 있습니다. 서버 연결 거부, TLS 핸드셰이크 실패, 구독 업데이트 실패는 각 문제부터 해결해야 합니다. FakeDNS는 이런 오류를 모두 해결하는 기능이 아닙니다.

기준 상태를 기록하세요. FakeDNS를 끄고 노드, 라우팅, 네트워크를 그대로 유지한 채 브라우저, 대상 앱, LAN 서비스 하나가 어떻게 동작하는지 확인하세요. 단순히 ‘빠르다’ 또는 ‘느리다’고 적는 대신 접속 여부와 예상한 아웃바운드로 연결되는지 기록하세요.
FakeDNS 관련 설정만 바꾸세요. ‘설정’에서 기능과 클라이언트가 안내하는 필수 의존 항목을 켠 다음 VPN을 중지하고 다시 시작하세요. 이때 노드, DNS 서비스, 라우팅 모드를 동시에 바꾸지 마세요.
이전 연결의 영향을 없애세요. 테스트 앱을 완전히 종료한 다음 다시 실행하세요. 앱이 DNS 캐시를 계속 사용한다면 강제 종료 후 테스트할 수 있습니다. 브라우저의 ‘보안 DNS’ 설정도 확인하세요.
조회와 연결 결과를 모두 확인하세요. 일반 DNS 테스트에서 풀에 속한 주소가 보일 수 있지만, 이후 실제 접속도 성공해야 합니다. 조회만 성공하고 연결이 실패하면 매핑 복원, VPN 트래픽 처리, 이전 캐시를 중점적으로 확인하세요.
문제가 생기면 설정을 완전히 되돌리세요. 기존 스위치 상태를 복원하고 VPN을 다시 시작한 뒤 앱을 재실행하세요. 앱이 이전 가상 주소를 계속 사용한다면 캐시가 만료될 때까지 기다리거나 기기를 재시작하세요. 가상 IP를 장기간 고정해 문제를 피하려고 하지 마세요.

정리: 복원·라우팅·복구가 모두 가능할 때만 켜 두세요

설정 후 일부 앱만 작동하지 않는다면 전역 규칙을 계속 추가하기보다 해당 앱의 암호화 DNS, 앱별 프록시 설정, 캐시부터 확인하세요. 실제 설정 경로를 확인하기 어렵다면 여러 DNS·스니핑 옵션을 동시에 변경하는 것보다 원래 설정으로 되돌리는 편이 문제를 찾기 쉽습니다.

FakeDNS 자주 묻는 질문: 이상한 주소, 앱 오류, 네트워크 전환

조회 결과가 198.18로 시작하면 노드에 문제가 있는 건가요?

먼저 ‘설정’ → ‘FakeDNS 사용’이 켜져 있는지 확인하세요. 주소가 설정된 풀의 범위에 속한다면 예상된 가상 응답입니다. 이어서 대상 사이트에 실제로 접속해 보세요. 연결 시 복원되지 않을 때 VPN 트래픽 처리, 스니핑 설정, 앱의 이전 캐시를 확인하면 됩니다. 주소 형태만 보고 노드가 작동하지 않는다고 판단하지 마세요.

브라우저는 되는데 다른 앱은 계속 로딩 중일 때는 어떻게 하나요?

‘앱별 프록시’에서 해당 앱이 처리 대상인지 확인한 뒤, 앱 자체에 별도의 보안 DNS가 설정되어 있는지 살펴보세요. 노드는 그대로 두고 FakeDNS를 끈 다음 VPN을 재시작하고 앱을 강제 종료한 뒤 다시 테스트하세요. 켰을 때만 실패한다면 해당 앱이 가상 주소의 반환 경로를 우회하는지 확인하세요.

켜도 DNS 검사에 로컬 DNS 서비스가 표시되면 유출인가요?

먼저 검사한 도메인의 아웃바운드 경로를 확인하세요. 규칙에 따라 직접 연결되었거나 앱 자체 암호화 DNS로 조회되었을 수 있습니다. 프록시를 사용하도록 설정한 도메인으로 다시 테스트하고 브라우저의 ‘보안 DNS’와 시스템의 ‘비공개 DNS’를 확인하세요. DNS 서비스 이름만으로 결론 내리지 말고 라우팅 대상과 함께 판단해야 합니다.

Wi-Fi에서 모바일 네트워크로 바꾼 뒤 접속이 안 되면 구독을 다시 가져와야 하나요?

먼저 VPN을 중지했다가 다시 시작하고 앱도 종료 후 재실행해 이전 연결과 매핑 캐시가 맞지 않는 문제를 배제하세요. 구독은 노드 설정을 관리할 뿐 앱의 DNS 캐시를 갱신하지 않습니다. 노드 자체에도 연결할 수 없을 때만 네트워크 연결 상태와 노드 설정을 점검하세요.

v2flyNG에 v2rayNG 설정을 그대로 복사해도 되나요?

기능 이름만 보고 그대로 복사해서는 안 됩니다. v2rayNG는 Xray 코어를 사용하고 v2flyNG는 V2Fly 코어를 사용합니다. 두 클라이언트 모두 관련 기능을 제공하더라도 지원하는 항목, 기본값, 화면에서 설정을 생성하는 방식이 다를 수 있습니다. 사용 중인 클라이언트와 코어의 지원 여부를 확인하고 DNS, 인바운드, 라우팅 설정을 각각 점검하세요.