V2Ray FakeDNS란? 가상 IP 매핑 원리와 사용 시점

핵심 내용

FakeDNS는 도메인을 합성 IP에 임시로 연결한 뒤, 연결이 프록시로 들어오면 도메인을 복원합니다. 도메인 정보를 유지해야 하는 투명 프록시 경로에 적합하며, 단독으로 속도를 높이는 기능은 아닙니다. 주소 할당, DNS 가로채기, TUN 트래픽 전달, 스니핑을 통한 복원 과정을 살펴보고 설정 예시와 확인 방법, 사용 중지 후 복구 방법까지 안내합니다. 기본 연결을 마치고 DNS 설정을 조정하려는 사용자에게 적합한 내용입니다.

FakeDNS란? 웹사이트의 실제 IP 대신 매핑 주소를 반환

일반 DNS는 도메인을 서버의 실제 주소로 변환합니다. 반면 FakeDNS는 현재 프록시 경로에서만 식별할 수 있는 주소를 먼저 할당합니다. 예를 들어 앱이 example.com을 조회하면 FakeDNS는 주소 풀에서 198.18.0.1을 반환하고, 메모리에 두 주소의 대응 관계를 저장할 수 있습니다. 이 주소는 해당 웹사이트의 서버 주소가 아니며, 공용 인터넷으로 직접 라우팅해서는 안 됩니다.

앱에서 도메인 조회 합성 주소 할당 프록시로 연결 전달 매핑을 통해 도메인 복원 라우팅에 따라 아웃바운드 선택

이후 앱은 합성 주소로 연결을 시도합니다. 프록시가 연결을 받으면 매핑 테이블에서 원래 도메인을 찾아 도메인 규칙에 따라 직접 연결할지 프록시를 사용할지 결정합니다. 최종적으로 실제 IP를 얻는 방법은 아웃바운드 유형과 DNS 확인 정책에 따라 다릅니다. 로컬 직접 연결 아웃바운드가 조회하거나, 원격 프록시에 도메인 처리를 맡길 수 있습니다. FakeDNS를 사용해도 실제 서버에 연결해야 한다는 점은 달라지지 않습니다.

흔히 사용하는 예시 대역은 198.18.0.0/15이며, 198.18.0.0부터 198.19.255.255까지의 특수 용도 주소 공간입니다. 원래 네트워크 장비 성능 테스트용으로 지정된 대역으로, 임의로 접속할 수 있는 공용 웹 주소도 아니고 일반적인 사설 LAN 주소 대역도 아닙니다. 합성 주소 풀로 사용하기 전에 기업 네트워크나 테스트 네트워크에서 이 대역을 실제로 사용하지 않는지 확인하세요.

131,072

/15 주소 풀의 총 IPv4 주소 수

일반 DNS에서 주로 사용하는 UDP/TCP 포트

443

DoH에서 주로 사용하는 HTTPS 포트

FakeDNS, 스니핑, TUN은 각각 어떤 역할을 할까?

세 기능은 같은 설정 화면에 표시되는 경우가 많지만 담당하는 작업은 서로 다릅니다. FakeDNS는 주소와 도메인의 매핑을 관리하고, TUN은 가상 네트워크 인터페이스를 통해 조건에 맞는 IP 트래픽을 클라이언트로 전달합니다. 스니핑이나 인바운드 목적지 복원 기능은 연결 정보에서 라우팅과 아웃바운드에 사용할 목적지를 알아냅니다. 한 기능만 켜서는 전체 경로가 제대로 작동한다고 볼 수 없습니다.

구성 요소	역할	누락 시 나타나는 증상
FakeDNS	DNS 조회에 합성 주소를 할당하고 도메인 매핑 저장	앱에 실제 IP가 반환되므로 매핑 경로가 작동하는지는 확인할 수 없음
TUN 또는 투명 프록시 가로채기	합성 주소로 향하는 연결을 프록시로 전달	앱이 합성 주소를 받았지만 연결은 해당 프록시 인바운드로 들어오지 않음
FakeDNS 목적지 복원	매핑 테이블을 조회해 합성 주소를 도메인으로 복원	로그에 합성 주소가 계속 표시되고 아웃바운드가 잘못된 목적지에 연결을 시도함
실제 DNS 조회 및 아웃바운드	실제 주소 조회와 서버 연결을 완료	도메인 복원에는 성공했지만 직접 연결용 DNS 조회나 프록시 아웃바운드가 실패함

HTTP Host 및 TLS SNI 스니핑과 FakeDNS 매핑 복원은 같은 기능이 아닙니다. 앞의 두 방식은 프로토콜 데이터에서 도메인을 식별하며, 프로토콜이나 암호화 방식, 앱 동작의 영향을 받습니다. FakeDNS 복원은 주로 이전에 저장한 매핑을 이용합니다. 앱이 실제 IP에 직접 접속하거나 클라이언트를 거치지 않고 자체적으로 DNS를 조회하는 경우, 또는 이전 실행에서 남은 합성 IP를 계속 사용하는 경우에는 사용할 수 있는 매핑이 없을 수 있습니다.

확인 방법: DNS 조회와 연결이 같은 매핑 경로를 거치는지 확인

한쪽 FakeDNS가 주소를 할당했는데 연결은 다른 프로세스나 다른 매핑 테이블로 들어간다면 먼저 트래픽 가로채기 경로를 바로잡으세요. VMess, VLESS로 전환하거나 노드를 바꿔도 누락된 도메인 매핑은 복구되지 않습니다.

사용 시점: 도메인 규칙이 필요할 때 트래픽 가로채기 조건 확인

투명 프록시가 주로 IP 연결을 받지만 라우팅 규칙에는 원래 도메인이 필요한 경우 FakeDNS를 고려해 볼 수 있습니다. 실제 IP를 먼저 조회한 다음 이 IP가 어떤 도메인에 속하는지 추측해야 하는 불확실성을 줄이고, 일부 요청은 로컬에서 실제 주소를 얻기 전에 다음 처리 단계로 넘길 수 있습니다. 다운로드 속도를 높여 주는 기능은 아니며 노드 대역폭이나 회선 혼잡도 바꾸지 않습니다.

사용을 고려해 볼 만한 경우: TUN이 안정적으로 작동하고 도메인별 분할 라우팅이 필요하며, 클라이언트가 DNS 조회와 합성 주소 라우팅, 목적지 복원을 모두 처리할 수 있는 경우.
대개 추가할 필요가 없는 경우: 시스템 프록시만 사용하고 앱이 HTTP CONNECT 또는 도메인 목적지를 지원하는 SOCKS 요청으로 도메인을 프록시에 전달하며, 현재 규칙도 제대로 적용되는 경우.
실제 DNS를 우선 유지할 경우: 기업 내부망, LAN 기기 검색, 실제 IP를 이용해 접근을 제어하는 소프트웨어, DNS 조회 결과를 직접 확인해야 하는 네트워크 진단 환경.
우선 사용을 미룰 경우: 기기에서 다른 VPN이나 투명 프록시도 실행 중이고, DNS와 기본 경로 및 합성 주소 대역을 어느 쪽이 관리하는지 확인되지 않은 경우.

브라우저의 보안 DNS나 앱 자체 DoH도 함께 점검해야 합니다. 일반 UDP 53 조회를 가로챘다고 해서 HTTPS를 통한 DNS 요청까지 FakeDNS로 전달되는 것은 아닙니다. 443 포트만 차단하면 일반 웹 접속까지 끊길 수 있으므로 보편적인 해결책으로 사용해서는 안 됩니다. 앱의 DNS 설정을 확인해 앱이 직접 조회할지, 클라이언트가 통합 처리할지 명확히 정하세요.

설정 항목: 주소 풀, DNS, 인바운드 복원 기능을 함께 구성

v2rayN은 데스크톱 클라이언트이고, v2rayNG는 Xray 코어를 사용하는 안드로이드 클라이언트이며, v2flyNG는 v2fly 코어를 사용합니다. 각 클라이언트의 인터페이스에서 코어 설정을 생성하거나 불러올 수 있지만 메뉴와 사용 가능한 옵션, 생성되는 설정은 서로 다릅니다. 특정 클라이언트의 화면을 모든 버전에 공통으로 적용되는 경로로 간주하지 마세요. 현재 실행 중인 코어가 지원하는 설정과 로그를 기준으로 확인해야 합니다.

주소 할당

주소 풀 항목: fakedns[].ipPool
예시 대역: 198.18.0.0/15
용량 항목: fakedns[].poolSize
예시 용량: 65535개 매핑 용량

용량은 유효 기간이나 동시 연결 한도를 뜻하지 않습니다. 매핑이 제거되는 방식은 사용하는 코어의 구현에 따라 확인해야 합니다.

조회 및 복원

DNS 서버 항목: dns.servers의 fakedns
인바운드 옵션: sniffing.enabled
복원 유형: destOverride의 fakedns
트래픽 조건: 합성 주소 연결이 일치하는 인바운드로 전달됨

DNS 설정이 있다는 사실만으로 시스템의 DNS 조회가 가로채진 것은 아닙니다. 클라이언트의 DNS 전달 및 라우팅 설정도 확인해야 합니다.

다음 JSON 조각은 일반적인 V2Ray 스타일의 IPv4 FakeDNS 설정을 통해 항목 간 관계를 이해하기 위한 예시입니다. 인바운드와 아웃바운드, 라우팅, 실제 DNS 설정은 생략했으므로 클라이언트 설정 전체를 그대로 덮어쓰는 용도가 아닙니다. Xray와 v2fly는 버전에 따라 동작이나 설정 항목이 다를 수 있으니 저장하기 전에 현재 코어의 지원 여부를 확인하세요.

{
  "fakedns": [
    {
      "ipPool": "198.18.0.0/15",
      "poolSize": 65535
    }
  ],
  "dns": {
    "servers": [
      "fakedns"
    ]
  }
}

합성 주소 연결을 복원하는 인바운드에는 다음과 같은 스니핑 설정을 사용할 수 있습니다. 여기서 fakedns는 목적지 복원 유형을 뜻하며, HTTP 및 TLS 스니핑 기능을 모두 켠다는 의미는 아닙니다. 옵션을 빠짐없이 선택하려고 다른 버전의 유형 이름까지 함께 복사하지 마세요.

{
  "sniffing": {
    "enabled": true,
    "destOverride": [
      "fakedns"
    ]
  }
}

사용 후 확인: DNS, 매핑, 라우팅을 단계별로 점검

확인할 것은 ‘옵션이 켜져 있음’이 아니라 한 번의 접속에서 도메인 조회부터 최종 아웃바운드까지 모두 정상적으로 처리되는지입니다. 먼저 현재 프록시 모드와 DNS 설정, 코어 종류를 기록하고 한 번에 한 그룹의 설정만 변경하세요. 구독에 포함된 서버 주소와 포트, 사용자 식별자는 FakeDNS 주소 풀 설정이 아니므로 테스트를 위해 바꿀 필요가 없습니다.

기준 상태를 기록합니다. FakeDNS를 끈 상태에서 같은 네트워크로 대상 사이트에 접속되는지 확인하고, 시스템 프록시와 TUN 중 어떤 모드를 사용하는지 기록한 뒤 현재 설정을 백업합니다.
DNS 조회 경로를 확인합니다. FakeDNS를 켠 뒤 새로 DNS 조회를 시작하는 도메인으로 접속하고, DNS 로그가 의도한 처리 경로를 거치는지 확인합니다. 해당 조회가 FakeDNS를 사용하도록 설정했다면 응답 주소는 설정된 주소 풀에 포함되어야 합니다.
연결이 프록시로 전달되는지 확인합니다. 연결 로그나 코어 로그에서 합성 주소 연결이 프록시에 들어오는지 확인하고, 로그에서 확인 가능한 단계까지 도메인이 복원되는지 살펴봅니다. 로그 수준에 따라 표시되는 정보가 다를 수 있으므로 IP 주소가 표시된 로그 한 줄만으로 실패를 단정하지 마세요.
분할 라우팅 결과를 확인합니다. 직접 연결해야 하는 도메인과 프록시를 사용해야 하는 도메인을 각각 테스트해 실제 아웃바운드를 확인합니다. 웹페이지가 열리는지만 확인해서는 규칙이 올바르게 적용됐는지 알 수 없습니다.
호환성도 확인합니다. LAN 서비스와 앱 로그인, 백그라운드 네트워크 연결을 점검하세요. IPv6를 켰다면 AAAA 조회도 확인해야 합니다. A 레코드만 검사하고 모든 트래픽이 가로채졌다고 판단하지 마세요.

Windows에서는 ipconfig /flushdns 명령으로 시스템 DNS 캐시를 비울 수 있습니다. 브라우저나 다른 앱에 자체 캐시와 연결이 남아 있을 수 있으므로 앱을 종료한 뒤 다시 실행하세요. 안드로이드에서는 먼저 클라이언트 연결을 중지하고 테스트 앱을 종료한 다음 다시 여세요. 새 결과를 얻으려고 네트워크와 노드, 프로토콜, DNS를 한꺼번에 반복해서 바꾸지 마세요. 비교가 어려워집니다.

테스트 시 유의점: 주소 풀에 응답이 있다고 최종 성공은 아님

조회 결과로 합성 주소가 반환된 것은 주소 할당 단계가 작동했다는 뜻일 뿐입니다. 연결이 올바른 인바운드로 들어오고 도메인 복원 후 예상한 아웃바운드 규칙에 적용되는 것까지 확인해야 전체 경로가 정상인지 판단할 수 있습니다.

자주 묻는 문제: 지연 시간, DNS 결과, 재시작 후 연결 실패

FakeDNS를 켠 뒤 조회는 빨라졌는데 다운로드 속도는 왜 그대로인가요?

합성 응답으로 줄어드는 것은 일부 로컬 DNS 조회 대기 시간뿐이며, 원격 노드의 대역폭은 늘어나지 않습니다. 웹페이지 첫 로딩 시간과 지속적인 다운로드 속도를 따로 측정하세요. 다운로드 속도가 계속 느리다면 주소 풀을 늘리는 대신 회선 상태와 노드 부하, 패킷 손실을 확인해야 합니다.

DNS 조회 도구에서 실제 IP가 반환되면 FakeDNS가 작동하지 않는 건가요?

먼저 도구가 실제로 어떤 DNS 서버에 조회했는지, 해당 도메인이 FakeDNS를 사용하도록 설정되어 있는지 확인하세요. 도구가 시스템 DNS 조회 경로를 우회하거나 다른 서버를 직접 조회했을 수 있으며, 실제 DNS를 사용하는 예외 규칙에 해당할 수도 있습니다. 조회 결과 하나만 보는 것보다 DNS 로그로 경로를 확인하는 편이 정확합니다.

클라이언트를 재시작한 뒤 일부 앱이 갑자기 연결되지 않나요?

앱에 이전 합성 주소가 캐시되어 있지만 새 프로세스에서는 매핑 테이블이 다시 만들어졌을 수 있습니다. 관련 앱을 종료하고 관리할 수 있는 DNS 캐시를 비운 다음 도메인을 다시 조회해 연결하세요. 클라이언트를 재시작해도 기존 주소 매핑이 그대로 유지된다고 가정하지 마세요.

LAN 도메인이나 프린터 서비스에 문제가 생기면 어떻게 설정해야 하나요?

먼저 실제 DNS를 잠시 복원해 관련이 있는지 확인한 다음, 클라이언트에서 지원하는 DNS 분할 처리와 직접 연결 규칙으로 내부망 도메인을 처리하세요. LAN DNS로 보내야 하는 이름을 모두 합성 주소 풀에 넣지 마세요. 기업 네트워크라면 주소 풀이 기존 라우팅과 충돌하지 않는지도 확인해야 합니다.

사용 중지 및 복구: DNS 주소 할당과 트래픽 가로채기를 함께 해제

사용을 중지할 때 주의해야 할 중간 상태는 DNS가 앱에 계속 합성 주소를 반환하는데 이를 복원하는 인바운드나 TUN은 이미 중지된 경우입니다. 테스트 앱을 일시 중지한 뒤 이전에 함께 사용하던 DNS 및 프록시 설정을 복구하고 연결을 재시작한 다음 오래된 캐시를 비우는 것이 안전합니다. 클라이언트에 FakeDNS 통합 모드가 있다면 코어 설정 한 줄만 직접 지우기보다 같은 메뉴에서 이전 상태로 되돌리세요.

DNS 복구: 새 조회에서 예상한 실제 DNS 결과가 반환되는지, 시스템에 연결할 수 없는 로컬 DNS 주소가 남아 있지 않은지 확인합니다.
라우팅 복구: 더 이상 필요하지 않은 합성 주소 풀 경로와 가상 인터페이스, 트래픽 가로채기 규칙이 클라이언트에서 정상적으로 해제됐는지 확인합니다.
앱 복구: 기존 연결을 종료하고 도메인을 다시 조회한 뒤 웹페이지와 내부망 서비스, 백그라운드 네트워크 연결을 점검합니다.
문제 해결에 필요한 정보 기록: 어느 단계에서 문제가 발생했는지, 특정 앱에만 영향을 주는지 기록합니다. 로그를 공유하기 전에 구독 주소와 사용자 식별자 등 민감한 정보를 삭제하세요.

FakeDNS의 장점은 투명 프록시의 라우팅 판단 과정에서 도메인 정보를 활용할 수 있다는 데 있습니다. 안정적으로 작동하는 시스템 프록시라면 단순한 설정을 유지하는 편이 관리하기 쉽습니다. 도메인별 분할 라우팅이 꼭 필요한 TUN 환경에서는 DNS 조회와 매핑, 인바운드, 아웃바운드가 서로 맞물려 작동하는지 확인하는 것이 중요합니다. 기본 설정은 전체 가이드의 DNS 설정을 참고하세요. 먼저 일반 DNS 경로가 제대로 작동하는지 확인한 다음 합성 주소 기능을 추가하는 것이 좋습니다.