大多数网站现在运行双协议栈。相同的服务器、API 或结算页面同时响应 IPv4 和 IPv6。该设置在 IPv4 地址资源紧缺时保持可达性，但同时将流量分散到两个独立故障的网络。
这带来了问题。如果您的监控仅测试 IPv4，它会报告正常，而本地 IPv6 用户却遭遇死网关、缺失的 DNS 记录或未经更新的防火墙规则。仪表板显示 100% 正常运行时间，而日益增长的用户群却报告网站断开。
本文介绍 Dotcom-Monitor 如何按自身标准测试 IPv6 路径：使用无隧道的本地 IPv6 唯一节点、浏览器脚本全部通过 IPv6 加载第三方资源，以及在 IPv4 路径正常时隔离 IPv6 故障的协议检测。
什么是 IPv6 监控？
IPv6 监控是从真实 IPv6 用户视角测试您的网站、API 和服务是否能正确响应 IPv6 请求的实践。它运行与您在 IPv4 上使用的相同可用性和性能检查——DNS 解析、页面加载、事务和协议响应——但通过 IPv6 路径，该路径拥有自己独立的 DNS 记录、路由和防火墙规则。
在同时支持双协议栈的网站上，IPv6 监控是确认 IPv6 部分正常工作的唯一方法。IPv4 检测无论 IPv6 是否健康都会通过，因此如果没有专门的 IPv6 网络监控测试，仅影响 IPv6 用户的故障会被忽视。下文将展示 Dotcom-Monitor 如何从本地 IPv6 唯一节点运行该测试，涵盖双栈环境中的正常运行时间、事务、DNS 和协议检测。
为什么双协议栈网络造成监控盲区
双协议栈服务在两个协议上响应，但 IPv4 和 IPv6 不共享路径。它们是两个路由平面。流量通过不同的 DNS 记录、不同的防火墙规则及不同的传输服务商，最终到达相同源地址。
因此请求可能在一个平面成功而另一个失败。IPv4 客户端解析 A 记录，经过您团队多年来调优的 IPv4 防火墙，成功加载页面。IPv6 客户端解析 AAAA 记录，却遭遇未完全配置的网关，导致超时。两者输入的是同一个网址，其中一个认为网站宕机。
两个协议平面在底层机制上也不同。IPv6 使用固定 40 字节基础头部、8 位流量类别字段和 20 位流标签，传输路由器对 IPv6 包处理不同于长期以来的尽力而为 IPv4 模型。单个 IPv6 子网拥有的地址远多于整个传统 IPv4 网络，这改变了路由传播和过滤规则的应用。监控的启示很简单：IPv4 结果无法可靠反映 IPv6 路径情况，必须在各自所在平面独立测试。
Dotcom-Monitor 如何运行本地 IPv6 唯一监控
Dotcom-Monitor 从全球监控网络中的真实 IPv4 和 IPv6 骨干节点运行检测。其中一些节点是双协议栈，可通过任一协议访问目标，另一些则为 IPv6 唯一。
IPv6 唯一节点之所以重要，在于它拒绝做的事。许多支持 IPv6 的网络设备还能通过如 6to4 隧道或 NAT64 的转换机制将流量返译回 IPv4。这种转换在生产环境中方便，测试时却会误导结果。双协议栈代理可能静默回退到 IPv4，报告“正常”，掩盖您正寻找的具体故障。
IPv6 唯一节点不进行转换。它仅发送和接收 IPv6 流量。当该节点检测通过，目标确实已通过原生 IPv6 响应。当检测失败，则发现了真正的 IPv6 故障，而非被回退掩盖的假象。
在本地 IPv4 节点和本地 IPv6 唯一节点分别运行相同检测，能清晰对比两个平面变化。两者结果间的任何差距都是特定 IPv6 问题，而非测量噪声。
这一基线分割覆盖平台所有设备类型。Web Applications 监控通过浏览器脚本执行业务交易。Web Pages 监控同样加载单页。Internet Infrastructure 监控针对服务器协议运行检测。Web Services 监控验证 API。每种监控都可固定使用 IPv6 唯一节点，且两类浏览器设备均使用EveryStep 脚本工具记录，您可任意节点重放整条路径。
用真实浏览器监控捕获第三方 AAAA 幽灵
您的源站可能完美支持 IPv6，但 IPv6 用户访问页面仍会出错。原因是您未托管的内容。现代页面会引入 CDN、网页字体、分析标签、聊天组件、支付处理器。IPv6 唯一用户加载页面时，浏览器也会试图全部通过 IPv6 获取这些资源。
如果某第三方未发布 AAAA 记录或丢弃 IPv6 包，浏览器会在该资源处挂起，等待连接超时，其它内容加载也会停滞。表现为页面半加载：导航缺失、资源框空白、结账按钮无响应。内部健康仪表盘始终绿灯，因为源站正常。故障存在于他人网络。
同一页面，两条路径：IPv6 唯一路径中第三方无 AAAA 记录资源超时。
Web Applications 监控通过真实浏览器从 IPv6 唯一节点加载完整页面，记录瀑布流中的每个请求来捕获此类问题。对于单页检测，Web Pages 监控同理。非单一的通过/失败结果，而是显示哪些资源解析成功、哪些超时、渲染什么时候卡住。下表展示了具体模式。
| 测试场景 | 核心 HTML | CDN 和媒体资源 | 第三方脚本 | 用户所见 |
|---|---|---|---|---|
| IPv4 监控 | 解析成功（A 记录） | 解析成功 | 解析成功 | 页面完整正常渲染。 |
| IPv6 唯一监控 | 解析成功（AAAA 记录） | 解析失败 | 超时 | 部分加载：布局混乱，空白框，结账卡顿。 |
以结账流程为例。Web Applications 脚本登录、添加商品、进入支付步骤。IPv4 路径全部通过。IPv6 唯一节点上支付处理脚本无 AAAA 记录，浏览器无法加载该脚本，表单无法使用。脚本在此处失败，并报告问题资源。传统域名的可用性探测不会提示任何结账异常。用合成监控脚本化检测，则将“网站在线”转变为“客户真的能支付”。
互联网基础设施监控如何隔离 IPv6 协议故障
浏览器检测捕获用户层面表现，还需关注底层。互联网基础设施监控每分钟甚至更频繁在 IPv6 唯一节点运行协议级检测。
这种高频和隔离很关键。如果您的 HTTP/S 或 DNS 端点通过 IPv4 响应正常，但 IPv6 上出错，该监控能独立报告 IPv6 协议错误，而非被 IPv4 的正常结果平均掩盖。Web Services 监控对 API 端点做相同处理。您将获得明确命名协议和路径的警报，而非模糊的“响应时间变差”。
DNS 检测值得单独关注。双协议栈网站需同时有全球范围内解析速度匹配的 A 和 AAAA 记录，失效或缺失的 AAAA 记录是 IPv6 常见故障之一。DNS 监控确认两个记录无处不达，监视 TTL 变化，确保迁移时 IPv6 用户不会被停留在无效条目。一旦报警，自动触发IPv6 路由跟踪，定位故障点是位于源站还是上游运营商。
Dotcom-Monitor 如何发现 Happy Eyeballs 延迟问题
有些 IPv6 问题不会表现为宕机，而表现为网站感觉缓慢，但原因无人能确定。常见原因是 Happy Eyeballs。
Happy Eyeballs（RFC 8305）是浏览器的回退机制。浏览器首先尝试 IPv6 连接，等待一个短时间间隔（默认约 250 毫秒的连接尝试延迟），然后并发尝试 IPv4。如果 IPv6 路径断开或缓慢，IPv4 连接胜出并承载请求。连接最终成功，用户很少看到错误。
这对用户有利，隐蔽了您的可见性。等待浏览器放弃 IPv6 依赖 IPv4 的这段时间，加入真实的首字节时间和最大内容绘制时间。每个 IPv6 用户都为最终通过 IPv4 成功的连接支付了一笔延迟“税”。被动工具和真实用户数据记录认为加载成功，忽略了结构性故障，体验缓慢却不显山露水。
原生 IPv6 唯一监控直接测量这笔延迟税，因为没有备用通道隐藏。IPv6 路径要么表现正常，要么不行，数据清晰反映在报告中。并排的瀑布流报告并列 IPv4 和 IPv6 的时序，让用户感觉但说不清原因的 250 毫秒差距成为您可指认的数据线。如果需要复习瀑布图读取方法，请参考我们的瀑布图优化指南。
如何在 Dotcom-Monitor 中设置双协议栈监控
这是让您获得两个协议平面数据而不增加维护工作的设置步骤。
- 步骤 1：用 EveryStep 脚本创建检测。录制关键路径或协议检测一次。相同脚本适用全地点，无需维护独立 IPv4 和 IPv6 版本。
- 步骤 2：分配原生 IPv4 和 IPv6 唯一节点。将检测分配到原生 IPv4 节点和 IPv6 唯一节点。IPv6 基线节点跳过 6to4 和 NAT64，保证无转换在节点与目标间。
- 步骤 3：设置检测频率。互联网基础设施协议检测频率可设到每分钟一次。Web Applications 浏览器检测按 SLA 设定间隔执行。
- 步骤 4：添加 A 和 AAAA 记录 DNS 检测。确认两个记录全局解析速度匹配，关注 TTL 变化，避免迁移时 IPv6 用户停留无效路由。
- 步骤 5：出现异常时触发 IPv6 路由跟踪。设置警报一旦可用性或响应时间下降即触发路由跟踪，快速分辨源站故障和上游故障。
- 步骤 6：对比两个瀑布流。并排查看 IPv4 与 IPv6 报告，任何资源、跳点或协议差异均是 IPv6 特定问题。
总结
双协议栈意味着每个请求有两条路径可达，也有两条路径可能出问题。仅用 IPv4 监控监视其中一条却报告两条情况，导致网站拿下完美正常时间记录，而 IPv6 用户却遇到超时、加载不完全及无法追踪的延迟惩罚。
Dotcom-Monitor 基于原生 IPv6 唯一节点无隧道，Web Applications 浏览器脚本通过 IPv6 加载每个第三方资源，互联网基础设施协议检测频率高达每分钟一次，并列瀑布图明确区分源站故障与上游故障，从而填补这一盲区。您无需猜测 IPv4 检测未触及的那一半流量。
