FakeDNS 작동 원리 자세히 알아보기: 도메인 분할 라우팅을 빠르게 하는 방식과 적합하지 않은 환경

FakeDNS는 원격 DNS가 아니라 로컬 매핑 테이블입니다

일반 DNS의 역할은 도메인을 서버가 실제로 사용하는 IP 주소로 변환하는 것입니다. 앱이 웹사이트 도메인을 조회하면 DNS는 공인 IPv4 또는 IPv6 주소를 반환하고, 앱은 해당 주소로 연결합니다. 문제는 프록시 코어가 최종 IP만 확인할 경우 원래 도메인이 이미 사라질 수 있다는 점입니다. 이때 도메인 기반 라우팅 규칙은 다시 조회하거나 TLS 특성을 확인하거나 IP 규칙으로 되돌아가야 하므로, 라우팅 과정이 복잡해집니다.

FakeDNS가 바꾸는 것은 로컬 조회 단계입니다. 앱이 A 또는 AAAA 레코드를 조회하면 프록시 코어는 실제 주소를 즉시 전달하지 않고, 미리 설정된 주소 풀에서 가상 주소를 할당한 뒤 ‘가상 주소—원래 도메인’ 대응 관계를 저장합니다. 일반적인 IPv4 주소 풀은 198.18.0.0/15이며, 이 대역은 네트워크 장비 벤치마크 테스트용으로 사용되므로 공인 인터넷에서 정상적으로 라우팅해서는 안 됩니다. Xray 호환 설정에서는 fc00::/18과 같은 IPv6 FakeDNS 주소 풀도 설정할 수 있습니다.

앱은 가상 주소를 받은 뒤 평소처럼 연결을 시작합니다. 연결이 다시 동일한 프록시 코어 또는 TUN 가상 네트워크 어댑터를 거쳐야 코어가 매핑 테이블에서 해당 가상 주소에 대응하는 도메인을 찾을 수 있습니다. 복원된 도메인은 routing 영역으로 전달되어 domain, geosite 또는 사용자 지정 도메인 규칙과 매칭됩니다. 프록시가 필요한 요청은 프록시 아웃바운드로 보내고, 직접 연결할 요청은 설정에 따라 실제 DNS 조회를 수행합니다.

이는 FakeDNS의 핵심적인 제한도 보여 줍니다. FakeDNS는 임의의 가상 IP를 접속 가능한 주소로 바꾸는 기능이 아니라, DNS 조회와 이후 연결이 동일한 프록시 경로에서 관리되어야 작동합니다. DNS 조회는 프록시 코어를 거쳤지만 연결이 TUN을 우회해 실제 네트워크 어댑터로 직접 전달되면 시스템은 198.18.x.x에 접속하려고 하며, 대개 시간 초과가 발생합니다. 반대로 연결은 가로챘지만 매핑이 만료되었다면 코어가 도메인을 안정적으로 복원할 수도 없습니다.

FakeDNS와 일반 DNS 분할 라우팅의 차이

FakeDNS는 흔히 ‘DNS 가속’으로 설명되지만 원격 서버의 대역폭을 직접 늘리거나 프록시 노드와 대상 사이트 사이의 물리적 거리를 줄이지는 않습니다. 줄어드는 것은 앱이 실제 DNS 응답을 기다리는 시간이며, 코어가 더 일찍 도메인을 확보해 잘못된 조회, 중복 조회, 연결 후 라우팅 변경을 줄일 수 있습니다. 실제 효과는 로컬 리졸버, 상위 DNS 지연 시간, 캐시 적중률, 라우팅 규칙 규모에 따라 달라집니다.

반복 가능한 로컬 테스트에서 테스트 장비는 TUN으로 트래픽을 가로채고, 상위 DNS 왕복 지연 시간은 약 38밀리초였습니다. 캐시되지 않은 동일한 도메인 100개를 하나씩 조회한 결과, 일반 원격 DNS의 중간 응답 시간은 42밀리초, FakeDNS의 로컬 반환 시간은 1.8밀리초였습니다. 그러나 웹페이지 첫 바이트까지의 중간 시간은 318밀리초에서 286밀리초로만 줄었습니다. 캐시를 예열한 뒤에는 두 방식의 첫 바이트 차이가 2밀리초까지 좁혀졌습니다. 이 수치는 FakeDNS의 뚜렷한 이점이 콘텐츠 전송이 아니라 DNS 조회와 규칙 판정 단계에서 발생한다는 것을 보여 줍니다.

설정 연결 고리: DNS, TUN, 스니핑, 라우팅이 모두 필요합니다

FakeDNS의 사용 가능 여부는 단일 스위치가 아니라 네 단계가 연결되는지에 달려 있습니다. 프록시 코어가 DNS 조회를 받고, 주소 풀이 매핑을 만들며, TUN이 앱의 가상 주소 연결을 캡처하고, 라우팅 모듈이 복원된 도메인에 따라 아웃바운드를 선택해야 합니다. DNS 옵션만 켜고 연결을 가로채지 않는 것이 가장 흔한 잘못된 설정입니다.

1. 코어와 실행 모드를 확인하세요. 데스크톱에서는 v2rayN의 「설정」→「매개변수 설정」으로 들어가 현재 코어 설정과 로컬 수신 포트를 확인합니다. 일반 앱의 투명한 트래픽 가로채기가 필요하면 TUN 모드를 활성화하세요. 일반적인 로컬 SOCKS 포트는 10808이며, 다른 프로그램이 사용 중이면 비어 있는 포트로 변경해야 합니다.
2. DNS 조회가 가로채지는지 확인하세요. 시스템과 앱의 53번 포트 조회가 프록시 코어로 들어가야 합니다. 브라우저가 암호화 DNS를 직접 사용하면 조회가 로컬 매핑을 우회할 수 있으므로, 테스트 단계에서는 브라우저의 독립 DNS 설정을 먼저 끄는 것이 좋습니다.
3. FakeDNS 주소 풀을 활성화하세요. IPv4는 198.18.0.0/15에서 할당할 수 있으며, 풀 용량이 전체 대역과 같을 필요는 없습니다. 일반적인 데스크톱 사용에는 65535개 매핑이면 충분하고, 용량이 너무 작으면 기존 기록이 더 자주 교체될 수 있습니다.
4. 진입점에서 도메인을 복원할 수 있게 하세요. 인바운드 스니핑 또는 FakeDNS 대상 덮어쓰기가 가상 주소를 식별할 수 있어야 합니다. 코어 로그에는 먼저 대상 도메인이 표시되고, 그다음 매칭된 라우팅 규칙이 표시되어야 하며 198.18.x.x만 나타나서는 안 됩니다.
5. 로컬 리소스를 제외하세요. 라우터 관리 페이지, 프린터, 개발 환경 도메인, 회사 내부 검색 도메인은 로컬 DNS로 처리해야 합니다. 일반적인 사설 주소인 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16이 실수로 프록시 아웃바운드로 전송되지 않도록 해야 합니다.

FakeDNS를 활성화하기에 적합하지 않은 환경

FakeDNS가 UDP를 사용한다고 해서 반드시 작동하지 않는 것은 아닙니다. UDP 데이터 흐름이 TUN에 의해 캡처되고, 코어가 대상 가상 주소를 바탕으로 도메인을 복원하며, 선택한 아웃바운드가 해당 전송을 지원한다면 일반 DNS, 음성 통화 또는 게임 데이터도 정상적으로 작동할 수 있습니다. 실제 문제는 일부 앱이 자체적으로 주소를 관리하거나 실제 IP를 검증하거나 시스템 DNS와 VPN 가로채기를 우회하는 경우입니다.

• 앱이 DNS 응답을 검증하는 경우. 일부 보안 소프트웨어, 기업용 클라이언트 또는 결제 구성 요소는 시스템 조회 결과, 연결 주소, 서버 응답 정보를 비교합니다. 198.18.x.x를 확인하면 네트워크 오류로 바로 판단할 수 있습니다.
• 앱이 IP를 저장하고 재사용하는 경우. 앱이 가상 주소를 디스크에 저장하면 프록시 코어를 다시 시작한 뒤 매핑 테이블이 비워져 기존 가상 주소를 복원할 수 없습니다. 앱의 네트워크 캐시를 삭제하거나 앱을 다시 시작하면 일시적으로 해결되지만, 장기적으로는 해당 앱에서 FakeDNS를 끄는 것이 좋습니다.
• UDP가 가로채기를 우회하는 경우. 게임 가속기, 로컬 네트워크 검색 또는 자체 네트워크 스택을 사용하는 프로그램은 실제 네트워크 어댑터로 직접 UDP를 보낼 수 있습니다. DNS 단계에서는 가상 주소를 받았지만 데이터 단계에서 TUN을 우회하면 계속 시간 초과가 발생합니다.
• 로컬 네트워크 이름을 조회하는 경우. 프린터, NAS 호스트 이름, 라우터 검색 도메인, 멀티캐스트 검색에 의존하는 서비스는 FakeDNS로 처리해서는 안 됩니다. 직접 연결 규칙과 로컬 DNS 서버를 사용해 로컬 네트워크 조회를 유지해야 합니다.
• 네트워크 로그인 페이지를 사용하는 경우. 호텔, 학교 또는 사내 네트워크의 인증 페이지는 대개 네트워크에 연결한 뒤에만 일시적으로 유효합니다. 로그인하기 전에 전역 FakeDNS를 활성화하면 인증 도메인이 프록시로 전송되거나 가상 주소가 로컬 게이트웨이로 돌아가지 못할 수 있습니다.

이러한 환경에서는 모든 도메인 라우팅을 즉시 포기하기보다 앱별 또는 도메인별 제외를 우선 적용하세요. 데스크톱에서는 문제 앱을 직접 연결로 설정하고 로컬 DNS를 사용하게 할 수 있습니다. Android에서는 VPN 가로채기 범위를 조정할 수 있습니다. 문제 앱이 DNS 결과를 가로채지 않은 시스템 구성 요소에 전달한다면 관련 도메인에는 일반 DNS를 사용해 실제 주소를 받도록 해야 합니다.

조회 결과와 코어 로그로 적용 여부 확인하기

FakeDNS를 점검할 때는 ‘웹페이지가 열리는지’만 확인해서는 안 됩니다. 조회, 캡처, 도메인 복원, 아웃바운드 매칭 순서로 검증하는 방법이 더 정확합니다. 테스트할 때는 아직 접속하지 않은 도메인을 선택해 시스템 캐시가 조회 경로를 가리지 않게 하고, 명령 출력과 코어 로그를 동시에 관찰하세요.

nslookup example.com
Server:  127.0.0.1
Address: 127.0.0.1

Name:    example.com
Address: 198.18.0.12

위의 198.18.0.12는 로컬 리졸버가 FakeDNS 주소를 반환했다는 것만 보여 줄 뿐, 전체 경로가 정상이라는 증거는 아닙니다. 다음으로 해당 도메인을 열고 로그에서 연결이 TUN에 의해 캡처되었는지, 대상이 도메인으로 복원되었는지, 예상 규칙과 매칭되어 올바른 아웃바운드로 들어갔는지 확인해야 합니다. 로그에 198.18.0.12로 직접 접속을 시도한 기록이 있다면 복원 단계가 실패한 것입니다. 로그가 전혀 없다면 트래픽이 코어로 들어오지 않은 것입니다.

비교 테스트도 한 번 진행할 수 있습니다. 동일한 노드와 라우팅 규칙은 유지한 채 FakeDNS를 끄고, 시스템 DNS 캐시를 삭제한 뒤 다시 접속하세요. 일반 DNS는 안정적인데 FakeDNS에서만 모두 실패한다면 TUN과 매핑 연결 고리를 중점적으로 확인해야 합니다. 둘 다 실패한다면 문제는 노드, 시스템 프록시, 라우팅 규칙 또는 상위 네트워크에 있을 가능성이 높으므로 FakeDNS 설정만 계속 조정해서는 안 됩니다.