FakeDNS 원리와 사용 사례: 설정 전 확인 사항

이 글의 핵심

FakeDNS는 트래픽을 투명하게 가로챈 뒤 원래 도메인 없이 대상 IP만 남는 문제를 해결하는 데 적합합니다. v2rayN 또는 v2rayNG를 사용 중이며 TUN이나 VPN 라우팅을 조정하려는 사용자를 위해 가상 IP 매핑 방식, 실제 DNS 조회가 필요한 요청, 로그와 캐시 삭제를 통한 확인 방법을 설명합니다. 현재 도메인 기반 라우팅이 잘 작동한다면 설정을 하나 더 추가하기 위해 FakeDNS를 켤 필요는 없습니다.

FakeDNS 원리: 가상 IP로 도메인 정보 보존하기

FakeDNS는 프록시 프로토콜도, 암호화 DNS도 아닙니다. 일반 DNS는 도메인에 실제 서버 주소를 반환하지만, FakeDNS는 전용 IP 풀에서 가상 IP를 할당하고 도메인과 가상 IP의 매핑을 기록합니다. 이후 앱이 이 주소에 연결하면 트래픽을 가로챈 커널이 매핑을 통해 원래 도메인을 찾아 라우팅과 아웃바운드 처리를 수행합니다.

도메인 조회 가상 IP 할당 앱에서 연결 시작 매핑으로 도메인 복원 규칙에 따라 출구 선택

이 연결 과정에서 Xray는 DNS 요청과 후속 연결을 모두 처리해야 합니다. 예를 들어 앱이 example.com을 조회해 IP 풀의 198.18.0.1을 받았다면, 이 주소로 향하는 연결은 매핑을 보유한 커널로 다시 들어와야 합니다. 이 IP는 할당 결과를 설명하기 위한 예시일 뿐, 해당 도메인의 실제 주소도 아니고 노드 설정의 서버 주소로 입력할 값도 아닙니다.

TUN과 도메인 기반 라우팅: FakeDNS가 해결하는 문제

v2rayN의 시스템 프록시는 대개 앱이 HTTP 또는 SOCKS 프록시를 직접 사용하므로 앱에서 도메인을 프록시로 전달할 수 있습니다. 반면 TUN은 네트워크 계층의 패킷을 가로채며, 커널이 보는 대상은 이미 IP로 변환된 상태일 수 있습니다. 이런 경우 도메인 규칙에 사용할 정보를 보존하는 것이 FakeDNS의 역할입니다.

v2rayNG는 Android VPN 인터페이스를 통해 기기 트래픽을 받지만, VPN을 사용한다고 FakeDNS가 자동으로 켜지는 것은 아닙니다. DNS 요청이 커널에 들어오는지, 커널이 가상 IP를 할당하는지, 연결 과정에서 도메인이 복원되는지는 서로 별개의 조건입니다. TLS 또는 HTTP 스니핑으로 일부 도메인 정보를 얻을 수도 있지만, 프로토콜과 앱 동작에 따라 한계가 있으므로 모든 연결에서 안정적으로 작동하는 대체 수단으로 볼 수는 없습니다.

명시적 프록시 경로

트래픽 진입점: HTTP 또는 SOCKS 인바운드
도메인 정보 출처: 앱이 전달한 대상 도메인
주요 확인 사항: 앱의 프록시 사용 여부와 원격 DNS 조회 여부
사용 여부 판단: 도메인이 온전히 전달된다면 대개 FakeDNS를 추가할 필요가 없습니다

SOCKS 앱도 로컬에서 먼저 DNS를 조회한 뒤 IP만 전달할 수 있습니다. 프록시 종류만으로 판단하지 마세요.

TUN 및 VPN 경로

트래픽 진입점: 가상 네트워크 인터페이스
도메인 정보 출처: FakeDNS 매핑 또는 사용 가능한 기타 메타데이터
주요 확인 사항: DNS 가로채기와 가상 IP 라우팅
사용 여부 판단: 도메인 기반 라우팅을 안정적으로 사용해야 할 때 검토

DNS 조회와 후속 연결이 모두 가로채여야 가상 IP 매핑이 작동합니다.

VLESS와 VMess는 프록시 연결을 담당하고 FakeDNS는 로컬 DNS와 대상 정보를 처리합니다. 프록시 프로토콜을 바꿔도 매핑 경로가 자동으로 복구되지는 않습니다. v2flyNG는 V2Fly 커널을 사용하므로 설정 기능과 필드 지원 여부를 실제 커널에 맞춰 확인해야 합니다. Xray 예제를 세 클라이언트에서 공통으로 사용할 수 있는 설정으로 간주하면 안 됩니다.

IP 풀과 설정 필드: 먼저 세 가지 숫자 이해하기

일반 DNS의 UDP/TCP 서비스 포트

131072

IPv4 /15 서브넷에 포함된 전체 IP 수

65535

아래 설정 예시의 poolSize 값

Xray의 FakeDNS 설정은 IPv4 풀로 198.18.0.0/15를 사용할 수 있습니다. 이 서브넷은 벤치마크용 특수 목적 IP 주소 공간으로, 일반적인 인터넷 서비스에 직접 접속할 수 있는 주소가 아닙니다. 서브넷에 포함된 전체 IP 수와 poolSize는 서로 다른 개념입니다. 전자는 프리픽스 길이로 결정되고, 후자는 구현에서 사용하는 매핑 풀의 용량을 지정합니다.

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

이 Xray 예시는 최상위 IP 풀 정의만 보여 주며, 단독 실행 가능한 전체 설정이 아닙니다. 실제로 연결하려면 내장 DNS의 fakedns 서버 항목과 연결을 받는 인바운드의 도메인 복원 설정도 필요합니다. 예를 들어 sniffing.destOverride에서 fakedns를 지원해야 합니다. IP 풀만 붙여 넣어도 시스템 DNS가 자동으로 우회되지는 않습니다.

생성된 설정부터 확인하세요: v2rayN의 TUN 구현은 일반 프록시 인바운드와 처리 경로가 다를 수 있습니다. Xray 필드를 모든 설정 파일에 붙여 넣지 말고 현재 실행 중인 구성 요소가 실제로 받아들이는 설정인지 확인하세요.
IP 주소 충돌을 확인하세요: 회사 VPN, 테스트 네트워크 또는 정적 라우팅에서 이미 198.18.0.0/15를 사용 중이라면 두 용도가 같은 서브넷을 두고 충돌하지 않도록 IP 풀과 라우팅을 다시 설계해야 합니다.
IPv6는 별도로 확인하세요: IPv4 풀만 있다고 AAAA 조회까지 올바르게 처리되는 것은 아닙니다. 현재 구현의 IPv6 정책을 확인하고 듀얼 스택 앱의 트래픽이 검증되지 않은 다른 경로로 빠지지 않게 하세요.

사용 사례: 어떤 트래픽에 FakeDNS가 필요할까요?

FakeDNS는 도메인 규칙에 의존하면서 앱에서 도메인을 직접 얻기 어려운 투명 트래픽 가로채기 환경에 적합합니다. 실제 DNS 조회가 먼저 이뤄져 도메인 식별에 영향을 주는 문제를 줄일 수 있지만, 웹페이지가 반드시 더 빨리 열리는 것은 아닙니다. 연결 결과에는 최종 아웃바운드, 서버 접근성, 실제 대상 주소 조회도 영향을 줍니다.

사용 사례	권장 사항	확인할 점
TUN으로 가로챈 뒤 도메인에 따라 출구 선택	활성화를 검토해 볼 만함	로그에서 도메인이 복원되고 연결이 예상한 규칙에 따라 처리되는지
브라우저에서 명시적 프록시를 사용하고 도메인이 이미 전달되는 경우	현재 설정을 유지해도 됨	앱이 도메인을 프록시에 전달하는지
회사 내부 도메인 및 사설 IP 접속	먼저 실제 DNS 조회 예외를 설정	내부 DNS 응답 주소와 직접 연결 라우팅이 일치하는지
앱이 고정 IP에 직접 연결	FakeDNS로 원래 도메인을 알아낼 수 없음	IP 규칙이나 해당 앱에 적합한 다른 규칙 사용
앱 자체 암호화 DNS 사용	먼저 DNS 요청이 내장 DNS를 우회하는지 확인	53번 포트만 가로채서는 앱 내 DNS 조회까지 처리할 수 없음

내부 도메인에는 FakeDNS를 특히 신중하게 적용해야 합니다. 회사 서비스는 사설 IP를 받기 위해 지정된 DNS를 사용해야 할 수 있습니다. 이런 조회는 실제 DNS로 처리하고 해당 연결은 직접 연결하도록 설정하는 편이 기존 접속 방식을 유지하기 쉽습니다. 예외 설정은 현재 사용하는 DNS 및 라우팅 구현에 맞춰야 합니다. 직접 연결 규칙 하나만 추가했다고 DNS 경로까지 바뀌는 것은 아닙니다.

활성화 전 확인 사항: DNS, 아웃바운드, 캐시를 함께 점검하세요

기준 상태를 기록하세요. 클라이언트와 실행 커널 버전, DNS 설정, TUN 또는 VPN 상태를 기록합니다. 동일한 도메인에 한 번 접속하고 로그를 저장해 두어야 이후 변화를 비교할 수 있습니다.
DNS 진입점을 확인하세요. 시스템 DNS가 가로채지고 있는지 점검합니다. 브라우저의 보안 DNS나 앱 내 DoH는 해당 진입점을 우회할 수 있습니다. 테스트 중에는 테스트 앱이 시스템 DNS를 사용하도록 임시 설정하고, 테스트가 끝나면 원래 설정으로 되돌리세요.
연결이 다시 커널로 들어오는지 확인하세요. 현재 TUN 또는 VPN이 가상 IP 풀의 트래픽을 받도록 라우팅되어 있는지 점검합니다. Android에서 앱별 프록시 설정으로 테스트 앱을 제외했다면, 해당 앱이 가상 IP를 받아도 연결을 커널로 돌려보내지 못할 수 있습니다.
실제 DNS 조회 경로를 확인하세요. 프록시 서버 주소가 도메인이라면 사용할 수 있는 부트스트랩 DNS 경로가 있어야 합니다. 아직 연결되지 않은 프록시를 통해 서버 주소를 조회하려 해서는 안 됩니다. 직접 연결할 대상에도 실제 IP가 필요할 수 있습니다.
한 번에 하나만 바꾸세요. 먼저 노드와 라우팅 프리셋은 그대로 두고 FakeDNS 관련 설정만 조정합니다. 커널, 프로토콜, DNS, 라우팅 규칙을 동시에 바꾸면 문제가 발생한 지점을 찾기 어렵습니다.

v2rayN과 v2rayNG의 UI 항목은 버전에 따라 달라질 수 있습니다. 오래된 스크린샷에서 스위치 위치를 찾기보다 실제 실행 설정과 로그를 기준으로 판단하세요. 현재 버전에서 필요한 설정을 제공하지 않는다면 검증된 모드를 유지하는 편이 좋습니다. 사용자 지정 설정을 사용하려면 DNS, 인바운드, 라우팅을 함께 이해해야 하며 필드 하나만 추가해서는 충분하지 않습니다.

확인과 되돌리기: DNS 조회 성공과 연결 성공을 따로 확인하세요

FakeDNS 테스트는 두 단계로 나눠야 합니다. 먼저 시스템의 DNS 조회 결과를 확인하고, 다음으로 같은 도메인에 실제로 연결해 봅니다. Windows에서는 명령 프롬프트에서 아래 명령을 실행할 수 있습니다. nslookup은 현재 사용하는 DNS 조회 경로만 확인하며, 브라우저 자체 DNS도 같은 경로를 이용한다는 뜻은 아닙니다.

ipconfig /flushdns
nslookup example.com

DNS 조회 단계: 해당 조회가 FakeDNS에서 처리되어야 한다면 반환된 IP가 설정한 가상 IP 풀에 포함되는지 확인하세요. 실제 IP가 반환됐다면 먼저 실제 DNS 조회 예외에 해당하는지 확인하고, 곧바로 실패라고 단정하지 마세요.
연결 단계: 테스트 앱에서 같은 도메인에 접속하고 로그에 표시되는 대상 도메인, 라우팅 규칙, 아웃바운드 태그를 확인하세요. 가상 IP를 최종 인터넷 서비스 주소로 삼아 일반 네트워크에 직접 전송해서는 안 됩니다.
비교 단계: 내부 도메인 하나와 IP 주소를 직접 사용하는 연결도 추가로 테스트해 예외 설정이 영향을 받지 않는지 확인하세요. 테스트 조건은 동일하게 유지해 노드 상태 변화와 FakeDNS 문제를 혼동하지 않도록 합니다.
되돌리기 단계: 기존 DNS 및 트래픽 가로채기 설정을 복원하고 클라이언트 연결을 다시 시작한 다음 시스템 캐시를 새로고침합니다. 테스트 앱은 완전히 종료했다가 다시 여세요. Android 앱에 이전 결과가 남아 있다면 먼저 앱을 강제 종료한 뒤 다시 실행하세요.

FakeDNS 매핑은 일반적으로 실행 중에만 유지됩니다. 커널이 재시작되거나 매핑이 제거되거나 설정이 바뀌면 앱에 이전 가상 IP가 캐시되어 있는데 새 커널에는 해당 도메인 정보가 없을 수 있습니다. 이때 노드를 계속 바꾸는 것은 대개 도움이 되지 않으므로 먼저 캐시를 지우고 연결을 다시 설정하세요. Windows의 ipconfig /flushdns는 시스템 DNS 캐시만 새로고침하며 모든 앱의 자체 캐시까지 지우지는 않습니다.

자주 묻는 질문: 가상 IP, 앱 충돌, 배터리 사용량

198.18로 시작하는 IP가 조회되는데 DNS가 잘못된 건가요?

FakeDNS가 켜져 있고 IP 풀이 198.18.0.0/15라면 정상적인 결과일 수 있습니다. 먼저 조회한 도메인이 FakeDNS를 사용해야 하는 경우인지 확인한 뒤, 연결 로그에서 해당 도메인이 복원되는지 살펴보세요. IP 모양만으로 문제 여부를 판단할 수 없으며, 이 주소를 웹사이트의 고정 IP로 저장해서도 안 됩니다.

FakeDNS를 끈 뒤에도 일부 앱에서 시간 초과가 발생하는 이유는 무엇인가요?

앱에 이전 가상 IP가 캐시되어 있을 수 있습니다. 기존 DNS 설정을 복원하고 클라이언트 연결을 다시 설정한 뒤 Windows에서 ipconfig /flushdns를 실행하고 앱을 완전히 종료했다가 다시 여세요. Android에서는 문제가 발생한 앱을 강제 종료한 뒤 테스트하세요. 처음부터 앱 데이터를 삭제하지는 마세요.

특정 게임이나 업무용 앱만 열리지 않을 때는 어떻게 확인하나요?

먼저 해당 앱에 필요한 도메인만 실제 DNS 조회 예외로 설정하고 다른 설정은 그대로 둔 채 테스트하세요. 일부 앱은 IP 주소 유형을 검사하거나 고정 IP를 사용하거나 자체적으로 DNS를 조회하므로, 다른 웹페이지가 정상적으로 열린다는 이유만으로 호환성 문제를 배제할 수 없습니다. 실제 DNS 조회로 바꾼 뒤 문제가 해결된다면 해당 앱의 DNS 및 라우팅 요구 사항을 확인하세요.

v2rayNG를 켜면 배터리를 더 많이 쓰거나 반드시 빨라지나요?

둘 다 단정할 수 없습니다. FakeDNS는 매핑을 관리하고 대상을 복원하는 데 사용되며, 실제 배터리 사용량은 네트워크 깨우기, 앱의 재시도, VPN의 지속 실행 여부에도 영향을 받습니다. 네트워크, 노드, 앱 작업량을 동일하게 유지해 비교하세요. 로그에 반복 재시도가 많이 보인다면 IP 풀을 늘리기보다 먼저 실패한 연결 경로를 수정해야 합니다.

FakeDNS를 켜는 기준은 도메인이 복원되고 올바른 라우팅이 이뤄지는지 확인할 수 있는가입니다. v2rayN, v2rayNG 또는 v2flyNG의 현재 설정이 안정적으로 작동한다면 기능을 추가하기 위해 굳이 바꿀 필요가 없습니다. FakeDNS를 도입하려면 DNS 진입점, 가상 IP 라우팅, 실제 DNS 조회 예외, 캐시 초기화 및 복구 방법을 먼저 명확히 확인한 뒤 일상적인 사용으로 확대하세요.