经历过凌晨三点被报警短信吵醒的运维人都懂，Nginx配置里藏着太多「温柔陷阱」。上周我们刚处理完那个诡异的502问题，结果你猜怎么着？周三灰度发布时又踩中了一个redirect配置的地雷。说实话，这些坑还真不是文档里能找全的，今天咱就掰开揉碎了聊聊那些年我们集体踩过的Nginx配置陷阱。
致命重定向循环
上周我们团队就差点被自己写的配置给「谋杀」了。某次改版后在测试环境配置了rewrite规则：
rewrite ^/old-path/(.*) /new-path/$1 permanent;，
看起来完美无瑕对吧？结果上线后直接导致301死循环。抓包后发现是因为反向代理场景下没处理好proxy_redirect，
后端返回的Location头直接被浏览器二次请求，形成了绝望的俄罗斯套娃。
超时参数的死亡多米诺
那次502排查血案让我们见识了超时配置的连锁反应。某金融平台曾因fastcgi_read_timeout值低于PHP-FPM的request_terminate_timeout，
导致大批长事务订单神秘消失。更反直觉的是keepalive_timeout设置并非越大越好，某电商大促期间就因设到600秒耗尽所有可用端口，
这配置玄学真能把人逼疯。
SSL的隐蔽陷阱
听说隔壁团队栽在SSL配置上时我还暗笑，直到自己踩坑才笑不出来。那次配置全站HTTPS时漏了proxy_set_header X-Forwarded-Proto $scheme;，
导致后端拿到的全是http协议头。最坑的是Android 7以下设备居然因此拒绝连接，这兼容性雷区简直防不胜防。
说实话，看再多文档都不如实战踩坑记得牢。就像最近用limit_req限流时才发现，
默认的burst参数在某些场景下会导致请求堆积压垮服务。建议新手上线前先用nginx -t做语法检查，
再用ss -ant | grep ESTAB监控连接状态。记住，Nginx的配置就像多米诺骨牌——每个参数都在暗中互相作用。
评论