多地区IPv6优先导致海外访问抖动，想请教排查顺序

最近在做一个面向东南亚和欧洲用户的小站，发现海外访问有明显的间歇性抖动：同一运营商下，白天首包正常，晚高峰偶发 3 到 8 秒超时，刷新后又恢复。现象主要出现在启用 IPv6 优先的终端，强制走 IPv4 后成功率会高一些，但延迟并不稳定。

我目前已经排除了源站 CPU、内存、磁盘和应用层慢查询，CDN 回源日志也没看到明显峰值，TLS 握手时间偶尔偏高。DNS 采用双栈解析，TTL 设得比较短，部分地区会命中不同边缘节点。怀疑点有三类：一是本地运营商到上游的 IPv6 路由绕路，二是 PMTU/分片问题，三是 Happy Eyeballs 策略导致的表现差异。

想请大家帮忙给一个更稳妥的排查顺序：如果要在不大改架构的前提下快速定位，应该优先看抓包、traceroute、RIPE Atlas 这类外部探测，还是先从 CDN 厂商的边缘日志和 Anycast 路由公告入手？如果有人处理过双栈环境下“IPv6 看似可用但体验更差”的案例，也欢迎分享最终是怎么收敛问题的。

先提醒下，排查时尽量补齐地区、运营商、ASN、终端系统和失败时间段，便于大家复现。顺序建议：1 先看 CDN 边缘日志与 v4/v6 命中差异；2 做 MTU/ICMPv6 抓包；3 用 RIPE Atlas+traceroute 验证绕路；4 最后再看 Happy Eyeballs。此类问题里，PMTU 黑洞和边缘节点选路异常最常见。

这类问题十有八九不是“单点炸了”，而是双栈里某一段在晚高峰偷偷拉胯。建议先按“最省时间能排大类”的顺序来：
1）先分 IPv4/IPv6 做多地区 curl+握手耗时对比；
2）再看 CDN 边缘日志，确认慢在边缘前还是回源/TLS；
3）重点测 PMTU，抓 icmp6 packet too big、MSS/分片；
4）最后再上 RIPE Atlas + mtr/traceroute 看晚高峰绕路。
Happy Eyeballs 往往

先按“证据可复现”排。建议你补充同一地区/同运营商的 v4、v6 对比数据：mtr/traceroute、tcpdump 抓 SYN/TLS、curl 记录 connect/ttfb，并固定单一边缘节点测试。优先查 PMTU，v6 一旦 ICMPv6 被丢很容易出现首包后卡顿；再看晚高峰是否切到异常 Anycast 节点。RIPE Atlas 适合验证地区性，CDN 边缘日志用于对齐时间点。发后续数据时尽量脱敏、按模板整理，方便大家继续

我也踩过类似坑，最后不是源站而是 IPv6 路径和 MTU 叠加。要是想先快定位，我会先做两件事：同地区 v4/v6 抓包对比首包、TLS、重传；再找 RIPE Atlas/第三方节点复现。想追问下，你这边有开 MSS clamping 或测过 1280/1400 这类 MTU 吗？