FakeDNS란? V2Ray 가상 DNS 작동 원리와 설정 시점

이 글에서 다루는 내용

FakeDNS는 가상 IP에 도메인 정보를 연결해 두는 방식으로, 도메인별 라우팅이 필요한 투명 프록시 환경에 적합합니다. DNS 응답부터 연결 처리와 도메인 복원까지 원리를 살펴보고, 커널 설정 예시와 TUN 점검·복구 방법을 안내합니다. 핵심은 만능 설정을 찾는 것이 아니라 DNS 요청과 후속 연결이 같은 복원 경로를 거치는지 확인하는 것입니다.

FakeDNS란? 가상 IP로 도메인 연결 정보 보존하기

일반 DNS는 도메인을 실제 연결 가능한 IP 주소로 변환합니다. 반면 FakeDNS는 지정된 주소 풀에서 가상 IP를 할당해 앱에 응답하고, 도메인과 가상 IP의 대응 관계를 저장합니다. 앱은 평소처럼 연결을 시도하지만 이 주소는 웹 서버의 실제 주소가 아니므로, 로컬 프록시가 연결을 받아 처리해야 합니다.

예를 들어 앱이 example.com을 조회하면 로컬 FakeDNS가 198.18.0.1을 할당할 수 있습니다. 앱이 이 주소의 443 포트에 연결하면 프록시는 매핑 정보를 조회해 목적지를 example.com:443으로 복원한 뒤, 도메인 규칙과 출구를 선택합니다. 주소는 작동 과정을 설명하기 위한 예시이며, 조회할 때마다 같은 주소가 할당된다는 뜻은 아닙니다.

도메인 조회 가상 IP 할당 대상 연결 가로채기 원래 도메인 복원 출구 규칙 적용

FakeDNS는 프록시에 연결이 도착했을 때 IP만 남고 도메인 정보가 사라지는 문제를 해결합니다. 노드를 제공하거나 VMess, VLESS, Trojan을 대체하지 않으며 REALITY 핸드셰이크 설정에도 영향을 주지 않습니다. 구독은 연결 정보를 제공하고 FakeDNS는 로컬 연결과 도메인 사이의 관계를 보존하므로, 두 기능은 서로 다른 계층에서 작동합니다.

198.18.0.0/15

아래 예시에서 사용하는 IPv4 주소 풀

일반 DNS에서 주로 사용하는 서비스 포트

4096

아래 예시에서 설정한 매핑 풀 용량

도메인 복원과 일반 스니핑의 차이

일반 프로토콜 스니핑은 HTTP Host나 TLS ClientHello에서 확인할 수 있는 서버 이름처럼 연결의 애플리케이션 계층 정보를 분석합니다. FakeDNS는 앞서 저장한 매핑을 바탕으로 도메인을 복원하므로 앱이 데이터 안에 도메인을 직접 노출할 때까지 기다릴 필요가 없습니다. 두 방식은 함께 사용할 수 있지만, HTTP/TLS 스니핑을 켰다고 FakeDNS 설정까지 완료되는 것은 아닙니다.

매핑을 통한 복원: 대상 가상 IP에 해당하는 도메인을 조회합니다. IP를 할당한 쪽과 연결을 받는 쪽이 유효한 매핑 정보를 공유해야 합니다.
프로토콜 스니핑: 연결 데이터에서 도메인을 추출합니다. 식별할 수 있는 도메인 정보가 없는 트래픽에서는 결과를 보장할 수 없습니다.
도메인 라우팅: 복원한 도메인으로 규칙을 적용합니다. 도메인을 복원했다고 규칙이 반드시 일치하는 것은 아니므로 규칙 순서와 대상 출구도 확인해야 합니다.
실제 연결: 프록시 출구는 도메인을 원격 측에 전달해 조회할 수 있습니다. 직접 연결 출구는 대개 실제 주소를 알아내야 하며, 구체적인 동작은 커널과 출구 설정에 따라 다릅니다.

따라서 FakeDNS를 켠다고 실제 DNS가 완전히 불필요해지는 것은 아닙니다. 앱은 실제 주소 조회를 기다리는 과정을 생략할 수 있지만, 직접 연결을 설정하거나 노드 서버 도메인을 조회하는 단계에서는 실제 DNS가 필요할 수 있습니다. 원격 프록시 연결에서는 목적지 도메인을 원격 측에서 조회할 수도 있습니다.

FakeDNS와 TUN: 연결해야 할 두 경로

TUN은 가상 네트워크 인터페이스를 제공해 라우팅 조건에 맞는 IP 트래픽을 받습니다. FakeDNS는 가상 DNS 응답과 매핑을 제공합니다. TUN이 가상 IP로 향하는 연결을 다시 프록시로 전달할 수 있어 두 기능을 함께 사용하는 경우가 많지만, TUN만으로 모든 DNS가 가로채지거나 특정 FakeDNS 구현이 사용되는 것은 아닙니다.

DNS 처리 경로

입력: 앱에서 보낸 도메인 조회 요청
처리: 지정된 DNS 모듈에서 가상 IP 할당
점검 항목: 시스템 DNS, 앱의 암호화 DNS, IPv6 조회

요청이 이 경로로 들어오지 않으면 나중에 복원할 매핑도 만들어지지 않습니다.

연결 처리 경로

입력: 앱에서 가상 IP로 보내는 연결
처리: TUN이 연결을 받아 해당 매핑 복원 로직으로 전달
점검 항목: 가상 주소 대역 라우팅, 매핑 수명, 출구 대상

해당 매핑을 모르는 다른 커널에 가상 주소를 그대로 전달해서는 안 됩니다.

v2rayN에서는 TUN 경로와 일반 프록시 경로가 서로 다른 설정 생성 방식이나 처리 모듈을 사용할 수 있습니다. 한 커널의 fakedns JSON을 다른 TUN 설정 형식에 그대로 붙여 넣지 마세요. 먼저 현재 선택된 커널과 사용 중인 설정, 로그를 확인한 뒤 어느 계층에서 DNS를 처리하는지 판단해야 합니다.

먼저 TUN을 끄고 기존 시스템 프록시로 노드에 정상 연결되는지 확인해 구독이나 서버 문제를 배제합니다.
v2rayN의 ‘설정’ → ‘매개변수 설정’에서 현재 버전이 제공하는 커널과 관련 설정 항목을 확인합니다. 메뉴 이름은 버전에 따라 다를 수 있으므로 실제 화면을 기준으로 확인하세요.
TUN을 켠 뒤 시스템 라우팅을 확인해 가상 주소 대역이 물리 게이트웨이가 아닌 프록시 경로로 전달되는지 점검합니다.
DNS 가로채기 설정과 앱 자체의 암호화 DNS 설정도 함께 확인합니다. 연결만 가로채고 도메인 매핑은 만들지 못하는 상황을 방지할 수 있습니다.

V2Ray / Xray 설정: 할당과 복원은 한 쌍

아래는 해당 필드를 지원하는 V2Ray / Xray 커널의 설정 예시로, 필드 간 관계를 설명하기 위한 것입니다. 전체 v2rayN 가져오기 설정이 아니며 인바운드 리스너, 노드 아웃바운드, 전체 라우팅 규칙은 포함하지 않습니다. GUI 클라이언트가 보통 해당 내용을 생성하며, 생성된 파일을 수정해도 다음 저장 때 덮어쓸 수 있습니다.

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

dns.servers의 fakedns는 가상 DNS 응답을 사용한다는 뜻이고, 최상위 fakedns는 주소 풀과 용량을 정의합니다. 여기서 4096은 설명을 위한 용량 예시이며 모든 커널의 기본값이나 성능 지표가 아닙니다. 실제 DNS 요청이 이 DNS 모듈로 들어가도록 설정해야 합니다. 필드만 추가해서는 시스템 요청을 자동으로 가로채지 않습니다.

가상 IP 연결을 받는 인바운드에도 해당 복원 기능을 켜야 합니다. 아래 sniffing 객체는 관련 인바운드 객체에 병합해야 하며, 별도의 최상위 설정이 아닙니다. 실제 필드 지원 여부는 사용하는 커널을 기준으로 확인하세요.

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

enabled는 이 인바운드의 스니핑 처리를 켭니다. destOverride의 fakedns는 가상 주소 매핑을 이용해 대상을 복원하도록 지정합니다.
이 예시에서는 routeOnly: false를 사용해 복원 결과를 라우팅 규칙 적용뿐 아니라 대상 교체에도 사용할 수 있게 합니다. 출구 동작을 이해하지 못한 상태에서 라우팅 전용 모드로 바꾸지 마세요.
프록시 출구를 선택했다면 복원된 도메인이 프록시 경로로 전달되는지 확인하세요. 직접 연결을 선택했다면 실제 주소를 얻을 수 있는 조회 경로를 마련해 가상 주소가 다시 반환되는 순환을 방지해야 합니다.
geosite: 규칙은 도메인 분류를, geoip: 규칙은 주소 분류를 기준으로 적용됩니다. 가상 IP는 대상 서버의 지리적 위치를 나타내지 않으므로 실제 대상 IP의 지역 분류에 사용할 수 없습니다.

언제 켤까? 연결 방식에 따라 선택하기

앱이 HTTP 프록시나 도메인을 포함한 SOCKS 요청으로 연결한다면 프록시가 이미 도메인을 알고 있을 수 있어 FakeDNS를 추가해도 얻는 이점이 크지 않습니다. 투명 프록시에서 대상 IP만 확인할 수 있고 도메인 규칙을 안정적으로 적용해야 하는 경우에 더 적합합니다.

사용 상황	권장 사항	먼저 확인할 항목
TUN으로 트래픽을 가로채고 도메인별로 주로 라우팅하는 경우	사용을 검토할 수 있음	DNS 요청과 연결이 매핑 정보를 공유하는지
브라우저에서 명시적 프록시를 사용하는 경우	우선 현재 설정 유지	프록시가 이미 도메인을 전달받는지
기업 내부망 및 로컬 네트워크 서비스 검색	먼저 실제 DNS 조회 예외 설정	내부 도메인, 프린터, 로컬 기기 접근
앱에서 자체 암호화 DNS를 강제 사용하는 경우	먼저 DNS 조회 우회 문제 해결	요청이 로컬 DNS 모듈을 거치는지
도구에서 대상의 실제 IP를 표시해야 하는 경우	해당 조회에는 실제 DNS 응답 유지	진단 결과가 가상 IP로 대체되는지

결론: 도메인 정보가 사라지는지 확인한 뒤 설정하세요

로그에 대상 도메인이 표시되고 도메인 규칙도 정상적으로 적용된다면 현재 DNS 설정을 유지하세요. 투명 프록시 경로에서 실제로 도메인 정보가 사라지고 조회와 연결을 모두 가로챌 수 있을 때만 FakeDNS를 시험해 보세요.

198.18.0.0/15는 네트워크 벤치마킹에 사용하는 특수 목적 주소 대역입니다. 웹사이트의 공인 IP 주소가 아니며 일반적인 사설망 대역과도 다릅니다. 로컬 테스트망이나 기업 환경에서 이미 사용 중이라면 먼저 라우팅 충돌을 확인하세요. 다른 주소 풀을 쓸 때도 커널 지원 여부와 라우팅 계획을 확인해야 하며, 임의의 공인 IP 대역으로 대체해서는 안 됩니다.

검증 방법: DNS 응답만 확인하지 마세요

전체 연결 경로를 검증해야 합니다. 198.18 또는 198.19로 시작하는 주소가 보이는 것은 특정 조회에서 가상 응답을 받았다는 뜻일 뿐, 이후 연결에서 도메인이 복원되거나 올바른 라우팅 규칙이 적용되었다는 증거는 아닙니다. 반대로 도구에 실제 주소가 표시되더라도 의도한 DNS 경로를 우회했을 수 있습니다.

기준 상태 기록. 현재 설정을 저장하고, 원래 접속할 수 있던 도메인 하나와 현재 노드 및 라우팅 모드를 기록합니다. 테스트 중에는 프로토콜을 바꾸지 마세요.
새 조회 실행. 설정을 적용한 뒤 테스트 앱을 다시 시작합니다. Windows에서는 ipconfig /flushdns를 실행해 시스템 DNS 캐시를 지울 수 있습니다. 브라우저 자체의 DNS 및 연결 캐시는 별도로 지워야 할 수 있습니다.
DNS 경로 확인. nslookup example.com으로 시스템 DNS 경로를 점검할 수 있습니다. 다만 이 도구가 브라우저의 암호화 DNS 동작을 재현하지 않을 수 있으므로, 이것만으로 정상 여부를 판단하지 마세요.
연결 로그 확인. 가상 대상이 원래 도메인으로 복원되는지, 최종적으로 어떤 출구가 적용되는지 확인합니다. 테스트를 위해 로그 상세 수준을 일시적으로 높였다면, 끝난 뒤 원래대로 되돌려 방문 도메인이 장기간 기록되지 않도록 하세요.
교차 테스트. 프록시 사이트, 직접 연결 사이트, 내부 도메인, IPv6 환경을 각각 확인합니다. 웹페이지 하나만 테스트하면 직접 연결 시 DNS 조회가 순환하거나 AAAA 조회가 우회하는 문제를 놓치기 쉽습니다.

자주 묻는 질문과 설정 복구

설정 후 모든 웹페이지가 열리지 않으면 무엇부터 바꿔야 하나요?

먼저 이전 DNS 모드로 복구하고 테스트 앱을 다시 시작해 기본 연결이 정상인지 확인합니다. 그런 다음 가상 주소 대역으로 향하는 연결이 올바른 인바운드로 들어가는지, 해당 인바운드에서 매핑 복원이 켜져 있는지 확인하세요. 구독이나 전송 프로토콜부터 바꾸지 마세요.

웹페이지는 열리는데 내부망 도메인이 조회되지 않으면 어떻게 하나요?

내부 도메인은 로컬 네트워크 DNS를 사용하는 실제 주소 조회 예외를 설정하고, 해당 도메인에 필요한 직접 연결 라우팅도 유지하세요. 내부 DNS 서버는 현재 네트워크 환경에 따라 동작할 수 있으므로 내부 도메인을 모두 외부 DNS 서버로 보내도 같은 결과를 기대할 수는 없습니다.

일부 앱에서만 가상 IP를 받지 못하는 이유는 무엇인가요?

해당 앱이 자체 암호화 DNS를 사용하는지, 캐시된 결과가 있는지, 고정 IP에 직접 연결하는지 확인하세요. 먼저 시스템 DNS를 사용하는 테스트 앱 하나로 전체 경로를 재현한 뒤 앱별 차이를 확인합니다. IP를 직접 사용하는 연결에는 복원할 DNS 매핑 자체가 없습니다.

v2rayNG와 v2flyNG에 데스크톱 설정을 그대로 복사해도 되나요?

그대로 복사할 수 없습니다. v2rayNG는 Xray 커널을, v2flyNG는 v2fly 커널을 사용하며, Android VPN 가로채기와 데스크톱 TUN의 설정 경로도 다릅니다. 앱에서 관련 기능을 설정할 수 있는지, 현재 커널이 해당 필드를 지원하는지 확인하고 앱이 실제로 생성한 설정을 점검하세요.

설정을 되돌릴 때는 DNS 설정 복구, 기존 라우팅 복구, 가로채기 서비스 재시작, 앱 캐시 삭제 순서로 진행하세요. 정상 작동하는 기준 설정을 보관하면 FakeDNS, IPv6, 스니핑, 라우팅 정책을 한꺼번에 조정하는 것보다 문제를 찾기 쉽습니다. 다시 켤 때는 한 번에 한 항목만 바꿔야 조회 우회, 매핑 만료, 출구 규칙 중 어디에서 문제가 생겼는지 구분할 수 있습니다.