问题背景
项目上使用SpringCloudGateway作为网关承接公网上各个业务线进来的请求流量，在网关的前面有两台Nginx反向代理了网关，网关做了一系列的前置处理后转发请求到后面各个业务线的服务，简要的网络链路为：- 网关域名(wmg.test.com) -> ... -> Nginx ->F5(硬负载域名fp.wmg.test) -> 网关 -> 业务系统
SRE等级定性P1
一个月黑风高的夜晚，负责运维Nginx的团队进行了生产变更，在两台新机器上部署了Nginx，然后让网络团队将网关域名的流量切换到了两台新的Nginx机器上，刚切换完，立马有业务线团队的人反应，过网关的接口请求都变成400了。负责运维Nginx的团队又让网络团队将网关域名流量切回到原有的两台Nginx上，业务线过网关的接口请求恢复正常，持续了两分多钟，SRE等级定性P1。
负责运维Nginx的团队说，两台新的Nginx配置和原有的两台Nginx配置一样，看不出什么问题，找到我，让我从网关排查有没有什么错误日志。
不太可能吧，如果新的两台Nginx配置和原有的两台Nginx配置一样的话，不会出现请求都是400的问题啊，我心想，不过还是去看了网关上的日志，在那个时间段，网关没有错误日志出现。
看了下新Nginx的日志，Options请求正常返回204，其它的GET、POST请求都是400，Options是预检请求，在Nginx层面就处理返回了，新Nginx的日志示例如下：- 10.x.x.x:63048 > - > 10.x.x.x:8099 > [2025-07-17T10:36:26+08:00] > 10.x.x.x:8099 OPTIONS /api/xxx HTTP/1.1 > 204 > 0 > https://domain/ > Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/138.0.0.0 Safari/537.36 > - > [req_time:0.000 s] >[upstream_connect_time:- s]> [upstream_header_time:- s] > [upstream_resp_time:- s] [-]
- 10.x.x.x:63048 > - > 10.x.x.x:8099 > [2025-07-17T10:36:26+08:00] > 10.x.x.x:8099 POST /api/xxx HTTP/1.1 > 400 > 0 > https://domain/ > Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/138.0.0.0 Safari/537.36 > - > [req_time:0.001 s] >[upstream_connect_time:0.000 s]> [upstream_header_time:0.001 s] > [upstream_resp_time:0.001 s] [10.x.x.x:8082]
负责运维Nginx的团队又花了一段时间定位问题，还是没有头绪，又找到我，让我帮忙分析调查下。
介入调查
我说测试环境地址是啥，我先在测试环境看下能不能复现，负责运维Nginx的团队成员说，没有在测试环境搭建测试，这一次变更是另一个成员直接生产变更。
来源：程序园用户自行投稿发布，如果侵权，请联系站长删除
免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！ |
提升卡
置顶卡
沉默卡
喧嚣卡
变色卡
千斤顶
照妖镜
