FakeDNS란? 가상 DNS 원리와 TUN 모드 연동, 사용 시나리오

핵심 내용

FakeDNS는 투명 프록시 환경에서 도메인 정보를 유지해야 할 때 유용하지만, DNS와 라우팅 설정 전체를 대신하지는 않습니다. 주소 매핑, TUN 트래픽 처리, Xray 설정, 문제 해결 순으로 살펴보고, 사용 중인 클라이언트가 필요한 조건을 갖췄는지 판단하는 방법과 로그 및 캐시 삭제로 설정을 확인하는 방법을 안내합니다. 스위치 하나만 보고 작동 여부를 추측하지 마세요.

FakeDNS 원리: 임시 주소로 도메인 정보 유지하기

FakeDNS는 웹 서버의 실제 주소가 아니라 로컬에서 매핑한 주소를 반환합니다. 일반 DNS는 도메인을 실제 IP 주소로 변환하지만, FakeDNS는 미리 정한 주소 풀에서 주소를 하나 할당하고 도메인과 임시 주소의 대응 관계를 기록합니다. 앱은 평소처럼 이 주소에 연결하고, 프록시가 연결을 처리하면 매핑 정보를 이용해 도메인을 복원한 뒤 라우팅 및 아웃바운드 처리로 전달합니다.

도메인 조회 가상 주소 할당 앱 연결 TUN 트래픽 처리 도메인 복원 아웃바운드 선택

Xray에서 흔히 사용하는 IPv4 주소 풀 예시는 198.18.0.0/15이며, 범위는 198.18.0.0부터 198.19.255.255까지입니다. 이 주소는 성능 측정용으로 예약된 범위로, 공인 서버 주소도 일반 가정용 사설 LAN 주소 대역도 아닙니다. 올바르게 설정된 FakeDNS 경로에서 앱이 이런 주소를 받는 것은 정상입니다.

핵심은 주소에서 도메인을 복원할 수 있어야 한다는 점입니다. 앱이 가상 주소에 연결할 때 프록시를 우회하거나, 연결을 처리하는 코어에 해당 매핑 정보가 없으면 정상적으로 접속할 수 없습니다. DNS 설정에 주소 풀만 입력하고 연결 처리와 도메인 복원 과정을 구성하지 않으면, 접속되던 사이트도 연결 시간 초과가 발생할 수 있습니다.

FakeDNS와 TUN: 트래픽 처리와 DNS 처리는 별개

TUN은 네트워크 패킷을 프록시로 전달하고, FakeDNS는 이 과정에서 도메인 정보를 복원할 수 있게 합니다. 두 기능은 함께 쓰이는 경우가 많지만 같은 기능은 아닙니다. TUN을 켜도 앱 연결만 처리되고 DNS 조회는 라우터나 기업 DNS, 브라우저의 암호화 DNS로 전송될 수 있습니다. 이 경우 실제 주소가 반환되므로 FakeDNS 매핑은 만들어지지 않습니다.

단계	필요한 조건	조건이 없을 때 나타나는 현상
DNS 요청 경로	조회 요청이 설정된 FakeDNS로 전달됨	실제 IP가 반환되어 가상 주소 매핑을 확인할 수 없음
연결 처리	주소 풀 대역의 트래픽이 올바른 TUN 또는 투명 프록시 인바운드로 전달됨	앱이 예약 주소에 직접 연결하다 시간 초과됨
도메인 복원	연결을 처리하는 코어에서 해당 매핑을 조회할 수 있음	라우팅에서 가상 주소만 확인되어 도메인 기반 분류가 불가능함
최종 아웃바운드	직접 연결 또는 프록시가 복원된 대상을 처리할 수 있음	규칙은 적용됐지만 연결은 실패함

도메인 복원과 트래픽 스니핑도 구분해야 합니다. HTTP Host나 TLS 서버 이름 같은 정보로 일부 연결을 식별할 수 있지만, 모든 연결에서 도메인을 읽을 수 있는 것은 아닙니다. FakeDNS는 앞서 조회한 매핑을 바탕으로 도메인을 복원하므로 앱 계층의 데이터에 전적으로 의존하지 않습니다. 다만 앱이 IP를 직접 사용하거나 해당 DNS 경로를 거치지 않으면 원래 도메인을 알아낼 수 없습니다.

판단 기준: 네 가지 단계를 확인한 뒤 FakeDNS 활성화

DNS 요청 경로, 주소 풀 라우팅, 매핑 복원, 아웃바운드 처리가 하나의 흐름으로 이어져야 합니다. TUN 아이콘이 켜졌는지만 확인해서는 부족합니다. 로그에서 복원된 대상 도메인과 선택된 아웃바운드를 확인한 다음 도메인 기반 라우팅이 실제로 적용되는지 판단하세요.

Xray 설정: 주소 풀과 인바운드 복원을 따로 확인

Xray에서 FakeDNS를 사용하려면 주소 풀 설정과 실제 DNS 사용 경로가 함께 구성되어야 합니다. 아래는 설명을 위한 최상위 설정 일부이며, 그대로 실행할 수 있는 완전한 클라이언트 설정은 아닙니다. IPv4 가상 주소 풀과 내장 DNS 서버 선택만 보여 줍니다. 실제로 사용하려면 인바운드, 라우팅, 아웃바운드 설정도 필요하며 앱의 DNS 조회가 이 DNS 모듈로 전달되어야 합니다.

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

poolSize는 매핑 풀의 용량을 나타내며 DNS 수신 포트나 네트워크 속도 설정이 아닙니다. 예시의 65535는 웹사이트에서 동시 연결 65535개를 사용할 수 있다는 뜻이 아닙니다. FakeDNS DNS 설정만으로 모든 실제 주소 조회를 처리할 수도 없습니다. 직접 연결할 대상, 프록시 서버 도메인, 특수한 내부 도메인은 실제 주소를 조회할 경로를 명확히 지정해야 합니다. 연결을 시작하는 단계에서 바로 사용할 수 없는 가상 주소를 받는 일을 방지할 수 있습니다.

주소 풀 및 DNS

최상위 필드: fakedns
IPv4 주소 풀: 198.18.0.0/15
예시 용량: 65535
DNS 서버 항목: fakedns

먼저 조회가 이 모듈로 전달되는지 확인한 뒤, 반환 주소가 설정된 풀 범위에 포함되는지 살펴보세요.

Xray 인바운드 복원

인바운드 필드: sniffing
활성화 여부: enabled: true
대상 재정의: destOverride: ["fakedns"]
확인 항목: 가상 주소 연결을 실제로 수신하는 인바운드

여기에는 복원과 관련된 필드만 나열했습니다. 나머지 스니핑 옵션은 기존 설정에 맞춰 병합하세요.

이 기능을 지원하는 Xray 인바운드에서 sniffing.destOverride의 fakedns는 매핑을 조회해 대상을 복원하는 데 사용됩니다. 이 필드를 다른 코어의 설정에 그대로 붙여 넣거나 TUN 트래픽을 받지 않는 인바운드만 수정하지 마세요. 클라이언트가 설정을 자동 생성하는 경우 임시 파일을 직접 수정해도 다음 실행 때 덮어써질 수 있으므로, 클라이언트에서 제공하는 설정 메뉴를 우선 사용하세요.

사용 시나리오: 도메인 기반 라우팅과 내부 DNS 예외

FakeDNS는 트래픽을 투명하게 처리하면서 아웃바운드를 도메인 기준으로 선택해야 하는 상황에 적합합니다. 예를 들어 시스템 HTTP 프록시를 사용하지 않는 앱은 TUN을 켜도 연결 대상 IP만 확인될 수 있습니다. FakeDNS로 매핑을 유지하면 라우팅 규칙에서 도메인을 다시 사용할 수 있습니다. 이 기능은 도메인 식별 경로를 개선할 뿐 구독 노드의 품질을 바꾸거나 VMess를 VLESS로 자동 변환하지는 않습니다.

사용 시나리오	권장 사항	주요 설정
TUN 사용 중 도메인 기반 라우팅 필요	필요한 조건이 모두 갖춰졌다면 활성화 가능	매핑 복원을 확인한 뒤 도메인 규칙 적용
명시적인 HTTP 또는 SOCKS 프록시만 사용	먼저 도메인 대상 정보가 이미 있는지 확인	이미 도메인을 알고 있다면 대개 가상 주소를 추가할 필요가 없음
기업 내부망 및 가정용 기기 검색	실제 DNS 조회 경로 유지 권장	내부 도메인은 해당 DNS로 전달하고, 필요에 따라 LAN 트래픽은 우회
앱에서 실제 IP 또는 주소 소속을 확인	앱 하나씩 호환성 테스트	필요하면 해당 앱이나 도메인에 실제 DNS 조회 예외 설정

LAN 프린터, 기업 내부 서비스, 로컬 기기 검색에 의존하는 앱은 모두 FakeDNS를 거치게 하지 않는 편이 좋습니다. 멀티캐스트 검색과 일반 유니캐스트 DNS는 서로 다른 방식입니다. 먼저 해당 서비스의 기존 DNS 경로를 유지한 뒤 처리 범위를 점차 넓히세요. 내부 도메인을 공용 DNS에 맡기면 FakeDNS를 꺼도 접속되지 않을 수 있습니다.

설정 순서: 일반 DNS와 TUN을 안정화한 뒤 가상 주소 매핑 추가

새 설정에서는 먼저 직접 연결, 프록시 연결, 내부망 접속을 각각 확인하세요. 도메인 식별이 실제로 누락되는 경우에만 FakeDNS를 추가하고 세 가지 연결을 다시 테스트하면 DNS 문제를 노드, 권한, 라우팅 문제와 구분할 수 있습니다.

검증 및 문제 해결: DNS 응답부터 대상과 아웃바운드까지 확인

웹페이지가 열리는지만 보고 FakeDNS를 검증해서는 안 됩니다. 기존 연결이나 캐시, 브라우저 자체 DNS 덕분에 접속이 정상일 수 있어 새 설정의 적용 여부를 확인하기 어렵습니다. 한 번에 설정 하나만 바꾸고 변경 전후의 DNS 결과, 연결 대상, 아웃바운드 태그를 기록하세요. 다음 절차는 특정 클라이언트 버전에 의존하지 않으며, 특정 메뉴가 모든 버전에서 같은 이름이라고 가정하지 않습니다.

실제 코어를 확인하세요. v2rayN의 코어 선택 항목이나 실행 로그에서 시작된 코어를 확인하고 클라이언트 및 코어 버전을 기록하세요. 설정에서 ‘알 수 없는 필드’ 오류가 나면 구독 노드를 계속 바꾸기 전에 해당 필드가 어느 코어에 속하는지 확인하세요.
DNS 요청 경로를 확인하세요. 일반 DNS는 UDP 또는 TCP의 53 포트를 사용하는 경우가 많지만, 내장 DNS 모듈이 있다고 시스템에서 해당 포트를 수신 중이라는 뜻은 아닙니다. 클라이언트의 DNS 처리 설정과 시스템 DNS 주소를 확인하고, 127.0.0.1:53을 바로 사용할 수 있다고 가정하지 마세요.
이전 캐시를 지우세요. 테스트 앱을 종료하고 시스템 캐시를 삭제한 뒤 앱을 다시 실행하세요. 브라우저에는 별도의 DNS 캐시와 보안 DNS 설정이 있을 수 있으므로 따로 확인해야 합니다.
주소와 복원 결과를 확인하세요. 조회 결과가 설정한 주소 풀에 포함되는지, 연결 로그에 복원된 도메인이나 관련 처리 기록이 표시되는지 확인하세요. 198.18.x.x가 보인다는 사실만으로 아웃바운드 연결 성공을 입증할 수는 없습니다.
실제 주소 조회와 라우팅을 확인하세요. 직접 연결 대상과 프록시 서버 도메인이 실제 주소를 받는지 확인한 다음 도메인 규칙에 적용된 아웃바운드를 살펴보세요. 문제 해결 후에는 대량의 연결 정보가 장기간 저장되지 않도록 로그 수준을 평상시 설정으로 되돌리세요.

Windows에서는 다음 명령으로 시스템 DNS 캐시를 지우고 네트워크 인터페이스별 DNS 서버 설정을 확인할 수 있습니다. 두 번째 명령은 PowerShell에서 실행해야 합니다. 두 명령은 DNS 요청 경로를 파악하는 데 쓰이며, 클라이언트 규칙을 자동으로 변경하거나 앱 내부의 모든 캐시를 삭제하지는 않습니다.

ipconfig /flushdns

Get-DnsClientServerAddress -AddressFamily IPv4

테스트 도구에서 실제 주소가 반환되면 먼저 어떤 DNS 서버에 질의했는지 확인한 뒤 FakeDNS의 실패 여부를 판단하세요. 가상 주소가 반환되지만 연결이 시간 초과되면 주소 풀 트래픽이 올바른 인바운드로 전달되는지, 매핑이 여전히 유효한지 확인해야 합니다. 코어를 재시작한 뒤 앱이 이전 가상 주소를 계속 사용할 수도 있지만 새 코어에는 해당 매핑이 없을 수 있습니다. 이때는 노드를 계속 바꾸기보다 앱을 재시작하고 캐시를 지우는 편이 효과적입니다.

AAAA 응답은 있지만 IPv4 매핑은 정상인 경우: IPv6 트래픽 처리와 DNS 정책을 확인하세요. IPv4 연결이 성공했다고 해서 모든 연결이 프록시를 거친다고 단정할 수는 없습니다.
기업 네트워크에서 문제가 발생한 경우: 네트워크 장비가 이미 198.18.0.0/15를 사용하고 있는지 확인해 주소 풀과 기존 라우트의 충돌을 방지하세요.
DNS 유출이 의심되는 경우: 일반 DNS, 암호화 DNS, IPv6 경로를 각각 확인하세요. 가상 주소가 반환된다는 사실만으로 모든 DNS 조회가 외부로 전송되지 않는다고 입증할 수는 없습니다.

자주 묻는 질문: 설정, 지연 시간, 비활성화 후 복구

FakeDNS를 켰는데도 도메인이 실제 IP로 조회되는 이유는 무엇인가요?

먼저 테스트 앱의 DNS 요청 경로를 확인하세요. 브라우저의 보안 DNS, 기존 시스템 DNS, 클라이언트의 실제 주소 조회 예외로 인해 실제 IP가 반환될 수 있습니다. 같은 도메인에 대해 시스템 조회 결과와 앱 접속 로그를 비교해 FakeDNS가 해당 도메인에 적용되는지 확인하세요. 가상 주소가 보이도록 만들기 위해 필요한 내부 도메인이나 서버 도메인 예외를 삭제하지 마세요.

198.18로 시작하는 주소가 반환되면 DNS가 오염된 건가요?

먼저 주소 풀 설정을 확인하세요. 풀을 198.18.0.0/15로 설정했다면 이 범위의 응답은 FakeDNS에서 예상되는 결과일 수 있습니다. 이어서 매핑 복원 및 아웃바운드 로그를 확인하세요. 이런 기능을 켠 적이 없는데 해당 주소가 나타난다면 현재 DNS 서버와 네트워크의 다른 트래픽 처리 설정을 점검하세요.

FakeDNS로 노드 지연 시간을 줄이거나 다운로드 속도를 높일 수 있나요?

노드에서 대상까지의 연결 품질을 직접 개선하지는 않습니다. 가상 주소를 할당하면 앱이 실제 주소 조회를 기다리는 단계를 건너뛸 수 있지만 이후 실제 주소 조회와 연결 수립이 필요할 수 있습니다. 비교할 때는 노드, 대상, 네트워크를 동일하게 유지하고 첫 연결과 지속 전송 결과를 각각 기록하세요. 페이지가 한 번 빨리 열렸다는 이유만으로 결론을 내리지 마세요.

FakeDNS를 껐는데도 앱이 접속되지 않는 이유는 무엇인가요?

앱에 가상 주소가 캐시되어 있거나 이전 연결이 유지되고 있을 수 있습니다. 관련 앱을 종료하고 기존 DNS 및 트래픽 처리 설정을 복원한 다음 Windows에서 ipconfig /flushdns를 실행하고 앱을 다시 시작하세요. 그래도 해결되지 않으면 라우팅과 DNS 서버도 함께 복원됐는지 확인하세요. TUN만 끄면 캐시된 가상 주소가 프록시를 우회해 접속을 시도할 수 있습니다.

최종 판단은 전체 연결 흐름을 기준으로 해야 합니다. 앱이 어떤 주소를 받았는지, 어떤 인바운드가 연결을 처리하는지, 도메인을 복원할 수 있는지, 규칙이 어떤 아웃바운드를 선택했는지 확인하세요. 라우팅과 프록시 모드를 더 조정하려면 전체 설명서를 참고하세요. 클라이언트를 처음 설정한다면 먼저 사용 가이드에 따라 기본 연결을 구성한 뒤 FakeDNS를 추가하세요.

플랫폼별 클라이언트 다운로드

Windows, macOS, Android 또는 Linux 클라이언트를 선택하고 구독을 가져와 기본 연결을 테스트한 다음 코어와 DNS 처리 설정을 확인하세요.

다운로드 페이지 사용 가이드