如何优化NGINX的TTFB？排查1.6秒长TTFB的原因

嘿，咱们一步步来拆解你这1.6秒的TTFB问题，先从你怀疑的重定向说起，逐个环节排查~

一、先看看重定向是不是在拖后腿？ #

你当前的Nginx 80端口配置有点小问题：把www.example.com和api.example.com的HTTP请求都一股脑重定向到https://www.example.com了——这可是个明显的坑！如果用户访问http://api.example.com，会被强制跳转到www域名，要是API请求本身不需要走www，这不仅逻辑错误，还会多一次不必要的跳转（甚至可能触发后续的二次修正跳转），直接拉长TTFB。

先把80端口的配置改成这样，给www和api单独做正确的重定向：

server {
    listen 80;
    server_name www.example.com;
    return 301 https://www.example.com$request_uri;
}

server {
    listen 80;
    server_name api.example.com;
    return 301 https://api.example.com$request_uri;
}

另外再检查你的443端口配置：同一个server块绑定了www和api域名，但两者共用同一个根目录/var/www/app/public_html/web——如果API服务有独立的入口文件（比如api.php）或者根目录，这会导致Nginx处理API请求时可能找不到正确的入口，间接拉长处理时间，建议给api单独配置一个server块哦。

二、Hetzner负载均衡的锅？ #

看你贴的负载均衡截图，咱们重点检查这几点：

• 健康检查是否正常：如果负载均衡的健康检查频繁失败，会反复在后端服务器间切换，带来额外的连接延迟。可以看看负载均衡的监控面板，健康检查的成功率是不是100%？
• 转发规则是否匹配：确认负载均衡的80/443端口是否正确转发到后端Nginx服务器的对应端口，有没有端口不匹配或者转发规则错误的情况？
• 绕开负载均衡测试：直接在本地hosts文件里把域名解析到后端Nginx服务器的IP，绕开负载均衡测试TTFB。如果TTFB明显下降，那问题大概率出在负载均衡的配置或者网络链路延迟上。

三、Nginx与PHP-FPM的通信是不是卡壳了？ #

TTFB长的核心原因往往是PHP脚本执行慢或者Nginx与PHP-FPM的连接效率低，咱们这么排查：

1. 抓慢PHP脚本：开启PHP-FPM的慢日志，在PHP-FPM的pool配置文件（比如www.conf）里加这两行：

   slowlog = /var/log/php-fpm/slow_requests.log
   request_slowlog_timeout = 1s
   

   这样执行时间超过1秒的脚本会被记录下来，直接定位到拖慢速度的罪魁祸首。
2. 优化PHP-FPM连接方式：如果当前Nginx用TCP连接PHP-FPM（比如fastcgi_pass 127.0.0.1:9000;），改成Unix Socket试试：fastcgi_pass unix:/run/php/php-fpm.sock;（路径根据你的PHP版本调整），Unix Socket的本地通信延迟比TCP低不少。
3. 检查PHP-FPM进程数：如果pm.max_children、pm.start_servers配置得太小，请求会排队等空闲进程，直接拉长TTFB。可以根据服务器的CPU核心数调整，比如CPU是4核的话，pm.max_children可以设为20左右，具体看你的内存情况。

四、Cloudflare的配置有没有拖后腿？ #

暂时绕开Cloudflare测试：修改本地hosts，把域名直接解析到Hetzner负载均衡的IP，测试TTFB是否下降。如果下降明显，那要检查Cloudflare的这几个配置：

• SSL模式：别用“Flexible”模式，这种模式下Cloudflare到后端是HTTP，会多一次TLS握手延迟，建议改成“Full”或“Full (Strict)”模式，确保端到端都是HTTPS。
• 缓存策略：动态请求（比如API）Cloudflare不会缓存，但可以看看有没有开启“Auto Minify”或者“Rocket Loader”这类优化功能，会不会和你的动态内容冲突？

备注：内容来源于stack exchange，提问作者caprio