FakeDNS란 무엇인가: Xray 코어 가상 IP 해석 원리와 활성화 시나리오

요청 하나의 전체 경로: FakeDNS가 개입하는 단계

FakeDNS를 끄면 앱이 먼저 시스템 DNS 서버에 도메인의 실제 IP를 조회한 뒤 결과를 받아 연결을 맺습니다. TUN 모드에서 코어가 보는 것은 IP 패킷이므로, 이 IP가 어떤 규칙에도 걸리지 않으면 도메인 정보는 사라지고 분기는 IP 규칙에 의존할 수밖에 없습니다.

FakeDNS를 켜면 조회가 Xray의 DNS 모듈로 넘어갑니다. 업스트림 DNS 서버에 실제 주소를 요청하는 대신 198.18.0.0/15 대역에서 빈 IP 하나를 골라 반환하고, 메모리 매핑 테이블에 '도메인 → 가상 IP'를 기록합니다.

앱은 이어서 이 가상 IP에 연결합니다. 트래픽이 TUN 인터페이스로 들어오면 라우팅 엔진이 목적지 주소가 FakeDNS 대역에 속하는 것을 확인하고 매핑 테이블에서 원래 도메인을 역조회해 geosite, domain 규칙이 평소처럼 매칭된 뒤 해당 아웃바운드로 전달합니다.

실제 DNS 해석은 아웃바운드 단계로 미뤄져 프록시 서버가 원격에서 처리합니다. 프록시를 거치는 트래픽은 로컬에서 DNS 왕복이 한 번 줄어들어 연결도 더 빨라집니다.

가상 IP 풀: 198.18.0.0/15는 어디서 왔고 왜 충돌하지 않나

198.18.0.0/15는 198.18.0.0부터 198.19.255.255까지 총 131,072개의 주소를 포함합니다. 이 대역은 RFC 2544에서 네트워크 장비 성능 테스트용으로 예약되어 있어 공인 서비스가 배포되지 않으므로, 가상 주소로 사용해도 실제 사이트와 충돌하지 않습니다.

매핑 테이블은 메모리에 상주하며 연결이 끝나면 항목이 바로 회수되므로 기본 풀로 일상적인 사용에 충분합니다. Xray는 루트 수준 fakedns의 pool 필드로 대역을 변경할 수도 있지만, 보통 기본값을 유지하면 됩니다.

설정 작성법: fake 서버 항목과 루트 수준 fakedns 필드

{
  "dns": {
    "servers": [
      "https://1.1.1.1/dns-query",
      {
        "address": "fake",
        "domains": ["geosite:geolocation-!cn"]
      }
    ]
  }
}

첫 번째는 실제 해석을 담당하는 일반 DoH 서버이고, 두 번째는 address가 fake인 항목으로 가상 IP를 발급합니다. domains 필터가 어떤 도메인이 fake를 거칠지 결정합니다. 위 작성법은 해외 도메인만 가상 IP를 받고, 중국 본토 도메인은 1.1.1.1이 정상적으로 해석합니다.

servers 배열을 직접 수정하고 싶지 않다면 Xray 1.8.0 이후부터 루트 수준 fakedns 필드를 바로 작성할 수 있습니다. 이는 fake 서버 항목을 자동으로 주입하는 것과 동일하며, 켜고 끄기만 원하고 설정을 바꾸고 싶지 않은 사용자에게 적합합니다.

{
  "fakedns": {
    "pool": "198.18.0.0/15",
    "skipFallback": false
  }
}

skipFallback은 폴백 동작을 제어합니다. false면 fake 항목이 처리하지 않은 도메인이 목록의 다른 DNS 서버를 계속 찾고, true면 바로 실패를 반환합니다. 평소에는 기본값인 false를 유지하면 됩니다.

• 도메인 해석 전략은 AsIs 유지: FakeDNS가 조회를 가로챈 뒤 라우팅이 도메인 기준으로 매칭하므로 로컬에서 IP로 먼저 해석할 필요가 없습니다.
• IPOnDemand로 바꾸지 말 것: 그렇게 하면 코어가 매칭 단계에서 실제 해석을 시작해 FakeDNS의 왕복 절약 효과가 사라집니다.
• 라우팅 규칙에 geosite:cn 직통 유지: 중국 본토 도메인은 fake 목록에 들어가지 않아 직통 트래픽에 영향이 없습니다.

v2rayN 및 v2rayNG 활성화 경로

두 클라이언트의 스위치는 모두 코어가 생성한 설정에만 적용되므로, 변경 후에는 코어나 앱을 재시작해야 DNS 모듈이 이전 상태를 계속 사용하지 않습니다.

켠 뒤 가장 먼저 중국 본토 사이트 하나에 접속해 직통으로 나가고 fake에 가로채이지 않았는지 확인하세요. 이 단계는 domains 필터 오류를 미리 드러내므로 해외 사이트를 바로 테스트하는 것보다 효과적입니다.

FakeDNS를 권장하지 않는 네 가지 상황

• 시스템 프록시 모드: 앱이 이미 도메인을 프록시에 넘겼고 라우팅도 원래 도메인 기준으로 매칭되므로, FakeDNS는 가상 IP 변환 한 번을 추가할 뿐 이득이 없습니다.
• 내부망 및 LAN 해석: NAS, 프린터, 회사 내부 도메인의 해석 결과가 라우팅 불가능한 가상 IP로 바뀌어 폴백 해석에 의존해야만 연결되므로 바로 실패하기 쉽습니다.
• 로컬 DNS 도구: AdGuard Home, 자체 구축 DoH 등의 광고 차단 및 내부망 해석 기능이 fake에 우회되어 필터 규칙이 무효화됩니다.
• IP 규칙 중심 설정: 가상 IP는 CIDR 및 IP 규칙에 매칭되지 않아 분기 결과가 예상과 달라집니다.

판단 기준은 단 하나입니다. 트래픽이 반드시 TUN 인터페이스를 거쳐야 하고, 분기는 도메인 규칙 중심이어야 합니다. 두 조건 중 하나라도 빠지면 FakeDNS의 이득은 매우 작은 반면 부작용으로 바로 연결이 안 될 수도 있습니다.

켠 뒤 검증 방법과 자주 묻는 질문

FakeDNS가 동작하는지 확인하려면 코어 로그를 보는 것이 가장 직접적입니다. 켠 뒤 해외 사이트 하나에 접속하면 로그에 아래와 유사한 기록이 나타나야 합니다.

2026/07/24 10:32:11 [Info] [TCP] dialing to target:198.18.0.7:443 via proxy

목적지 주소가 198.18.x.x라면 이 연결이 실제로 가상 IP를 사용했다는 뜻입니다. 라우팅 로그에서 역조회된 도메인까지 확인하면 FakeDNS와 도메인 규칙이 모두 정상 동작한다는 것을 알 수 있습니다.