为什么 IPv6 地址正常，网站还是打不开
很多站长在 [VPS](https://cn.hostease.com/vps/)（[虚拟专用服务器](https://cn.hostease.com/vps/)）控制台里看到 IPv6 地址已经分配，执行 ip -6 addr 也能看到全局地址，却发现浏览器访问域名仍然超时。这个问题通常不是单点故障，而是“地址、路由、DNS（域名系统）、防火墙、Web 服务监听”五个环节里有一处没有闭合。本文不再重复基础开启流程，而是教你如何按排障顺序定位卡点。
建议先把现象拆成两类：第一类是服务器自己不能访问外部 IPv6，例如 ping6 2001:4860:4860::8888 失败；第二类是服务器能出站，但外部用户访问你的网站失败。前者重点查默认路由和网关，后者重点查 DNS、端口放行和 Nginx/Apache 监听。按这个顺序查，可以避免一上来就改配置文件导致问题变多。
如果你使用的是 Hostease VPS 或其他支持原生 IPv6 的[云主机](https://cn.hostease.com/vps/)，排障逻辑基本一致。生产环境操作前，建议先记录当前 IP、网关、防火墙规则和 Web 服务配置，方便回滚。
先判断问题在服务器出站还是外部入站
排查 IPv6 时，不要只看“有没有地址”。地址存在只能说明网卡层面拿到了配置，不代表默认路由、邻居发现和防火墙都正常。先在服务器上执行三条命令：
ip -6 addr show
ip -6 route show
ping6 -c 3 2001:4860:4860::8888
第一条确认是否有 scope global 的 IPv6 地址；第二条确认是否有 default via 或 default dev 的默认路由；第三条验证服务器是否能访问公网 IPv6。若 ping6 返回 Network is unreachable，通常是默认路由缺失，而不是 DNS 问题。
一个常见误区是把 fe80:: 开头的链路本地地址当成公网地址。链路本地地址只能在同一二层网络里通信，不能直接用于公网访问。你需要看到类似 2001:db8::/32 示例格式的全局地址；实际地址以服务商分配为准，不要照抄示例网段。
路由和网关：最容易被忽略的第一处故障
如果服务器已有全局 IPv6 地址，但公网测试失败，先看路由表。正常情况下，路由表里应至少有一条默认路由：
ip -6 route show | grep default
若没有输出，可以临时添加一条默认路由做验证：
sudo ip -6 route add default via 2001:db8:1::1 dev eth0
ping6 -c 3 2001:4860:4860::8888
这里的 2001:db8:1::1 是文档示例地址，必须替换为控制台或服务商邮件中提供的 IPv6 网关。若临时路由添加后连通性恢复，说明问题在持久化网络配置，而不是服务端应用。
Ubuntu 22.04/24.04 通常通过 Netplan 保存路由，配置片段可参考：
network:
version: 2
ethernets:
eth0:
dhcp4: true
addresses:
- "2001:db8:1::10/64"
routes:
- to: "::/0"
via: "2001:db8:1::1"
保存后先执行 sudo netplan try，确认不会断连再应用。Debian 传统网络配置、CentOS 旧版本的 ifcfg-eth0 也要写入默认网关，否则重启后临时路由会消失。更多基础服务器运维思路可参考 服务器管理教程。
DNS AAAA 记录：域名无法访问时必须单独验证
服务器可以访问外部 IPv6 后，下一步才检查域名解析。很多“IPv6 已配置但网站打不开”的案例，实际上是 DNS（域名系统）没有添加 AAAA 记录，或者 AAAA 记录指向了旧地址。
dig AAAA example.com +short
curl -6 -I https://example.com
如果 dig 没有返回 IPv6 地址，说明域名还没有指向服务器。此时应进入域名解析面板添加 AAAA 记录，主机记录一般为 @ 或 www，记录值填写服务器的全局 IPv6 地址。建议把 TTL 设置为 300 秒，便于排障期间快速调整。
如果 dig 返回了地址，但 curl -6 超时，需要继续判断是端口没通还是 Web 服务没监听。可以在另一台支持 IPv6 的机器上测试：
nc -6 -vz example.com 443
nc -6 -vz example.com 80
端口连接失败通常指向防火墙、安全组或应用监听问题。若你同时维护 WordPress 站点，可结合 WordPress 教程栏目 一并确认域名解析和 HTTPS 证书是否同步更新。
防火墙、安全组与 Web 服务监听要一起查
IPv4 能访问不代表 IPv6 也被放行。Linux 本机防火墙、云平台安全组和 Web 服务监听是三层独立开关，只要有一层漏掉 IPv6，外部访问就会失败。
先检查本机防火墙规则：
sudo ip6tables -L -n
sudo nft list ruleset | grep -i inet -A 20
sudo ufw status verbose
如果使用 UFW，要确认 /etc/default/ufw 中存在 IPV6=yes，然后重新加载规则：
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
sudo ufw reload
接着检查 Web 服务是否监听 IPv6。Nginx 需要包含 IPv6 监听：
listen [::]:80;
listen [::]:443 ssl http2;
Apache 则可检查是否有：
Listen [::]:80
Listen [::]:443
修改配置后，不要直接重启生产服务，先运行语法检查：
sudo nginx -t
sudo apachectl configtest
如果语法检查通过，再重载服务。对于安全组，确认入站规则同时放行 IPv6 来源，例如 ::/0 到 80/443 端口；只写 0.0.0.0/0 只代表 IPv4。
用一张排障表快速定位责任点
当你已经执行过前面的命令，可以把结果放进下面这张表来判断下一步，而不是反复猜测：
| 现象 | 优先检查 | 验证命令 | 常见修复 |
|---|---|---|---|
| 没有全局 IPv6 地址 | 服务商分配与系统网卡 | ip -6 addr |
申请地址段或写入静态地址 |
| 提示 Network is unreachable | 默认路由 | ip -6 route |
补充 IPv6 网关并持久化 |
| 域名没有 IPv6 结果 | AAAA 记录 | dig AAAA |
添加或修正解析记录 |
| 端口超时 | 防火墙和安全组 | nc -6 -vz |
放行 80/443 的 IPv6 入站 |
| 端口通但页面异常 | Web 服务与证书 | curl -6 -I |
检查监听、[虚拟主机](https://cn.hostease.com/web-hosting/)和 HTTPS 证书 |
如果你的站点使用 CDN（内容分发网络），还要确认 CDN 控制台是否启用了 IPv6 访问，以及源站是否允许 CDN 的 IPv6 回源地址。排障时可以先临时关闭代理，只测源站直连，确认源站没问题后再恢复 CDN 配置。
生产环境排障的安全建议
IPv6 排障涉及网络配置，错误操作可能导致 SSH 断连。建议使用以下安全流程：先开启一个保持登录的 SSH 会话，再新开一个窗口修改配置；每次只改一个变量，例如只改路由或只改防火墙；修改后立即用外部 IPv6 网络测试，不要一次性改完所有文件。
对于线上业务，推荐把关键命令输出保存下来，例如：
ip -6 addr show > ipv6-before.txt
ip -6 route show >> ipv6-before.txt
sudo ip6tables -L -n >> ipv6-before.txt
这样即使排障过程中出现异常，也能快速对比修改前后的差异。若你需要从零搭建环境，可以先阅读 网站性能优化指南，把系统、域名和站点访问速度按顺序检查，再进入 IPv6 优化阶段。
总结：按链路排查，不要只盯着地址
IPv6 故障排查的关键，是把“有地址”拆成“地址有效、路由可达、DNS 正确、端口放行、服务监听”五个可验证环节。建议每一步都用命令确认结果：ip -6 addr 看地址，ip -6 route 看路由，dig AAAA 看解析，nc -6 看端口，curl -6 看最终 HTTP 响应。
如果你需要稳定的双栈运行环境，可以优先选择原生支持 IPv6、控制台信息清晰、工单能提供网关与安全组说明的 VPS（虚拟[专用服务器](https://cn.hostease.com/dedicated-server/)）方案。已经上线的网站则建议先在低流量时段完成 IPv6 排障和验证，再把结果纳入日常监控，避免问题只在部分地区或部分运营商网络中暴露。