纯 IPv6 VPS 如何访问 IPv4：NAT64 原理、部署判断与回滚

先判断：你的服务器真的只有 IPv6 吗？

NAT64 解决的是：服务器所在网络没有原生 IPv4 出口，但需要访问 IPv4-only 目标。部署前先确认网卡地址、默认路由、DNS 解析和实际出站路径。

纯 IPv6：没有可用 IPv4 默认路由，访问 IPv4-only 服务失败。
双栈：同时有可用 IPv4 和 IPv6 出口。通常不应为了“看起来完整”而叠加 NAT64。
IPv6 + 共享 IPv4 网关：先确认服务商是否已提供转换能力，避免重复配置。

重要：先做只读检查并保存网络配置。不要直接覆盖 DNS、默认路由或防火墙规则。

一、做最小化诊断

在 Debian / Ubuntu 上记录地址、路由和 DNS 状态：

ip -br address
ip -6 route
ip -4 route
cat /etc/resolv.conf
getent ahosts github.com
curl -4 -I --connect-timeout 5 https://github.com
curl -6 -I --connect-timeout 5 https://github.com

如果 IPv6 请求成功、IPv4 请求失败，只能说明当前 IPv4 访问路径不可用；还要区分没有 IPv4 地址、没有默认路由、DNS 返回问题或目标网络阻断。不要仅凭 ping 结果判断 HTTPS 可用性。

二、理解 DNS64 与 NAT64 的分工

DNS64 负责合成 AAAA 记录，NAT64 负责转换数据包。当域名只有 A 记录时，DNS64 解析器可以根据 NAT64 前缀合成可路由的 IPv6 地址；客户端连接该地址后，由 NAT64 网关将 IPv6 流量转换为 IPv4。

单独配置 DNS64 不等于已经拥有 NAT64 出口。两端必须使用匹配的前缀和转换服务。常见 Well-Known Prefix 是 64:ff9b::/96，但只有网络确实提供对应 NAT64 服务时才能使用。

三、选择部署方式

方式 A：使用服务商提供的 NAT64

优先使用服务商官方地址和配置说明。确认递归 DNS、NAT64 前缀、TCP/UDP 支持范围以及流量限制。

方式 B：通过独立 NAT64 网关

如果管理多个纯 IPv6 节点，可以单独部署受控 NAT64 网关，让业务节点通过明确路由或代理访问 IPv4。网关应与业务服务隔离，限制管理面暴露，并监控连接数、带宽和日志。

方式 C：使用现成脚本

可研究 Nat64-OneClick。使用前核对脚本支持的系统版本、网络拓扑、依赖和卸载/恢复能力。仅在确认目标为纯 IPv6、且已备份路由与防火墙状态后考虑运行；不要把它用于双栈服务器。

四、上线前后验证

记录执行前的地址、路由、DNS 和防火墙规则。
确认 DNS64 对 IPv4-only 域名能返回合成 AAAA，原生 IPv6 域名解析不受影响。
用 curl -4、curl -6 分别测试目标，必要时用多个 IPv4-only 域名交叉验证。
检查软件包仓库、GitHub Release 下载等真实业务场景，不要只验证 ICMP。
观察 DNS 延迟、连接失败率、MTU/分片问题和长连接稳定性。

NAT64 不保证所有 IPv4 应用都能工作。硬编码 IPv4 地址、应用层 IP 字面量和特殊 UDP 行为可能需要额外处理。

五、回滚原则

回滚必须恢复原始 DNS、路由和防火墙状态，而不是简单删除一个软件包。先停止新服务，再按安装前备份恢复配置，最后重新执行 IPv4/IPv6 连通性测试。若脚本没有明确卸载步骤和恢复说明，不应在生产服务器上直接试跑。

对双栈机器，优先保留系统原有 IPv4/IPv6 路由策略；如果只是某个程序无法连接 IPv4-only 目标，应先检查程序代理、DNS 和目标网络，不要把整机网络改成 NAT64 架构。