IPv6 网站访问异常怎么查？DNSPup 双栈检测、DNS 与端口排障指南
网站增加 IPv6 记录后，部分用户可能访问变快，也可能出现"IPv4 正常、IPv6 超时"的隐蔽故障。浏览器会在多个地址之间选择，单一探针和单一运营商无法代表所有情况。本文从 A/AAAA 记录、双栈连接、证书、端口、路由和应用层六个角度，给出一套小白可以执行、团队可以自动化的排障方法，并说明如何借助 DNSPup 的 IPv6、DNS、Ping、TCPing、MTR 和网页监控建立证据链。
一、为什么 IPv6 故障容易被忽略
很多监控只测试 A 记录，站点新增 AAAA 后却没有同步检查防火墙、负载均衡和源站监听。支持 IPv6 的客户端可能优先连接 AAAA，遇到黑洞路由后等待回退；不支持 IPv6 的客户端则完全看不到问题。于是同一个域名在办公室、家庭宽带和云服务器上表现不同。
双栈排障要回答三个问题：DNS 是否返回了正确的 A 和 AAAA，IPv4/IPv6 是否都能建立 TCP/TLS 连接，应用在两条路径上的响应内容是否一致。不能只用"ping 通"判断网站可用，也不能因为某个公共解析器返回了记录就认为所有地区都已生效。
二、准备一份双栈验收表
上线前把域名、A 记录、AAAA 记录、监听端口、证书 SAN、源站地址、CDN 配置和回滚时间写入验收表。对主站、API、静态资源和健康接口分别测试。每项记录检测节点、网络类型、解析答案、连接时间、HTTP 状态码和正文关键字，避免只保留截图。
DNSPup 可以先从 DNS 检测开始，再分别进行 IPv4 和 IPv6 Ping、TCPing、网页测速与 MTR。免费体验监控覆盖 IP、DNS、端口、证书和网页，适合把上线前的临时验收转成持续监控。测试对象必须是自有或明确授权的域名与服务器。
三、检查 A/AAAA 记录
先确认记录名称、TTL、CNAME 链和权威 DNS。若域名经过 CDN，用户最终看到的地址可能不是源站地址；这并不代表解析错误。多地检测时重点观察答案集合是否符合预期，是否存在某个区域残留旧地址，是否只有 AAAA 指向了已经下线的负载均衡。
记录变更期间不要频繁来回切换。TTL 只是缓存上限，不代表所有递归解析器会在同一秒刷新。DNSPup 的多地区结果应与权威查询、运营商递归结果和本地缓存一起分析。若只有一个探针拿到旧答案，先确认查询时间、递归服务器和 TTL，再决定是否回滚。
四、验证 IPv6 路径
IPv6 地址格式长且容易复制错误，检查时要确认压缩写法、前缀长度和是否误把内网地址发布到公网。源站网卡、云安全组、主机防火墙、负载均衡监听和容器网络都要允许目标端口。TCPing 成功只能证明端口可建立连接，仍需继续验证 TLS 和 HTTP。
使用 MTR 或 Traceroute 时，要区分中间路由器不响应和真实丢包。某一跳显示 100% 丢包而后续仍然正常，并不一定是故障；如果丢包从某一跳开始并持续到目标，且网页体验也异常，才有更强的关联证据。晚高峰和不同运营商的路径可能变化，应采用时间序列而不是一次结论。
五、证书和 Host 头
IPv4 与 IPv6 可能落到不同的入口，证书却必须同时覆盖访问域名。检查证书的 SAN、有效期、签发链和 SNI，不能只看 IP 直接访问得到的证书。对于 CDN 或反向代理，测试请求必须带正确的 Host 头，否则返回的可能是默认站点。
如果 IPv6 返回 421、403 或 404，而 IPv4 是 200，优先比较入口配置和路由规则；如果 TCP 连接成功但 TLS 超时，检查 IPv6 监听、证书链和 MTU。DNSPup 的证书与网页监控可以提供连续证据，避免只在故障时手动查询。
六、双栈结果归一化
报告中不要把 IPv4 和 IPv6 混成一个平均耗时。至少按照 family、probe、resolved_ip、dns_ms、connect_ms、tls_ms、ttfb_ms、total_ms 和 error_code 分组。若一组没有 IPv6 能力，应标记为"不支持"而不是"失败"，否则可用率会被错误拉低。
建议为错误定义固定枚举：NO_AAAA、NO_ROUTE、TCP_TIMEOUT、TLS_NAME_MISMATCH、HTTP_STATUS、CONTENT_MISMATCH 和 UNKNOWN。每次告警同时给出地址族、节点和时间，值班人员才知道应该检查 DNS、网络还是应用。
七、用 API 接入持续检测
DNSPup Customer API v1 的文档入口是 https://dnspup.com/api.html。调用时使用 X-API-Key 和 X-API-Secret，并按账户配置固定公网 IP 或完整服务器域名来源白名单。密钥只能在后端使用，不能放在前端代码、文章示例或公共仓库。API 客户端应实现超时、幂等、重试上限和请求 ID 关联。
一个双栈检测任务可以在内部记录 target、families、probe_group、deadline 和 consent_ref。结果回写时，将 IPv4/IPv6 分成两条记录，前端再根据地址族展示趋势。对于 API 响应中的 IP、ASN 和位置数据，注明数据源与更新时间，不把地理数据库结果当作绝对事实。
八、常见故障案例
案例一：AAAA 指向新负载均衡，但安全组未开放 443。DNS 看起来正确，IPv6 TCPing 超时，IPv4 正常。修复安全组并复测即可。案例二：IPv6 入口使用了旧证书，TLS 报主机名不匹配。更新证书链并清理入口缓存。案例三：IPv6 页面返回 200，但静态资源仍解析到不可达地址，页面出现白屏。需要把资源域名也加入双栈监控。
案例四：移动网络 IPv6 访问慢，云服务器探针正常。MTR 显示某运营商在高峰期拥塞，应与运营商或 CDN 讨论路由和接入区域，而不是简单删除 AAAA。每个案例都要同时保存 DNS、TCP、TLS 和 HTTP 证据，避免只凭感觉修改记录。
九、上线与回滚
灰度开启 AAAA 时，先为测试域名和少量地区配置，再逐步扩大。观察至少一个完整高峰周期，重点看 IPv6 失败率、回退比例、证书错误和静态资源成功率。回滚前记录当前 TTL 与权威答案，回滚后继续保留 IPv6 监控一段时间，确认旧路径没有隐藏问题。
十、安全与合规
只检查自己负责的域名、IP 和端口，不进行大范围地址扫描。日志隐藏真实用户参数、令牌和内部主机名；分享报告时可以保留地址族和自治系统，但不展示家庭节点精确位置。对于监控 API，使用最小权限、来源白名单、密钥轮换和审计日志。
总结
IPv6 网站排障需要把 DNS、地址族、端口、TLS、路由和应用内容分层验证。DNSPup 的双栈检测、免费体验监控、300+ 家宽节点以及 Customer API v1，可以帮助站长持续比较 IPv4/IPv6 的真实可用性。上线前建立基线，故障时按证据顺序排查，才能避免用一次 ping 结果做出错误结论。
本文关键词：IPv6 网站检测、IPv4 IPv6 双栈排障、AAAA 记录检查、IPv6 端口测试、DNSPup IPv6、网站可用性监控。
附录：双栈上线前逐项检查
可以按以下顺序操作：确认权威 DNS 上的 A、AAAA、CNAME 与 TTL；确认 AAAA 使用的是公网地址而不是 ULA 或链路本地地址；确认源站和负载均衡同时监听 IPv4 与 IPv6；确认云安全组、主机防火墙和容器网络放行业务端口；确认 IPv6 入口使用正确的 SNI 和证书链；确认 CDN、WAF 与回源策略没有把两个地址族分到不同应用；确认静态资源、API 和健康接口都可用；最后从支持 IPv6 的家庭节点、移动网络和云机房分别复测。
每项结果都保存检测时间和节点。若某个节点不支持 IPv6，要记录"不支持能力"，不要记作站点失败。若 IPv6 能建立 TCP 但网页内容错误，要将问题归类为应用或入口配置，而不是网络不可达。上线期间保留旧的 IPv4 监控，双栈稳定后也不要删除，因为回退路径仍可能承担大量请求。
附录：如何阅读双栈指标
DNS 耗时高而连接耗时正常，通常先检查递归服务器或缓存；DNS 正常但 TCP 超时，重点检查路由、ACL 和端口监听；TCP 正常而 TLS 失败，检查证书、SNI、时间和 MTU；TLS 正常而 HTTP 状态码异常，查看 Host、WAF 和应用路由；状态码正常而正文不匹配，检查 CDN 缓存、错误兜底页和资源域名。把指标按层次阅读，比直接删除 AAAA 更安全。
附录：回滚注意事项
如果必须临时删除 AAAA，先确认 TTL 和权威服务器，保留变更前后的截图与记录。删除后继续观察 IPv4 的成功率、连接耗时和证书，不能把 IPv6 问题掩盖成"恢复正常"。修复完成后先用测试域名重新灰度，再扩大到主域名。所有操作写入变更单，方便以后追查。
十一、IPv6 与 CDN 回源的特殊检查
很多站点的 IPv6 只到达 CDN，CDN 回源仍然使用 IPv4。此时用户侧 IPv6 正常，并不代表源站已经具备 IPv6 服务能力。验收时要分别测试用户到 CDN、CDN 到源站以及源站健康检查三段路径。若 CDN 节点能够返回页面，但回源偶发 502，应比较 IPv4 与 IPv6 回源策略、连接池、Host 头和超时设置。
静态资源域名也要单独检查。主页面通过 IPv6 返回 200，而脚本、字体或图片的 AAAA 指向旧入口，浏览器可能表现为白屏或功能不可用。把关键资源的域名加入 DNSPup 网页或 DNS 监控，设置正文关键字和资源数量检查，能够比单独检查主域名更早发现问题。
十二、家庭网络的双栈差异
家庭宽带可能使用原生 IPv6、隧道、NAT64 或完全没有 IPv6。一个城市内不同运营商的前缀、路由和 MTU 也可能不同。报告要把"节点不支持 IPv6""节点支持但目标不可达""目标可达但应用错误"分开统计，不能把所有失败都归结为网站配置。多节点观察至少覆盖一个工作日和一个晚高峰，结论才有稳定性。
十三、IPv6 监控的日常维护
证书续期、CDN 规则、负载均衡扩容和云安全组变更都可能只影响一个地址族。每次发布流程都要同时触发 IPv4、IPv6 的网页和端口复测。每周审阅 AAAA 答案是否仍属于批准范围，检查 IPv6 失败率和回退比例有没有缓慢上升。发现趋势变化时先保留证据和变更记录，再联系网络或云平台负责人。
对用户反馈"部分地区打不开"的工单，不要只让用户刷新 DNS。记录用户网络类型、发生时间、浏览器错误和地址族能力，在授权范围内使用相近地区节点复现。通过 DNSPup 的多地区结果与 MTR 路径，可以判断是区域递归缓存、运营商路由还是站点入口配置，避免给出无根据的结论。
如果团队暂时没有 IPv6 用户样本，也可以先把双栈检测作为上线门禁。每次证书续期、CDN 切换和安全组变更后自动跑一轮 IPv4/IPv6 对比；只有两种地址族均满足状态码、正文、证书和端口条件，变更才进入下一阶段。门禁失败时先确认属于节点能力、DNS、路由、端口、证书还是应用内容，再由对应负责人处理，不要直接删除 AAAA。
将门禁结果保存到发布记录中，并保留检测节点、地址族、解析答案和请求时间。后续如果出现回归，可以直接判断是发布变更还是网络环境变化。对于无法支持 IPv6 的节点，标记能力限制；对于支持 IPv6 但目标不可达的节点，进入故障流程，两个状态不能混用。
门禁结果还可以作为证书续期、CDN 切换和云安全组变更的共同验收项。每次变更完成后，用同一批地区和同一组指标复测，结果写入发布记录；若指标只在某个地址族偏离，责任范围就能快速缩小。