V2Ray FakeDNS 작동 원리: 가상 IP 할당, 트래픽 스니핑 연동과 활용 사례

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

일반 DNS는 도메인을 실제 연결 주소로 변환합니다. FakeDNS는 처리 대상인 A 또는 AAAA 쿼리에 가상 주소를 할당하고, 로컬에 도메인과 가상 주소의 매핑을 저장합니다. 앱은 정상적인 DNS 응답을 받은 것으로 여기고 해당 주소로 연결을 시도합니다. 프록시 코어가 연결을 받으면 매핑 테이블을 조회해 원래 도메인을 복원한 뒤 라우팅과 아웃바운드 처리로 넘깁니다.

여기서 ‘복원’은 로컬 매핑 조회를 뜻합니다. 공용 DNS에 PTR 역방향 조회를 요청하는 것이 아닙니다. 예를 들어 앱이 example.com을 조회해 주소 풀의 한 주소를 받으면, 코어는 앱이 해당 주소로 연결할 때 같은 매핑 테이블을 조회해 example.com을 찾아낼 수 있습니다. 구체적으로 어떤 주소가 할당될지는 실행 상태에 따라 달라지므로 특정 가상 주소를 규칙에 고정해 두면 안 됩니다.

가상 IP는 이 기기에서 연결을 가로채는 과정에 쓰이는 표식일 뿐, 웹 서버의 실제 주소가 아닙니다.다른 기기에서 그대로 접속할 수 없고, 일반 게이트웨이를 거쳐 공용 인터넷으로 보내도 대상 서버가 응답하지 않습니다. 최종적으로 직접 연결을 선택하더라도 먼저 도메인을 올바르게 복원한 뒤 해당 주소를 조회하고 연결해야 합니다.

주소 풀과 포트: 먼저 세 가지 숫자 구분하기

198.18.0.0/15는 198.18.0.0부터 198.19.255.255까지 포함하며, 성능 측정용으로 예약된 주소 대역입니다. 일반 사설 LAN 주소 대역은 아닙니다. 정상적인 공용 인터넷 대상 주소로 사용되지 않는다는 점을 이용해 가상 주소 풀로 쓸 수 있지만, 기업 네트워크나 테스트 환경, 다른 터널에서 이미 사용 중일 수도 있습니다. 활성화하기 전에 라우팅 충돌이 없는지 확인하세요.

poolSize는 매핑 풀의 용량을 뜻합니다. DNS 캐시 유지 시간이나 동시 연결 수 제한이 아닙니다. 이 글의 4096은 설정 예시일 뿐, 모든 기기에 적합한 최적값은 아닙니다. 용량이 부족하거나 매핑이 제거된 뒤에도 앱이 이전 주소를 계속 사용하면 도메인 복원에 실패할 수 있습니다. 브라우저 캐시만 지우고 코어의 매핑과 시스템 DNS 캐시 수명은 확인하지 않는 실수를 피하세요.

• 주소 풀: 어떤 대상 주소를 가상 주소로 인식할지 결정합니다. 기존 업무용 주소와 겹치면 안 됩니다.
• 매핑 용량: 보존할 수 있는 매핑 항목 수를 정합니다. 속도를 숫자만으로 판단하지 말고 실제 동작을 확인하세요.
• DNS 진입점: 일반 DNS는 보통 UDP/TCP 53번 포트를 사용하지만, 코어에 DNS 모듈이 내장되어 있다고 해서 로컬 53번 포트에서 자동으로 대기하는 것은 아닙니다.

FakeDNS, sniffing, TUN: 각 기능의 역할은 다릅니다

TUN은 가상 네트워크 인터페이스로 라우팅된 IP 트래픽을 받지만, 모든 연결에 도메인 정보가 포함되는 것은 아닙니다. 일반 sniffing은 HTTP Host나 TLS 핸드셰이크 등 지원되는 프로토콜 정보에서 도메인을 찾아냅니다. FakeDNS는 앞서 생성한 매핑을 바탕으로 도메인을 복원합니다. 두 방식 모두 도메인 정보를 보완하지만 출처가 다르므로 같은 기능으로 볼 수 없습니다.

앱이 IP 주소를 직접 사용하거나, 가로채지 않은 암호화 DNS를 사용하거나, 활성화 전에 저장해 둔 실제 주소를 재사용하면 FakeDNS가 매핑을 만들 기회가 없습니다. 이때 연결이 계속 IP 규칙으로 처리되더라도 곧바로 기능이 작동하지 않는다고 단정할 수는 없습니다. 반대로 DNS 쿼리는 FakeDNS로 들어왔지만 대상 연결이 TUN이나 투명 인바운드를 우회하면, 앱이 가상 주소로 연결을 시도하다 실패할 수 있습니다.

Xray 설정 예시: 주소 할당과 인바운드 복원을 함께 구성하기

아래는 Xray 형식의 필드 관계를 보여 주는 예시이며, 그대로 실행할 수 있는 완성 설정은 아닙니다. V2Ray는 널리 쓰이는 통칭이고, 구체적인 필드와 동작은 실제 사용하는 코어를 기준으로 확인해야 합니다. v2rayN은 클라이언트이며, v2rayNG는 Xray 코어를, v2flyNG는 V2Fly 코어를 사용합니다. 화면에 표시되는 이름이 비슷하다고 해서 서로 다른 코어의 JSON 설정을 그대로 복사하지 마세요.

첫 번째는 최상위 설정 예시입니다. IPv4 풀을 선언하고 내장 DNS에서 FakeDNS를 사용하도록 지정합니다. 필요한 관계만 보여 주며 노드 서버의 도메인 조회, LAN 도메인 예외, IPv6, DNS 트래픽 진입점은 포함하지 않았습니다. 클라이언트가 생성한 전체 설정을 이 내용으로 덮어쓰지 마세요.

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

두 번째는 가상 대상 연결을 받는 인바운드 객체에 적용하며, 매핑 테이블을 조회해 도메인을 복원하는 설정입니다. 필요한 관계를 명확히 보여 주려고 fakedns만 남겼습니다. HTTP, TLS 등의 스니핑 유형을 추가하려면 먼저 사용 중인 코어가 지원하는지 확인하세요. 이 객체를 최상위 독립 설정으로 사용하거나, 대상 연결을 받지 않는 인바운드에 잘못 추가하지 마세요.

{
  "sniffing": {
    "enabled": true,
    "destOverride": [
      "fakedns"
    ]
  }
}

• 노드 서버가 도메인 이름을 사용한다면 실제 주소를 조회할 수 있는 경로가 있어야 합니다. 가상 주소를 노드 연결의 최종 주소로 사용하면 안 됩니다.
• 도메인을 복원해야 geosite: 규칙을 적용할 근거가 생깁니다. geoip:는 IP를 대상으로 하므로 가상 주소를 웹사이트의 실제 위치를 나타내는 주소로 취급할 수 없습니다.
• IPv4 풀만 설정했다고 AAAA 쿼리와 IPv6 연결까지 처리되는 것은 아닙니다. 듀얼 스택 네트워크에서는 별도로 확인해야 합니다.

활용 사례: 투명 프록시에 효과적, 일반 시스템 프록시는 단순하게 유지

HTTP 프록시와 원격 DNS 조회를 지원하는 SOCKS 요청은 도메인을 프록시에 직접 전달할 수 있습니다. 이런 경우 FakeDNS를 추가해도 새로운 문제를 해결하지 못할 수 있습니다. 투명 프록시는 IP 패킷만 받기 때문에 도메인 정보가 누락되기 쉽고, 이때 FakeDNS가 주로 쓰입니다. 기능을 켜기 전에 트래픽에 부족한 정보가 도메인인지, 노드 연결·아웃바운드 조회·라우팅 순서 문제인지 먼저 파악하세요.

FakeDNS는 DNS 암호화 기능이 아니며 모든 DNS 쿼리가 프록시를 거치도록 보장하지도 않습니다. 앱에 전달되는 DNS 응답을 바꿀 뿐, 이후 실제 주소를 어느 쪽에서 어떤 전송 방식으로 조회할지는 아웃바운드와 DNS 정책에 달려 있습니다. VMess나 VLESS 같은 노드 프로토콜만으로 FakeDNS의 작동 여부가 결정되지는 않으며, 이를 위해 구독을 다시 가져올 필요도 없습니다.

확인 절차: DNS 응답부터 최종 아웃바운드까지 추적하기

1. 기준 상태를 보존하세요. 먼저 일반 프록시 모드에서 같은 노드로 대상 사이트에 접속되는지 확인하고 현재 설정을 백업합니다. 구독, 라우팅 규칙 데이터베이스, DNS를 한꺼번에 바꾸지 마세요.
2. 트래픽 가로채기 경로를 확인하세요. 선택한 TUN 또는 투명 프록시 방식을 활성화하고 앱의 DNS 쿼리와 후속 연결이 모두 예상한 경로로 들어오는지 확인합니다. Windows에서는 ‘설정’ → ‘네트워크 및 인터넷’에서 현재 네트워크 인터페이스를 확인할 수 있습니다. 다만 물리 네트워크 어댑터에 표시된 DNS 주소만으로 트래픽 가로채기가 성공했다고 판단할 수는 없습니다.
3. 오래된 캐시를 지우세요. 테스트 앱을 종료한 뒤 Windows 명령 프롬프트에서 ipconfig /flushdns를 실행해 시스템 캐시를 지우고 앱을 다시 엽니다. 브라우저 자체 캐시와 암호화 DNS 설정은 별도로 확인해야 합니다.
4. 실제 쿼리를 관찰하세요. 앱에서 요청을 보내 조회를 유도하고 DNS 로그를 통해 응답 주소가 설정한 풀에 속하는지 확인합니다. nslookup example.com은 참고용으로 사용할 수 있지만, 브라우저와 다른 경로로 쿼리할 수 있으므로 한 번의 결과로 모든 앱을 판단하면 안 됩니다.
5. 복원 및 라우팅 결과를 확인하세요. 사용 가능한 로그에서 원래 가상 대상, 복원된 도메인, 적용된 규칙, 아웃바운드 태그를 확인합니다. 로그 상세 수준은 코어와 클라이언트마다 다릅니다. 필요하다면 테스트 중에만 로그 수준을 높이고 테스트가 끝나면 원래대로 돌리세요.
6. 예외 동작을 검증하세요. 사내 사이트, IPv6 대상, 직접 연결 규칙을 각각 테스트합니다. 프록시 사이트 하나가 열린다고 해서 DNS 정책 전체가 올바르다는 뜻은 아닙니다.

테스트는 DNS가 어떤 응답을 반환했는지, 연결이 어디로 갔는지, 어떤 규칙이 적용됐는지 확인할 수 있어야 합니다. ping만 실행해서 웹 프록시가 작동하는지 판단하는 것은 적절하지 않습니다. 가상 주소는 ICMP에 응답할 필요가 없고 웹 트래픽은 다른 연결 경로를 사용하기 때문입니다. 가상 주소를 받는 속도를 웹사이트 접속 지연 시간으로 기록해서도 안 됩니다. 서로 다른 지표입니다.

자주 발생하는 문제: 가상 주소 잔류, 사내망 장애, 라우팅 규칙 미적용

코어를 재시작한 뒤에만 문제가 생긴다면 매핑 상태와 앱 캐시가 서로 맞지 않는 경우도 고려해야 합니다. 앱은 이전 가상 주소를 저장하고 있지만 새 프로세스에는 해당 매핑이 없을 수 있습니다. 이때는 노드를 계속 바꾸기보다 앱을 다시 시작하고 DNS를 재조회하는 편이 효과적입니다. 풀 용량을 늘려도 반복된다면 DNS 처리 구성 요소가 여러 개 실행 중인지 다시 확인하세요. 용량을 무한정 늘려 문제 해결을 대신할 수는 없습니다.

원복 순서: DNS 복원, 캐시 삭제, 일반 프록시 확인

현재 네트워크에 적합하지 않다고 판단되면 원래 설정으로 되돌리면 됩니다. 중요한 점은 가상 주소 할당과 이에 의존하는 트래픽 가로채기를 함께 해제해 연결 경로가 반만 남지 않게 하는 것입니다. 클라이언트 업데이트로 설정 생성 방식이 바뀔 수 있으므로, 어떤 옵션을 켰는지 추측하지 말고 미리 저장해 둔 설정을 기준으로 복원하세요.

• 기존 DNS 서버, 도메인 예외, 클라이언트 트래픽 가로채기 설정을 복원합니다.
• 물리 네트워크 인터페이스와 시스템 라우팅에 가상 주소 풀을 가로채는 규칙이 남아 있지 않은지 확인합니다.
• 앱을 종료하고 DNS 캐시를 지운 뒤, 같은 대상에 일반 시스템 프록시 방식으로 접속해 봅니다.
• 문제가 쿼리, 매핑 복원, 아웃바운드 연결 중 어느 단계에서 발생했는지 기록하고 다음에는 해당 단계만 조정합니다.

이 점만 기억하면 됩니다. FakeDNS는 도메인 정보가 필요한 라우팅 경로를 보완하는 기능입니다. 도메인이 이미 안정적으로 전달되는 환경에서는 복잡성을 늘리면서까지 옵션을 추가할 필요가 없습니다. 투명 프록시에서 도메인 정보가 실제로 누락될 때 주소 풀, 쿼리 진입점, 인바운드 복원, 아웃바운드 조회를 차례로 연결하세요. 필드 관계는 설정 레퍼런스의 DNS 설정에서 확인하고, 기본 연결 문제는 연결 문제 해결 안내를 참고하세요.