文章
文章文档网址导航

云服务器要不要开启 IPv6？双栈访问、DNS、CDN 与防火墙配置说明

云服务器开启 IPv6 前，应先确认 CDN、源站、路由、Web 监听、防火墙和监控是否形成完整链路。本文说明双栈部署、AAAA 记录发布、分链路测试与回滚方法。

云服务器是否要开启 IPv6，不能只看控制台里有没有分配 IPv6 地址。更实际的判断是：你的用户、CDN、源站和运维工具是否已经形成一条可验证、可回滚的 IPv6 访问链路。

如果网站已经接入支持 IPv6 的 CDN，而 CDN 仍通过 IPv4 回源，访客通常已经可以用 IPv6 访问网站，此时源站不必为了“支持 IPv6”立刻开放公网 IPv6。反过来，如果网站没有 CDN、需要让 IPv6-only 网络直接访问源站，或者希望减少对 IPv4 地址的依赖，就值得部署 IPv4/IPv6 双栈。

最重要的一条原则是：不要先添加 AAAA 记录，再慢慢修服务器。 AAAA 一旦对外生效，部分用户就会尝试走 IPv6。若路由、监听端口、防火墙或证书链路有一处没有准备好，网站可能不是完全打不开，而是只在部分网络、部分设备上间歇性变慢或失败。

云服务器要不要开启 IPv6？双栈访问、DNS、CDN 与防火墙配置说明

先分清三种“支持 IPv6”

网站链路中的 IPv6 至少可以分成三层：

  1. 访客到 CDN 使用 IPv6：DNS 返回 CDN 的 IPv6 地址，访客通过 IPv6 连接边缘节点，CDN 再用 IPv4 或 IPv6 回源。
  2. CDN 到源站使用 IPv6：源站向 CDN 提供可访问的 IPv6 地址，回源链路也走 IPv6。
  3. 访客直接访问源站 IPv6：没有 CDN 代理，或某个不经过 CDN 的子域名直接把 AAAA 指向云服务器。

这三种情况不能混为一谈。很多 CDN 可以在源站只有 IPv4 的情况下，为访客提供 IPv6 访问。Cloudflare 的官方文档也说明，其 IPv6 兼容功能可以在边缘接收 IPv6 请求，并兼容仅支持 IPv4 的源站。是否需要给源站开 IPv6，应根据回源需求、可用性目标和运维能力决定，而不是只看前台检测工具是否显示“支持 IPv6”。

适合暂缓源站 IPv6 的情况包括：

  • CDN 已经覆盖公网访问，源站只允许 CDN 回源
  • 当前监控、备份、面板或安全设备还不能完整处理 IPv6
  • 云服务商没有提供稳定前缀、默认网关或清晰的安全组规则
  • 团队暂时无法分别验证 IPv4 和 IPv6

适合部署双栈的情况包括：

  • 网站或 API 需要被 IPv6-only 网络直接访问
  • 不使用 CDN，用户会直接连接源站
  • 需要给源站、负载均衡或容器平台建立完整的 IPv6 网络
  • 希望提前完成双栈改造，并能持续监控两条链路

开启前先确认地址、前缀和默认路由

云平台显示“已分配 IPv6”不等于操作系统已经能正常访问公网。先从服务商文档或控制台确认以下信息：

  • 分配的是单个 IPv6 地址还是一个前缀
  • 地址是自动配置、DHCPv6 下发，还是需要手动写入系统
  • 默认网关如何配置
  • 是否需要在虚拟网络、子网或网卡层单独启用 IPv6
  • 公网 IPv6 是否还受云防火墙、安全组或网络 ACL 控制
  • IPv6 流量是否单独计费

在 Linux 上可以先查看地址和路由：

ip -6 addr show
ip -6 route show

正常情况下，网卡上应有可用于公网通信的全局 IPv6 地址，并存在默认路由。只有 fe80::/10 范围的链路本地地址，通常不足以让公网用户访问网站。

再测试服务器主动访问 IPv6 站点：

ping -6 -c 4 2606:4700:4700::1111
curl -6 -I https://www.cloudflare.com/

示例地址和域名仅用于连通性测试。若这里失败，不要继续添加 AAAA 记录，应先检查云平台路由、系统网络配置和出站规则。

用于网站 DNS 的应是稳定地址。不要把操作系统为了客户端隐私生成、可能定期变化的临时 IPv6 地址写进 AAAA 记录。地址变更策略还要与云主机重建、网卡更换和实例迁移方式一起确认。

Web 服务必须明确监听 IPv6

服务器能访问 IPv6 网络，不代表 Nginx、Apache 或应用进程已经监听 IPv6。先检查当前端口：

ss -lntp

Nginx 的站点配置通常需要同时包含 IPv4 和 IPv6 监听，例如：

server {
    listen 80;
    listen [::]:80;

    listen 443 ssl;
    listen [::]:443 ssl;

    server_name example.com www.example.com;
}

修改后先检查配置，再平滑重载：

nginx -t
systemctl reload nginx

不同操作系统和 Nginx 构建对双栈套接字的处理可能不同，ipv6only 的默认行为也可能受平台影响。不要因为看到 [::]:443 就直接假定 IPv4 一定同时可用，最好明确保留 IPv4 与 IPv6 两组监听，并用 curl -4、curl -6 分别验证。

如果前面还有负载均衡、反向代理、容器端口映射或面板生成的配置，也要逐层检查。常见问题是宿主机已经监听 IPv6，但容器只绑定 IPv4；或者负载均衡支持 IPv6，后端健康检查仍指向错误端口。

防火墙要同时检查云端和系统端

IPv4 规则不会自动等价地保护 IPv6。启用 IPv6 后，至少要检查以下位置：

  • 云平台安全组
  • 子网网络 ACL 或云防火墙
  • 系统的 nftables、ip6tables、firewalld 或 ufw
  • 主机面板生成的规则
  • CDN 源站白名单和回源端口

对普通网站，通常只需要向公网开放确实使用的端口，例如 TCP 80 和 443。SSH、数据库、面板和监控端口应继续限制来源，不能因为新增 IPv6 就变成任意地址可访问。

尤其不要用“全部丢弃 ICMPv6”作为简单加固手段。IPv6 的邻居发现、错误报告和路径 MTU 发现依赖 ICMPv6。RFC 4890 专门给出了 ICMPv6 过滤建议：应按类型和场景制定规则，而不是一刀切地禁止。错误过滤可能表现为小请求正常、大响应或特定路径卡住，排查起来比端口完全不通更困难。

如果使用 nftables，先查看现有规则集和计数器，再按发行版及当前策略修改：

nft list ruleset

不要直接复制陌生服务器的整套防火墙命令。规则表名、链名、默认策略和管理工具不同，盲目覆盖可能同时中断 IPv4、IPv6 和远程管理连接。

AAAA 记录应当最后添加

完成地址、路由、监听、防火墙和 TLS 检查后，再为需要直连 IPv6 的域名添加 AAAA 记录。A 记录继续指向 IPv4，AAAA 记录指向稳定的 IPv6 地址，形成双栈解析。

查询结果可以分别检查：

dig +short A example.com
dig +short AAAA example.com

如果域名接入了代理型 CDN，不要擅自把 AAAA 直接指向源站，否则可能绕过 CDN、防护和缓存。应先确认 DNS 记录是否由 CDN 代理、CDN 是否自动发布边缘 IPv6 地址，以及源站地址是否应保持隐藏。

上线前可以适当降低相关记录的 TTL，给回滚留出时间。TTL 不是越低越好，变更结束并稳定观察后，应恢复为正常值，减少不必要的 DNS 查询压力。

IPv4 和 IPv6 必须分开验收

只在浏览器里刷新一次不能证明双栈正常。现代客户端可能使用 Happy Eyeballs 一类机制，在 IPv6 和 IPv4 之间快速选择能工作的连接，因此 IPv6 已经故障时，用户仍可能因为回退到 IPv4 而感觉“基本能开”。不同网络和客户端的回退速度并不完全一致，故障可能只表现为首屏偶尔慢几秒。

建议至少执行以下测试：

curl -4 -I https://example.com/
curl -6 -I https://example.com/

检查两次请求的状态码、重定向、证书、Server Name Indication 和最终页面是否一致。还可以继续检查路径：

ping -6 example.com
traceroute -6 example.com
tracepath6 example.com

测试应覆盖不同网络，例如本地宽带、手机网络和一台外部云主机。若网站经过 CDN，还要分别验证访客到 CDN、CDN 到源站，以及绕过 CDN 的内部健康检查链路。

监控也要区分地址族。只监控域名而不固定 IPv4 或 IPv6，可能让探针每次都走健康的那条链路，从而漏掉另一条链路的故障。至少应分别记录：

  • IPv4 和 IPv6 的 DNS 解析结果
  • TCP 连接和 TLS 握手时间
  • HTTP 状态码与关键页面内容
  • IPv6 丢包、路径变化和失败率
  • CDN 的 IPv4/IPv6 请求及回源统计

出现间歇性打不开时怎么判断

双栈上线后，最典型的问题不是所有用户同时失败，而是“公司网络正常，手机网络慢”“部分地区打不开”“第一次很慢，刷新又好了”。可以按以下顺序定位：

  1. 查询域名是否已经返回 AAAA，以及 AAAA 是否指向预期的服务器或 CDN。
  2. 在故障网络上强制使用 curl -6，确认问题是否只出现在 IPv6。
  3. 检查云安全组与系统防火墙是否同时允许 80、443 和必要的 ICMPv6。
  4. 检查 Nginx 或应用是否真正监听 [::]:80、[::]:443。
  5. 检查 IPv6 默认路由、路径 MTU 和回程路由。
  6. 检查 CDN 是否错误地把源站 AAAA 当作回源地址，或健康检查是否失败。

若需要紧急恢复，优先移除有问题的 AAAA 记录或暂停对应的 IPv6 代理入口，让客户端只获得已经验证的 IPv4 路径。不要先删除服务器地址或重写整套网络配置，否则在 DNS 缓存尚未过期时，仍有用户会继续访问旧 IPv6 地址。

一份可执行的上线清单

  • 已确认云服务商提供的 IPv6 前缀、地址、网关、路由和计费方式
  • 操作系统存在稳定的全局 IPv6 地址与默认路由
  • Web 服务、反向代理和容器均监听 IPv6
  • 云安全组和系统防火墙都已配置 IPv6 规则
  • 没有一刀切地阻断 ICMPv6
  • HTTPS 证书和虚拟主机在 IPv6 访问时正常
  • 已用 curl -4 和 curl -6 分别测试
  • CDN 代理、回源方式和源站暴露范围已经确认
  • AAAA 记录在所有链路准备完成后才发布
  • 已建立独立的 IPv4、IPv6 监控和回滚方案

对多数已有网站，合理路线不是立即改成 IPv6-only，而是先保持 IPv4 可用，再逐步补齐 IPv6，形成可观察、可回退的双栈环境。如果 CDN 已经为访客提供 IPv6，而源站 IPv4 运行稳定，可以先完善监控和安全策略，再决定是否开放源站 IPv6。真正需要避免的，不是“暂时没有 IPv6”，而是发布了 AAAA，却没有把路由、监听、防火墙、TLS 和监控一起纳入上线流程。

参考资料

资料核验日期：2026-09-29。

实操指南网络

网站迁移后邮件总进垃圾箱？SPF、DKIM、DMARC 与 PTR 记录配置指南

2026-9-28 15:57:15

WordPress实操指南

WordPress 数据库为什么越来越大？修订版本、Transient 与日志表清理方法

2026-9-29 14:39:34