网站 TTFB 偏高怎么排查？从网络到后端的逐层定位方法

TTFB（Time To First Byte，首字节时间）高，先别急着换服务器。
打开浏览器开发者工具的 Network 面板，看请求的 Waiting (TTFB) 那一列：如果它占了大头，问题基本在服务端响应或网络链路上，而不是前端资源加载。
下面按从外到内的顺序，用几个命令把范围缩小。

先分清是网络慢还是后端慢

在本地终端对首页发起一次请求，把各阶段耗时拆开：

curl -o /dev/null -s -w "dns:%{time_namelookup} connect:%{time_connect} tls:%{time_appconnect} starttransfer:%{time_starttransfer} total:%{time_total}\n" https://你的域名/

重点看 time_starttransfer（首字节时间）和 time_appconnect（TLS 握手完成）的差值。
如果 time_starttransfer 只比 time_appconnect 多几十毫秒，说明服务端处理很快，TTFB 高主要来自 DNS 解析、建连或 TLS 握手，优先检查域名解析和 CDN 线路；
如果差值达到几百毫秒甚至秒级，就是后端处理慢，继续往下查。

在服务器本机再执行一次同样的 curl。
本机 TTFB 明显低于外网，说明公网链路或 CDN 回源有问题；
本机也慢，说明问题在应用或数据库。

检查 Nginx 和后端处理耗时

登录服务器，看 Nginx 访问日志里的 $request_time 和 $upstream_response_time。
如果开了这两个变量，能直接对比总耗时和后端耗时：

log_format timed '$remote_addr - $request_time - $upstream_response_time - $request';
access_log /var/log/nginx/access.log timed;

$request_time 大而 $upstream_response_time 小，瓶颈在 Nginx 自身或客户端网络；
两者都大，瓶颈在 PHP-FPM、Python 应用或数据库。
没有日志变量时，用 top 和 iostat 看负载：CPU 是否跑满、磁盘 IO 是否持续 100%、内存是否触发 swap。

PHP 站点重点看 PHP-FPM 慢日志。
在 php-fpm.conf 或池配置里开启：

request_slowlog_timeout = 5s
slowlog = /var/log/php-fpm/slow.log

重启 PHP-FPM 后，超过 5 秒的请求会记录调用栈，能直接看到是哪个函数或外部请求拖慢。

数据库和外部接口最容易拖后腿

很多 TTFB 高不是 Web 服务器的问题，而是页面在等数据库或第三方接口。
检查 MySQL 慢查询：

SHOW VARIABLES LIKE 'slow_query_log';
SHOW VARIABLES LIKE 'long_query_time';

开启慢查询日志后，用 mysqldumpslow 或 pt-query-digest 找出耗时最长的 SQL，优先给 WHERE、JOIN 和 ORDER BY 涉及的字段加索引。
页面里如果有同步调用支付、短信、地图等外部接口，也会把 TTFB 拉高，能改成异步或加缓存的尽量改。

用缓存把重复计算挡在前面

动态页面每次请求都查库、渲染模板，TTFB 自然下不来。
对不常变的页面加一层缓存：Nginx 的 proxy_cache 或 fastcgi_cache 可以缓存后端响应，CDN 可以缓存静态资源和部分 HTML。
配置缓存前先确认页面是否包含登录态或个性化内容，避免把用户私有数据缓存给其他人。

如果站点已接入 CDN，检查缓存命中率。
命中率低时，TTFB 高的请求会频繁回源，等于没加速。
在 CDN 控制台查看缓存规则，把图片、CSS、JS 的缓存时间设长，HTML 按业务需要设置较短缓存或开启“回源跟随”。

验证优化是否生效

改完后用同一组 curl 命令重复测试，对比 time_starttransfer 的变化。
建议连续测 5 次取中位数，避免单次网络抖动造成误判。
浏览器端再开一次开发者工具，确认 Waiting (TTFB) 下降，同时观察页面整体加载时间是否改善。

如果 TTFB 仍然偏高，回到第一步重新判断：是 DNS 解析慢、TLS 握手慢，还是后端某个接口慢。
逐层排除比直接升级服务器更有效，也更省钱。

常见疑问

TTFB 多少算正常？
没有统一标准，静态页面通常希望在 200ms 以内，动态页面在 500ms 到 800ms 之间比较常见。超过 1 秒就值得排查，但还要结合用户所在地区和网络环境判断。

开了 CDN 后 TTFB 反而更高？
可能是 CDN 回源慢或缓存未命中。先确认源站响应时间，再检查 CDN 的缓存规则和回源线路，必要时调整缓存过期时间或更换回源方式。

只优化前端能降低 TTFB 吗？
不能。TTFB 衡量的是服务器返回第一个字节的时间，前端优化影响的是后续资源加载和渲染，两者要分开处理。