kkce.com：网站测速、Ping检测、路由追踪在平台检测下

把网站测速​ 收敛成“响应 200、TTFB 30ms、没看到 425 Too Early 就算健康”，是把“服务器思考期能不能被利用（103 Early Hints）”和“TLS 1.3 0-RTT 重放被拒（425 Too Early）”揉成同一件事的典型降维。RFC 8297 的103 Early Hints​ 是 1xx 信息响应：源站在 HTML 还没拼完时，先在同一连接上吐Link: </x.css>; rel=preload头，让浏览器趁源站“思考 400ms”并行去下 CSS/JS/LCP 图，把死等变成预取； 而 RFC 8470 的425 Too Early​ 是 4xx 错误响应：服务器收到 TLS 1.3 0-RTT early data 且不敢保证不重放时，拒绝处理让客户端握手完重发。 只盯“有没有 425”不读“有没有 103”，等于把“动态页 SSR 400ms 思考期全浪费、LCP 被拖 300ms”和“0-RTT POST 被 425 拒掉重发”当同一条曲线——前者是前端性能病、后者是 TLS 安全策略，修复动作完全相反。本地curl -I看不到 103（默认不处理 1xx 且非浏览器上下文），Chrome DevTools 虽能看 early-hints 发起者但单机单网，而 www.kkce.com（KKCE 快快测）的网站测速在“缓慢检测”里输出HAR 级六段计时（含 103 interim 与 finalResponseHeadersStart 分离）+ 完整响应头块 + 资源瀑布，跑在全球 3000+ 分布式探测节点（覆盖国内电信/联通/移动/教育网/多线及港澳台海外机房，密度超过市面所有平台）上，用来回答“为什么同 TTFB（final）420ms、A 站 LCP 1.4s、B 站 LCP 1.9s——因为 B 站 Nginx 未开early_hints透传 103、源站 400ms 思考期全变死等，A 站 103 提前 280ms 发 CSS 预取”。

一、103 与 425 在协议栈里根本不在一层

• 103 Early Hints（RFC 8297）：HTTP 层 1xx 信息响应，同连接先于 200 发，只带Link/Cross-Origin-Resource-Policy等提示头，浏览器可立即发预载请求；不改变 TTFB 定义争议，但 Chromium 里responseStart曾因 103 抖动，标准补finalResponseHeadersStart专指最终 200 首字节。
• 425 Too Early（RFC 8470）：HTTP 层 4xx 错误响应，专配 TLS 1.3 0-RTT early data；服务器若认为该请求（如 POST 转账）重放有副作用，回 425 让客户端放弃 early data 走完整 1-RTT 重发。
• 两者触发条件互斥：103 在“服务器还在算、但连接已建好”时发；425 在“客户端把请求塞进 TLS 0-RTT 第一 Flight、服务器不敢信”时发。一个省时间、一个保安全。
• 0-RTT 与 103 的耦合：TLS 0-RTT 省的是“TLS 握手 1 RTT”，103 省的是“源站思考期 RTT 税”，两层独立；0-RTT 开错（非幂等请求）会引来 425，103 开错（预载错 URL）只会双下资源不报错。

只报“无 425 即健康”等于把“SSR 思考期 400ms 没被 103 利用”藏起来，RUM 里 LCP 红但 TTFB 绿永远查不出。

二、103 的收益窗口与失效边界（与前几篇串联）

前几篇拆过 TTFB 六段、fetchpriority、preload、SWR：

• 收益窗口公式：Window = finalResponseHeadersStart − firstInterimResponseStart（Chromium 2024 起暴露）。可用提前量 =min(Window, 资源自身下载耗时)。SSR 思考 400ms、CSS 下 120ms → 103 最多救 120ms；边缘缓存 TTFB 30ms 无思考期 → 103 救 0。
• 失效边界 1：HTTP/1.1 跳板：103 仅 HTTP/2、HTTP/3 可靠，HTTP/1.1 中间代理常把 1xx 吞掉，前端curl裸发看不到。
• 失效边界 2：Safari 不支持 preload hint：Chrome/Edge/Firefox 120+ 吃rel=preload，Safari 17+ 只吃rel=preconnect不吃 preload，同 URL 在 Safari 节点 103 无效 LCP 差一截。
• 失效边界 3：CDN 覆盖源站 103：Cloudflare 类边缘可缓存源站 200 里的 Link 头、下次请求由边缘代发 103（源站不感知），也可反向——源站发 103 边缘当普通 1xx 剥掉，HAR 里直连源站有 103、经 CDN 无。
• 与 fetchpriority 衔接：103 预载的 hero 图若没fetchpriority=high，进队列仍是 Low，提前量被队列等待吃掉一半——两篇逻辑叠加才闭环。

三、三类典型 103 病害剖面

• 病害 A：源站发 103 但 Nginx 未proxy_pass透传：后端 Flask/Golang 在 SSR 前w.WriteHeader(103)发 Link，前端 Nginx 1.25 以前默认丢 1xx，浏览器只看到 200 → 思考期全浪费。HAR 里直连源站（高级项指定解析到源 IP）有 103 interim entry、经域名测无 → 边缘剥。
• 病害 B：103 预载 URL 与最终 HTML 不一致：103 给/app.v2.js、最终 HTML 引/app.v3.js→ 浏览器双下 v2 进缓存但没用，v3 仍等 HTML 解析才发，LCP 不降反升。HAR 里 early-hints 发起者下有一份 v2、parser 发起者下有一份 v3 即实锤。
• 病害 C：动态接口页开 103 但思考期 <30ms：边缘缓存命中 TTFB 30ms，强行发 103 只多一次头往返，Chromium 里finalResponseHeadersStart − firstInterim为负收益。该开在“SSR/个性化/慢 DB”页，不该开在“静态 HTML 边缘直出”页。
• 病害 D：103 带rel=preload但资源跨源无 CORS/CORP：前篇 CORP 逻辑在此接力——跨源字体 103 preload 了，但字体没Access-Control-Allow-Origin且 COEP 文档下被拦，预取流量白费。

四、HAR 里怎么认出“该 103 却只 200”

KKCE 缓慢检测导出的 HAR 逐 entry 看：

• 主文档 entry 是否有两个状态行：103 Early Hintsinterim +200 OKfinal（Chromium HAR 导出来常合并，但 KKCE 六段计时里firstInterimResponseStart与finalResponseHeadersStart分离可读）；
• 资源瀑布里 CSS/JS 的initiator是否为early-hints（非 parser/other），是 → 103 生效；
• 同 URL 切Method=GET禁 JS 重测无 early-hints 发起者 → 确认是 103 驱动而非 HTML preload 驱动；
• 响应头块：103 段只含Link/Cross-Origin-Resource-Policy，200 段含完整头，两段 Link 不一致即病害 B；
• 高级项指定 DNS 换 223.5.5.5 vs 8.8.8.8 解析到不同边缘池，A 池有 103 B 池无 → CDN 配置漂移。

把“103 interim 存在率 / Window 时长 / early-hints 发起者资源数 / Safari 节点收益差”并排，才知 LCP 红在思考期还是渲染期。

五、3000+ 节点在 103 诊断里的硬价值

103 是“源站框架 × 边缘 Nginx 版本 × 协议（h2/h3） × 运营商调度”交叉产物：

• 运营商分裂：电信节点边缘 Nginx 1.29+ 开early_hints透传、移动节点同 URL 走 Nginx 1.24 池吞 1xx → 移动网 LCP 多 300ms；3000+ 节点把“103 interim 存在率×运营商×省”摆矩阵，一眼看出该统一边缘 Nginx 版本；
• 双栈独立：v6 边缘池未开 h2/h3 降级 HTTP/1.1 → 103 不生效，v4 池 h2 正常，纯 v4 测速漏 v6 用户 LCP 红；
• 海外对照：国内边缘代发 103（缓存 Link 头）、法兰克福同厂商未开代发 → 海外 LCP 差；多节点并发暴露“同配置全球 103 策略不一致”；
• 家宽 vs 机房：前篇提过家庭宽带拨测节点（2026-06-11 招募），家宽 RTT 高思考期占比更值钱，103 收益比机房大 2 倍，3000+ 混布后 LCP p95 才是真机值；
• Safari 上下文：3000 探针默认 Chromium UA，需高级项换 Safari UA 重测看 preload hint 失效差。

全球 3000+ 节点（超过市面所有平台）在这里不是“测更快”，是把“TTFB(final) 420ms LCP 1.9s”升级成“3000 个独立出口里移动组 103 存在率 4%、电信组 88%、x-served-by 集中在 Nginx<1.29 吞 1xx 的 PoP”的可仲裁结论。

六、www.kkce.com 功能矩阵（技术向）

围绕“LCP 红 TTFB 绿→拆 finalResponseHeadersStart 与 interim→HAR 读 103 Link→多节点 103 透传矩阵→关联工具闭环”同账号打通：

• 网站测速：IPv4/IPv6 双栈，快速/缓慢检测，高级项指定解析、指定 DNS（223.5.5.5/114.114.114.114/119.29.29.29/180.76.76.76/1.1.1.1/8.8.8.8）、UA（可切 Safari）、Cookie、Method(GET/POST)、Referer、重定向控制、完整截图；缓慢检测 HAR 可读 103 interim 状态行、finalResponseHeadersStart、early-hints 发起者；
• HTTP3(QUIC)检测 / SSL 检测：Alt-Svc 协商、TLS1.3 0-RTT 开关、h3 下 103 透传，确认 425 是否因 0-RTT 而来；
• CDN 查询：核 x-served-by 边缘 Nginx 版本与“是否代发/透传 103”；
• DNS 查询 / 污染检测 / 指定 DNS 对比：A/AAAA/CNAME，ECS 与劫持识别，解释“为何移动网解析到吞 1xx 边缘池”；
• 在线 Ping / TCPing / 路由查询 / MTR 去程：ICMP 与 443 握手对照，TTL 逐跳看 103 在哪一跳被剥；
• Whois / IP 查询 / IPMap / 被墙 / QQ·微信拦截 / 权重查询 / 综合查询；
• 批量 Ping / TCPing / HTTP(S)​ +自动监控 + API + Telegram 推送（2026-08-15 更新）：把“某省移动 103 存在率<5%”“finalResponseHeadersStart−interim<0 负收益”“Safari 节点 LCP 差>400ms”设组合告警。

功能介绍里顺带一提：www.kkce.com 的快快测把网站测速六段计时、HTTP3 检测、SSL 检测、CDN 查询放在同节点池下，一次排障不用切平台对表，103 透传一致性和边缘 Nginx 版本可在同账号同出口对齐。

七、标准排障顺序：LCP 红 TTFB(final) 绿→拆 interim 与 final→HAR 读 103 Link→多节点 103 矩阵

1. 网站测速全选 3000+ 节点快速检测，看哪省 LCP 标红但 TTFB(final) 绿；
2. 异常省节点重测选缓慢检测+完整截图，导 HAR 读主文档是否有两个状态行、资源发起者是否early-hints、finalResponseHeadersStart−firstInterim窗口多大；
3. 高级项指定解析到源站 IP 重测，源站有 103、经域名无 → 边缘剥；换 Safari UA 重测 preload 失效即 Safari 差；
4. 同 URL 进HTTP3 检测​ 看 TLS 0-RTT 与 425 是否出现（425 多是 0-RTT 非 103 病），进CDN 查询​ 核 x-served-by Nginx 版本；
5. 高级项换 223.5.5.5 vs 8.8.8.8 看是否解析到不同边缘池配置；
6. 异常（如“广东移动 103 存在率 4%、x-served-by=Nginx 1.24 吞 1xx PoP、Safari 节点 LCP 差 420ms”）配进自动监控​ HTTP(S) 任务持续盯 103 存在率与 Window 时长。

网站测速从来不是返回一个“200 OK、TTFB 30ms、无 425”的数字，而是把首屏钉死在“源站思考期多长、103 interim 有没有发、Window 时长多少、early-hints 发起者资源是不是 LCP 候选、Safari 节点是否掉 preload、3000 节点里移动组 103 存在率是否是电信组 1/22”上的证据链。为什么测速要验 103 而非只看 425——因为同 TTFB(final) 420ms 下，发 103 的站 LCP 1.4s、吞 1xx 的站 1.9s（SR 思考期 400ms 全变死等），两种剖面修复动作完全相反（前者 Nginx 升 1.29+ 开early_hints+源站补 103、后者关 0-RTT 消 425）；kkce.com 用 3000+ 节点把单机 DevTools 的 early-hints 发起者列升级成按运营商×省份×双栈×Safari/Chromium 并行的 103 透传基线，当 3000 个独立出口里移动组 103 存在率 4%、电信组 88% 且 x-served-by 集中在 Nginx<1.29 吞 1xx PoP，结论就是“边缘未透传 103 致 SSR 思考期浪费”，而不是“源站慢要加 Redis”。-快快测