页面迟迟没有返回第一个字节，不一定是服务器“算得慢”。首字节时间过长的源站与网络排查流程，应先把 DNS 解析、连接建立、请求传输和源站处理拆开，再用同一请求做对照，避免只凭页面加载感觉判断。
先选一个稳定复现问题的页面或 API，记录测试时间、访问区域、协议和请求地址。连续测 5 至 10 次，比较中位数，并保留正常时段作为参照。浏览器开发者工具的 Network 瀑布图可显示 DNS、连接、TLS 与等待响应等阶段；若请求经过代理或 CDN，也要记下这些路径信息。
第一层：确认 DNS 是否拖慢请求
DNS 解析负责把域名映射到 IP。若解析耗时明显偏高、间歇失败，或不同递归解析器返回的地址不同，浏览器可能在连接源站之前就已等待。注意，缓存命中时解析耗时可能接近于零，不能据单次结果认定 DNS 一直正常。
- 在出现问题的终端和网络上，使用 dig 或 nslookup 查询目标域名，记录返回地址与响应时间。
- 改用另一台设备或不同递归解析器重复查询，并核对结果是否一致；若有权访问权威 DNS 配置，再检查记录类型、目标地址和 TTL 是否符合预期。
- 清理本机 DNS 缓存后重新访问，观察是否改变；同时对比直接访问 IP 与域名的结果。若直连 IP 快、域名访问慢，优先继续核对解析和地址选择，但需考虑 HTTPS 证书与虚拟主机要求，不能把 IP 访问当作完全等价测试。
不同查询结果可能来自缓存尚未更新、DNS 记录配置或递归解析路径差异。若解析稳定且耗时占比很小，就不要把排查重点停留在 DNS。
第二层：检查用户到服务端的链路
DNS 返回地址后，请求仍需经过网络往返。往返时延（RTT）高、丢包或路由绕行，会拉长 TCP 握手与 TLS 握手；它们和应用处理时间是不同问题。可在客户端用 traceroute 或 mtr 查看路由与丢包线索，并在浏览器瀑布图中对照连接阶段。
- 若多个目标都同时变慢，且路由中后段出现持续丢包或延迟升高，更像本地网络、运营商出口或中间链路问题。单个中间节点不响应并不等于故障：路由设备可能限制 ICMP 回包，应结合后续节点及实际请求判断。
- 若仅某个地址或区域异常，比较该域名解析到的不同地址，检查是否存在特定线路、边缘节点或跨区域路径差异。
- 若 DNS、连接和 TLS 阶段都短，但等待响应时间长，网络链路通常不是首要嫌疑，继续检查源站。
不要把 ping 的结果直接当作网页首字节时间。ICMP 与 HTTPS 请求走的处理路径不同，且 ICMP 可能被限速或屏蔽。
第三层：判断是否由源站处理造成
源站处理耗时包括接收请求后排队、执行应用逻辑、访问数据库或其他依赖，再开始发送响应的时间。静态文件和动态 API 的瓶颈也可能不同：前者常受磁盘、缓存或服务配置影响，后者还可能等待数据库查询或下游服务。
- 选择一个轻量静态资源和一个问题页面，在同一网络、同一时段分别请求。静态资源快而动态接口慢，优先检查应用逻辑及其依赖。
- 查看服务器访问日志或 APM 中的请求总耗时、应用处理耗时和依赖调用耗时，并用请求 ID 对齐客户端与服务端记录。若客户端等待长而服务端记录短，回查网络、代理或响应传输；若服务端处理本身长，沿调用链找耗时步骤。
- 检查是否有连接池耗尽、线程排队、数据库慢查询、下游超时或缓存未命中。比较高峰与低峰、单实例与其他实例，判断问题是否集中在负载或个别节点。
若前置 CDN 或反向代理参与请求，还要区分边缘节点等待、回源耗时和源站处理时间。只有明确请求在哪一段停留，才适合调整缓存、扩容或优化代码；盲目增加服务器资源未必能解决链路问题。
把排查结果变成可验证结论
首字节时间过长的源站与网络排查流程，关键不是一次测出一个数字，而是让客户端计时、路由观察和服务端日志相互印证。每次只改变一个条件，例如解析器、网络出口或请求路径；改动后重复相同测试，并记录变化。若问题只在特定区域、特定地址或高负载时出现，保留对应时间与请求标识，交给网络或服务维护人员继续定位。
常见问题
首字节时间高，就一定是源站慢吗？
不一定。DNS、握手、链路往返和代理回源都可能增加等待时间，应先看瀑布图分段。
解析时间为零，是否说明 DNS 没问题？
不能完全说明。浏览器或系统可能使用了缓存；可在缓存刷新后重复查询，并比较不同解析器。
路由追踪有丢包，是否就是网络故障？
未必。中间设备可能不回应探测包；需要看后续节点，并与实际 HTTPS 请求表现交叉验证。
应该先优化数据库还是加机器？
先看服务端调用链和负载证据。若耗时集中在慢查询，优化查询更有针对性；若请求排队与资源饱和明显，再评估容量调整。