FakeDNS는 가상 주소에 도메인 정보를 저장해, TUN이 트래픽을 가로챈 뒤에도 도메인 기준으로 분기할 수 있게 합니다. 속도 향상 기능도, 실제 DNS 조회를 대체하는 기능도 아닙니다. 가상 주소 반환부터 연결 가로채기, 도메인 복원, 아웃바운드 선택까지 작동 순서를 살펴보고, 사용 조건과 설정 확인 항목, 원상 복구 방법을 안내합니다. 연결은 정상적으로 되며 DNS와 라우팅 설정을 조정하려는 사용자에게 적합합니다.
FakeDNS가 도메인 정보를 저장하는 방식
일반 DNS는 도메인을 대상 서버의 IP 주소로 변환합니다. 앱이 연결을 시작하면 운영체제의 네트워크 계층에는 보통 대상 IP만 표시됩니다. 여러 도메인이 같은 IP를 사용하면 이 주소만으로는 앱이 원래 접속하려던 도메인을 알아내기 어렵습니다. FakeDNS는 응답 방식을 바꿔 가상 IP를 할당하고, 그 주소에 대응하는 도메인을 로컬에 저장합니다.
예를 들어 앱이 example.com을 조회하면 FakeDNS가 주소 풀에서 IP를 할당합니다. 앱이 해당 주소로 연결하면 프록시 코어는 매핑 테이블에서 example.com을 찾아 도메인 기준으로 라우팅을 판단합니다. 이 주소는 로컬 처리 과정에서 사용하는 표식일 뿐, 웹사이트 서버의 새 주소가 아니며 원격 노드 주소로 사용할 수도 없습니다.
가상 주소 풀과 실제 DNS의 차이
Xray의 FakeDNS 설정에서 흔히 사용하는 IPv4 주소 풀은 198.18.0.0/15입니다. 범위는 198.18.0.0부터 198.19.255.255까지이며, 네트워크 성능 측정용으로 예약된 주소 공간입니다. 인터넷에서 바로 접속할 수 있는 대상 주소가 아니며, 가정용 LAN의 사설 IP 대역과도 다릅니다.
주소 풀의 범위와 매핑 용량은 같은 개념이 아닙니다. 대역에 포함된 주소 수가 현재 코어가 실제로 보관하는 매핑 수와 일치한다고 볼 수 없습니다. 용량, 회수 정책, 재시작 후 매핑 유지 여부는 구현에 따라 다르므로, 특정 예시의 용량을 모든 클라이언트의 기본값으로 간주하지 마세요.
- 가상 응답: 앱이 로컬에서 식별할 수 있는 대상 표식을 먼저 전달합니다. 웹사이트의 실제 IP를 즉시 알아낼 필요는 없습니다.
- 실제 DNS 조회: 연결은 최종적으로 실제 서비스에 도달해야 합니다. 도메인을 원격 프록시에 전달하면 원격에서 조회할 수 있으며, 직접 연결할 때는 보통 로컬에서 실제 주소를 확인해야 합니다.
- 암호화 DNS: DNS 조회를 전송하는 방식을 보호하는 기능입니다. 가상 IP를 반환할지 여부와는 별개의 개념이므로 서로 대체할 수 없습니다.
TUN 모드에서 도메인 기준으로 트래픽 분기하기
TUN은 라우팅 조건에 맞는 IP 트래픽을 가상 네트워크 인터페이스로 전달하지만, 앱이 조회한 도메인 정보까지 자동으로 보존하지는 않습니다. FakeDNS를 사용하면 코어가 대상 가상 IP를 도메인으로 복원해 도메인 규칙을 적용할 수 있습니다. 특히 시스템 HTTP 프록시를 사용하지 않지만 TUN으로 가로챌 수 있는 앱에 유용합니다.
TUN과 가상 주소 연동
- DNS 응답
- 매핑을 지원하는 구성 요소가 가상 IP 반환
- 트래픽 진입점
- 가상 네트워크 인터페이스와 관련 라우팅
- 도메인 정보 출처
- 조회 결과와 연결 대상 사이의 주소 매핑
- 주요 확인 항목
- 주소 풀로 향하는 트래픽이 같은 처리 경로로 돌아오는지
TUN은 트래픽을 가로채고, 매핑은 도메인을 복원합니다. 두 기능이 모두 제대로 작동해야 전체 흐름이 완성됩니다.
시스템 프록시가 도메인 전달
- DNS 응답
- 가상 주소가 필요하지 않을 수도 있음
- 트래픽 진입점
- 앱에서 사용하는 HTTP 또는 SOCKS 프록시
- 도메인 정보 출처
- 프록시 요청에 포함된 대상 호스트명
- 주요 확인 항목
- 앱이 프록시에 도메인을 전달하는지
앱이 이미 프록시에 도메인을 전달한다면 FakeDNS는 보통 필요하지 않습니다.
도메인을 복원한 뒤 어떤 아웃바운드를 사용할지는 라우팅 규칙으로 결정됩니다. FakeDNS가 모든 트래픽을 자동으로 프록시로 보내거나 직접 연결 허용 목록을 만들어 주지는 않습니다. 도메인 규칙과 IP 규칙의 순서에 따라 적용 결과가 달라질 수 있습니다. IP 지리 정보로 트래픽을 분기한다면 규칙이 실제 DNS 조회로 얻은 대상 주소를 기준으로 판단하는지도 확인하세요.
FakeDNS를 사용하기 좋은 상황
현재 연결에서 어떤 정보가 사라졌는지 먼저 확인한 다음 사용 여부를 결정하세요. 앱 연결은 가로챌 수 있지만 코어 로그에는 대상 IP만 표시되어 예상한 도메인 규칙이 적용되지 않고, 앱의 DNS 조회도 같은 처리 경로에 포함할 수 있다면 테스트해 볼 만합니다. 이 두 조건이 모두 충족되어야 합니다.
| 사용 상황 | 권장 사항 | 우선 확인할 항목 |
|---|---|---|
| TUN으로 트래픽을 가로채며 도메인 규칙을 주로 사용하는 경우 | 사용해 볼 수 있음 | DNS 조회와 가상 주소 연결이 모두 가로채지는지 |
| 브라우저에서 시스템 프록시를 정상적으로 사용하는 경우 | 우선 현재 설정 유지 | 프록시 요청에 도메인이 이미 포함되어 있는지 |
| 업무용 VPN과 사내 도메인을 함께 사용하는 경우 | 먼저 제외 항목을 계획 | 기업 DNS, 사내 네트워크 대역, 라우팅 우선순위 |
| 앱에서 실제 IP를 저장하거나 검증해야 하는 경우 | 실제 DNS 조회 우선 | 가상 주소가 앱의 판단에 영향을 주는지 |
| 대상이 IP 주소 문자열인 경우 | 매핑으로 도메인을 복원할 수 없음 | IP 규칙으로 연결을 직접 처리 |
FakeDNS를 사용하면 실제 DNS 조회 결과를 기다린 뒤 전달 방식을 정해야 하는 경우가 줄어들 수 있지만, 다운로드 속도나 접속 지연이 개선된다고 보장할 수는 없습니다. 앱이 자체 암호화 DNS를 사용하면 조회가 로컬 매핑 서비스를 우회할 수도 있습니다. 일반 DNS 요청을 가로챘더라도 앱이 가상 IP가 아닌 실제 IP를 받을 수 있습니다.
활성화 전에 처리 경로의 네 가지 항목 확인
v2rayN 데스크톱에서 먼저 ‘설정’ 메뉴를 열어 현재 TUN, DNS, 라우팅 옵션을 확인하세요. 세부 메뉴 이름은 버전에 따라 다를 수 있습니다. Android용 v2rayNG는 Xray 코어를 사용하지만 VPN 권한이 승인되었다는 사실은 앱에서 트래픽 진입점을 만들 수 있다는 뜻일 뿐, FakeDNS 매핑이 작동한다는 의미는 아닙니다. 두 플랫폼 모두 원래 설정을 기록하고 한 번에 여러 항목을 바꾸지 마세요.
- 현재 설정을 백업하세요. DNS 서버, 라우팅 규칙, 사용 중인 코어 정보를 저장합니다. FakeDNS를 끈 상태에서 노드 연결이 정상인지 먼저 확인해 기존 연결 문제를 매핑 문제로 오인하지 않도록 하세요.
- DNS 진입점을 확인하세요. 대상 앱의 조회가 어떤 리졸버를 거치는지 확인합니다. 일반 DNS는 주로 UDP 또는 TCP의
53포트를 사용합니다. 브라우저에 내장된 암호화 DNS는 이 포트만 확인해서는 사용 여부를 알 수 없습니다. - 주소 풀 라우팅을 확인하세요.
198.18.0.0/15를 사용한다면 해당 대역이 업무용 네트워크에서 사용 중이지 않은지, 규칙에 의해 물리 네트워크 인터페이스로 먼저 제외되지 않는지 확인하세요. 특수한 네트워크에서 이 대역을 실제로 사용할 수 있으므로, 충돌이 발생하면 그대로 적용하지 마세요. - 도메인 복원 설정을 확인하세요. 현재 코어의 인바운드, 스니핑 또는 매핑 설정이 가상 IP에서 도메인을 복원하도록 구성되어 있는지 확인합니다. Xray의
fakedns,ipPool,poolSize등은 각각 역할이 다릅니다. 매핑을 처리하는 인바운드 설정은 빼고 주소 풀만 추가해서는 안 됩니다.
스니핑과 FakeDNS는 서로 다른 기능입니다. 스니핑은 HTTP 호스트명이나 TLS 핸드셰이크 정보에서 도메인을 식별할 수 있고, 매핑은 이전 DNS 조회 기록을 이용합니다. 트래픽 종류에 따라 얻을 수 있는 정보가 다르므로 모든 암호화 연결에서 스니핑으로 도메인을 복원할 수 있다고 가정하지 마세요. 클라이언트가 설정을 자동 생성하는 경우 생성 파일을 직접 수정해도 다음 실행 때 덮어써질 수 있습니다.
가상 IP와 규칙 적용 여부 확인하기
테스트에는 일반 도메인 하나와 직접 연결해야 하는 사내 대상 하나만 사용하세요. 기존 연결을 닫은 다음 다시 조회하고 접속합니다. 연결 재사용이나 DNS 캐시가 변경 전 결과를 계속 사용할 수 있으므로, 이미 열려 있는 웹페이지 하나만 보고 판단하지 마세요.
- 1단계: 조회 결과를 확인합니다. Windows에서
nslookup example.com을 실행할 수 있습니다. 이 도구의 조회 경로가 실제로 FakeDNS를 거친다면 응답은 설정된 주소 풀에 포함되어야 합니다. 결과가 다르더라도 기능이 고장 났다고 단정하지 말고, 도구가 앱에서 사용하는 조회 경로를 우회하는지 먼저 확인하세요. - 2단계: 코어 로그를 확인합니다. 도메인에 다시 접속해 로그에 원래 도메인, 적용된 규칙, 아웃바운드가 표시되는지 살펴보세요. 로그 수준에 따라 표시되는 항목이 다릅니다. 필요한 경우 잠시 로그 수준을 높인 뒤 확인을 마치면 원래대로 돌려놓으세요.
- 3단계: 직접 연결 대상을 확인합니다. 사내 도메인과 LAN 서비스를 테스트해 잘못 프록시 처리되지 않는지 확인하세요. ‘도메인, 조회 결과, 적용된 아웃바운드, 연결 성공 여부’를 기록하고 한 번에 설정 하나만 바꾸세요.
직접 연결 충돌과 비활성화 후 복구 방법
가장 흔한 실패 사례는 앱이 가상 IP를 받았지만 매핑을 인식하지 못하는 경로로 연결되는 경우입니다. 예를 들어 특정 프로세스는 TUN에서 제외했는데 시스템 DNS는 여전히 가로채이거나, 기업 VPN이 주소 풀 대역을 먼저 차지할 수 있습니다. 이런 문제는 노드 속도와 관련이 없으므로 노드를 계속 바꿔도 해결되지 않습니다.
활성화 후 특정 앱 하나만 직접 연결되지 않는다면 어떻게 하나요?
먼저 해당 프로세스가 TUN에서 제외되어 있는지 확인하세요. 직접 연결이 꼭 필요하다면 실제 DNS 응답을 사용하게 하고 연결도 직접 연결 경로로 보내야 합니다. DNS 제외와 트래픽 제외는 함께 설정해야 합니다. 프로세스만 제외하고 가상 주소를 계속 전달하면 안 됩니다.
FakeDNS를 껐는데도 시간 초과가 발생하는 이유는 무엇인가요?
앱이나 운영체제에 이전 가상 IP가 캐시되어 있을 수 있습니다. 원래 DNS 설정을 복원한 뒤 문제가 발생한 앱을 다시 시작하세요. Windows에서는 명령 프롬프트에서 ipconfig /flushdns를 실행해 시스템 DNS 캐시를 비운 다음 다시 연결할 수 있습니다. 브라우저 캐시와 기존 장시간 연결도 별도로 다시 생성해야 할 수 있습니다.
클라이언트를 다시 시작한 뒤 일부 연결이 갑자기 실패하면 어떻게 하나요?
‘앱에는 이전 DNS 결과가 남아 있지만 코어의 매핑 테이블은 새로 만들어진’ 상황인지 확인하세요. 기존 연결을 종료하고 관련 캐시를 비운 다음 다시 조회합니다. 구현에 따라 매핑을 저장할 수 있지만 지원 여부는 현재 백엔드에 달려 있으므로 재시작 전후의 매핑이 항상 같다고 가정해서는 안 됩니다.
가상 IP가 보이면 DNS가 유출되지 않았다는 뜻인가요?
아닙니다. 해당 조회에서 가상 응답을 받았다는 것만 알 수 있습니다. 다른 앱이나 레코드 유형, 브라우저 자체의 조회 경로는 다르게 작동할 수 있습니다. 시스템 리졸버, 앱의 암호화 DNS, IPv6 AAAA 조회를 각각 확인한 뒤 실제 라우팅 결과도 살펴보세요.
매핑 작동 여부를 확인하는 것보다 안정적인 접속이 목적이라면, 원인을 파악하기 쉽고 되돌릴 수 있는 설정을 우선하세요. 시스템 프록시가 도메인을 제대로 전달한다면 FakeDNS를 추가할 필요가 없습니다. TUN에서 도메인 기준으로 분기해야 할 때만 DNS, 매핑, 라우팅, 아웃바운드를 차례로 확인하세요. 원인을 알 수 없는 연결 실패가 발생하면 네트워크 옵션을 한꺼번에 바꾸지 말고 연결 문제 해결 절차를 따라 점검하세요.