V2Ray FakeDNS 원리와 가상 IP 매핑·사용 사례

일반 DNS와 FakeDNS의 차이

일반 DNS의 A·AAAA 조회는 각각 IPv4·IPv6 주소를 가져옵니다. 앱은 응답을 받은 뒤 보통 해당 주소로 직접 연결합니다. 투명 프록시 진입점에 도달한 연결에는 ‘대상 IP와 포트’만 남을 수 있지만, 도메인 규칙에는 앱이 처음 조회한 이름이 필요합니다. FakeDNS는 앞단의 응답 방식을 바꿉니다. 실제 서버 주소를 바로 반환하는 대신, 제어된 경로 안에서만 의미가 있는 가상 IP를 할당합니다.

예를 들어 앱이 www.example.com을 조회하면 FakeDNS는 198.18.0.2를 할당하고 둘 사이의 매핑을 저장합니다. 이후 앱이 198.18.0.2:443에 연결하면 연결을 가로챈 코어가 매핑을 조회해 대상을 www.example.com:443으로 복원할 수 있습니다. 이 주소는 작동 원리를 설명하기 위한 예시이며, 직접 접속할 수 있는 테스트 서버도 아니고 모든 클라이언트에서 고정으로 첫 할당되는 주소도 아닙니다.

가상 IP 매핑의 전체 흐름

이 흐름의 핵심은 ‘DNS가 무엇을 응답했는가’가 아니라, 응답과 후속 연결이 다시 이어질 수 있는가입니다. DNS 응답을 처리하는 매핑 테이블과 대상 연결을 처리하는 코어는 매핑 상태를 공유하거나, 이 기능을 지원하는 통합 구성 요소로 연결되어야 합니다. 한 인스턴스가 가상 주소를 할당했는데 매핑 정보가 없는 다른 인스턴스가 연결을 받으면, 그 인스턴스에는 직접 접속할 수 없는 특수 목적 주소만 보입니다.

1. 제어된 DNS 경로로 조회 전달: 앱의 A 또는 AAAA 요청이 설정된 DNS 경로를 거쳐야 합니다. 기존 DNS의 UDP 53 포트만 가로챈다고 해서 앱 자체의 암호화 DNS까지 처리되는 것은 아닙니다.
2. 매핑 테이블에 기록: FakeDNS가 도메인에 가상 주소를 할당합니다. 주소 풀에 여유가 부족해지면 구현에 따라 오래된 매핑을 회수할 수 있습니다. 주소가 할당되는 순서는 고정된 인터페이스로 간주하면 안 됩니다.
3. 가상 주소 연결 가로채기: TUN 또는 투명 프록시 규칙이 연결을 도메인 복원을 지원하는 진입점으로 전달해야 합니다. FakeDNS 자체는 TUN 네트워크 인터페이스를 만들거나 시스템 라우팅 전체를 자동으로 설정하지 않습니다.
4. 매핑을 조회해 대상 복원: 코어가 가상 IP에 대응하는 도메인을 찾아 도메인 규칙과 후속 아웃바운드에서 사용합니다. 실제 연결 대상을 다시 쓰는지는 진입점의 스니핑 설정 등에도 영향을 받습니다.
5. 실제 사이트에 연결: 프록시 아웃바운드를 선택하면 도메인 대상 전송을 지원하는 프로토콜이 도메인을 원격 측에 전달할 수 있습니다. 직접 연결을 선택하면 보통 실제 연결 가능한 주소를 얻기 위해 실제 DNS 조회가 필요합니다.

따라서 FakeDNS를 사용해도 DNS가 불필요해지는 것은 아닙니다. 실제 DNS 조회를 미루고 도메인 연관 정보를 보존하는 방식입니다. VMess, VLESS 같은 프록시 프로토콜을 대체하거나 노드 인증 정보를 수정하지 않으며, 서버 연결 불가, 전송 경로 오류, TLS 설정 불일치도 해결하지 못합니다.

설정 항목: 주소 풀, DNS, 진입점의 도메인 복원

‘V2Ray FakeDNS’는 이런 방식을 통칭하는 말로 자주 쓰이지만, V2Ray와 Xray의 실제 설정 기능과 항목, 클라이언트 연동 방식은 각각 확인해야 합니다. 아래는 해당 항목을 지원하는 Xray-core JSON 설정을 기준으로 명시적인 예시 값을 보여줍니다. 모든 버전의 기본값이라고 단정하는 내용은 아닙니다. v2rayN, v2rayNG, v2flyNG는 인터페이스와 설정 생성 방식이 다르므로 다른 코어의 설정을 그대로 복사하지 마세요.

아래는 최상위 객체에 포함되는 DNS 및 주소 풀 설정 일부이며, 단독으로 실행할 수 있는 전체 설정은 아닙니다. 리스너, 아웃바운드, 시스템 라우팅이 정의되어 있지 않고 IPv4 풀만 보여 줍니다. 따라서 AAAA 조회도 같은 방식으로 처리된다고 단정할 수 없습니다. 실제 배포에서는 사용 중인 코어의 문서를 참고해 IPv6 처리 방식과 실제 DNS 폴백 경로를 설정해야 합니다.

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

가상 주소 연결을 받는 인바운드에도 도메인 복원 설정이 필요합니다. 아래는 해당 인바운드 내부의 sniffing 항목만 보여 주며, 나머지 인바운드 설정을 자동으로 채우지는 않습니다. 일반적으로 routeOnly는 스니핑 결과를 라우팅에만 사용하고 대상을 다시 쓰지 않는다는 뜻입니다. 이 예시에서는 아직 복원되지 않은 가상 대상을 아웃바운드로 넘기지 않도록 false로 명시했습니다.

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

적합한 환경과 적합하지 않은 환경

FakeDNS가 특히 유용한 환경은 TUN이나 투명 프록시를 이미 사용하면서 도메인별 분기도 필요한 경우입니다. 투명 프록시는 네트워크 계층에서 연결을 받아 처리하므로 연결 정보만으로 도메인을 알 수 없는 경우가 있습니다. 매핑 테이블을 사용하면 도메인 규칙이 HTTP Host나 TLS 핸드셰이크 정보에만 의존하지 않아도 됩니다. 실제 DNS 조회를 프록시 출구 측에서 처리하려는 설정에도 사용할 수 있지만, 그 목적을 달성할 수 있는지는 아웃바운드와 라우팅, 실제 DNS 설정의 조합에 달려 있습니다.

명시적 프록시와 투명 프록시는 따로 판단해야 합니다. 도메인 대상 요청을 지원하는 SOCKS 요청이나 HTTP CONNECT 요청은 도메인을 직접 전달할 수 있어 FakeDNS가 필요하지 않을 수 있습니다. 반면 앱이 로컬에서 먼저 DNS를 조회한 뒤 IP를 프록시에 전달하면 도메인이 사라질 수 있습니다. ‘시스템 프록시’라는 표현만 보고 결정하지 말고 실제 요청 형식을 확인하세요.

흔한 부작용: 캐시, 내부망, DNS 우회

FakeDNS는 유지 기간이 있는 로컬 매핑 테이블을 사용하지만, 앱과 시스템에는 이전 DNS 응답이 계속 캐시될 수 있습니다. 코어가 재시작되어 기존 매핑이 사라졌는데 앱이 캐시된 가상 IP로 연결을 시도하면 ‘처음에는 되다가 모드를 바꾼 뒤 접속이 안 되는’ 문제가 생길 수 있습니다. 이 경우 아웃바운드를 선택하기 전에 문제가 발생하므로 노드를 계속 바꿔도 대개 해결되지 않습니다.

• 모드 전환 후 연결 끊김: FakeDNS를 끄거나 TUN을 종료한 뒤에도 캐시된 가상 주소가 사용될 수 있습니다. 먼저 연결 가로채기 모드를 원래대로 맞춘 다음 캐시를 지우고 관련 앱을 다시 시작하세요.
• 사내 서비스 오류: 내부 도메인은 사내 DNS에서 내부 주소를 받아야 할 수 있습니다. 모든 조회를 구분 없이 가상 주소 풀로 보내지 말고, 해당 도메인에는 실제 DNS 조회와 직접 연결 경로를 명시적으로 설정하세요.
• 앱 자체 DNS 조회: 앱에 DoH나 DoT가 내장되어 있거나 자체 조회 결과를 사용하면 기존 DNS 연결 가로채기로 조회를 포착하지 못할 수 있습니다. 이때 가상 매핑이 없는 것은 정상이며 주소 풀이 고장 났다는 뜻이 아닙니다.
• IPv4와 IPv6 처리 불일치: A 조회는 가상 주소 풀을 거치고 AAAA 조회는 다른 경로를 사용하면 같은 앱에서도 연결이 불안정할 수 있습니다. 두 레코드 유형과 IPv6 라우팅, 해당 주소 풀 설정을 각각 확인하세요.
• 진단 도구 결과 차이: 조회 도구에 198.18 대역이 표시된다고 해서 도메인의 실제 주소가 그곳이라는 뜻은 아닙니다. 가상 IP의 연결 여부를 테스트해도 원격 사이트의 가동 상태를 직접 확인할 수 없습니다.

FakeDNS를 쓴다고 자동으로 ‘DNS 누출이 없어지는’ 것은 아닙니다. 로컬 직접 연결 아웃바운드에서 실제 DNS 조회가 발생할 수 있고, 앱이 제어된 DNS를 우회할 수도 있습니다. DNS 경로를 점검할 때는 조회가 어디로 전달되는지와 연결이 어떤 아웃바운드로 나가는지 각각 확인하세요. 한 번 가상 주소가 반환됐다는 사실만으로 결론을 내려서는 안 됩니다.

가상 IP 연결 실패, 순서대로 점검하기

도메인 하나, 앱 하나, 노드 하나를 정해 전환 전후의 증상을 기록하는 것이 좋습니다. 아래에서는 www.example.com을 조회 예시로 사용합니다. 명령은 현재 로컬 DNS 경로를 확인하기 위한 것이며, 조회가 반드시 FakeDNS에 도달한다고 보장하지는 않습니다. Windows, macOS, Linux의 DNS 도구는 브라우저와 다른 조회 경로를 사용할 수도 있습니다.

nslookup -type=A www.example.com
nslookup -type=AAAA www.example.com

1. 먼저 조회 결과가 가상 주소 풀에 있는지 확인: A 응답이 설정된 풀에 속한 주소라면 해당 조회에서 가상 응답을 받은 것입니다. 여전히 실제 IP가 반환된다면 조회가 제어된 DNS를 우회했는지, 해당 도메인에 실제 DNS 예외가 적용됐는지 확인하세요.
2. 다음으로 연결이 코어에 전달되는지 확인: 앱이 연결을 시작할 때 액세스 로그를 확인하세요. 가상 주소가 반환됐는데 코어에 해당 연결 기록이 없다면 노드의 VMess나 VLESS 설정을 먼저 바꾸지 말고 TUN 라우팅과 진입점의 연결 가로채기부터 점검하세요.
3. 매핑에서 도메인을 복원할 수 있는지 확인: 로그에 가상 IP만 계속 표시된다면 연결을 받는 인바운드에 적합한 복원 설정이 적용됐는지 확인하세요. 코어 재시작, 주소 풀 변경, 다중 인스턴스 전환이 있었는지도 점검해야 합니다. 로그 형식은 버전마다 다르므로 한 줄만 보고 실패를 단정하지 마세요.
4. 마지막으로 라우팅과 아웃바운드 확인: 도메인을 복원했는데도 연결이 실패한다면 도메인 규칙이 어떤 아웃바운드를 선택하는지 확인하세요. 직접 연결에는 정상적인 실제 DNS 조회 경로가 필요합니다. 프록시 아웃바운드라면 노드 연결, 서버 측 DNS 조회, 전송 설정을 이어서 점검하세요.

Windows에서는 아래 명령으로 시스템 DNS 캐시를 지울 수 있지만 모든 앱의 내부 캐시까지 삭제되지는 않습니다. 캐시를 지우기 전에 현재 연결 가로채기 모드가 올바른지 확인하세요. 그렇지 않으면 앱이 사용할 수 없는 응답을 다시 받게 됩니다. 브라우저나 백그라운드에서 계속 실행되는 프로그램에 문제가 남으면 관련 프로세스를 종료한 뒤 다시 시도하세요.

ipconfig /flushdns