FakeDNS 가상 DNS 매핑 원리 완벽 해설: 언제 켜고 언제 피해야 할까

FakeDNS가 해결하는 문제는 ‘더 정확한 DNS’가 아니라 도메인 정보의 소실입니다

애플리케이션이 도메인에 접속할 때는 보통 먼저 DNS에 실제 주소를 요청한 다음, 반환된 IP에 연결합니다. 프록시 코어에 들어온 연결에 대상 IP만 남아 있다면 도메인 정보가 이미 사라졌을 수 있습니다. 이때 geosite나 전체 도메인, 도메인 접미사로 작성한 라우팅 규칙은 직접 일치시킬 수 없고 대상 IP, 프로토콜 스니핑 결과 또는 다른 보조 정보에 의존해야 합니다.

FakeDNS는 DNS 단계에서 임시 가상 주소를 먼저 반환하고, 코어 내부에 ‘도메인—가상 주소’ 대응 관계를 저장합니다. 이후 애플리케이션이 이 가상 주소에 연결하면 코어가 원래 도메인을 역으로 찾아 도메인 규칙에 따라 직접 연결, 프록시 또는 차단을 결정할 수 있습니다. 본질적으로 단기간 유지되는 매핑 테이블이며, 공용 DNS 서비스가 아니고 가상 주소를 인터넷에 게시하지도 않습니다.

Xray에서 흔히 사용하는 FakeDNS 주소 풀은 198.18.0.0/15와 같은 전용 예약 IPv4 대역을 사용합니다. 이 주소 대역은 대상 사이트의 실제 주소가 되지 않으며, 로컬 장치나 제어된 네트워크 스택 안에서 인덱스 역할만 합니다. 실제 주소 풀, 용량과 처리 방식은 코어 설정 및 클라이언트 버전에 따라 달라지므로 특정 기본값이 모든 환경에서 고정된다고 보면 안 됩니다.

한 번의 요청이 가상 주소 매핑을 거치는 과정

v2rayN의 TUN 모드를 예로 들어 브라우저가 docs.example.net에 접속한다고 가정해 보겠습니다. FakeDNS가 활성화되고 DNS 트래픽이 TUN에 의해 가로채인 경우, 전체 흐름은 대략 여섯 단계로 나뉩니다:

1. 애플리케이션이 시스템에 docs.example.net DNS 조회를 요청합니다.
2. TUN 네트워크 스택이 조회를 가로채 코어 설정의 DNS 처리 체인으로 전달합니다.
3. FakeDNS가 주소 풀에서 가상 IP 하나를 할당하고, 해당 IP와 원래 도메인의 대응 관계를 기록합니다.
4. 애플리케이션은 가상 IP를 받은 뒤 일반 주소에 연결하듯 TCP 또는 UDP 트래픽을 시작합니다.
5. TUN이 이 연결을 다시 가로챕니다. 코어가 매핑 테이블을 조회해 docs.example.net을 복원합니다.
6. 라우팅 모듈이 도메인 규칙에 따라 아웃바운드를 선택하고, 실제 대상 주소 조회는 해당 아웃바운드 경로에서 계속 진행됩니다.

애플리케이션이 도메인 조회
    ↓
TUN이 DNS 가로채기
    ↓
FakeDNS가 가상 IP를 반환하고 매핑 저장
    ↓
애플리케이션이 가상 IP에 연결
    ↓
코어가 원래 도메인 복원
    ↓
도메인 라우팅 일치 → 직접 연결 또는 프록시 아웃바운드 선택

여기서 말하는 ‘DNS 왕복을 한 번 줄인다’는 것은 애플리케이션이 연결을 시작하기 전에 공용 상위 DNS가 실제 IP를 반환할 때까지 기다리지 않아도 된다는 뜻입니다. FakeDNS는 로컬에서 즉시 매핑 결과를 제공할 수 있습니다. 그러나 전체 접속 과정에서 DNS 조회가 완전히 사라진다는 의미는 아닙니다. 프록시 아웃바운드는 원격 서버에 도메인 조회를 맡길 수 있고, 직접 연결 아웃바운드도 설정에 따라 지정된 DNS를 호출할 수 있습니다. 생략되는 것은 앞단의 실제 주소 조회 한 번이지, 모든 경로의 도메인 조회가 아닙니다.

매핑에는 수명이 있습니다. 캐시 만료, 코어 재시작, 설정 다시 불러오기 또는 주소 풀 항목 회수 후에는 기존 가상 주소의 대응 관계가 사라질 수 있습니다. 따라서 FakeDNS 반환값을 장기 업무 데이터로 저장해서는 안 되며, 다른 장치에 복사해 사용하는 것도 적합하지 않습니다.

FakeDNS, 스니핑과 실제 DNS의 역할 분담

도메인 스니핑과 FakeDNS는 자주 함께 사용되지만 도메인을 얻는 시점이 다릅니다. 스니핑은 연결이 코어에 들어온 뒤 HTTP 요청의 Host나 TLS 핸드셰이크의 서버 이름처럼 프로토콜 데이터에서 대상 이름을 추출하려고 시도합니다. 반면 FakeDNS는 더 이른 단계에서 개입해 애플리케이션이 DNS를 조회할 때 확정적인 매핑을 만듭니다.

스니핑은 트래픽에 식별 가능한 필드가 있어야 합니다. 프로토콜 동작이나 암호화 핸드셰이크 형식이 바뀌거나, 애플리케이션이 IP에 직접 연결하거나, 첫 번째 패킷에 사용할 수 있는 도메인이 없으면 스니핑 결과가 비어 있을 수 있습니다. FakeDNS는 업무 페이로드에서 도메인을 추측하지 않고, DNS 조회와 후속 연결이 동일한 제어 네트워크 스택을 통과하기만 하면 매핑 테이블을 따라 이름을 복원할 수 있습니다.

실제 DNS는 최종적으로 연결 가능한 대상 주소를 찾는 역할을 계속 담당합니다. FakeDNS는 ‘애플리케이션이 먼저 조회한 뒤 실제 IP에 연결’하는 순서를 ‘애플리케이션이 가상 IP를 받고, 코어가 도메인을 복원한 뒤, 아웃바운드 단계에서 다시 조회’하는 방식으로 바꿉니다. 이 변화로 라우팅 결과에 따라 조회 위치를 정할 수 있습니다. 프록시 도메인은 프록시 경로에서 처리하고 직접 연결 도메인은 로컬에서 선택한 DNS에 맡길 수 있어, 조회 결과와 실제 아웃바운드 위치가 어긋나는 문제를 줄입니다.

TUN 모드에서 활성화하기 적합한 상황

도메인 기반 세밀한 라우팅

규칙이 주로 geosite, 도메인 접미사 또는 전체 도메인에 의존한다면 FakeDNS의 가치가 가장 큽니다. 애플리케이션이 원래 실제 IP만 네트워크 스택에 넘기더라도 코어는 가상 주소 매핑을 통해 도메인을 되찾을 수 있습니다. ‘특정 사이트는 프록시로, 자주 쓰는 한국 국내 도메인은 직접 연결로, 나머지는 기본 규칙으로 처리’하는 구성에서는 도메인 정보가 안정적일수록 매칭 결과를 쉽게 설명할 수 있습니다.

조회 위치를 아웃바운드에 맞추고 싶은 경우

같은 도메인도 네트워크 위치에 따라 서로 다른 주소를 반환할 수 있습니다. 로컬 DNS로 먼저 조회한 뒤 실제 IP를 프록시 경로에 넘기면 조회 위치와 연결 위치가 분리될 수 있습니다. FakeDNS를 사용하면 애플리케이션은 먼저 가상 주소를 받고, 코어가 아웃바운드를 결정한 다음 실제 조회를 처리합니다. 프록시 측에서 도메인을 조회해야 하는 연결에는 이런 순서가 일반적으로 더 적합합니다.

별도 프록시 설정을 지원하지 않는 프로그램을 가로채야 하는 경우

TUN 모드는 HTTP 또는 SOCKS 프록시 옵션이 없는 프로그램도 처리할 수 있습니다. 이때 FakeDNS와 TUN을 함께 사용하면 해당 프로그램의 일반 시스템 DNS 조회와 후속 연결을 동일한 처리 경로로 보낼 수 있습니다. 프로그램이 시스템 네트워크 스택을 따르고 트래픽이 실제로 가로채인다면 도메인 규칙이 더 완전한 매칭 조건을 확보할 수 있습니다.

프로토콜 스니핑에 대한 단일 의존성 줄이기

스니핑은 여전히 보조 정보로 활용할 수 있지만 도메인 복원을 혼자 맡길 필요는 없습니다. 연결이 빠르게 수립되거나 첫 패킷의 특징이 불안정하거나 UDP 전송을 사용하는 애플리케이션에서는 미리 만들어 둔 FakeDNS 매핑이 보통 더 직접적입니다. 다만 FakeDNS가 모든 UDP 프로토콜을 자동으로 호환하게 만드는 것은 아닙니다. FakeDNS는 대상 매핑만 담당하며, 해당 프로토콜이 현재 아웃바운드를 통해 전송될 수 있는지는 노드, 코어와 라우팅 설정에 달려 있습니다.

FakeDNS를 끄거나 우회해야 하는 상황

로컬 네트워크 이름과 분기 DNS가 실제 응답에 의존하는 경우

기업 내부망, 가정용 장치 이름, 라우터 관리 도메인과 지역별 DNS는 로컬 네트워크 확인자가 반환하는 사설 주소에 의존하는 경우가 많습니다. 이러한 조회가 FakeDNS에 의해 먼저 대체되면 애플리케이션이 서비스 검색에 필요한 실제 레코드를 받지 못할 수 있습니다. 일반적으로 내부망 도메인, 사설 주소 대역과 지정 DNS 서버는 직접 연결하도록 설정하고 FakeDNS 규칙에서 제외합니다. 제외 관계를 확인하기 어렵다면 FakeDNS를 끈 뒤 먼저 내부망 접속을 검증하는 편이 안전합니다.

애플리케이션이 DNS 반환 내용을 읽거나 검증하는 경우

일부 진단 도구, 네트워크 관리 프로그램, 도메인 조회 테스트 프로그램과 업무용 클라이언트는 주소를 받은 뒤 연결만 하는 것이 아니라 DNS 응답을 표시하거나 저장하고, 비교하거나 검증하기도 합니다. 이런 프로그램은 A, AAAA 또는 기타 레코드의 실제 내용을 확인해야 합니다. 가상 주소는 프로그램이 관찰하는 데이터를 바꾸므로 해당 조회에는 적합하지 않습니다.

연결이 동일한 TUN 매핑 체인을 거치지 않는 경우

FakeDNS의 전제는 ‘조회할 때 매핑을 기록하고 연결할 때 매핑을 읽는 것’입니다. DNS 조회만 가로채고 후속 연결이 TUN을 우회하면 애플리케이션은 가상 주소를 일반 네트워크로 직접 보내려 합니다. 반대로 연결은 TUN에 들어오지만 DNS 조회가 다른 장치나 독립된 암호화 조회 경로에서 처리되면 코어가 매핑을 얻지 못할 수 있습니다. 두 경로가 일치하지 않으면 먼저 인계 범위를 통일하고, 통일할 수 없다면 FakeDNS를 끄세요.

조회 결과를 다른 장치에 전달해야 하는 경우

가상 주소는 이를 생성한 매핑 인스턴스 안에서만 유효합니다. 해당 주소를 설정 파일에 기록하거나 로컬 네트워크의 다른 호스트에 보내거나 포트 탐색에 사용하거나 코어를 재시작한 뒤 계속 재사용하면 실패할 수 있습니다. 별도 라우터 방식으로 배포할 때는 DNS 응답과 후속 연결이 항상 동일한 인스턴스로 돌아오는지 특히 확인해야 합니다. 클라이언트가 다른 게이트웨이로 전환할 수 있다면 실제 주소를 반환하는 편이 동작 일관성을 유지하기 쉽습니다.

문제 해결 단계에서 원래 조회 경로를 확인해야 하는 경우

문제가 상위 DNS, 분기 DNS, 도메인 오염, 캐시 또는 IPv4와 IPv6 선택에 집중되어 있다면 FakeDNS는 변환 계층을 하나 더 추가합니다. 이때는 잠시 끄고 조회가 어느 서버로 전송되는지, 어떤 레코드가 반환되는지, 연결이 어느 주소를 선택하는지 직접 확인할 수 있습니다. 실제 조회 경로가 정상임을 확인한 뒤 매핑을 다시 켜고 차이를 비교하세요.

v2rayN에서 활성화하기 전 점검 순서

v2rayN은 버전에 따라 TUN, DNS와 코어 설정 메뉴의 구성이 달라질 수 있고, 옵션 이름도 코어 기능에 따라 바뀔 수 있습니다. 오래된 화면 캡처를 그대로 따라 하기보다 데이터 경로를 기준으로 점검하는 편이 낫습니다. 다음 순서는 대부분의 구성에 적용할 수 있습니다:

1. TUN이 실제로 실행 중인지 확인합니다. 먼저 일반 애플리케이션 트래픽이 코어로 들어오는지 확인해 인계가 완료되지 않은 상태에서 DNS 변수를 추가하지 않도록 합니다.
2. DNS 조회가 TUN으로 들어오는지 확인합니다. 시스템에 남아 있는 별도 DNS 도구, 브라우저 자체 조회 설정 또는 다른 네트워크 서비스가 조회를 매핑 체인 밖으로 우회시킬 수 있습니다.
3. 사설 네트워크 제외 항목을 점검합니다. 로컬 네트워크 도메인, 게이트웨이 주소, 프린터와 내부 서비스는 실제 환경에 따라 직접 연결하거나 제외해야 합니다.
4. 라우팅 규칙을 단순화합니다. 처음 테스트할 때는 명확한 직접 연결, 프록시와 기본 규칙만 남겨 여러 규칙 세트가 동시에 판단에 영향을 주지 않도록 합니다.
5. 그다음 FakeDNS를 활성화합니다. 설정을 다시 불러온 뒤 새로 조회를 시작하고, 애플리케이션 캐시에 남은 이전 주소로 결과를 판단하지 마세요.
6. 로그에서 도메인과 아웃바운드를 확인합니다. 코어가 원래 도메인을 복원했는지, 해당 도메인이 최종적으로 어느 라우팅 규칙과 일치했는지를 중점적으로 확인합니다.

v2rayN에서 구독 노드를 사용하더라도 FakeDNS와 노드 프로토콜은 서로 다른 계층입니다. VMess, VLESS 등의 노드 매개변수는 프록시 아웃바운드가 서버에 연결하는 방식을 결정하고, FakeDNS는 로컬 DNS와 라우팅 처리 단계에 위치합니다. 노드가 연결된다고 해서 FakeDNS 설정이 올바르다는 뜻은 아니며, FakeDNS 매핑이 정상이어도 서버 주소, 포트, 보안 계층 또는 전송 매개변수 오류를 해결할 수는 없습니다.

마찬가지로 Android에서 v2rayNG이 Xray 코어를 사용할 때는 로컬 VPN 인계, DNS 설정과 노드 프로토콜을 구분해야 합니다. v2flyNG은 v2fly 코어를 사용하므로 실제 지원 기능은 해당 코어와 클라이언트의 현재 구현을 기준으로 판단해야 합니다. 특정 데스크톱 설정 필드를 다른 코어에 그대로 옮긴 뒤 동작이 완전히 같을 것이라고 가정하지 마세요.

일반적인 장애를 찾는 방법

활성화 후 모든 도메인이 열리지 않는 경우

먼저 DNS 조회가 FakeDNS로 들어오는지 확인한 다음, 가상 주소에 해당하는 연결이 TUN에 의해 가로채이는지 확인하세요. 시스템 라우팅이 예약 주소 대역을 일반 네트워크 어댑터로 보내면 매핑이 코어 내부에서 완결되지 않습니다. 주소 풀이 로컬 기존 네트워크, 가상 머신 네트워크 또는 다른 터널 설정과 충돌하는지도 확인해야 합니다.

웹페이지는 접속되지만 로컬 네트워크 장치가 연결되지 않는 경우

이는 대개 노드 문제가 아니라 내부망 이름이나 사설 주소가 잘못된 처리 범위에 포함된 결과입니다. 로컬 네트워크 도메인을 로컬 DNS에 맡겨야 하는지, 사설 네트워크 대역을 직접 연결해야 하는지, 로컬 서비스 검색 트래픽을 물리 네트워크 안에 유지해야 하는지 확인하세요. 먼저 명확한 내부망 범위에 대한 제외 규칙을 만든 뒤 장치 이름 접속과 직접 IP 접속의 차이를 테스트합니다.

로그에 가상 IP만 표시되고 원래 도메인이 보이지 않는 경우

연결 단계에서 매핑을 제대로 읽지 못했다는 뜻입니다. 조회와 연결이 서로 다른 코어 인스턴스를 사용했거나, 매핑이 만료되었거나, 애플리케이션이 오래된 캐시를 재사용했거나, 일부 트래픽이 TUN을 우회했을 수 있습니다. 애플리케이션을 종료한 뒤 시스템 DNS 캐시를 비우고 코어를 다시 불러온 다음 완전히 새로운 조회와 연결을 수행하는 편이 같은 페이지를 반복해서 새로 고치는 것보다 유효한 로그를 얻기 쉽습니다.

규칙 일치 결과가 예상과 반대인 경우

규칙 순서를 확인하세요. 라우팅은 일반적으로 설정 순서대로 일치하므로, 범위가 넓은 IP, 포트 또는 도메인 규칙이 앞에 있으면 연결을 먼저 처리할 수 있습니다. FakeDNS가 복원한 도메인, 스니핑으로 얻은 도메인과 최종 조회 결과인 IP도 구분해야 합니다. 문제를 찾을 때는 한 번에 하나의 주요 판단 조건만 남기고, 원인을 확인한 뒤 조합 규칙을 복원하세요.

한동안 실행한 뒤 간헐적으로 실패하는 경우

절전 모드 복귀, 네트워크 전환, 코어 다시 불러오기 또는 장시간 연결 유지 이후에 실패하는지 관찰하세요. 이런 이벤트로 애플리케이션 캐시의 가상 주소와 현재 매핑 테이블이 동기화되지 않을 수 있습니다. 애플리케이션을 닫았다가 다시 열고, DNS 캐시를 새로 고치고, TUN을 다시 만들면 문제가 오래된 매핑에서 비롯되었는지 확인하는 데 도움이 됩니다. 자주 발생한다면 주소 풀 용량과 단기간에 많은 도메인 조회가 발생하는지도 점검해야 합니다.

최종 선택: 스위치 이름이 아니라 트래픽 경로로 판단하기

FakeDNS를 사용하기에 적합한 조건은 분명합니다. DNS 조회와 후속 연결이 동일한 TUN 경로로 인계되고, 라우팅이 안정적으로 도메인을 확보해야 하며, 최종 조회를 아웃바운드 단계에서 처리할 수 있어야 합니다. 이런 구조에서는 애플리케이션이 연결하기 전 실제 DNS를 기다리는 시간을 한 번 줄이고, geosite, 도메인 접미사와 전체 도메인 규칙에 더 신뢰할 수 있는 입력을 제공할 수 있습니다.

꺼두거나 우회해야 하는 조건도 분명합니다. 프로그램이 실제 DNS 레코드를 읽어야 하거나, 로컬 네트워크가 분기 조회에 의존하거나, 가상 주소가 다른 장치로 전달되거나, 조회와 연결이 동일한 매핑 인스턴스로 들어간다고 보장할 수 없는 경우입니다. FakeDNS는 기본적으로 많이 사용할수록 좋은 가속 기능이 아니라 조회 순서를 바꾸는 라우팅 도구입니다.

실제 설정에서는 먼저 TUN, 실제 DNS와 기본 라우팅이 독립적으로 작동하도록 한 뒤 FakeDNS를 추가하세요. 한 번에 한 요소만 변경하고 로그로 ‘조회, 매핑, 연결, 라우팅, 아웃바운드’ 다섯 단계를 확인합니다. 이렇게 하면 문제가 생겨도 모든 이상을 노드 품질 탓으로 돌리지 않고 DNS 인계, 매핑 복원 또는 규칙 일치 중 어느 단계의 장애인지 판단할 수 있습니다.