FakeDNS란? 작동 원리와 설정 방법, 사용 시나리오

이 글의 핵심

FakeDNS는 프록시로 트래픽이 들어올 때 대상 IP만 남아 도메인 기반 라우팅에 필요한 정보를 잃는 문제를 해결합니다. TUN과 DNS 설정을 바꾸려는 사용자를 위해 가상 IP 매핑 원리부터 DNS 가로채기, 연결 복구, 실제 DNS 조회 경로까지 살펴보고 단계별로 확인합니다. 노드를 더 빠르게 만드는 기능도 아니고 TUN을 켰다고 반드시 사용해야 하는 설정도 아닙니다.

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

일반 DNS 조회는 도메인을 실제 서버 주소로 변환합니다. FakeDNS는 조회된 도메인에 가상 IP를 할당하고, 로컬에 도메인과 가상 IP의 대응 관계를 저장합니다. 예를 들어 앱이 example.com을 조회하면 주소 풀에서 IP 하나를 받을 수 있습니다. 앱이 이 주소로 연결하면 프록시 코어가 저장된 매핑을 바탕으로 원래 도메인을 복원합니다. 이 주소는 웹사이트의 실제 서버 주소가 아니므로 인터넷 연결에 그대로 사용할 수 없습니다.

앱에서 도메인 조회 가상 IP 할당 대상 연결 가로채기 원래 도메인 복원 규칙에 따라 아웃바운드 선택

이 과정이 성립하려면 두 가지 조건이 필요합니다. DNS 조회를 매핑을 관리하는 구성 요소가 처리해야 하고, 이후 연결도 해당 매핑을 인식하는 처리 경로로 들어와야 합니다. 첫 번째 조건만 충족하면 앱은 가상 IP를 받아도 연결할 수 없습니다. 두 번째 조건만 충족하면 조회 결과가 실제 IP이므로 FakeDNS에서 사용할 매핑이 없습니다.

도메인을 복원하면 프록시는 도메인 규칙에 따라 직접 연결 또는 프록시 연결을 선택할 수 있습니다. 직접 연결에는 보통 연결 가능한 실제 주소가 필요합니다. 프록시 아웃바운드가 도메인 조회를 원격에 맡길 수 있는지는 아웃바운드 프로토콜과 설정에 따라 달라집니다. FakeDNS는 로컬 조회와 대상 식별 방식을 바꿀 뿐, 최종 연결 대상의 DNS 조회를 대신하거나 VMess, VLESS 프로토콜 매개변수를 바꾸지 않습니다.

FakeDNS, TUN, 트래픽 스니핑의 역할

TUN은 트래픽 진입점, FakeDNS는 주소 매핑 방식, 스니핑은 대상 식별 방식입니다. 서로 같은 기능을 하는 설정이 아닙니다. TUN으로 들어오는 것은 대개 IP 패킷입니다. 앱이 다른 곳에서 이미 도메인을 IP로 변환했다면 패킷에 도메인 정보가 남아 있지 않을 수 있어 별도의 도메인 식별 경로가 필요합니다.

기능	주요 역할	단독으로 보장할 수 없는 점
TUN	라우팅 대상에 해당하는 IP 트래픽을 처리 경로로 전달	모든 연결에 도메인 정보가 포함되는 것은 아님
FakeDNS	가상 IP를 할당하고 도메인 매핑을 보존	모든 DNS 조회와 연결을 자동으로 가로채지는 않음
HTTP/TLS 스니핑	프로토콜 데이터에서 호스트 이름 식별 시도	모든 암호화 트래픽에서 도메인을 복원할 수는 없음
도메인 기반 라우팅 규칙	도메인 조건에 따라 아웃바운드 선택	도메인 정보가 없는 연결에 정보를 임의로 채워 넣을 수는 없음

판단 기준: 연결에서 도메인 정보가 사라지는지 확인한 뒤 FakeDNS 사용 여부 결정

앱이 SOCKS를 통해 도메인을 직접 전달하고 도메인 규칙도 정상적으로 적용된다면 현재 설정을 유지해도 됩니다. 투명 프록시 적용 후 대상 IP만 표시되는 일이 잦아 도메인 기반 라우팅에 실제로 문제가 생길 때 가상 IP 매핑을 추가하는 편이 좋습니다.

FakeDNS는 자체 매핑을 사용해 도메인을 복원하므로 앱이 읽을 수 있는 HTTP 호스트 헤더나 TLS 호스트 이름을 보내야 하는 것은 아닙니다. 다만 앱 자체의 암호화 DNS, IP 고정 연결, 별도 DNS 캐시는 이 매핑 경로를 우회할 수 있습니다. 스니핑을 켰다고 모든 연결에 도메인 규칙이 적용되는 것은 아닙니다.

설정 전 확인할 사항: 코어와 DNS 가로채기 범위

v2rayN은 데스크톱 클라이언트이며, 실제 설정 기능은 사용 중인 코어와 실행 모드에 따라 다릅니다. v2rayNG는 Android용으로 Xray 코어를 사용하고, v2flyNG는 Android용으로 V2Fly 코어를 사용합니다. 클라이언트 이름만 보고 설정 항목이 같다고 판단해서는 안 됩니다. 특히 TUN 트래픽 진입점과 노드 프록시 코어를 서로 다른 구성 요소가 담당할 수 있으므로 Xray의 FakeDNS 항목을 다른 구성 요소의 설정에 그대로 적용하면 안 됩니다.

DNS 경로 확인

일반 DNS: UDP 53 및 TCP 53 트래픽이 실제로 어디로 향하는지 확인
앱 DNS 조회: 브라우저에서 별도의 보안 DNS를 사용하는지 확인
IPv6 조회: AAAA 응답과 IPv6 라우팅이 동일한 방식으로 가로채지는지 확인
실제 주소 조회: 노드 도메인과 직접 연결 대상에 필요한 DNS 조회 경로 유지

53번 포트를 가로채도 모든 암호화 DNS가 가로채지는 것은 아닙니다.

연결 경로 확인

가상 IP 주소 풀: 예시 주소 대역: 198.18.0.0/15
로컬 진입점: 가상 IP 대상 연결이 동일한 매핑 처리 경로로 들어오는지 확인
도메인 복원: 진입점에서 해당 FakeDNS 복원 기능을 지원하고 활성화했는지 확인
네트워크 충돌: 기업 네트워크나 다른 터널이 같은 주소 대역을 사용하는지 확인

198.18.0.0/15는 벤치마크용 주소 대역이며 웹사이트의 실제 주소가 아닙니다.

IPv4와 IPv6는 각각 확인해야 합니다. IPv4 가상 풀만 설정했는데 앱이 실제 IPv6 주소를 계속 받을 수 있다면 다른 경로로 연결될 수 있습니다. 반드시 장애라는 뜻은 아니지만 라우팅 동작이 예상과 달라질 수 있습니다. 테스트 결과를 맞추려고 시스템 IPv6를 무작정 끄지 말고, 먼저 클라이언트가 IPv6 가로채기를 함께 지원하는지 확인하세요.

Xray 설정 예시: 주소 풀, DNS, 진입점 복원

아래는 설정 항목 간 관계를 설명하기 위한 Xray JSON 일부이며, 전체 TUN 설정은 아닙니다. 최상위 fakedns 주소 풀, DNS의 fakedns 서버, SOCKS 진입점의 도메인 복원 설정을 보여 줍니다. 적용하기 전에 현재 Xray 버전이 해당 항목을 지원하는지 확인하고, 기존 dns 및 inbounds 설정과 하나씩 병합해야 합니다. 기존 진입점이나 아웃바운드 설정을 덮어쓰지 마세요.

{
  "fakedns": [
    {
      "ipPool": "198.18.0.0/15",
      "poolSize": 65535
    }
  ],
  "dns": {
    "servers": [
      "fakedns"
    ]
  },
  "inbounds": [
    {
      "tag": "local-socks",
      "listen": "127.0.0.1",
      "port": 10808,
      "protocol": "socks",
      "settings": {
        "udp": true
      },
      "sniffing": {
        "enabled": true,
        "destOverride": [
          "fakedns"
        ]
      }
    }
  ]
}

poolSize: 65535는 매핑 풀의 용량 설정이며 노드 개수나 속도를 뜻하지 않습니다. 장시간 실행할 때는 매핑 수명과 앱 캐시가 서로 맞는지가 더 중요합니다.
127.0.0.1:10808은 이 예시에서 SOCKS 진입점으로 사용하는 주소이며 DNS 수신 포트가 아닙니다. 시스템 DNS에 이 주소와 포트를 입력한다고 DNS 서비스가 자동으로 만들어지지는 않습니다.
여기서 dns.servers는 FakeDNS만 보여 줍니다. 실제 환경에서는 코어가 지원하는 규칙에 따라 실제 DNS 조회도 구성해야 하며, 실제 IP가 필요한 조회가 모두 가상 IP 풀로 들어가게 해서는 안 됩니다.
destOverride의 fakedns는 매핑을 이용해 대상 도메인을 복원합니다. 이 설정만으로 TUN 네트워크 어댑터가 생성되거나 시스템 DNS가 코어로 전달되는 것은 아닙니다.

클라이언트가 설정 파일을 자동 생성하는 경우, 임시 생성 파일을 직접 수정하면 재시작하거나 노드를 바꿀 때 변경 사항이 사라질 수 있습니다. 현재 버전에서 제공하는 사용자 지정 설정 기능을 사용하거나 지원 범위 내에서 DNS와 진입점 설정을 조정하세요. 규칙 항목을 확인하려면 먼저 설정 가이드를 살펴보세요. 서로 다른 코어의 예시를 하나의 설정 파일에 섞지 마세요.

확인 절차: DNS 응답부터 라우팅 결과까지 추적

한 번에 한 종류의 설정만 바꾸고, 원래대로 되돌릴 수 있도록 설정을 보관한 뒤 아래 순서대로 테스트하세요. 가상 IP 하나를 확인하는 데 그치지 말고 전체 경로가 정상적으로 이어지는지 확인해야 합니다. 지연 시간을 한 번 측정하는 것만으로는 도메인 기반 라우팅이 제대로 작동하는지 알 수 없습니다.

기준 상태 기록. 테스트할 도메인을 하나 정하고 현재 DNS 응답, 연결 성공 여부, 적용된 아웃바운드를 기록합니다. 테스트 중에는 노드, 구독, 규칙 세트를 동시에 바꾸지 마세요.
기존 캐시 삭제. Windows에서는 PowerShell에서 Clear-DnsClientCache를 실행한 다음 테스트할 앱을 다시 시작합니다. 시스템 명령으로 브라우저 내부 캐시나 프록시 코어 자체의 매핑까지 삭제할 수는 없습니다.
응답 주소 확인. 조회가 설정한 IPv4 가상 풀을 실제로 거쳤다면 응답 주소는 198.18.0.0/15 범위에 있어야 합니다. 실제 주소가 반환되면 라우팅을 바로 바꾸지 말고 먼저 DNS가 어디로 향하는지 확인하세요.
실제 연결 시도. 클라이언트 로그에서 대상이 예상한 도메인으로 복원되는지, 적용된 규칙이나 아웃바운드가 무엇인지 확인합니다. 로그 항목은 코어마다 다르므로 모든 로그 수준에서 매핑 세부 정보가 표시되는 것은 아닙니다.
직접 연결과 프록시 연결을 각각 테스트. 두 유형 모두 연결에 성공해야 합니다. 직접 연결만 실패한다면 실제 DNS 조회와 직접 연결 아웃바운드를 확인하세요. 가상 IP 연결이 모두 시간 초과된다면 먼저 연결 복구 경로를 점검합니다.
기능 해제 후 확인. 해당 모드를 끈 뒤 시스템과 앱 캐시를 다시 지우고, 새 조회에서 이전 가상 IP를 계속 사용하지 않는지 확인합니다. 확인하지 않으면 해제 후 발생한 연결 실패를 네트워크 장애로 오해하기 쉽습니다.

정리: 가상 IP를 받는 것은 첫 단계일 뿐

가상 IP 반환, 처리 경로로 연결 전달, 도메인 복원, 올바른 아웃바운드 선택, 최종 연결 성공까지 모두 충족해야 검증이 끝납니다. 어느 한 단계라도 빠져 있다면 관련 경로를 점검하세요. 가로채기 범위를 무작정 넓혀 해결하려고 해서는 안 됩니다.

FakeDNS 사용에 적합한 상황과 보류해야 할 경우

FakeDNS는 투명 프록시가 필요하고 도메인 규칙에 의존하며 DNS를 한곳에서 관리할 수 있는 환경에 적합합니다. 프로토콜 스니핑 결과에 대한 의존도를 줄일 수 있지만, 매핑 상태와 캐시 일관성도 관리해야 합니다. 현재 겪는 문제를 기준으로 사용 여부를 결정하세요.

사용을 검토할 만한 경우: TUN 적용 후 로그에 IP만 자주 표시되어 도메인 규칙이 잘 적용되지 않고, 시스템과 앱의 DNS 조회 경로를 제어할 수 있는 경우.
현재 설정을 유지해도 되는 경우: 브라우저가 명시적인 프록시 설정을 통해 도메인을 전달하고, 기존 도메인 기반 라우팅이 안정적으로 작동하며, 투명 프록시가 필요하지 않은 경우.
먼저 점검해야 할 경우: 기업 내부망에서 분리 DNS를 사용하거나 내부 도메인이 있거나 라우팅이 가상 풀과 충돌하는 경우. 내부 조회와 인터넷 조회를 먼저 구분해야 합니다.
주의해서 테스트할 경우: 앱이 DNS 조회 결과를 디스크에 장기간 저장하거나, IP를 프로세스 간에 전달하거나, 프록시를 종료한 뒤에도 기존 연결을 계속 사용하는 경우.
개선 효과를 기대해선 안 되는 경우: 노드에 연결할 수 없거나 서버 인증 매개변수가 잘못되었거나 전송 경로가 혼잡한 경우. 이런 문제는 도메인 매핑으로 해결되지 않습니다.

로컬 네트워크 프린터, 네트워크 저장 장치, 사내 업무용 도메인에는 보통 로컬 네트워크 요건에 맞는 DNS 조회 방식을 유지해야 합니다. 모든 조회를 가상 IP로 바꾸면 실제 주소에 의존하는 장치 검색, 접근 제어 또는 진단 절차가 작동하지 않을 수 있습니다. 관련 설정을 한꺼번에 켜기보다 일부 환경에서 먼저 확인한 뒤 범위를 넓히면 문제 원인을 찾기 쉽습니다.

FakeDNS 자주 묻는 질문과 문제 해결 순서

DNS에서 198.18로 시작하는 주소를 받았는데 웹페이지가 열리지 않는 이유는 무엇인가요?

먼저 후속 연결이 동일한 매핑 처리 경로로 들어오는지 확인한 뒤 진입점의 도메인 복원 설정을 점검하세요. 한 구성 요소가 주소를 할당하고, 매핑을 공유하지 않는 다른 구성 요소가 연결을 처리하면 연결에 실패합니다. 우회하려고 가상 IP를 실제 웹사이트 주소처럼 직접 연결 규칙에 추가하지 마세요.

TUN을 켰는데 브라우저 조회 결과가 왜 여전히 실제 IP인가요?

브라우저의 보안 DNS, 시스템에서 지정한 암호화 DNS 서비스, 기존 캐시를 확인하세요. 제어 가능한 테스트 환경에서만 시스템 DNS를 임시로 사용하고 브라우저를 다시 시작한 다음 응답을 살펴볼 수 있습니다. TUN이 IP 트래픽을 가로챈다고 해서 모든 암호화 DNS를 식별하고 바꿀 수 있는 것은 아닙니다.

클라이언트를 종료한 뒤 웹사이트가 열리지 않는다면 어떤 설정부터 확인해야 하나요?

먼저 시스템 프록시와 DNS 설정을 복원한 뒤 Clear-DnsClientCache를 실행하고 오류가 계속되는 앱을 다시 시작하세요. 앱이 이전 가상 IP를 계속 사용하면 앱 자체의 DNS 캐시를 지우거나 앱을 다시 시작합니다. 가상 풀 주소를 시스템 DNS로 설정하지 마세요.

FakeDNS를 켜도 geosite 및 geoip 규칙이 필요한가요?

분류하려는 트래픽에 따라 필요한 규칙을 유지해야 합니다. FakeDNS는 도메인 정보를 제공할 뿐 라우팅 정책을 만들지는 않습니다. 도메인 규칙은 이름으로 트래픽을 구분하고 IP 규칙은 실제 IP 조건을 처리할 수 있습니다. 가상 IP 풀을 특정 지역의 IP로 간주하지 말고, 매핑 정보가 사라지는 문제를 해결하려고 domainStrategy를 바꾸지도 마세요.

실제 설정은 다음 순서로 진행하면 됩니다. 먼저 일반 프록시와 실제 DNS가 정상적으로 작동하도록 설정하고, 그다음 TUN 가로채기를 확인한 뒤 마지막으로 FakeDNS를 적용하세요. 각 단계의 로그를 보관하고 되돌릴 수 있는 설정을 유지해야 DNS 조회, 라우팅, 아웃바운드 연결 중 어디에서 문제가 생겼는지 구분할 수 있습니다.