FakeDNS 원리 완벽 해설: 가상 IP로 도메인 분할 라우팅을 빠르게 하는 방법

FakeDNS가 해결하는 문제

일반 DNS 모드에서는 앱이 먼저 도메인을 실제 IP로 변환한 다음 해당 IP에 연결합니다. 프록시 코어가 연결을 가로챌 때 확인할 수 있는 대상은 203.0.113.20:443처럼 주소 하나뿐일 수 있습니다. 하나의 주소에서 여러 도메인을 서비스하거나 서버 주소가 자주 바뀌면 IP만으로 라우팅 규칙을 작성할 때 오판하기 쉽습니다.

FakeDNS는 실제 공인 주소를 제공하지 않습니다. 앱의 DNS 요청을 받으면 미리 정한 주소 풀에서 가상 IP를 할당하고 ‘도메인과 가상 IP’의 임시 매핑을 저장합니다. 이후 앱이 이 가상 주소에 연결하면 TUN 인바운드가 연결을 가로채고, 프록시 코어가 매핑 테이블에서 원래 도메인을 되찾습니다. 따라서 라우팅 모듈은 domain, domainSuffix 또는 규칙 세트에 기록된 도메인을 직접 매칭할 수 있습니다.

자주 사용하는 IPv4 주소 풀은 198.18.0.0/15입니다. 이 대역은 네트워크 장비 성능 테스트용이므로 공용 인터넷 라우팅에 사용되지 않아야 하며, 로컬 가상 대상으로 활용하기에 적합합니다. /15 대역에는 131072개의 주소가 포함되지만 Xray 설정에서는 보통 poolSize: 65535처럼 더 작은 매핑 풀을 지정해 실제로 필요하지 않은 초대형 매핑 테이블 생성을 피합니다.

위의 1~3밀리초는 동일한 Android 기기에서 캐시되지 않은 도메인을 연속 조회할 때 로컬에서 응답하는 데 걸리는 범위입니다. FakeDNS가 가상 주소를 반환하는 시간일 뿐 웹페이지 전체 로딩 속도를 뜻하지는 않습니다. 실제 연결에는 노드 핸드셰이크, 원격 DNS 조회, TLS 연결 설정, 콘텐츠 전송이 이어집니다.

하나의 도메인 요청이 가상 IP 매핑을 거치는 과정

전체 흐름은 여섯 단계로 나눌 수 있습니다. 첫째, 앱이 시스템 DNS에 A 또는 AAAA 조회를 보냅니다. 둘째, TUN 모드가 DNS 트래픽을 프록시 코어에 전달합니다. 셋째, FakeDNS가 주소 풀에서 사용 중이지 않은 주소를 꺼내 매핑 테이블에 기록합니다. 넷째, 앱이 가상 주소를 받은 뒤 TCP 또는 UDP 연결을 시작합니다. 다섯째, 인바운드가 대상 주소를 기준으로 도메인을 역조회합니다. 여섯째, 라우팅 모듈이 도메인에 따라 직접 연결, 프록시 또는 차단을 결정합니다.

1. 조회가 프록시 코어로 전달됨: DNS 요청은 TUN 또는 제어된 로컬 DNS가 가로채야 합니다. 앱이 외부 DNS에 직접 연결하면 FakeDNS는 해당 조회를 받을 수 없습니다.
2. 임시 매핑 생성: 예를 들어 news.example에 198.18.0.12가 할당되며, 매핑은 로컬 메모리에서만 유효합니다.
3. 앱이 가상 주소에 연결: 앱은 198.18.0.12를 일반적인 대상 주소로 취급하므로 FakeDNS를 이해할 필요가 없습니다.
4. 인바운드가 도메인 복원: 코어가 매핑 테이블에서 news.example을 찾은 뒤 도메인을 스니핑 및 라우팅 모듈에 전달합니다.
5. 라우팅 규칙 매칭: 도메인 규칙은 실제 DNS 조회가 이루어지기 전에 아웃바운드를 결정할 수 있어 ‘먼저 조회하고 나중에 판단’할 때 생기는 정보 손실을 줄입니다.
6. 아웃바운드가 조회 완료: 직접 연결 아웃바운드는 보통 로컬에서 실제 주소를 조회합니다. 도메인 대상 주소를 지원하는 프록시 아웃바운드는 도메인을 원격에서 처리하도록 전달할 수 있으며, 구체적인 동작은 아웃바운드 프로토콜과 DNS 설정에 따라 달라집니다.

Xray 설정의 핵심 필드

Xray 설정은 보통 서로 연동되는 세 부분으로 구성됩니다. 최상위 fakedns가 주소 풀을 정의하고, dns.servers가 조회를 FakeDNS에 전달하며, 인바운드의 sniffing.destOverride가 코어에서 가상 주소 매핑을 통해 대상 도메인을 복원하도록 합니다. 어느 한 필드만 추가해서는 전체 흐름이 완성되지 않습니다.

다음은 필드 간 관계를 설명하기 위한 최소 예시입니다. 클라이언트가 설정을 생성할 때 로컬 DNS, 규칙 세트, 여러 인바운드가 추가될 수 있습니다. 편집하기 전에 현재 설정을 먼저 내보내고, 사용 중인 클라이언트가 하위 JSON 사용자 지정을 허용하는지 확인하세요. 구독 업데이트로 수동 변경한 노드 매개변수가 덮어써질 수 있습니다.

{
  "fakedns": [
    {
      "ipPool": "198.18.0.0/15",
      "poolSize": 65535
    }
  ],
  "dns": {
    "servers": [
      "fakedns",
      "1.1.1.1"
    ],
    "queryStrategy": "UseIP"
  },
  "inbounds": [
    {
      "tag": "tun-in",
      "protocol": "tun",
      "settings": {
        "stack": "system"
      },
      "sniffing": {
        "enabled": true,
        "destOverride": [
          "http",
          "tls",
          "quic",
          "fakedns"
        ],
        "metadataOnly": false
      }
    }
  ],
  "routing": {
    "domainStrategy": "IPIfNonMatch"
  }
}

destOverride의 fakedns는 매핑을 읽는 데 사용되며, http, tls, quic은 각 프로토콜 메타데이터에서 도메인을 보완하는 데 사용됩니다. 두 출처는 서로 충돌하지 않습니다. 매핑은 조회된 도메인을 직접 제공하고, 프로토콜 스니핑은 FakeDNS를 거치지 않았지만 핸드셰이크에 호스트명이 포함된 일부 연결도 처리할 수 있습니다.

v2rayNG에서 Xray 코어를 사용할 때는 클라이언트 화면에서 TUN과 로컬 DNS를 관리하는 것이 좋습니다. 일반적인 확인 경로는 ‘설정’ → ‘VPN 설정’에서 트래픽 가로채기 관련 옵션을 확인한 다음, ‘설정’ → ‘라우팅 설정’에서 규칙 순서를 확인하는 것입니다. 버전에 따라 스위치 이름이 바뀔 수 있으므로 화면의 스위치 상태만 보지 말고 내보낸 실행 설정과 코어 로그를 기준으로 작동 여부를 판단하세요.

FakeDNS를 사용하기 좋은 환경

FakeDNS는 TUN이 기기 전체 트래픽을 인계하고 라우팅 규칙을 주로 도메인 기준으로 작성한 환경에 가장 적합합니다. Android 앱은 먼저 자체적으로 도메인을 조회한 뒤 실제 IP를 네트워크 스택에 전달하는 경우가 많습니다. TUN이 대상 IP만 볼 수 있으면 도메인 규칙 매칭률이 스니핑 결과에 좌우되지만, FakeDNS를 사용하면 DNS 조회와 이후 연결이 매핑으로 연결되어 라우팅 판단이 더 직접적으로 이루어집니다.

• 대규모 도메인 분할 라우팅: 수천 개의 도메인 접미사나 규칙 세트를 사용하며 연결 전에 대상 도메인을 명확히 해야 하는 경우
• 주소를 공유하는 서비스: 여러 사이트가 동일한 서비스 주소를 함께 사용해 IP만으로는 서비스 도메인을 안정적으로 구분하기 어려운 경우
• 주소가 자주 바뀌는 서비스: 서버가 동적 조정을 통해 서로 다른 주소를 반환해 정적 IP 규칙이 빠르게 무효화되는 경우
• 원격 조회가 필요한 경우: 프록시 아웃바운드에서 도메인을 유지해 노드가 위치한 네트워크가 최종 조회를 수행해야 하는 경우
• UDP 및 QUIC 트래픽: 앱이 UDP 443을 사용할 때 FakeDNS 매핑과 QUIC 스니핑으로 대상 정보를 보완할 수 있는 경우

v2rayN의 시스템 프록시 모드만 사용하는 경우 브라우저는 보통 대상 도메인을 로컬 SOCKS 또는 HTTP 인바운드에 직접 전달합니다. 이때 코어는 이미 도메인을 알고 있으므로 FakeDNS를 켜도 뚜렷한 이점이 없을 수 있습니다. 필요한지는 인바운드 유형과 로그에 표시되는 대상 형식을 기준으로 판단하세요.

LAN에 특수 라우팅이 포함되어 있다면 주의해야 합니다. 일부 실험실, 가상화 플랫폼 또는 기업 장비는 성능 테스트나 내부 시뮬레이션에 198.18.0.0/15를 사용할 수 있습니다. 시스템 라우팅 테이블이 이미 이 대역을 실제 인터페이스로 지정하고 있다면 FakeDNS 주소가 기존 네트워크와 겹쳐 연결이 LAN으로 전송되고 TUN에 들어오지 않을 수 있습니다.

FakeDNS, 스니핑, TUN의 연동 방식

TUN의 역할은 IP 패킷을 가로채는 것이고, FakeDNS의 역할은 도메인과 가상 주소의 관계를 저장하는 것입니다. 스니핑은 HTTP Host, TLS Server Name 또는 QUIC 핸드셰이크에서 도메인을 추출합니다. 세 기능이 해결하는 문제는 서로 다릅니다. 순서에 맞게 연결해야 도메인 규칙이 더 많은 앱 트래픽에 적용됩니다.

먼저 최소한의 작동 흐름을 만든 뒤 고급 설정을 하나씩 추가하세요. 주소 풀, DNS 서버, 라우팅 규칙, MTU를 한 번에 변경하면 장애 원인을 구분하기 어렵습니다. 다음 순서는 v2rayNG의 Xray 코어 설정에 적합하며, 구독으로 생성된 실행 설정을 확인할 때도 활용할 수 있습니다.

1. ‘설정’ → ‘VPN 설정’에서 TUN 또는 VPN 트래픽 인계가 활성화되어 있는지 확인하고, 대상 앱이 앱별 규칙에서 제외되지 않았는지 확인합니다.
2. 연결을 시작한 뒤 코어 로그를 확인해 TUN 인바운드가 존재하고 주소 충돌, 권한 오류 또는 인터페이스 생성 실패가 없는지 확인합니다.
3. 실행 설정에서 fakedns 주소 풀을 확인하고 DNS 서버 목록에 FakeDNS 처리 항목이 포함되어 있는지 확인합니다.
4. 인바운드 스니핑이 활성화되어 있고 destOverride에 최소한 fakedns가 포함되어 있는지 확인합니다. 웹 트래픽을 식별해야 할 때만 http, tls, quic을 추가로 유지하세요.
5. ‘설정’ → ‘라우팅 설정’에서 규칙 순서를 확인합니다. 차단 규칙, 사설 주소 규칙, 직접 연결 규칙이 앞에 있으면 대상 도메인 규칙보다 먼저 매칭될 수 있습니다.
6. 한 번도 방문하지 않은 테스트 도메인으로 연결을 시작하고, 로그에 가상 주소, 복원된 도메인, 최종 아웃바운드 태그가 순서대로 표시되는지 확인합니다.

MTU 문제와 FakeDNS는 서로 다른 계층에 속합니다. 도메인은 정상적으로 복원되지만 페이지가 일부만 로드되거나 대용량 파일 전송이 멈춘다면 TUN MTU를 확인하세요. Android 기기에서는 1500에서 1400 또는 1380으로 조정해 비교 테스트할 수 있으며, 매번 한 값만 변경해야 합니다. 모든 도메인에서 연결 자체가 되지 않는다면 DNS 가로채기와 주소 풀 라우팅으로 돌아가 계속 확인하세요.

Mux도 FakeDNS를 대체하지 않습니다. Mux는 하나의 하위 연결에 여러 논리 연결을 실어 연결 재사용에 주로 영향을 주고, FakeDNS는 대상 도메인을 보존합니다. Mux를 켜거나 꺼도 가상 주소 매핑 생성 여부는 바뀌지 않아야 하지만 연결 수와 로그 표시 방식은 달라질 수 있습니다.

자주 발생하는 문제와 단계별 해결

FakeDNS 문제는 보통 세 가지 형태로 나타납니다. 앱이 가상 IP를 받은 뒤 연결하지 못하거나, 도메인 규칙이 매칭되지 않거나, 클라이언트를 종료한 뒤에도 잠시 접속이 실패하는 경우입니다. 첫 번째는 TUN이 가상 대역을 가로채는지 먼저 확인하고, 두 번째는 매핑과 규칙 순서를 확인하며, 세 번째는 대개 시스템 DNS 캐시에 남은 가상 주소와 관련이 있습니다.

문제 해결 시 브라우저 결과만 확인하지 마세요. 코어 로그에서 최소한 네 가지를 확인해야 합니다. DNS 조회가 클라이언트에 들어왔는지, 가상 주소가 할당되었는지, 인바운드가 도메인을 복원했는지, 라우팅이 최종적으로 어떤 아웃바운드를 선택했는지입니다. 네 단계 중 빠진 단계가 있으면 해당 모듈로 돌아가 수정하고, 노드와 프로토콜을 동시에 교체하지 마세요.

‘조회가 빠른 것’과 ‘연결이 빠른 것’도 구분해야 합니다. FakeDNS의 로컬 응답은 수 밀리초 안에 끝날 수 있지만 프록시 노드 지연, TCP 패킷 손실, TLS 핸드셰이크, 서버 응답이 여전히 페이지 속도를 결정합니다. 가상 매핑과 라우팅이 모두 올바르다면 속도 문제는 노드 지연, 패킷 손실률, 전송 매개변수를 계속 확인해야 합니다.