FakeDNS란? 가상 IP 매핑 원리와 v2rayN 설정 시점

이 글의 핵심 내용

설정 판단: FakeDNS는 주로 투명 프록시 적용 후 대상 IP만 확인되고 원래 도메인을 알 수 없는 문제를 해결합니다. TUN을 사용하면서 도메인별로 트래픽을 분기해야 할 때 유용합니다. 이 글에서는 매핑 원리, 커널별 차이, 활성화 전 확인 사항과 문제 발생 시 되돌리는 방법을 살펴보고, 정상적인 가상 IP와 DNS 처리 누락, 앱 호환성 문제를 구분하는 방법을 안내합니다.

FakeDNS 원리: 도메인을 보존한 뒤 연결 경로를 결정

가상 IP 매핑: 일반 DNS는 도메인에 연결 가능한 실제 IP 주소를 반환합니다. 반면 FakeDNS는 지정된 주소 풀에서 IP를 할당하고, 로컬에 도메인과 가상 IP의 대응 관계를 저장합니다. 이 주소는 대상 웹사이트의 공개 IP가 아니라, 이후 연결에서 도메인을 식별하기 위한 색인입니다. 앱은 결과를 받은 뒤 평소처럼 연결을 시도하고, 프록시 처리 과정에서 매핑을 참조해 원래 도메인을 찾습니다.

도메인 조회 가상 IP 할당 연결 가로채기 원래 도메인 복원 규칙에 따라 경로 선택

연결 처리의 완결성: DNS 요청과 이후 연결이 서로 연동되는 처리 경로를 거쳐야 가상 IP가 의미를 가집니다. DNS가 가상 IP를 반환했는데 TUN이 해당 주소 풀의 트래픽을 가로채지 않으면, 앱이 일반 네트워크로 연결을 보내 결국 시간 초과가 발생할 수 있습니다. 반대로 앱이 별도의 암호화 DNS로 실제 IP를 받아 오면 FakeDNS에는 해당 조회의 도메인 매핑이 생성되지 않습니다.

출구 측 DNS 조회: 도메인을 복원했다고 해서 연결에 실제 DNS가 더는 필요하지 않은 것은 아닙니다. 이후 DNS 조회 여부와 위치는 아웃바운드 유형, 도메인 처리 정책, 서버 동작에 따라 달라집니다. 직접 연결하려면 보통 연결 가능한 IP가 필요하고, 도메인 전달을 지원하는 프록시 아웃바운드는 원격 서버에서 도메인을 처리하도록 맡길 수 있습니다. FakeDNS는 로컬에서 도메인을 식별하고 트래픽을 분기하는 기능이지, 인터넷 전체의 이름 조회를 대체하는 기능은 아닙니다.

주소 풀과 포트: 가상 IP가 보여도 DNS 오류는 아닙니다

수치 확인: Xray의 FakeDNS는 198.18.0.0/15 주소 풀을 사용하는 경우가 많습니다. 이 대역은 네트워크 성능 측정용으로 예약된 범위이며 일반 공개 웹사이트 주소가 아닙니다. 아래 내용은 주소와 프로토콜에 관한 사실이며, 속도 측정 결과나 모든 환경에 그대로 적용해야 하는 기본 설정이 아닙니다.

/15

예시 주소 풀의 접두사 길이

131072

해당 IPv4 블록의 전체 주소 수

기존 DNS에서 사용하는 서버 포트

주소 범위: 198.18.0.0/15는 198.18.0.0부터 198.19.255.255까지 포함합니다. 주소 블록의 전체 크기가 커널에 저장되는 매핑 수와 같은 것은 아닙니다. 실제 용량은 주소 풀 설정과 구현상의 제한에 따라 달라집니다. 기업 실험망에서 이미 이 범위를 사용 중이라면 먼저 라우팅 충돌을 해결해야 합니다. ‘예약된 주소’라고 해서 ‘현재 내 시스템에서 사용하지 않는 주소’라고 단정할 수는 없습니다.

정상 동작: 도메인 조회 결과가 주소 풀에 포함되고, 앱에 접속할 수 있으며, 연결 로그에서 도메인과 예상한 아웃바운드의 연관 관계를 확인할 수 있습니다.
이상 동작: 조회 결과는 주소 풀에 포함되지만 연결이 가로채기 경로로 들어가지 않거나, 로그에 가상 IP만 남은 채 계속 시간 초과가 발생합니다.
확인 범위: UDP 53을 수신하거나 전달하는 것만으로 모든 DNS 요청을 처리할 수 있는 것은 아닙니다. 기존 DNS는 TCP를 사용할 수도 있고, 앱이 암호화 DNS를 사용할 수도 있습니다.

확인할 점: 가상 IP 자체가 아니라 연결 처리의 완결성을 점검하세요

확인 순서: 먼저 도메인 조회가 예상한 DNS 처리 경로를 거치는지 확인하고, 다음으로 가상 IP 연결이 TUN에 들어오는지 확인한 뒤, 마지막으로 도메인 복원과 아웃바운드 경로를 점검하세요. 조회 결과만 달라졌다고 해서 트래픽 분기가 제대로 적용된 것은 아닙니다.

v2rayN에서 설정할 때: 시스템 프록시와 TUN을 먼저 구분하세요

시스템 프록시 사용 시: 시스템 프록시 설정을 따르는 앱은 보통 대상 도메인을 로컬 HTTP 또는 SOCKS 프록시에 전달합니다. 다만 실제 DNS 조회를 어디서 하는지는 앱과 프로토콜 사용 방식에 따라 달라집니다. 로그에 도메인이 표시되고 라우팅도 예상대로 동작한다면 FakeDNS를 굳이 활성화할 필요가 없는 경우가 많습니다. FakeDNS는 VMess, VLESS 노드 연결을 위한 필수 조건이 아니며, 구독 오류나 TLS 설정 문제를 해결해 주지도 않습니다.

시스템 프록시 사용 시 확인할 항목

트래픽 유입 경로: 앱이 로컬 프록시 설정을 따르는지
도메인 정보 출처: 프록시 요청 또는 앱의 DNS 조회 방식
활성화 조건: 먼저 도메인 식별에 실제로 누락이 있는지 확인
확인 위치: 연결 로그와 라우팅 규칙 적용 결과

선택 기준: 도메인이 이미 확인되고 트래픽 분기가 정상이라면 현재 DNS 경로를 유지하는 편이 관리하기 쉽습니다.

TUN 사용 시 확인할 항목

트래픽 유입 경로: 가상 네트워크 어댑터가 IP 패킷을 수신
도메인 정보 출처: DNS 매핑 또는 프로토콜 스니핑
활성화 조건: DNS 요청과 가상 IP 연결 모두 가로채기
확인 위치: DNS·인바운드·아웃바운드 로그

선택 기준: 도메인 규칙을 유지해야 하는데 유입된 정보가 IP뿐이라면 가상 IP 방식을 검토하세요.

커널별 차이: v2rayN은 데스크톱 클라이언트입니다. 화면에서 선택한 노드의 커널과 TUN에서 실제 트래픽을 처리하는 구성 요소가 서로 다를 수 있습니다. 노드가 Xray로 연결된다고 해서 Xray의 FakeDNS 필드를 모든 TUN 설정에 그대로 붙여 넣어서는 안 됩니다. 현재 설정과 시작 로그를 확인해 DNS, TUN, 라우팅을 각각 어떤 구성 요소가 처리하는지 파악한 뒤 해당 커널이 지원하는 설정을 사용하세요.

Android에서의 차이: v2rayNG는 Xray 커널을, v2flyNG는 v2fly 커널을 사용합니다. 두 앱의 화면 옵션, 설정 생성 방식, 지원 필드는 데스크톱 화면을 보고 추정할 수 없습니다. 이름이 비슷해도 각 앱의 현재 버전에서 제공하는 DNS 및 트래픽 가로채기 옵션을 따로 확인해야 합니다. 플랫폼 간 설정을 옮길 때는 트래픽 분기 목표만 유지하고, 검토하지 않은 저수준 설정을 그대로 복사하지 마세요.

설정 순서: 주소 풀, DNS 응답, 도메인 복원을 모두 구성해야 합니다

최소 설정 예시: 아래에는 Xray 최상위 fakedns 주소 풀 설정만 표시합니다. 필드의 의미를 이해하기 위한 예시이며 단독 실행 가능한 전체 설정은 아닙니다. poolSize의 65535는 이 예시에서 선택한 매핑 용량으로, 주소 블록의 전체 크기나 모든 시스템에 권장되는 값이 아닙니다. v2rayN이 자동 생성하는 파일은 재시작 후 덮어써질 수 있으므로 수정 전에 사용자 설정을 적용하고 저장하는 방법을 확인하세요.

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

기준 설정 기록: 현재 DNS, 라우팅, TUN 설정을 저장하고, 변경 전후를 비교할 일반 웹사이트 하나와 로컬 네트워크 서비스 하나를 정합니다.
DNS 유입 경로 확인: 시스템과 앱의 DNS 요청이 예상한 처리 경로로 들어오는지 확인합니다. 설정에 주소 풀만 정의한다고 해서 모든 시스템 DNS 요청이 자동으로 FakeDNS를 사용하지는 않습니다.
FakeDNS 응답 연결: 해당 Xray 설정에서 관련 DNS 요청이 내장 fakedns 서비스를 사용하도록 지정해야 합니다. 구체적인 조회 규칙은 직접 연결과 프록시 사용 목적에 맞춰 구성하세요.
도메인 복원 확인: 해당 Xray 인바운드를 사용하는 경우 스니핑 설정의 enabled와 destOverride를 확인하세요. 이 중 fakedns 항목은 매핑에서 도메인을 복원하는 데 사용됩니다. 다른 트래픽 가로채기 구성 요소는 각각의 동등한 기능을 사용해야 합니다.
항목별 검증: 일반 웹 브라우징, 로컬 네트워크 접속, 대상 앱을 확인합니다. 복원된 도메인과 아웃바운드가 올바른지 먼저 점검한 다음 일상적인 사용 범위를 넓히세요.

IPv6 설정: IPv4 주소 풀만 있다고 해서 IPv6도 같은 방식으로 처리되는 것은 아닙니다. 앱이 AAAA 레코드를 먼저 조회한 뒤 IPv6로 연결할 수 있습니다. 이 경로에 맞는 라우팅 및 DNS 정책이 없으면 앱마다 동작이 달라질 수 있습니다. A와 AAAA 조회 및 각 연결 경로를 따로 검증하세요. IPv4 연결 한 번이 성공했다고 전체 구성이 정상이라고 볼 수는 없습니다.

적합한 사용 사례와 호환성 고려: 도메인 규칙을 우선하고 실제 IP가 필요한 경우는 별도로 처리하세요

라우팅 규칙의 장점: TUN에 들어오는 정보는 대개 대상 IP이므로 IP만으로 특정 웹사이트의 트래픽을 안정적으로 구분하기 어렵습니다. 하나의 도메인이 여러 IP에 연결될 수 있고, 하나의 IP에서 여러 도메인이 서비스될 수도 있습니다. FakeDNS는 조회 시점의 도메인을 보존해 도메인 규칙이 적용될 근거를 제공하지만, 실제 DNS 요청이 어떤 경로를 거쳤는지에 따라 적용 범위가 제한됩니다. 모든 연결에서 도메인을 복원할 수 있는 것은 아닙니다.

사용 사례	주요 영향	권장 처리 방법
TUN에서 도메인별 트래픽 분기	매핑을 통해 연결에 원래 도메인을 보존할 수 있음	DNS와 연결이 모두 가로채지는지 확인한 뒤 활성화
실제 대상 IP로 매칭	가상 IP만으로는 대상 네트워크를 식별할 수 없음	도메인 복원 후 DNS 조회와 규칙 적용 순서를 확인
로컬 네트워크 이름 및 기기 검색	로컬 DNS, 멀티캐스트 또는 전용 검색 프로토콜에 의존할 수 있음	해당 로컬 조회와 직접 연결 경로를 유지
앱이 DNS 조회 결과를 검증	예약된 주소를 거부하거나 잘못된 결과를 캐시할 수 있음	커널이 지원하는 제외 기능을 사용하고, 필요하면 이전 설정으로 되돌리기
앱이 고정 IP로 직접 연결	매핑에 사용할 이전 도메인 조회가 없음	IP 규칙을 확인하고 FakeDNS가 도메인을 만들어 낼 것이라 기대하지 않기

호환성 문제가 생기는 이유: 일부 앱은 조회된 IP가 예상한 대역에 속하는지 확인하거나, DNS 결과를 다른 프로세스나 기기로 전달합니다. 가상 IP는 원래 매핑 환경을 벗어나면 대개 사용할 수 없습니다. 따라서 대응되는 트래픽 가로채기 기능이 없는 다른 기기와 FakeDNS 응답을 공유하거나, 반환된 주소를 서버의 실제 IP인 것처럼 장기 설정에 저장하지 마세요.

설정 조정: 일부 기능이 호환되지 않으면 적용 범위를 먼저 줄이세요

권장 사항: 특정 앱이나 로컬 서비스 하나만 문제가 있다면 해당 앱의 DNS, 라우팅, 주소 검증 요구 사항부터 확인하세요. 현재 커널이 제외 기능을 지원하는 경우에만 일부 설정을 조정합니다. 신뢰할 수 있는 예외 처리가 어렵다면 불분명한 규칙을 여러 개 덧붙이는 것보다 실제 DNS 경로로 되돌리는 편이 검증하기 쉽습니다.

문제 진단 및 복구: 조회, 매핑, 연결 순서로 점검

문제 발생 시 확인: 활성화 후 ‘웹페이지는 열리지만 특정 앱이 작동하지 않는’ 문제가 생기면 오류가 발생한 시간대의 로컬 로그를 보관하고, 해당 앱이 별도의 DNS나 고정 IP, 다른 네트워크 경로를 사용하는지 확인하세요. 노드, 라우팅 규칙, DNS를 한꺼번에 바꾸지 마세요. 문제가 해결되더라도 무엇이 원인이었는지 판단하기 어려워집니다.

가상 IP가 조회되지 않음: 테스트 도메인이 실제로 FakeDNS 조회 규칙에 해당하는지 확인하세요. 실제 IP가 반환되는 것은 제외 정책에 따른 정상 동작일 수도 있고, 앱 자체 DNS나 이전 캐시 때문일 수도 있습니다.
가상 IP를 받았지만 연결 시간 초과: TUN이 실행 중인지, 주소 풀 경로가 올바른 인터페이스로 들어가는지, 다른 가상 네트워크 어댑터나 기업 네트워크 경로와 충돌하지 않는지 확인하세요.
로그에 가상 IP만 표시됨: 해당 인바운드의 도메인 복원 설정을 확인하고, 재시작 후 매핑은 사라졌는데 앱에는 이전 DNS 캐시가 남아 있는 상황인지 살펴보세요.
도메인은 맞지만 경로가 잘못됨: 규칙의 적용 순서와 프로세스·포트·IP 규칙이 먼저 일치하는지 확인하세요. 이 경우에는 DNS만의 문제가 아닙니다.
브라우저와 앱의 동작이 다름: 암호화 DNS, 앱의 프록시 설정, 캐시를 각각 확인하세요. 브라우저에서 한 번 성공했다고 다른 프로세스도 정상이라고 볼 수는 없습니다.

Windows 캐시: 실제 DNS로 되돌리기 전에 DNS 응답과 트래픽 가로채기 설정을 복구한 다음 시스템 캐시를 비우고 대상 앱을 다시 시작하세요. 아래 명령은 Windows DNS 클라이언트 캐시만 비우며 브라우저 내장 캐시를 삭제하거나 노드를 변경하지 않습니다. 오래 실행 중인 앱은 자체 연결 풀을 보관할 수 있으므로 완전히 종료한 뒤 다시 열어야 합니다.

ipconfig /flushdns

복구 확인: 새 DNS 조회에서 이전 가상 IP가 더 이상 반환되지 않는지, 로컬 네트워크 서비스에 접속할 수 있는지, 시스템 프록시 또는 TUN이 의도한 상태인지 확인하세요. 트래픽 가로채기를 끈 뒤에도 앱이 이전 가상 IP에 연결하려 한다면 직접 연결 규칙에 주소를 추가하지 말고 앱 캐시를 계속 정리하세요. 직접 연결한다고 가상 색인이 실제 서버 주소로 바뀌지는 않습니다.

자주 묻는 질문: FakeDNS, 스니핑, 개인정보 보호의 범위

FakeDNS와 프로토콜 스니핑은 어떻게 다른가요?

정보를 얻는 방식: FakeDNS는 이전 DNS 조회를 바탕으로 매핑을 유지합니다. 프로토콜 스니핑은 일부 HTTP 또는 TLS 핸드셰이크 정보처럼 연결 데이터에서 식별 가능한 이름을 추출하려고 시도합니다. 스니핑은 프로토콜과 암호화 방식에 제약을 받고, 매핑은 DNS 요청이 로컬 처리 경로를 거쳤는지에 따라 달라집니다. 두 기능을 함께 사용할 수는 있지만 모든 트래픽을 처리한다고 서로 보장해 주지는 않습니다.

FakeDNS를 켜면 반드시 더 빨라지나요?

성능의 범위: 로컬에서 가상 IP를 할당하면 실제 DNS 조회가 끝난 뒤 로컬 트래픽 분기를 시작하는 단계를 줄일 수는 있습니다. 하지만 최종 연결 성능은 출구 측 DNS 조회, 네트워크 경로, 서버, 앱 동작에 따라 달라집니다. 지연 시간이 줄어든다고 미리 단정하기보다 규칙이 올바르게 적용되는지와 앱이 안정적으로 작동하는지를 비교하는 편이 합리적입니다.

FakeDNS를 사용하면 DNS 조회 유출을 막을 수 있나요?

개인정보 보호의 범위: 이 기능만으로 DNS 유출을 막는다고 보장할 수는 없습니다. 앱이 시스템 DNS를 우회할 수 있고, 프록시 서버 주소를 미리 조회해야 할 수도 있으며, 직접 연결 트래픽이 다른 DNS 서버를 사용할 수도 있습니다. DNS 조회에서 가상 IP가 반환됐는지만 볼 것이 아니라 시스템 DNS, 앱 DNS, 출구 측 DNS 조회, 라우팅을 각각 확인해야 합니다.

커널을 재시작한 뒤 일부 연결이 갑자기 실패하는 이유는 무엇인가요?

캐시 일관성: 재시작 후에도 매핑이 유지된다고 가정해서는 안 됩니다. 앱에는 이전 가상 IP가 저장되어 있지만 새로 실행된 커널에 해당 매핑이 없으면 연결이 실패할 수 있습니다. 노드를 계속 바꾸기보다 도메인을 다시 조회하고 관련 캐시를 비운 뒤 앱을 재시작하는 편이 문제 해결에 효과적입니다.

최종 판단: 시스템 프록시에서 도메인별 트래픽 분기가 정상이라면 FakeDNS를 상시 켜 둘 필요는 없습니다. TUN에서 실제로 도메인 정보가 누락되고 DNS와 연결 경로를 모두 제어할 수 있을 때 활성화를 검토하세요. 설정을 마친 뒤에는 도메인 복원, 라우팅 규칙 적용, 앱 호환성 세 가지를 함께 확인하세요.