FakeDNS란? Xray 가상 IP와 DNS 설정·TUN 연동 가이드

이 글의 핵심

FakeDNS는 IP 트래픽에서 도메인 정보를 복원해야 하는 환경에 적합하며, 모든 연결에 켜야 하는 속도 향상 기능은 아닙니다. DNS 조회, 가상 주소 매핑, 인바운드 스니핑, 라우팅의 관계를 먼저 이해하고 v2rayN에서 실제로 사용하는 코어를 확인하세요. 이 글에서는 Xray 설정 항목, Windows 검증 절차, 비활성화 후 캐시 삭제 방법을 설명하고, ‘주소가 조회되는데 연결은 시간 초과되는’ 상황을 방지하는 데 중점을 둡니다.

FakeDNS 작동 원리: 실제 IP를 조회하지 않고 주소 반환

일반 DNS는 상위 DNS 서버에 도메인의 A 또는 AAAA 레코드를 조회해 실제 주소를 받은 뒤 연결을 시작합니다. 반면 FakeDNS는 로컬에 ‘도메인과 가상 IP’의 매핑을 저장합니다. 앱이 도메인을 조회하면 지정된 주소 풀에서 주소를 할당해 먼저 반환합니다. 이 주소는 웹 서버 주소가 아니므로 매핑 정보 없이 직접 사용할 수 없습니다.

앱이 도메인을 조회 가상 주소 할당 대상 연결 가로채기 대상 도메인 복원 라우팅에 따라 아웃바운드 선택

앱이 example.com을 조회한다고 가정해 보겠습니다. 로컬에서는 주소 풀에 있는 198.18.x.x 주소 중 하나를 반환합니다. 이후 앱이 해당 주소로 연결하면 트래픽은 같은 매핑 정보를 읽을 수 있는 처리 경로로 들어가야 합니다. 그래야 Xray가 원래 도메인을 복원해 도메인 규칙을 적용하고 요청을 적절한 아웃바운드로 전달할 수 있습니다. 트래픽이 가로채기 경로를 우회하면 시스템은 해당 웹사이트를 호스팅하지 않는 가상 주소에 연결을 시도할 뿐입니다.

이 때문에 FakeDNS는 TUN과 함께 사용하는 경우가 많습니다. 가상 네트워크 인터페이스가 앱에서 해당 주소로 향하는 IP 트래픽을 받아들일 수 있기 때문입니다. 하지만 TUN은 트래픽을 가로채는 진입점일 뿐, DNS 조회까지 자동으로 FakeDNS로 전달하거나 서로 다른 코어가 매핑 정보를 공유하도록 보장하지 않습니다. DNS 조회와 후속 연결이 하나의 처리 흐름으로 이어져야 합니다.

주소 풀과 매핑 용량: 세 숫자의 의미

Xray의 FakeDNS 설정에서는 ipPool과 poolSize를 지정할 수 있습니다. 아래는 IPv4 설정 예시입니다. 숫자는 설정 항목의 의미를 보여 주며 모든 클라이언트의 기본값이 같다는 뜻은 아닙니다. 주소 풀과 매핑 용량은 별개이므로 대역이 충분히 넓다고 해서 매핑이 회수되지 않는다고 단정할 수 없습니다.

198.18.0.0/15

IPv4 가상 주소 풀 예시

131072

이 대역에 포함된 IPv4 주소 총수

65535

아래 예시의 최대 매핑 용량

198.18.0.0/15는 네트워크 성능 테스트용으로 예약된 주소 범위입니다. 공인 웹사이트 주소도, 일반 가정용 사설 네트워크 대역도 아닙니다. 기업 테스트 네트워크나 다른 터널에서 이미 이 범위를 사용한다면 라우팅 충돌이 발생할 수 있습니다. 사용 전에 로컬 라우팅을 확인하고, ‘예약된 주소’가 충돌하지 않는다는 뜻으로 이해하지 마세요.

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

이는 Xray 설정의 일부 구조일 뿐, 완성된 클라이언트 설정이 아닙니다. 인바운드, 아웃바운드, DNS 가로채기, 라우팅 규칙을 포함하지 않으며 직결 대상에 실제 주소를 조회하는 방법도 설정하지 않습니다. 그대로 연결에 사용할 수 있는 파일이 아닙니다. 매핑은 실행 중에 유지되는 상태이므로 코어를 재시작한 뒤에도 이전 주소가 같은 도메인을 가리킨다고 가정하면 안 됩니다.

판단 기준: 먼저 전체 흐름을 확인한 뒤 용량 조정

DNS가 가상 주소를 반환했는데 웹페이지가 열리지 않는다면 먼저 트래픽이 같은 처리 경로로 돌아오는지, 도메인이 정상적으로 복원되는지 확인하세요. poolSize를 늘려도 DNS 우회, 인바운드 스니핑 누락, 가상 대역을 직결하도록 잘못 설정한 문제는 해결되지 않습니다.

FakeDNS, 일반 DNS, 도메인 스니핑의 차이

FakeDNS는 암호화 DNS도 HTTP·TLS 스니핑도 아닙니다. FakeDNS는 매핑을 만들고, 스니핑은 연결 내용에서 도메인으로 추정할 수 있는 정보를 추출합니다. Xray는 매핑 정보를 이용해 도메인을 복원하므로 모든 연결에서 애플리케이션 계층의 호스트명을 읽을 필요는 없습니다. 그렇더라도 앱이 실제 IP에 직접 접속하고 해당 도메인에 대한 조회가 없었다면 FakeDNS가 도메인을 알아낼 수는 없습니다.

방식	주요 기능	사용 시 제한사항
일반 DNS	접속 대상의 실제 A·AAAA 주소 조회	직결 대상에는 최종적으로 연결 가능한 주소가 필요
FakeDNS	가상 주소를 반환하고 도메인 매핑 저장	후속 연결은 해당 매핑을 처리하는 경로를 거쳐야 함
HTTP·TLS 스니핑	프로토콜 내용에서 호스트명 식별	프로토콜, 암호화 방식, 핸드셰이크 내용에 따라 제한됨
DoH、DoT	DNS 조회가 전송되는 과정 보호	가상 주소 매핑이나 라우팅 분기를 자동으로 처리하지 않음

프록시가 필요한 도메인에서는 FakeDNS를 사용하면 클라이언트가 실제 IP를 기다리는 단계를 생략할 수 있습니다. 프록시 아웃바운드가 도메인을 원격으로 전달하는 방식이라면 이후 처리 과정에서 주소를 조회할 수 있습니다. 하지만 직결 웹사이트에는 여전히 실제 주소가 필요합니다. DNS 조회 비용은 연결 전체에서 사라지는 것이 아니라 다른 단계로 옮겨갈 수 있습니다. 웹페이지 로딩 속도는 노드 지연 시간, 패킷 손실, 서버 응답, 리소스 수에도 영향을 받으므로 일정한 속도 향상을 보장할 수 없습니다.

적합한 경우: 앱이 주로 IP 연결을 시작하고 TUN이 안정적으로 트래픽을 가로채며 도메인 규칙에 사용할 정보를 더 정확히 확보하려는 경우.
우선 활성화할 필요가 없는 경우: 브라우저가 프록시 프로토콜로 도메인을 전달하고 시스템 프록시가 정상 작동하며, 아직 도메인 정보가 누락되는 문제가 없는 경우.
주의가 필요한 경우: 기업 내부망, 로컬 네트워크 기기 검색, 실제 DNS 조회 결과에 의존하는 소프트웨어, 다른 가상 네트워크 인터페이스와 함께 사용하는 환경.
대신할 수 없는 것: 올바른 구독 설정, 정상 작동하는 노드, 정확한 시스템 시간, 서버 측 지원.

v2rayN에서 활성화하기 전: 코어와 DNS 진입 경로 확인

v2rayN은 클라이언트 인터페이스이고 Xray는 호출해서 사용하는 코어입니다. 인터페이스에 ‘TUN’이 보인다고 해서 해당 모드가 반드시 Xray의 fakedns 항목을 읽는다고 단정하면 안 됩니다. 일부 실행 모드는 서로 다른 설정 생성 경로를 사용하므로 실제 설정 항목과 트래픽 가로채기 방식이 다를 수 있습니다. 시작 로그에 기록된 코어 이름, 버전, 설정 로드 결과를 먼저 확인한 다음 이 글의 Xray 설정을 사용할지 결정하세요.

기준 상태 보존: 현재 설정을 백업합니다. TUN을 끈 상태에서 기존 시스템 프록시로 같은 노드가 대상 웹페이지에 접속되는지 확인하세요. 현재 DNS, 라우팅 모드, 로컬 포트도 기록합니다.
설정 확인: v2rayN의 ‘설정’ → ‘매개변수 설정’에서 코어와 인바운드 관련 설정을 확인한 뒤 ‘설정’ → ‘DNS 설정’의 기존 항목도 살펴보세요. 버전에 따라 메뉴 이름이 다를 수 있으니 실제 인터페이스를 기준으로 확인합니다.
생성된 설정 확인: 실행 설정에 예상한 fakedns, DNS 서버 목록, 인바운드 sniffing 항목이 포함되어 있는지 확인하세요. 스위치 하나가 켜져 있는지만 보고 기능이 적용됐다고 판단하면 안 됩니다.
가로채기 범위 확인: DNS 조회가 예상한 로컬 처리 경로로 들어가고 가상 대역 연결도 가로채는지 확인하세요. 브라우저의 보안 DNS, 앱 내장 DoH, IPv6 조회가 해당 경로를 우회하는지도 살펴봅니다.
항목별 검증: 저장한 뒤 클라이언트 안내에 따라 코어를 재시작합니다. 먼저 프록시 대상 하나와 직결 대상 하나를 확인한 뒤 로컬 네트워크 서비스를 테스트하세요. 한 번에 한 종류의 설정만 변경합니다.

Xray 주소 매핑 설정

주소 풀 항목: fakedns[].ipPool
용량 항목: fakedns[].poolSize
DNS 진입 경로: dns.servers의 fakedns
예시 범위: 198.18.0.0/15

이 항목은 매핑과 DNS 조회를 관리하며, 시스템 가상 네트워크 인터페이스를 자동으로 만들지는 않습니다.

Xray 인바운드 도메인 복원 설정

스니핑 활성화: sniffing.enabled를 true로 설정
복원 유형: destOverride에 fakedns 포함
대상 처리 방식: routeOnly와 아웃바운드 요구사항 확인
필수 조건: 연결이 매핑 정보를 보유한 처리 경로로 들어가야 함

라우팅 식별에만 사용하는 것은 연결 대상이 교체됐다는 뜻이 아닙니다. 최종적으로 가상 IP를 공인 인터넷의 대상으로 보내면 안 됩니다.

특히 routeOnly에 주의하세요. 복원한 도메인을 규칙 매칭에만 사용하는 것과 연결 대상 자체로 사용하는 것은 서로 다릅니다. 이후 아웃바운드가 여전히 가상 IP로 연결을 시도하면 시간 초과가 발생할 수 있습니다. 현재 코어의 설정 설명과 전체 아웃바운드 구성을 함께 확인하고, 불리언 값 하나만 따로 복사하지 마세요.

검증 방법: 조회 결과와 연결 로그를 함께 확인

198.18.x.x 주소가 보이는 것은 해당 조회에서 가상 주소를 받았다는 사실만 보여 줄 뿐, 프록시 아웃바운드가 성공했다는 뜻은 아닙니다. 반대로 웹페이지가 열린다고 해도 브라우저가 시스템 DNS를 우회했을 수 있습니다. ‘조회가 어떤 경로로 처리되는지’와 ‘연결이 최종적으로 어디로 전달되는지’를 함께 확인해야 합니다.

브라우저에서 열어 둔 테스트 탭을 닫습니다. Windows 터미널에서 ipconfig /flushdns를 실행한 뒤 브라우저를 완전히 종료하고 다시 열어 오래된 캐시의 영향을 방지하세요.
아래 명령으로 조회를 실행해 시스템이 현재 사용하는 DNS 경로에서 주소 풀의 주소가 반환되는지 확인하세요. 외부 DNS를 지정하면 기존 시스템 경로를 테스트하는 것이 아닙니다.
같은 도메인에 접속한 뒤 코어 로그에서 대상 도메인과 아웃바운드 태그를 확인하세요. 필요한 경우 검증 중에만 로그 수준을 임시로 높이고, 확인이 끝나면 원래대로 되돌려 방문 기록이 과도하게 남지 않도록 합니다.
직결해야 하는 대상도 하나 확인해 가상 IP가 최종 서버 주소로 사용되지 않는지 확인하세요. 로컬 라우터와 내부망 서비스에 계속 접속할 수 있는지도 테스트합니다.

ipconfig /flushdns
nslookup example.com
route print

nslookup은 일반 DNS 조회를 확인하는 데 적합하지만 브라우저 내장 DoH의 실제 동작을 보여 주지는 않습니다. route print로 가상 대역의 라우팅 경로를 확인할 수 있습니다. 해당 대역이 별도로 표시되지 않더라도 곧바로 가로채기 실패라고 단정하면 안 됩니다. 일부 TUN 설정은 더 넓은 대역의 경로를 사용하기 때문입니다. 인터페이스, 메트릭, 클라이언트 로그를 함께 확인하세요.

완료 기준: 프록시·직결·종료 후 복구 확인

프록시 도메인이 의도한 아웃바운드를 사용하고, 직결 대상에 접속할 수 있으며, FakeDNS를 끄고 캐시를 삭제한 뒤 일반 DNS 조회가 복구되어야 테스트를 마친 것입니다. 속도 측정 한 번으로 이 세 가지 확인을 대신하지 마세요.

자주 묻는 문제: 캐시, IPv6, 비활성화 후 복구

TUN을 끈 뒤 방금까지 열리던 사이트가 모두 시간 초과되는 이유는 무엇인가요?

시스템이나 앱에 가상 주소가 캐시된 상태에서 주소를 복원하던 처리 경로가 이미 중단됐을 수 있습니다. 먼저 기존 DNS와 시스템 프록시 설정을 복구하고 ipconfig /flushdns를 실행한 다음 브라우저를 완전히 종료했다가 다시 여세요. 특정 앱만 문제가 있다면 노드를 반복해서 바꾸기보다 해당 앱의 DNS 캐시를 지우거나 앱을 재시작해야 합니다.

FakeDNS를 켰는데도 조회 결과가 공인 IP인 이유는 무엇인가요?

먼저 조회가 FakeDNS를 설정한 코어로 들어가는지 확인한 다음 DNS 규칙이 해당 도메인에 실제 DNS 서버를 선택하는지 살펴보세요. 브라우저 보안 DNS, 앱 내장 DNS 조회, 다른 네트워크 인터페이스의 DNS가 우회 경로일 수 있습니다. 가상 주소를 받으려고 시스템 DNS 전체를 무작정 127.0.0.1로 바꾸지 마세요. 해당 주소에서 실제로 서비스가 대기 중이고 안정적으로 실행되어야 합니다.

IPv4는 정상인데 일부 웹사이트가 열리지 않는 이유는 무엇인가요?

AAAA 조회와 IPv6 연결이 어떻게 처리되는지 확인하세요. IPv4 주소 풀만 설정했다고 IPv6에도 같은 정책이 자동 적용되지는 않습니다. 실제 IPv6 연결이 다른 경로를 사용할 수 있습니다. DNS 응답, 가로채기 범위, 라우팅 규칙을 일치시키고 A와 AAAA 조회를 각각 테스트하세요. IPv6 비활성화를 모든 환경에 통하는 해결책으로 여기면 안 됩니다.

코어를 재시작한 뒤 기존 연결을 계속 사용할 수 없는 이유는 무엇인가요?

실행 중 매핑은 새로 만들어졌지만 앱에는 이전 가상 IP가 남아 있을 수 있습니다. 캐시를 지우고 연결을 다시 만든 뒤 도메인 복원과 아웃바운드 로그를 확인하세요. 설정을 되돌려야 한다면 백업한 DNS와 라우팅 설정을 복구하고 클라이언트 안내에 따라 코어를 재시작한 다음 일반 DNS 조회와 직결 접속을 확인하세요. 인터페이스의 스위치 하나만 끄고 작업을 끝내면 안 됩니다.

FakeDNS는 특정 트래픽 가로채기 경로에서 도메인 정보를 유지하는 기능입니다. VMess, VLESS 인증 설정을 바꾸거나 만료된 구독과 접속할 수 없는 노드를 고쳐 주지는 않습니다. 기본 연결이 안정적이고 도메인 기반 라우팅이 필요하며 설정을 검증하고 되돌릴 수 있을 때 활성화를 고려하세요. 브라우저가 가끔 멈추는 정도라면 먼저 자주 묻는 문제의 시스템 프록시, DNS, 라우팅 점검 절차로 원인을 좁혀 보세요.