主 题：两次网页“卡几秒”排障：一次是 CF Tunnel 路径，一次是 HTTP/2 空闲连接
发 布 者：xushuo
标签分类： 技术
时 间：2026-09-15 08:56:54
内容预览：最近给几个自用 Web 服务排了两次很像、但根因完全不同的“网页偶发卡几秒”，过程挺有意思，脱敏记录一下，也想问问大家有没有遇到类似情况。环境大致是：自建源站 + Caddy，前面还有 TCP 四层分流；手机 Android/Chrome 是主要访问端。下面不放域名、IP 和具体机器。第一类：Cloudflare Tunnel 路径卡顿之前一部分服务的数据链路是：浏览器 -%26gt%3b Cloudflare/Access -%26gt%3b Tunnel -%26gt%3b 源站在某些手机网络/Wi-Fi 下，经常出现首开转圈几秒，而且刷新也会继续卡，不是“第一次慢、第二次快”。源站负载、源站本地访问都正常，同一设备换网络后体感又可能明显不同。后来做 A/B，把数据面从 Tunnel 拿掉，只保留需要的鉴权能力，页面/API/SSE 改成直接访问源站。那一类卡顿明显改善。所以这次的经验是：Tunnel 本身不等于慢，但如果某条本地网络到 CF 边缘/Anycast 的路径不理想，它会成为所有请求共同经过的瓶颈。这个场景里“刷新也卡”是一个比较明显的特征。第二类：直连以后，又遇到一种“冷开卡 5~10 秒，刷新秒开”这次已经不是 Tunnel 了。现象是：页面放一阵子不访问，再打开，偶尔空白/转圈 5~10 秒；一旦出来，马上刷新就是秒开；随后访问同域名其他页面也很快；关掉 Clash/TUN 后仍然可以复现。一开始很容易怀疑前端，所以我也走了不少弯路：拆大 JS、拆大 CSS、做 critical CSS、把非关键库延后、记录 Long Task 等。确实顺手把页面从 500KB+ 的大单文件整理成了小 HTML + 可缓存 CSS/JS，但后来证明这些不是那 5~10 秒的根因。真正有用的是逐层做 A/B：加 Navigation Timing / Resource Timing；做一个同域名、只有 1~2K
直达链接： https://www.nodeseek.com/post-929240-1
发 布 者：xushuo
标签分类： 技术
时 间：2026-09-15 08:56:54
内容预览：最近给几个自用 Web 服务排了两次很像、但根因完全不同的“网页偶发卡几秒”，过程挺有意思，脱敏记录一下，也想问问大家有没有遇到类似情况。环境大致是：自建源站 + Caddy，前面还有 TCP 四层分流；手机 Android/Chrome 是主要访问端。下面不放域名、IP 和具体机器。第一类：Cloudflare Tunnel 路径卡顿之前一部分服务的数据链路是：浏览器 -%26gt%3b Cloudflare/Access -%26gt%3b Tunnel -%26gt%3b 源站在某些手机网络/Wi-Fi 下，经常出现首开转圈几秒，而且刷新也会继续卡，不是“第一次慢、第二次快”。源站负载、源站本地访问都正常，同一设备换网络后体感又可能明显不同。后来做 A/B，把数据面从 Tunnel 拿掉，只保留需要的鉴权能力，页面/API/SSE 改成直接访问源站。那一类卡顿明显改善。所以这次的经验是：Tunnel 本身不等于慢，但如果某条本地网络到 CF 边缘/Anycast 的路径不理想，它会成为所有请求共同经过的瓶颈。这个场景里“刷新也卡”是一个比较明显的特征。第二类：直连以后，又遇到一种“冷开卡 5~10 秒，刷新秒开”这次已经不是 Tunnel 了。现象是：页面放一阵子不访问，再打开，偶尔空白/转圈 5~10 秒；一旦出来，马上刷新就是秒开；随后访问同域名其他页面也很快；关掉 Clash/TUN 后仍然可以复现。一开始很容易怀疑前端，所以我也走了不少弯路：拆大 JS、拆大 CSS、做 critical CSS、把非关键库延后、记录 Long Task 等。确实顺手把页面从 500KB+ 的大单文件整理成了小 HTML + 可缓存 CSS/JS，但后来证明这些不是那 5~10 秒的根因。真正有用的是逐层做 A/B：加 Navigation Timing / Resource Timing；做一个同域名、只有 1~2K
直达链接： https://www.nodeseek.com/post-929240-1
