V2Ray FakeDNS란? 작동 원리와 설정 방법, 활용 사례

핵심 내용

FakeDNS는 도메인과 가상 주소의 매핑을 저장해 두었다가, 대상 IP만 확인할 수 있는 투명 프록시가 원래 도메인을 다시 알아내도록 돕습니다. DNS 조회와 이후 연결을 같은 프록시 경로에서 처리하는 경우에 적합하며, DNS 주소만 바꿔 속도를 높이는 기능은 아닙니다. 아래에서 데이터 흐름을 살펴보고 Xray 설정 예시, v2rayN 확인 경로, 연결이 끊겼을 때의 복구 방법을 안내합니다.

FakeDNS란? 먼저 가상 IP를 반환한 뒤 도메인 복원

일반 DNS는 “이 도메인에 해당하는 실제 주소가 무엇인가요?”라는 질문에 답합니다. FakeDNS는 “방금 조회한 도메인을 이 가상 주소로 나타내세요”라고 답합니다. 예를 들어 앱이 example.com을 조회하면 FakeDNS는 주소 풀에서 주소 하나를 할당하고 대응 관계를 저장합니다. 앱이 그 주소로 연결하면 프록시 진입점이 도메인을 찾아내고, 도메인 규칙에 따라 직접 연결하거나 프록시를 통해 내보냅니다.

앱에서 도메인 조회 가상 주소 할당 프록시로 연결 유입 매핑에서 도메인 복원 규칙에 따라 아웃바운드 선택

핵심은 “가상”이라는 말이 아니라 전체 흐름이 이어지는지입니다. DNS 응답에 사용된 매핑 테이블에 이후 연결을 처리하는 구성 요소도 접근할 수 있어야 합니다. DNS 요청은 한 프로세스로 들어가고 연결은 매핑을 공유하지 않는 다른 프로세스로 전달된다면, 후자는 공용 인터넷에 접속할 수 없는 대상 주소만 보게 됩니다. 두 프로그램 모두 프록시라고 해서 매핑을 자동으로 공유한다고 가정해서는 안 됩니다.

일반 DNS와 FakeDNS의 차이

일반 DNS도 도메인 기반 라우팅과 함께 사용할 수 있습니다. 앱이 HTTP 프록시를 사용하거나 도메인을 SOCKS 프록시에 전달하면 프록시가 이미 도메인을 알고 있을 수 있으므로, 이 경우 FakeDNS를 추가해도 얻는 이점이 크지 않을 수 있습니다. TUN이나 투명 프록시가 IP를 대상으로 하는 연결을 가로채고, 라우팅 규칙에는 원래 도메인이 필요한 경우에 FakeDNS가 특히 유용합니다.

비교 항목	일반 DNS	FakeDNS
응답 결과	상위 DNS 서버에서 조회한 실제 주소	로컬 주소 풀에서 할당한 가상 주소
도메인 보존 방식	프록시 프로토콜, 스니핑 또는 추가 기록에 의존	도메인과 가상 주소의 매핑 테이블에 의존
이후 연결	실제 IP로 연결 가능	먼저 연결을 가로채 대상 주소를 복원해야 함
실제 주소를 조회하는 시점	대개 앱이 연결하기 전	아웃바운드 방식에 따라 이후 단계에서 처리
비활성화 후 남는 캐시	캐시된 주소는 유효 기간 동안 대체로 계속 연결 가능	남아 있는 가상 주소 때문에 연결이 실패할 수 있음

FakeDNS는 암호화 DNS와도 다릅니다. DoH와 DoT는 DNS 조회를 전송하는 방식을 다루고, FakeDNS는 도메인 정보가 이후 연결까지 어떻게 이어지는지를 다룹니다. 조회를 FakeDNS에 전달하더라도 직접 연결 대상에는 실제 주소 조회가 필요할 수 있으며, 프록시 서버의 도메인도 정상적으로 해석되어야 합니다. 따라서 모든 DNS 요청이 사라지거나 모든 트래픽이 프록시를 통과한다고 볼 수는 없습니다.

주소 풀과 포트: 헷갈리기 쉬운 숫자 세 가지

131072

/15 네트워크에 포함되는 IPv4 주소 수

65535

이 글의 예시에서 사용하는 poolSize 값

일반 DNS 서비스의 포트 번호

198.18.0.0/15는 198.18.0.0부터 198.19.255.255까지 포함하며, 주소는 총 131072개입니다. 그렇다고 매핑 테이블이 이 주소를 모두 동시에 저장한다는 뜻은 아닙니다. 예시에 나온 poolSize는 매핑 풀의 용량 설정입니다. 주소 범위, 매핑 용량, DNS 캐시 유효 기간은 서로 다른 개념입니다.

포트도 구분해야 합니다. 시스템이 DNS 서비스에 조회를 보낼 때 일반적으로 사용하는 대상 포트는 UDP 또는 TCP 53입니다. 프록시 프로그램 내부의 DNS 수신 포트는 별도로 설정할 수 있습니다. HTTP·SOCKS 로컬 수신 포트는 DNS 포트가 아니므로, 시스템 DNS를 HTTP 프록시 수신 주소로 지정해도 FakeDNS가 자동으로 작동하지 않습니다.

주소 풀은 기존 VPN, 사내 네트워크, 테스트 네트워크에서 사용하는 대역과 겹치지 않도록 설정하세요.
주소 풀을 변경했다면 TUN 라우팅 또는 투명 전달 규칙이 새 대역을 포함하는지 함께 확인하세요.
매핑 풀을 크게 설정해도 웹페이지가 더 빨라지는 것은 아닙니다. 먼저 DNS 조회와 연결이 같은 경로를 따라 처리되는지 확인하세요.

설정 전에 확인할 점: DNS를 가로채는 주체와 연결을 처리하는 주체

v2rayN은 클라이언트 인터페이스이고, Xray는 실행될 수 있는 프록시 코어입니다. 인터페이스의 TUN 기능은 별도 구성 요소가 담당할 수도 있으므로, 노드에서 VLESS나 VMess를 사용한다는 이유만으로 TUN의 DNS를 Xray가 처리한다고 단정할 수 없습니다. 프로토콜은 노드 연결 방식을 설명할 뿐, 로컬 DNS 가로채기 구조를 결정하지 않습니다.

시스템 프록시 사용 환경

가로채는 대상: 시스템 프록시 설정을 따르는 앱
도메인 정보의 출처: 프록시 요청에 도메인이 직접 포함될 수 있음
DNS 처리 범위: 시스템의 모든 DNS 조회를 가로채는 것은 아님
권장 시작 방법: 먼저 일반 DNS와 도메인 라우팅 사용

브라우저에서 프록시로 접속하는 용도만 필요하다면 가상 주소 풀을 먼저 도입할 필요는 없습니다.

TUN 또는 투명 프록시 사용 환경

가로채는 대상: 가상 네트워크 인터페이스 또는 전달 진입점으로 들어오는 패킷
도메인 정보의 출처: FakeDNS 매핑 또는 다른 스니핑 결과
DNS 처리 범위: DNS 조회를 가로채는 경로를 명확히 설정해야 함
필수 조건: 가상 주소 연결이 해당 매핑 테이블로 돌아올 수 있어야 함

먼저 구성 요소의 구현 방식을 확인한 다음, 해당 구성 요소가 지원하는 FakeDNS 설정 형식을 선택하세요.

v2rayN의 「설정」→「매개변수 설정」에서 현재 코어와 관련된 설정을 확인하고, 시작 로그에서 실제로 실행된 프로세스를 살펴보세요. 버전에 따라 메뉴 그룹 이름이 달라질 수 있으므로 현재 인터페이스와 로그를 기준으로 판단하세요.
인터페이스에 「설정」→「DNS 설정」이 있다면, 먼저 어느 코어의 설정을 변경하는지 확인하세요. 이름이 같은 DNS 옵션을 전역 스위치로 간주해서는 안 됩니다.
현재 시스템 프록시 상태, TUN 상태, DNS 설정을 기록한 뒤 한 번에 하나씩 변경하세요. 바로 되돌릴 수 있도록 기존 설정을 복사해 두세요.
v2rayNG 또는 v2flyNG를 사용하는 경우에도 실제 코어와 설정의 지원 여부를 먼저 확인하세요. 데스크톱 클라이언트의 메뉴 경로를 Android에 그대로 적용하지 마세요.

Xray 설정 예시: 매핑 생성과 대상 복원 모두 필요

아래는 해당 필드를 지원하는 Xray 코어를 위한 설정 예시이며, 이것만으로 실행할 수 있는 완전한 노드 설정은 아닙니다. 사용 전에 로컬 코어 버전의 설정 문서를 확인하세요. 클라이언트가 자동 생성한 파일은 설정 저장이나 노드 전환 시 덮어써질 수 있으므로, 임시 파일을 반복해서 수정하기보다 클라이언트가 지원하는 사용자 설정 기능을 이용하세요.

1단계: 주소 풀 정의 및 FakeDNS 선택

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

최상위 fakedns에서 매핑 풀을 정의하고, dns.servers의 "fakedns"로 내부 FakeDNS 서비스를 선택합니다. 이 최소 예시는 필드 간 관계만 보여 줍니다. 노드 서버 도메인, LAN 도메인, 직접 연결 대상에 필요한 실제 DNS 조회 방식은 포함하지 않습니다. 실제 운영 설정에서는 용도에 따라 일반 DNS 서버를 지정해 모든 조회를 가상 주소 풀에 맡기지 않도록 하세요.

2단계: 연결을 받는 진입점에서 도메인 복원

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

두 번째 설정은 최상위 필드로 새로 추가하는 것이 아니라, 실제 대상 연결을 받는 inbound 객체에 병합해야 합니다. destOverride의 "fakedns"는 FakeDNS 매핑에서 대상 도메인을 복원하는 데 사용됩니다. DNS 조회를 받는 진입점에만 설정하고 웹 또는 앱 연결을 받는 진입점에는 빠뜨리지 마세요.

프록시에 연결하기 전에 프록시를 통해 DNS를 조회해야 하는 순환 의존성을 막으려면 노드 서버 주소를 먼저 조회할 수 있어야 합니다.
가상 주소 연결에 도메인 규칙만 적용한 뒤 가상 주소를 그대로 직접 연결해서는 안 됩니다. 아웃바운드 전에 대상 주소를 정상적으로 복원해야 합니다.
IPv6 조회를 사용하는 경우 AAAA 레코드와 IPv6 트래픽 정책을 별도로 설계하세요. IPv4 주소 풀만 설정했다고 해서 IPv6까지 가로채는 것은 아닙니다.

가상 주소만 확인하는 데 그치지 않고 FakeDNS 작동을 검증하는 방법

제대로 검증하려면 DNS 응답, 연결 가로채기, 최종 접속 결과를 모두 확인해야 합니다. 198.18.x.x가 표시되더라도 그 조회에서 가상 주소를 받았다는 뜻일 뿐, 브라우저 연결 성공이나 도메인 라우팅 규칙이 예상대로 적용됐다는 증거는 아닙니다.

이전 상태를 정리합니다. 테스트 브라우저를 닫고 설정을 적용한 다음 관련 코어를 재시작하세요. Windows에서는 터미널에서 아래 명령을 실행해 시스템 DNS 캐시를 지울 수 있습니다. 앱 자체 캐시는 별도로 지워야 할 수도 있습니다.
테스트 도메인을 조회합니다. nslookup example.com을 실행하고 반환 주소와 표시된 DNS 서버를 기록하세요. IPv4 FakeDNS를 사용한다면 A 레코드가 설정된 주소 풀에 포함되는지 확인하세요.
앱의 연결 경로를 확인합니다. 브라우저를 다시 열고 같은 도메인에 접속하세요. 브라우저의 보안 DNS가 시스템 조회 경로를 우회할 수 있으므로, 명령줄 결과가 모든 앱에 적용된다고 가정하지 말고 해당 기능을 잠시 끈 상태와 비교하세요.
라우팅 결과를 확인합니다. 코어 액세스 로그에서 대상 도메인과 아웃바운드 표시를 확인하세요. 로그 형식은 버전에 따라 다를 수 있으므로 “연결 성공” 문구만 보지 말고 예상한 도메인으로 복원됐는지 확인하세요.
직접 연결과 프록시 연결을 확인합니다. 기존 규칙이 적용되는 대상을 각각 하나씩 골라 테스트하고, 도메인 규칙에 일치한 뒤 해당 아웃바운드로 연결되는지 확인하세요. 가상 IP의 위치 정보를 기준으로 직접 연결 여부를 판단하지 마세요.

ipconfig /flushdns
nslookup example.com

nslookup에서 실제 IP가 반환된다면 조회가 FakeDNS로 들어가지 않았거나, 해당 도메인이 설계상 일반 DNS를 사용하도록 되어 있을 수 있습니다. 가상 IP가 반환되지만 웹페이지가 열리지 않는다면 구독이나 노드 설정을 먼저 바꾸지 말고 가상 대역의 라우팅과 매핑 복원을 확인하세요.

자주 묻는 문제: 가상 주소, 브라우저 우회, 비활성화 후 연결 끊김

198.18로 시작하는 주소를 확인했는데도 왜 접속할 수 없나요?

먼저 해당 주소가 현재 설정된 주소 풀에 속하는지 확인한 다음 TUN 라우팅이 그 주소를 가로채는지 살펴보세요. 이어서 연결을 받는 진입점이 같은 매핑을 읽을 수 있는지 확인하세요. DNS 응답은 적용됐지만 연결이 프록시를 우회하는 상태가 가장 흔한 반쪽 설정입니다.

명령줄 조회는 정상인데 브라우저는 왜 다른 경로를 사용하나요?

브라우저 설정에서 「보안 DNS」 또는 「보안 DNS 사용」 옵션을 찾아 잠시 끈 뒤 브라우저를 재시작해 비교하세요. 브라우저가 암호화된 조회를 직접 보내거나 이전 연결을 재사용할 수 있습니다. 시스템 캐시를 지워도 브라우저 내부 상태까지 지워지는 것은 아닙니다.

TUN을 끈 뒤 일부 웹사이트에 갑자기 접속할 수 없는 이유는 무엇인가요?

앱에 가상 IP가 캐시되어 있지만 이를 복원하던 경로는 이미 종료됐을 수 있습니다. 기존 시스템 DNS와 라우팅을 복구하고 ipconfig /flushdns를 실행한 다음 문제가 있는 앱을 재시작하세요. 그래도 해결되지 않으면 가상 네트워크 인터페이스의 라우팅이 남아 있는지 확인하세요.

FakeDNS를 켜면 게임 지연 시간이 줄어드나요?

FakeDNS는 주로 도메인과 연결의 연관 방식을 바꿀 뿐, 노드까지의 거리나 네트워크 혼잡을 바꾸지는 않습니다. 실제 IP 탐지, 내장 네트워크 진단 또는 주소 자체 검증이 필요한 앱은 가상 응답과 호환되지 않을 수도 있습니다. 먼저 일반 DNS로 테스트한 뒤 앱별로 예외 처리 여부를 결정하세요.

코어를 재시작한 뒤 이전에 열어 둔 웹사이트가 잠시 접속되지 않는 이유는 무엇인가요?

매핑 테이블이 재시작 후에도 유지된다고 가정하지 마세요. 앱에 캐시된 가상 주소에 대응하는 도메인이 더 이상 없거나 새 매핑과 일치하지 않을 수 있습니다. 노드를 계속 바꾸기보다 기존 연결을 닫고 DNS 캐시를 새로 고친 뒤 다시 조회하는 편이 효과적입니다.

적합한 사용 사례와 복구 순서

투명 프록시에서 도메인 정보를 안정적으로 유지해야 하고, DNS와 연결을 서로 연동되는 구성 요소가 처리하며, 예외 규칙을 관리할 수 있을 때 FakeDNS가 적합합니다. 구독 노드에 추가되는 기능이 아니며 서버 노드가 특정 프로토콜을 사용해야 하는 것도 아닙니다. 주요 설정은 로컬 트래픽 가로채기와 라우팅 단계에서 이루어집니다.

적합한 경우: TUN 환경에서 도메인별 라우팅이 필요하지만 앱 프록시 요청만으로 도메인 정보를 유지할 수 없는 경우, 또는 투명 프록시에 명확한 DNS 가로채기와 대상 복원 절차가 이미 있는 경우.
일반 DNS를 우선 사용할 경우: 브라우저에서 시스템 프록시만 사용하거나, LAN 이름 검색에 의존하거나, 실제 주소 진단이 필요하거나, 사내 네트워크 정책으로 DNS를 관리하는 경우.
먼저 호환성을 테스트할 경우: 게임, 실시간 통신, 가상 머신, 여러 VPN을 겹쳐 사용하는 환경. 가상 대역 충돌 여부와 UDP·IPv6가 같은 가로채기 정책을 따르는지 확인하세요.

되돌릴 때는 먼저 기존 DNS 설정과 가로채기 규칙을 복원해 새 조회가 정상적으로 처리되는지 확인하세요. 그런 다음 관련 TUN 또는 투명 프록시 경로를 종료하고 시스템과 앱의 캐시를 지우세요. 마지막으로 도메인 조회와 일반 접속을 각각 확인합니다. 주소 풀 설정만 삭제한 채 앱에 이전 가상 주소를 계속 반환하거나, 프록시 프로세스만 종료하고 가상 대역 라우팅을 남겨 두지 마세요.