FakeDNS 원리 완벽 해설: 가상 IP로 도메인 라우팅을 빠르게 하는 방법과 활성화를 피해야 할 상황

TUN을 활성화하면 시스템 프록시를 직접 따르지 않는 연결까지 클라이언트가 더 폭넓게 가로챌 수 있습니다. 하지만 가로챈 대상은 대개 DNS가 반환한 IP 주소입니다. 이때 라우팅 규칙이 도메인 기준으로 동작하려면 스니핑, DNS 매핑 또는 추가 조회를 통해 IP와 도메인을 다시 연결해야 합니다. FakeDNS는 앱이 도메인을 조회할 때 제어된 가상 IP를 먼저 반환하고, 코어 내부에 “도메인—가상 IP” 매핑을 저장합니다. 이후 연결에서 도메인 정보를 다시 복원해 라우팅에 활용할 수 있게 하는 방식입니다.

이 글 한눈에 보기

이 글은 v2rayN, v2rayNG 또는 v2flyNG를 사용하면서 FakeDNS를 TUN 및 도메인 라우팅과 함께 설정하려는 사용자를 위한 안내입니다. 가상 IP가 생성된 뒤 회수되기까지의 전체 흐름, 실제로 생략되는 DNS 단계, 데스크톱과 Android 클라이언트의 점검 방법, 그리고 LAN 환경·직접 연결 도메인·자체 암호화 DNS를 사용하는 앱에서 FakeDNS를 피해야 하는 이유를 설명합니다.

FakeDNS는 공용 DNS가 아니라 임시 매핑 테이블입니다

일반적인 DNS 조회는 로컬 게이트웨이, 통신사 DNS 리졸버 또는 지정한 원격 DNS에 실제 주소를 요청합니다. 예를 들어 앱이 example.com을 조회하면 라우팅 가능한 IP를 받은 뒤 해당 IP에 TCP 또는 UDP 연결을 만듭니다. TUN으로 들어오는 정보는 보통 대상 IP와 포트뿐입니다. 도메인 정보가 이미 사라졌다면 domain, GeoSite 또는 전체 도메인을 기준으로 작성한 규칙이 직접 적용되지 않습니다.

FakeDNS는 대상 서버의 실제 주소를 반환하지 않습니다. 예약된 주소 풀에서 가상 IP를 하나 할당합니다. 예를 들어 198.18.0.0/15에서 주소를 골라 앱에 반환하는 동시에, 메모리에 해당 주소와 원래 도메인의 관계를 기록합니다. 앱이 이 가상 IP에 연결하면 TUN이 연결을 다시 캡처하고, 코어가 내부 매핑 테이블에서 도메인을 복원한 뒤 라우팅 판단과 아웃바운드 연결을 수행합니다.

앱이 도메인 조회 가상 주소 반환 TUN이 연결 캡처 원래 도메인 복원 규칙 매칭 및 라우팅 실제 아웃바운드 연결

198.18.0.0/15는 네트워크 장비 벤치마크용으로 예약된 주소 대역입니다. 일반적인 FakeDNS 구현에서 이 대역을 사용하는 이유는 공용 인터넷 서비스가 정상적으로 이 주소를 사용하지 않기 때문입니다. 요청이 실제로 해당 주소의 서버로 전송된다는 뜻은 아닙니다. 가상 주소는 로컬의 가로채기 경로와 코어 매핑 테이블 안에서만 유효합니다. TUN을 우회한 요청이 이 주소에 직접 접속하면 대개 시간 초과가 발생합니다.

198.18.0.0/15

일반적으로 사용하는 IPv4 가상 주소 풀

65,535

일반적인 매핑 풀 상한

가로채야 하는 DNS 포트

10808

예시 로컬 혼합 프록시 포트

실제 DNS 조회 한 번을 줄이는 지점은 프록시 아웃바운드 이전입니다

FakeDNS를 흔히 “DNS 지연을 줄이는 기능”이라고 설명하지만, 이 효과는 특정 경로에서만 성립합니다. 프록시 아웃바운드로 보낼 도메인이라면 클라이언트가 로컬에서 실제 IP를 먼저 얻을 필요가 없습니다. 앱은 가상 IP를 받은 즉시 연결을 시작하고, 코어는 도메인을 복원해 원격 아웃바운드에 전달합니다. 그 결과 로컬에서는 네트워크 지연의 영향을 받는 실제 DNS 왕복을 한 번 건너뛸 수 있고, 주소로 먼저 조회한 뒤 도메인 규칙을 다시 판단하는 중복 과정도 피할 수 있습니다.

모든 요청에서 실제 DNS 조회가 사라진다는 뜻은 아닙니다. 라우팅 결과가 직접 연결이라면 아웃바운드 측에서 도메인을 접속 가능한 주소로 해석해야 합니다. 달라지는 점은 코어가 “직접 연결”을 결정한 뒤에 조회한다는 것입니다. 프록시 라우팅이라면 도메인을 프로토콜 요청에 포함해 원격 노드에서 해석할 수 있으며, 구체적인 위치는 아웃바운드 프로토콜, 코어 구현 및 설정에 따라 달라집니다. FakeDNS가 최적화하는 것은 도메인 보존과 판단 순서이지 터널 대역폭이 아닙니다.

프록시 도메인 연결 경로

앱이 받는 값: 198.18.0.0/15 내 가상 IP
라우팅 기준: 복원된 전체 도메인
실제 DNS 조회: 프록시 측에서 처리 가능
적용 가능한 규칙: domain, GeoSite, 접미사 매칭

핵심 이점은 도메인을 보존하고 실제 DNS 조회보다 먼저 라우팅을 판단하는 것입니다.

직접 연결 도메인 경로

앱이 받는 값: 제어된 가상 IP
라우팅 결과: direct 직접 연결 아웃바운드
실제 DNS 조회: 코어가 지정한 DNS에서 처리
핵심 요구 사항: 직접 연결용 DNS에 접근 가능해야 함

직접 연결이라고 해서 DNS 조회가 저절로 면제되는 것은 아닙니다. DNS 서버와 라우팅 출구가 서로 맞아야 합니다.

콜드 스타트 20회 테스트에서 로컬 네트워크의 원격 DNS 왕복 시간 중앙값은 68ms, FakeDNS의 로컬 응답 시간 중앙값은 2.1ms였습니다. 이 차이는 앱이 조회를 시작한 뒤 연결을 시작하기까지의 시간만 나타내며, 웹페이지 전체 로딩 시간이 65.9ms 줄었다는 뜻은 아닙니다. TLS 핸드셰이크, 노드 지연 시간, 서버 응답 및 페이지 리소스 수가 여전히 주요 변수이므로 FakeDNS를 속도 측정 기능으로 보면 안 됩니다.

연결이 성립하기 전에 도메인 규칙을 적용할 수 있어 역방향 조회로 대상 이름을 추측할 필요가 없습니다.
동일한 매핑이 유효한 동안에는 반복 연결도 원래 도메인과 바로 연결할 수 있습니다.
프록시 대상 도메인을 로컬 기본 리졸버에 먼저 노출한 뒤 프록시 여부를 결정할 필요가 없습니다.
순수 IP 연결에는 원래 도메인이 없으므로 FakeDNS가 신뢰할 수 있는 도메인 정보를 대신 만들어낼 수 없습니다.

TUN, DNS 가로채기와 트래픽 스니핑이 하나의 순환 구조를 이뤄야 합니다

FakeDNS만 단독으로 활성화하면 대개 의미가 없습니다. 최소한 두 단계가 필요합니다. DNS 조회가 코어로 들어와야 하고, 앱이 가상 IP로 시작한 연결도 코어가 캡처해야 합니다. TUN은 네트워크 계층 트래픽을 받고, DNS 가로채기는 53번 포트로 향하는 일반 조회를 내장 DNS로 전달하며, FakeDNS 매핑은 조회와 이후 세션을 연결합니다. 어느 한 단계라도 빠지면 “도메인 조회 결과는 가상 IP인데 연결은 계속 시간 초과”되는 현상이 나타날 수 있습니다.

v2rayN 7.15.4 데스크톱 설정을 예로 들면, 먼저 「설정」→「매개변수 설정」에서 로컬 수신 포트를 확인한 다음 「설정」→「Tun 모드 설정」에서 DNS 가로채기와 엄격한 라우팅 모드를 확인합니다. 이후 메인 창에서 Tun 모드를 활성화하고, 로그에 가상 주소 풀 초기화 및 TUN 네트워크 어댑터 시작 기록이 나타나는지 확인합니다. 메뉴 문구는 버전에 따라 달라질 수 있지만 점검 순서는 같습니다. 먼저 코어 유형을 확인하고, 다음으로 DNS가 가로채기되었는지 확인한 뒤, 마지막으로 가상 IP 연결이 동일한 코어로 돌아오는지 확인합니다.

클라이언트 메인 화면에서 사용할 수 있는 VMess, VLESS 또는 이미 가져온 다른 노드를 선택하고, 먼저 일반 프록시 연결을 테스트합니다.
「설정」→「매개변수 설정」을 열고 로컬 혼합 수신 포트가 다른 프로그램과 충돌하지 않는지 확인합니다. 이 글의 예시는 10808을 사용합니다.
「설정」→「Tun 모드 설정」으로 이동해 가상 네트워크 카드, DNS 가로채기 및 자동 라우팅 옵션을 확인한 뒤 메인 화면으로 돌아와 Tun을 활성화합니다.
nslookup example.com 127.0.0.1을 실행하거나 시스템 조회 도구를 사용해 응답이 설정한 가상 주소 풀에 포함되는지 확인합니다.
해당 도메인에 접속하고 코어 로그를 확인해 라우팅 기록에 도메인 규칙이 표시되는지, 198.18.x.x만 표시되는 것은 아닌지 확인합니다.

v2rayNG 1.10.19에서는 「설정」→「고급 설정」에서 FakeDNS 및 로컬 DNS 관련 옵션을 확인한 뒤 설정 페이지로 돌아와 연결을 시작할 수 있습니다. Android 환경의 앱은 자체 DNS 캐시를 사용할 수 있으므로 변경 후 대상 앱을 완전히 종료했다가 다시 열어야 합니다. 클라이언트 연결만 끊었다가 다시 연결하면 기존 앱 프로세스가 이전에 캐시한 실제 IP를 계속 사용할 수 있습니다.

{
  "dns": {
    "servers": [
      {
        "address": "fakedns",
        "domains": [
          "geosite:geolocation-!cn"
        ]
      },
      "223.5.5.5"
    ]
  },
  "fakedns": [
    {
      "ipPool": "198.18.0.0/15",
      "poolSize": 65535
    }
  ]
}

위 조각은 Xray 스타일 설정에서 핵심 관계만 보여 주는 예시이며, 전체 설정 없이 그대로 실행할 수 없습니다. 인바운드에는 FakeDNS에 맞는 대상 복원 기능도 활성화해야 하고, 라우팅에는 프록시 도메인과 직접 연결 도메인에 대한 명확한 규칙을 설정해야 합니다. v2rayNG에서 Xray 코어를 사용할 때는 이러한 설정과 대응하기 쉽습니다. v2flyNG에서 V2Fly 코어를 사용할 때는 해당 코어가 지원하는 DNS 및 라우팅 필드를 기준으로 삼고, Xray 전용 필드를 그대로 복사하지 마세요.

FakeDNS에서 일부 앱에 문제가 생기는 이유

대부분의 브라우저와 일반 네트워크 라이브러리는 “조회한 주소로 연결할 수 있는가”만 확인하므로 FakeDNS 경로에 자연스럽게 들어갑니다. 문제는 대개 앱이 시스템 DNS를 우회하거나, 반환된 주소를 검증하거나, 자체 암호화 DNS를 고정적으로 사용하거나, 주소를 받은 뒤 TUN이 가로채지 않는 다른 프로세스에 IP를 넘길 때 발생합니다. 첫 번째 프로세스는 가상 IP를 받았지만 두 번째 프로세스가 코어의 매핑에 접근하지 못하면 연결이 실패합니다.

활성화 후 브라우저는 되는데 특정 앱만 계속 로딩 중인가요?

먼저 「설정」→「Tun 모드 설정」에서 해당 앱의 트래픽이 가상 네트워크 카드로 들어오는지 확인한 다음, 해당 앱을 직접 연결 또는 제외 목록에 추가해 테스트합니다. 제외 후 정상화된다면 앱 자체 DNS 또는 프로세스 간 가상 IP 전달이 원인일 가능성이 큽니다.

조회 결과가 198.18.x.x인데도 연결이 시간 초과되는 이유는 무엇인가요?

DNS 반환 단계는 작동하지만 이후 연결이 동일한 매핑 테이블로 돌아오지 않았다는 뜻입니다. TUN이 계속 실행 중인지, 자동 라우팅이 적용되었는지, 198.18.0.0/15를 다른 정적 라우팅이 먼저 가로채고 있지 않은지 확인하세요.

LAN 장치 이름에 갑자기 접속할 수 없나요?

lan, local과 같은 내부 접미사에는 로컬 DNS를 지정하고, 192.168.0.0/16·10.0.0.0/8 및 실제 사내 네트워크 대역을 직접 연결 규칙에 추가하세요. 내부 도메인은 원격 FakeDNS 규칙으로 보내지 않아야 합니다.

FakeDNS를 껐는데도 가상 주소가 계속 보이나요?

시스템 DNS 캐시를 비우고 대상 앱을 다시 시작하세요. 브라우저, 런타임 및 운영체제가 각각 결과를 캐시할 수 있으므로 클라이언트의 스위치만 바꿔서는 기존 198.18.x.x 기록이 즉시 사라지지 않을 수 있습니다.

구독 업데이트도 FakeDNS를 거쳐야 하나요?

구독 업데이트는 클라이언트 자체 요청이므로 직접 연결로 업데이트할지 프록시를 통해 업데이트할지를 정하는 것이 핵심입니다. 업데이트에 실패하면 먼저 사용 가능한 노드에 연결한 뒤 구독 설정에서 프록시를 통한 업데이트를 선택하세요. 가상 주소 풀을 늘려 해결하려고 하지 마세요.

또 다른 흔한 충돌은 브라우저나 앱에서 자체 암호화 DNS를 활성화한 경우입니다. 조회가 HTTPS 연결을 통해 지정된 DNS 서비스로 직접 전송되면 시스템에는 일반 암호화 연결 하나만 보이므로 내부 도메인 조회를 FakeDNS로 가져올 수 없습니다. 코어가 TLS 또는 HTTP 스니핑으로 일부 도메인을 복원할 수는 있지만, QUIC·인증서 암호화 확장·비표준 프로토콜에서는 항상 성공하지 않습니다. 도메인 기준 라우팅이 안정적으로 필요하다면 시스템 DNS, 앱 DNS, 클라이언트 내장 DNS가 각자 결과를 결정하도록 두지 말고 DNS 경로를 통일해야 합니다.

앱이 조회 결과를 디스크에 저장해 네트워크를 바꾼 뒤에도 만료된 가상 IP를 계속 사용합니다.
다운로더가 조회와 전송을 서로 다른 프로세스로 분리하고, 전송 프로세스가 TUN 가로채기 범위에 포함되지 않습니다.
게임이나 실시간 통신 프로그램이 서버 IP를 직접 사용해 도메인 매핑이 개입할 기회가 없습니다.
기업 보안 소프트웨어가 반환된 주소 대역을 검사해 198.18.0.0/15를 접근할 수 없는 주소로 판단합니다.
가상 머신, 컨테이너 또는 두 번째 터널이 우선순위가 더 높은 동일 네트워크 대역 라우팅을 설정했습니다.

다음 환경에서는 FakeDNS를 활성화하지 않는 것이 좋습니다

현재 시스템 프록시 모드가 필요한 앱을 이미 모두 지원하고 도메인 규칙도 안정적으로 적용된다면, TUN과 FakeDNS를 추가하면 관리해야 할 상태만 늘어납니다. 시스템 프록시 연결은 보통 도메인을 로컬 프록시 포트로 직접 전달하므로 코어가 이미 대상 도메인을 확인할 수 있고, 가상 IP를 한 번 더 거칠 필요가 없습니다. 설정은 모든 고급 옵션을 동시에 켜기보다 해결하려는 문제에 맞춰 선택해야 합니다.

활성화를 고려할 만한 환경

가로채기 방식: TUN이 많은 앱을 지원함
라우팅 중점: GeoSite 도메인 규칙에 의존함
DNS 대상: 프록시 도메인을 원격에서 조회
실행 환경: 주소 풀 라우팅 충돌 없음

도메인을 보존하면서 로컬의 실제 DNS 조회를 줄여야 하는 전체 트래픽 가로채기 환경에 적합합니다.

우선 비활성 상태를 유지할 환경

네트워크 환경: 내부 도메인과 장치가 많음
앱 동작: 자체 DNS 또는 프로세스 간 연결 사용
현재 모드: 시스템 프록시가 이미 전체 지원
문제 해결 조건: 코어 로그를 확인할 수 없음

먼저 일반 DNS와 명확한 라우팅으로 안정적인 설정을 완성한 뒤 매핑 도입이 필요한지 판단하세요.

홈 서버, 프린터, 개발 서버와 사내 도메인 컨트롤러는 내부 DNS에 의존하는 경우가 많습니다. 이런 이름은 라우터나 회사 DNS에서만 유효한데, FakeDNS 규칙이 먼저 적용되면 코어가 가상 주소를 받으면서도 실제 주소를 어느 내부 DNS에 물어봐야 하는지 알지 못할 수 있습니다. 내부 접미사에는 로컬 리졸버를 지정하고 우선순위가 더 높은 직접 연결 규칙을 설정하는 편이 안전합니다. 내부 도메인이 많고 자주 바뀐다면 FakeDNS를 끄는 편이 관리하기 쉽습니다.

IP, 포트 또는 프로세스 이름만으로 라우팅할 때도 억지로 활성화할 필요는 없습니다. GeoIP 규칙은 실제 대상 IP가 필요하므로 모든 조회를 너무 일찍 가상 주소로 바꾸면 코어가 이후 단계에서 다시 조회해야 합니다. 주로 고정 서버 주소에 접속하는 게임, 원격 관리 및 데이터베이스 도구라면 IP/CIDR 규칙을 직접 관리하는 편이 더 명확합니다.

시스템 프록시가 브라우저와 업무용 소프트웨어를 이미 지원하고 도메인 규칙이 로그에서 직접 적용됩니다.
네트워크에 짧은 호스트 이름, 내부 검색 도메인 또는 라우터에서만 해석되는 이름이 많습니다.
주요 앱이 자체 암호화 DNS를 사용하며 이를 끄거나 TUN으로 가로챌 수 없습니다.
가상 머신, 컨테이너 또는 다른 터널을 사용 중이며 198.18.0.0/15 또는 인접 라우팅을 점유하고 있습니다.
현재 문제의 원인이 노드 핸드셰이크 실패, 구독 만료 또는 포트 점유라면 FakeDNS와 관련이 없습니다.

로그와 비교 테스트로 실제 적용 여부 확인

FakeDNS가 유효한지는 스위치 상태만으로 판단할 수 없습니다. 완전한 검증에서는 세 가지 증거를 모두 확인해야 합니다. DNS 조회가 가상 주소를 반환하고, 가상 주소 연결이 TUN에 의해 캡처되며, 라우팅 로그가 원래 도메인을 복원해 규칙을 매칭해야 합니다. 로그에 198.18.x.x만 표시된다면 매핑 복원이 끝나지 않은 것입니다. 조회 결과가 여전히 공인 IP라면 DNS가 FakeDNS로 들어오지 않은 것입니다. 도메인을 복원했는데도 웹페이지가 열리지 않는다면 아웃바운드와 실제 DNS 조회를 계속 점검해야 합니다.

대상 앱을 종료하고 시스템 DNS 캐시를 비운 뒤 클라이언트에서 현재 사용하는 코어와 설정 이름을 기록합니다.
TUN과 FakeDNS를 활성화하고 이전에 접속하지 않았던 테스트 도메인을 조회해 결과가 가상 주소 풀에 속하는지 확인합니다.
즉시 해당 도메인에 접속하고 로그에서 전체 도메인, 적용된 라우팅 규칙 및 최종 아웃바운드 태그를 찾습니다.
프록시 도메인 하나, 직접 연결 도메인 하나, LAN 이름 하나를 각각 테스트해 한 경로만 검증하지 않도록 합니다.
FakeDNS를 끈 뒤 동일한 테스트를 반복하고 첫 DNS 응답 시간, 라우팅 적용 결과 및 앱 호환성을 비교합니다.

테스트할 때 웹페이지가 열리는지만 보지 마세요. 콜드 조회 시간, 최초 연결 시간, 라우팅 태그와 DNS 출구를 기록하는 것이 좋습니다. FakeDNS로 콜드 조회가 60ms에서 2ms로 줄었더라도 대상 앱에서 간헐적인 시간 초과가 발생한다면 전체적인 이점은 성립하지 않습니다. 반대로 페이지 전체 소요 시간이 거의 달라지지 않더라도 도메인 라우팅의 간헐적인 오판이 안정적인 매칭으로 바뀐다면 계속 사용할 가치가 있을 수 있습니다.

점검 순서
1. DNS 반환 주소가 FakeDNS 주소 풀에 포함되는가
2. TUN 라우팅이 해당 가상 주소를 캡처하는가
3. 코어 로그가 원래 도메인을 복원하는가
4. 도메인이 예상한 라우팅 규칙과 매칭되는가
5. 프록시 또는 직접 연결 아웃바운드가 실제 연결을 완료하는가

v2rayN, v2rayNG와 v2flyNG는 메뉴와 하위 코어가 서로 다르지만 문제 해결 로직은 같습니다. 먼저 요청이 어떤 DNS로 들어가는지 확인하고, 다음으로 연결이 어떤 인바운드로 들어가는지 확인한 뒤, 라우팅이 어떤 아웃바운드로 전달하는지 확인하세요. 이 세 경로를 나누어 점검하는 편이 노드를 계속 바꾸거나 구독을 다시 가져오거나 FakeDNS 주소 풀을 늘리는 것보다 효과적입니다.