FakeDNS 작동 원리 해설: 가상 주소 매핑으로 DNS 지연 줄이기

FakeDNS 흐름: 가상 IP를 먼저 반환하고 원래 도메인을 복원

일반적인 DNS 과정에서는 먼저 도메인을 DNS 서버로 보내 실제 A 또는 AAAA 레코드를 받은 다음, 애플리케이션이 반환된 주소에 연결합니다. 이 과정에는 최소 한 번의 DNS 왕복이 필요합니다. 시스템 DNS 응답이 느리거나 DNS 요청이 잘못된 경로로 나가거나 로컬 캐시에 기록이 없으면, 연결 수립이 DNS 단계에서 지연될 수 있습니다.

FakeDNS는 로컬 DNS 처리 경로를 바꿉니다. 애플리케이션이 도메인을 조회하면 커널은 즉시 공용 DNS에서 실제 주소를 가져오는 대신, 미리 정한 주소 풀에서 가상 IP를 할당하고 ‘도메인—가상 IP’ 매핑을 기록합니다. 이후 애플리케이션이 가상 IP로 연결을 시작하면 TUN 인바운드가 연결을 가로채고, 코어가 매핑 테이블에서 원래 도메인을 찾아 도메인 규칙에 따라 프록시, 직접 연결 또는 차단 출구를 선택합니다.

일반적으로 사용하는 IPv4 주소 풀은 198.18.0.0/15입니다. 이 주소 대역은 네트워크 장비 벤치마크 테스트용으로 사용되며 공용 인터넷에서 라우팅되지 않으므로, 로컬 매핑 표식으로 적합합니다. 가상 IP는 대상 서버의 주소가 아니며 최종 목적지로 프록시 노드에 직접 전송되지도 않습니다. 로컬 인덱스와 비슷한 역할을 할 뿐이고, 실제 프록시 요청의 목적지는 복원된 도메인입니다.

위 지연 시간은 동일한 기기에서 캐시를 비운 조회를 100회 연속 실행한 예시입니다. 로컬 FakeDNS 응답 중앙값은 약 1.2ms, 원격 DNS 왕복 중앙값은 약 43ms였습니다. 이는 첫 DNS 응답이 더 빨라질 수 있음을 보여 줄 뿐이며, 웹 페이지 전체 로딩 시간이 반드시 41.8ms 줄어든다는 뜻은 아닙니다. 이후 속도는 TLS 핸드셰이크, 노드 왕복 시간, 패킷 손실과 서버 응답이 좌우합니다.

매핑 테이블, 스니핑과 아웃바운드의 연동 방식

FakeDNS가 작동하려면 세 단계가 동시에 충족되어야 합니다. DNS 조회를 코어가 받아야 하고, 가상 주소 연결을 해당 인바운드가 가로채야 하며, 아웃바운드로 나가기 전에 매핑 기록으로 도메인을 복원할 수 있어야 합니다. 주소 풀만 활성화하고 TUN 트래픽을 코어로 유입시키지 않으면 애플리케이션이 198.18.x.x를 받은 뒤 연결하지 못할 수 있습니다.

코어가 가상 IP를 대상으로 한 연결을 받으면 대상이 FakeDNS 주소 풀에 속하는지 확인합니다. 예를 들어 매핑 테이블에 198.18.0.27이 example.net에 대응한다고 기록되어 있으면 대상을 도메인으로 복원할 수 있습니다. 이후 라우터는 설정 순서에 따라 도메인 규칙, IP 규칙, 포트 규칙과 인바운드 태그를 확인하고 프록시 또는 직접 연결 아웃바운드를 선택합니다.

여기서 ‘프로토콜 스니핑’과 ‘FakeDNS 복원’을 혼동하기 쉽습니다. HTTP, TLS 또는 QUIC 스니핑은 트래픽 내용에서 도메인을 식별하려고 시도하지만, FakeDNS 복원은 앞서 생성된 매핑을 직접 읽습니다. 두 기능은 함께 사용할 수 있습니다. 다만 매핑 복원은 모든 연결에서 식별 가능한 호스트명이 노출되어야 하는 방식이 아니므로, 페이로드에서 도메인을 추출하기 어려운 연결에서도 더 안정적으로 작동합니다.

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

이 설정은 주소 풀과 DNS 서버 사이의 개념적 관계만 보여 주며, 인바운드·라우팅·아웃바운드 없이 단독으로 사용할 수 없습니다. 클라이언트가 실제 설정을 생성할 때는 TUN 인바운드에서 대상 복원이 활성화되어 있는지, 로컬 네트워크가 같은 주소 대역을 실험 장비나 기업 테스트 환경에 사용하고 있지 않은지도 확인해야 합니다.

FakeDNS가 지연 시간과 라우팅에 미치는 실제 영향

FakeDNS의 가장 직접적인 효과는 ‘애플리케이션이 실제 DNS 응답을 기다리는 과정’을 ‘애플리케이션이 로컬 가상 주소를 즉시 받는 과정’으로 바꾸는 것입니다. 원격 DNS 왕복 시간이 길거나 첫 패킷이 타임아웃되기 쉽거나 여러 애플리케이션이 동시에 캐시 조회를 시작할 때 차이가 크게 나타납니다. 이미 시스템 캐시에 기록된 도메인은 전체 조회 지연을 다시 부담하지 않으므로 효과가 줄어듭니다.

두 번째 효과는 도메인 정보를 유지하는 것입니다. 일반적인 DNS 조회 후에는 애플리케이션이 실제 IP에만 연결하므로 TUN에 들어오는 정보가 대상 주소뿐일 수 있습니다. 하나의 IP에서 여러 도메인을 서비스한다면 IP 규칙만으로는 정확히 구분하기 어렵습니다. FakeDNS가 연결 단계에서 원래 도메인을 복원하면 domain, domainSuffix, geosite 같은 규칙을 아웃바운드 선택 전에 매칭할 수 있습니다.

확인 항목	일반 원격 DNS	FakeDNS	판단 방법
처음 반환되는 주소	실제 A/AAAA 레코드	예약 대역 가상 IP	애플리케이션 측 조회 결과 확인
도메인 정보	조회 후 IP만 남을 수 있음	매핑 테이블로 복원	라우팅 매칭 로그 확인
콜드 조회 지연	DNS 왕복 시간의 영향	대개 로컬 응답	연속 테스트 후 중앙값 비교
최종 연결 대상	실제 IP 또는 원격 조회 결과	복원된 도메인	프록시 아웃바운드 로그 확인

세 번째 효과는 DNS 조회 경로를 더 일관되게 만들 수 있다는 점입니다. 특정 도메인은 프록시를 통해야 하는데 시스템이 먼저 로컬 네트워크에서 DNS를 조회하면, DNS 경로와 트래픽 경로가 분리될 수 있습니다. FakeDNS는 로컬에서 먼저 가상 주소를 할당하고 실제 조회를 프록시 아웃바운드 측으로 미룰 수 있으므로, 로컬 DNS가 프록시 도메인의 조회 결과에 미치는 영향을 줄입니다.

FakeDNS는 문제 해결 방식도 바꿉니다. 198.18.x.x가 보인다고 즉시 DNS 오류로 판단해서는 안 됩니다. 먼저 해당 주소가 설정된 풀에 속하는지, 매핑 기록이 존재하는지, 연결이 TUN으로 들어갔는지 확인하세요. 애플리케이션은 가상 주소를 받았지만 코어가 도메인을 복원하지 못할 때에만 연결 중간 단계가 끊긴 것으로 볼 수 있습니다.

TUN 모드 및 라우팅 규칙과 함께 사용하기

TUN 모드는 가상 네트워크 카드를 통해 시스템 프록시를 직접 사용하지 않는 프로세스의 트래픽을 가로채므로 FakeDNS와 가장 자주 함께 사용하는 진입 방식입니다. v2rayN에서는 먼저 ‘설정’ → ‘매개변수 설정’에서 로컬 수신 포트를 확인한 다음 TUN 모드를 활성화하세요. TUN 옵션의 위치는 버전에 따라 달라질 수 있으므로 최종적으로 상태 표시줄과 코어 시작 로그를 기준으로 확인해야 합니다.

Android의 v2rayNG는 Xray 코어를 사용하고, v2flyNG는 v2fly 코어를 사용합니다. 기기 전체 트래픽 가로채기를 활성화한 뒤에는 클라이언트 설정의 로컬 DNS, 도메인 정책과 라우팅 모드가 동일한 설정 구성에서 비롯되었는지 확인해야 합니다. 다른 로컬 네트워크 도구가 VPN 인터페이스를 동시에 점유하게 두지 마세요. DNS 조회가 현재 코어를 우회할 수 있습니다.

1. 먼저 TUN 가로채기를 확인합니다. 애플리케이션 자체의 HTTP 또는 SOCKS 프록시 설정을 끄고 클라이언트를 시작한 뒤 테스트 도메인에 접속하여 연결이 여전히 코어 로그에 나타나는지 확인하세요.
2. 다음으로 가상 주소를 확인합니다. 캐시되지 않은 도메인을 조회하고 설정된 풀의 198.18.x.x 주소가 반환되는지 확인하세요.
3. 도메인 복원을 확인합니다. 라우팅 로그에서 가상 IP만 보지 말고 원래 도메인을 찾아보세요. 가상 IP만 기록된다면 대상 복원 설정을 점검해야 합니다.
4. 규칙 매칭을 검증합니다. 프록시 도메인과 직접 연결 도메인을 각각 테스트하여 예상한 아웃바운드 태그로 연결되는지 확인하세요.
5. 마지막으로 폴백을 테스트합니다. FakeDNS를 끈 뒤 일반 DNS로 전환하여 설정에 문제가 생겨도 명확하게 사용할 수 있는 폴백 경로가 남아 있는지 확인하세요.

규칙 순서는 특히 중요합니다. 가상 주소는 임시 대상일 뿐입니다. 포괄적인 IP 규칙이 먼저 198.18.0.0/15와 매칭되어 직접 연결을 허용하면, 도메인이 복원되기 전에 연결이 잘못된 출구로 전달될 수 있습니다. 더 안정적인 방법은 TUN 인바운드에서 FakeDNS 복원을 완료한 뒤 도메인 규칙으로 라우팅하고, LAN과 내부 서비스를 명확히 제외하는 것입니다.

FakeDNS를 켜기 적합한 환경과 피해야 할 환경

TUN이 안정적으로 트래픽을 가로채고, 원격 DNS 왕복 시간이 길며, 도메인 라우팅 규칙이 많고, 애플리케이션 트래픽이 IP 형태로만 코어에 들어오는 환경이라면 FakeDNS를 켜기에 적합합니다. 이 경우 콜드 조회 대기 시간을 줄이는 동시에 라우터가 원래 도메인을 다시 사용할 수 있으므로 단순히 수십 밀리초를 줄이는 것 이상의 효과가 있습니다.

브라우저에서만 로컬 HTTP 또는 SOCKS 포트로 명시적 연결을 사용하는 경우 브라우저는 대개 도메인을 프록시에 직접 전달합니다. 코어가 이미 도메인을 받은 상태라면 FakeDNS가 라우팅 정확도를 높이는 효과는 작습니다. 이런 구성에서는 우선 10808, 10809 등의 수신 포트가 충돌하지 않는지 확인하고 시스템 프록시가 올바른 포트를 가리키는지 점검하세요.

• 사용 권장:TUN으로 전체 트래픽을 가로채며 코어 로그에 대상 IP만 표시되는 경우가 많습니다.
• 사용 권장:원격 DNS 콜드 조회가 장기간 50ms를 초과하고 앱을 처음 열 때 눈에 띄는 대기가 발생합니다.
• 주의해서 사용:조직 내부 도메인은 LAN DNS가 반드시 조회해야 하며, 지역별로 다른 도메인 조회 결과가 존재합니다.
• 주의해서 사용:실제 네트워크가 이미 198.18.0.0/15 또는 사용자 지정 가상 주소 풀을 사용합니다.
• 효과 제한적:애플리케이션이 이미 명시적 프록시로 도메인을 전달하고 있으며 로컬 DNS가 현재 병목이 아닙니다.

로그로 검증과 문제 해결을 완료하는 방법

FakeDNS 검증은 웹 페이지가 열리는지만 확인해서는 안 됩니다. DNS 응답, TUN 가로채기, 도메인 복원, 규칙 매칭과 프록시 아웃바운드의 다섯 단계를 모두 점검해야 합니다. 어느 한 단계라도 빠지면 ‘가끔 작동함’ 또는 ‘일부 앱만 실패함’ 같은 결과가 나타날 수 있습니다.

이전에 접속하지 않았던 도메인 두 개를 선택하세요. 하나는 프록시를 사용하고 다른 하나는 직접 연결되어야 합니다. 클라이언트 내부 DNS 캐시를 비운 뒤 각각 조회를 시작하고 반환 주소와 시간을 기록하세요. 그런 다음 즉시 연결을 수립하여 로그에서 원래 도메인, 인바운드 태그와 아웃바운드 태그를 확인합니다. 테스트 중에는 노드 차이를 DNS 차이로 잘못 판단하지 않도록 노드를 자주 바꾸지 마세요.

1. 현재 클라이언트 설정을 기록하고 로컬 SOCKS 포트가 10808, HTTP 포트가 10809인지 확인하거나 실제 사용자 지정 값을 기록하세요.
2. TUN을 시작한 뒤 코어 로그에서 가상 네트워크 카드가 성공적으로 생성되었고 라우팅 추가 실패나 인터페이스 점유 메시지가 없는지 확인하세요.
3. 테스트 도메인을 조회하여 응답 주소가 설정된 FakeDNS 풀에 포함되는지 확인하세요. 응답 시간은 일반적으로 원격 DNS 왕복 시간보다 짧아야 합니다.
4. 연결을 시작한 뒤 로그에서 원래 도메인을 검색하고, 최종 대상이 계속 198.18.x.x로만 표시되지 않는지 확인하세요.
5. 프록시 도메인이 proxy에, 직접 연결 도메인이 direct에 매칭되는지 확인하고 앞에 있는 포괄적인 규칙에 덮어쓰이지 않도록 하세요.
6. 연속으로 20회 테스트하여 중앙값과 실패 횟수를 각각 기록하세요. 한 번의 가장 빠른 결과로 결론을 내리지 마세요.

테스트에 실패하면 역순으로 되돌려 보세요. 먼저 도메인 라우팅 규칙을 잠시 비활성화하여 기본 프록시 아웃바운드에 연결할 수 있는지 확인합니다. 다음으로 FakeDNS를 끄고 일반 DNS를 사용해 조회를 점검합니다. 마지막으로 TUN을 끄고 명시적 시스템 프록시로 로컬 수신 포트를 확인합니다. 한 번에 하나의 변수만 바꿔야 문제가 주소 풀, DNS, TUN, 라우팅 또는 노드 경로 중 어디에 있는지 판단할 수 있습니다.

FakeDNS의 핵심 가치는 특이해 보이는 조회 결과를 만드는 데 있지 않고, 전체 트래픽을 가로채는 환경에서도 도메인 정보를 안정적으로 유지하는 데 있습니다. 올바르게 설정하면 가상 주소는 로컬에 잠시만 존재하고, 라우팅 판단은 복원된 도메인을 사용하며, 프록시 아웃바운드는 VMess, VLESS와 구독 노드의 실제 설정에 따라 연결을 수립합니다. 사용 여부는 DNS 지연 시간, TUN 가로채기 방식, 내부 네트워크 구조와 라우팅 요구 사항을 종합해 결정해야 합니다.