「接口响应 800ms」——这个 800ms 里，有多少是数据库慢查询，有多少是跨区回源的网络耗时？不拆段就无法优化，这是后端最常见的甩锅现场。

TTFB（首字节时间）≈ DNS + TCP + TLS + 服务端处理 + 最后一跳网络 RTT。关键结论：同省同运营商 p75 在 60ms 内健康，跨大区 100ms 需关注，300ms 以上基本有明确问题。但单一节点的一次值毫无意义，受抖动干扰极大。

KKCE【网站测速】按真实浏览器建连顺序拆段：DNS Lookup、Connect（TCP）、SSL Handshake、TTFB、Full Load。高级项支持指定解析、DNS、UA、Cookie、Method（GET/POST）、Referer、重定向控制、完整截图，可模拟登录态请求真实业务接口。

判读矩阵：

• TCP+TLS 低，唯独 TTFB 高 → 后端慢（慢 SQL、锁等待、缓存失效、跨区回源）
• TTFB 高且跨运营商明显（广东移动 300ms、广东电信 60ms）→ CDN 调度没命中移动边缘，不是 MySQL 的锅
• DNS 单项高 → 解析商或 Local DNS 问题
• TCP 建连高、TLS 正常 → 中间链路拥塞或源站 backlog 满
• SSL 握手高 → 证书链过长、未开会话复用、协议降级到 TLS1.2

实战：先【在线Ping】确认基础 RTT，再用【网站测速】拆段定位到层，最后拿【路由查询】看绕路。如果确认是后端，再进 APM 查慢查询——先证网络清白再动代码，能省掉一半无效重构。对 API 接口同样适用，Method 切 POST、带 Cookie 就能测登录态接口的首包延迟。

FAQ

• Q：TTFB 多少算合格？A：看 p75 而非均值，同省同网 <60ms 理想，>300ms 必查。
• Q：CDN 开启后 TTFB 反而高了？A：首次访问未命中边缘缓存会回源，且多一跳，看第二次请求的缓存命中表现。
• Q：Full Load 高但 TTFB 低？A：那是前端问题——资源过大、未压缩、未懒加载，与后端无关。