本可避免的P1事故：Nginx变更导致网关请求均响应400
问题背景
项目上使用SpringCloudGateway作为网关承接公网上各个业务线进来的请求流量，在网关的前面有两台Nginx反向代理了网关，网关做了一系列的前置处理后转发请求到后面各个业务线的服务，简要的网络链路为：
网关域名(wmg.test.com) -> ... -> Nginx ->F5(硬负载域名fp.wmg.test) -> 网关 -> 业务系统
某天，负责运维Nginx的团队要增加两台新的Nginx机器，原因说来话长，按下不表，使用两台新的Nginx机器替代掉原先反向代理网关的两台Nginx。
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]
去找了网络团队，从流量回溯设备上看到400确实是网关返回的，还没有到后面的业务系统，400代表BadRequest，我怀疑是不是请求体的问题，想让网络将那个时间段的流量包数据取下来分析，网络没给，只给我了业务报文参数，走网关请求的业务参数报文是加密的，我本地运行程序可以正常解密报文，我反馈给了负责运维Nginx的团队。
负责运维Nginx的团队又花了一段时间定位问题，还是没有头绪，又找到我，让我帮忙分析调查下。
介入调查
我说测试环境地址是啥，我先在测试环境看下能不能复现，负责运维Nginx的团队成员说，没有在测试环境搭建测试，这一次变更是另一个成员直接生产变更。
我要来了新的Nginx配置文件和老的Nginx配置文件比对了下，发现有不一样的地方，老Nginx上反向代理网关的配置如下：
server {
listen 8080;
server_name wmg.test.com;
add_header X-Frame-Options "SAMEORIGIN";
add_header X-Content-Type-Options "nosniff";
add_header Content-Security-Policy "frame-ancestors 'self'";
location / {
proxy_hide_header host;
client_max_body_size 100m;
add_header 'Access-Control-Allow-Origin' "$http_origin" always;
add_header 'Access-Control-Allow-Credentials' 'true' always;
add_header 'Access-Control-Allow-Methods' 'GET, POST, OPTIONS, DELETE, PUT';
add_header 'Access-Control-Allow-Headers' '...';
if ($request_method = 'OPTIONS') {
return 204;
}
proxy_pass http://fp.wmg.test:8090;
}
}
新Nginx配置如下：
upstream http_gateways{
server fp.wmg.test:8090;
keepalive 30;
}
server {
listen 8080 backlog=512;
server_name wmg.test.com;
add_header X-Frame-Options "SAMEORIGIN";
add_header X-Content-Type-Options "nosniff";
add_header Content-Security-Policy "frame-ancestors 'self'";
location / {
proxy_hide_header host;
proxy_http_version 1.1;
proxy_set_header Connection "";
client_max_body_size 100m;
add_header 'Access-Control-Allow-Origin' "$http_origin" always;
add_header 'Access-Control-Allow-Credentials' 'true' always;
add_header 'Access-Control-Allow-Methods' 'GET, POST, OPTIONS, DELETE, PUT';
add_header 'Access-Control-Allow-Headers' '...';
if ($request_method = 'OPTIONS') {
return 204;
}
proxy_pass http://http_gateways;
}
}
新Nginx代理网关的配置与原有Nginx上的配置区别在于：
使用upstream配置了网关的F5负载均衡地址：
upstream http_gateways{
server fp.wmg.test:8090;
keepalive 30;
}
设置http协议为1.1，启用长连接
proxy_http_version 1.1;
proxy_set_header Connection "";
我让负责运维Nginx的团队在测试环境的Nginx上按照新的Nginx配置模拟了生产环境：
Nginx：10.100.8.11 监听9104端口
网关：10.100.22.48 监听8081端口
Nginx的9104端口转发到网关的8081端口，配置如下：
upstream http_gateways{
server 10.100.22.48:8081;
keepalive 30;
}
server {
listen 9104 backlog=512;
server_name localhost;
add_header X-Frame-Options "SAMEORIGIN";
add_header X-Content-Type-Options "nosniff";
add_header Content-Security-Policy "frame-ancestors 'self'";
location / {
proxy_hide_header host;
proxy_http_version 1.1;
proxy_set_header Connection "";
client_max_body_size 100m;
add_header 'Access-Control-Allow-Origin' "$http_origin" always;
add_header 'Access-Control-Allow-Credentials' 'true' always;
add_header 'Access-Control-Allow-Methods' 'GET, POST, OPTIONS, DELETE, PUT';
add_header 'Access-Control-Allow-Headers' '...';
if ($request_method = 'OPTIONS') {
return 204;
}
proxy_pass http://http_gateways;
}
}
问题复现
通过Nginx请求网关到后端服务接口，问题复现，请求响应400：
curl -v -X GET http://10.100.8.11:9104/wechat-web/actuator/info
去掉下面的两个配置，请求正常响应200：
proxy_http_version 1.1;
proxy_set_header Connection "";
天外来锅
将这个现象反馈给了负责运维Nginx的团队，结果负责运维Nginx的团队查了半天说网关不支持长连接，要让网关改造。
不应该啊，以往网关发版的时候，是滚动发版的，F5上先下掉一个机器的流量，停启这个机器上的网关服务，然后F5上流量，F5下流量的时候是有长连接存在的，每次都会等个5分钟左右才能下掉一路的流量。
得，先放下手头的工作，花点时间来证明网关是支持长连接的。
在Nginx机器上通过命令行指定长连接方式访问网关请求后端服务接口：
wget -d --header="Connection: keepalive" http://10.100.22.48:8081/wechat-web/actuator/info http://10.100.22.48:8081/wechat-web/actuator/info http://10.100.22.48:8081/wechat-web/actuator/info
回车出现如下日志：
Setting --header (header) to Connection: keepalive
DEBUG output created by Wget 1.14 on linux-gnu.
URI encoding = ‘UTF-8’
Converted file name 'info' (UTF-8) -> 'info' (UTF-8)
Converted file name 'info' (UTF-8) -> 'info' (UTF-8)
--2025-07-17 13:45:08-- http://10.100.22.48:8081/wechat-web/actuator/info
Connecting to 10.100.22.48:8081... connected.
Created socket 3.
Releasing 0x0000000000c95a90 (new refcount 0).
Deleting unused 0x0000000000c95a90.
---request begin---
GET /wechat-web/actuator/info HTTP/1.1
User-Agent: Wget/1.14 (linux-gnu)
Accept: */*
Host: 10.100.22.48:8081
Connection: keepalive
---request end---
HTTP request sent, awaiting response...
---response begin---
HTTP/1.1 200 OK
transfer-encoding: chunked
Content-Type: application/vnd.spring-boot.actuator.v3+json
Date: Thu, 17 Jul 2025 05:25:34 GMT
---response end---
200 OK
Registered socket 3 for persistent reuse.
Length: unspecified [application/vnd.spring-boot.actuator.v3+json]
Saving to: ‘info’
[ <=> ] 83 --.-K/s in 0s
2025-07-17 13:45:08 (7.75 MB/s) - ‘info’ saved [83]
URI encoding = ‘UTF-8’
Converted file name 'info' (UTF-8) -> 'info' (UTF-8)
Converted file name 'info' (UTF-8) -> 'info' (UTF-8)
--2025-07-17 13:45:08-- http://10.100.22.48:8081/wechat-web/actuator/info
Reusing existing connection to 10.100.22.48:8081.
Reusing fd 3.
---request begin---
GET /wechat-web/actuator/info HTTP/1.1
User-Agent: Wget/1.14 (linux-gnu)
Accept: */*
Host: 10.100.22.48:8081
Connection: keepalive
---request end---
HTTP request sent, awaiting response...
---response begin---
HTTP/1.1 200 OK
transfer-encoding: chunked
Content-Type: application/vnd.spring-boot.actuator.v3+json
Date: Thu, 17 Jul 2025 05:25:34 GMT
---response end---
200 OK
Length: unspecified [application/vnd.spring-boot.actuator.v3+json]
Saving to: ‘info.1’
[ <=> ] 83 --.-K/s in 0s
2025-07-17 13:45:08 (9.47 MB/s) - ‘info.1’ saved [83]
URI encoding = ‘UTF-8’
Converted file name 'info' (UTF-8) -> 'info' (UTF-8)
Converted file name 'info' (UTF-8) -> 'info' (UTF-8)
--2025-07-17 13:45:08-- http://10.100.22.48:8081/wechat-web/actuator/info
Reusing existing connection to 10.100.22.48:8081.
Reusing fd 3.
---request begin---
GET /wechat-web/actuator/info HTTP/1.1
User-Agent: Wget/1.14 (linux-gnu)
Accept: */*
Host: 10.100.22.48:8081
Connection: keepalive
---request end---
HTTP request sent, awaiting response...
---response begin---
HTTP/1.1 200 OK
transfer-encoding: chunked
Content-Type: application/vnd.spring-boot.actuator.v3+json
Date: Thu, 17 Jul 2025 05:25:34 GMT
---response end---
200 OK
Length: unspecified [application/vnd.spring-boot.actuator.v3+json]
Saving to: ‘info.2’
[ <=> ] 83 --.-K/s in 0s
2025-07-17 13:45:08 (11.1 MB/s) - ‘info.2’ saved [83]
FINISHED --2025-07-17 13:45:08--
Total wall clock time: 0.1s
Downloaded: 3 files, 249 in 0s (9.25 MB/s)
可以看到第一个请求建立了socket 3，Connection: keepalive，请求成功，http响应状态码为200
第二个请求重用了第一个连接，socket 3，Connection: keepalive，请求成功，http响应状态码为200
第三个请求依然重用了第一个连接，socket 3，Connection: keepalive，请求成功，http响应状态码为200
网关是支持长连接的，反馈给负责运维Nginx的团队，负责运维Nginx的团队又查了半天，又找到我说还是得拜托我来调查解决掉这个问题。
深度调查
在测试环境Nginx机器10.100.8.11上使用tcpdump命令抓取与网关相关的流量包：
tcpdump -vv -i ens192 host 10.100.22.48 and tcp port 8081 -w /tmp/ng400.cap
找到出现http响应码为400的请求，可以看到流量包中的wechat-web/actuator/info请求响应为：HTTP/1.1 400 Bad Request
观察请求体，其中一个请求头Host的值为：http_gateways，这引起了我的注意：
查阅资料得到，HTTP/1.1协议规范定义HTTP/1.1版本必须传递Host请求头
- Both clients and servers MUST support the Host request-header.
- A client that sends an HTTP/1.1 request MUST send a Host header.
- Servers MUST report a 400 (Bad Request) error if an HTTP/1.1
request does not include a Host request-header.
- Servers MUST accept absolute URIs.
https://www.w3.org/Protocols/rfc2616/rfc2616-sec5.html#sec5.2
https://www.w3.org/Protocols/rfc2616/rfc2616-sec19.html#sec19.6.1.1
Host的格式可以包含：. 和 - 特殊符号，_ 不被支持
查阅Nginx的官方文档得知，proxy_set_header 有两个默认配置：
proxy_set_header Host $proxy_host;
proxy_set_header Connection close;
https://nginx.org/en/docs/http/ngx_http_proxy_module.html#proxy_set_header
可以看出Nginx启用了HTTP/1.1协议，Host如果没有指定会取$proxy_host，那么使用upstream的情况下，$proxy_host就是upstream的名称，而此处的upstream中包含_，不是合法的Host格式。
HTTP/1.1规定必须传递Host的一方面原因就是为了支持单IP地址托管多域名的虚拟主机功能，方便后端服务根据不同来源Host做不同的处理。
Older HTTP/1.0 clients assumed a one-to-one relationship of IP addresses and servers; there was no other established mechanism for distinguishing the intended server of a request than the IP address to which that request was directed. The changes outlined above will allow the Internet, once older HTTP clients are no longer common, to support multiple Web sites from a single IP address, greatly simplifying large operational Web servers, where allocation of many IP addresses to a single host has created serious problems.
那么只要遵循了HTTP/1.1协议规范的框架（Tomcat、SpringCloudGateway、...）在解析Host时发现Host不是合法的格式时，就响应了400。
本地搭建了一个测试环境，debug了下网关的代码，在SpringCloudGateway解析http请求类ReactorHttpHandlerAdapter中的apply方法里面可以看到，解析Host失败会响应400：
下面是SpringCloudGateway解析http请求类ReactorHttpHandlerAdapter中的apply方法逻辑：
public Mono<Void> apply(HttpServerRequest reactorRequest, HttpServerResponse reactorResponse) {
NettyDataBufferFactory bufferFactory = new NettyDataBufferFactory(reactorResponse.alloc());
try {
ReactorServerHttpRequest request = new ReactorServerHttpRequest(reactorRequest, bufferFactory);
ServerHttpResponse response = new ReactorServerHttpResponse(reactorResponse, bufferFactory);
if (request.getMethod() == HttpMethod.HEAD) {
response = new HttpHeadResponseDecorator(response);
}
return this.httpHandler.handle(request, response)
.doOnError(ex -> logger.trace(request.getLogPrefix() + "Failed to complete: " + ex.getMessage()))
.doOnSuccess(aVoid -> logger.trace(request.getLogPrefix() + "Handling completed"));
}
catch (URISyntaxException ex) {
if (logger.isDebugEnabled()) {
logger.debug("Failed to get request URI: " + ex.getMessage());
}
reactorResponse.status(HttpResponseStatus.BAD_REQUEST);
return Mono.empty();
}
}
SpringCloudGateway通过debug级别日志输出这类不符合协议规范的日志，生产日志级别为info，因此不会打印这样异常的日志。
解决方案
既然HTTP/1.1协议规定必须传递Host且没有通过配置显式指定Nginx传递的Host时Nginx会有默认值，那么在Nginx的配置中增加传递Host的配置覆盖默认值的逻辑，查阅Nginx的文档，可以通过增加下面的配置解决：
proxy_set_header Host $host;
在测试环境Nginx9104端口代理配置中增加上面的配置，再次执行，请求正常响应200。
完整配置如下：
upstream http_gateways{
server 10.100.22.48:8081;
keepalive 30;
}
server {
listen 9104 backlog=512;
server_name wmg.test.com;
add_header X-Frame-Options "SAMEORIGIN";
add_header X-Content-Type-Options "nosniff";
add_header Content-Security-Policy "frame-ancestors 'self'";
location / {
proxy_set_header Host $host;
proxy_hide_header host;
proxy_http_version 1.1;
proxy_set_header Connection "";
client_max_body_size 100m;
add_header 'Access-Control-Allow-Origin' "$http_origin" always;
add_header 'Access-Control-Allow-Credentials' 'true' always;
add_header 'Access-Control-Allow-Methods' 'GET, POST, OPTIONS, DELETE, PUT';
add_header 'Access-Control-Allow-Headers' '...';
if ($request_method = 'OPTIONS') {
return 204;
}
proxy_pass http://http_gateways;
}
}
解决方案不止一个:
- 可以修改upstream的名称，去掉不支持的_，比如更换为：http-gateways、httpgateways
- 还可以直接指定Host的值为域名（domain），proxy_set_header Host 'doamin';
总结
这个问题只要在测试环境测试下，是必现的，不属于测试case没有覆盖到的范畴，一定要重视测试流程，很多流程看似繁琐，其实都是血与泪的教训得来的。
本可避免的P1事故：Nginx变更导致网关请求均响应400的更多相关文章
- 一次不规范HTTP请求引发的nginx响应400问题分析与解决
背景 最近分析数据偶然发现nginx log中有一批用户所有的HTTP POST log上报请求均返回400,没有任何200成功记录,由于只占整体请求的不到0.5%,所以之前也一直没有触发监控报警,而 ...
- Nginx 流量带宽等请求状态统计( ngx_req_status)
Nginx 流量带宽等请求状态统计 ( ngx_req_status) 插件下载地址: wget http://nginx.org/download/nginx-1.4.2.tar.gz git c ...
- 微信内嵌浏览器sessionid丢失问题，nginx ip_hash将所有请求转发到一台机器
现象微信中打开网页,图形验证码填写后,经常提示错误,即使填写正确也会提示错误,并且是间歇性出现. 系统前期,用户使用主要集中在pc浏览器中,一直没有出现这样的问题.近期有部分用户是在微信中访问的,才出 ...
- nginx负载下站点错误响应会导致其他节点重复响应问题的解决过程
目录 前言 问题来了 问题又来了 问题分析 困惑 转机 后续 前言: 这是我上周工作过程中的一次解决问题的过程.解决的是nginx负载下站点错误响应导致其他节点重复响应. 我在整理这个记叙文时,在给这 ...
- Nginx+Lua+Redis 对请求进行限制
Nginx+Lua+Redis 对请求进行限制 一.概述 需求:所有访问/myapi/**的请求必须是POST请求,而且根据请求参数过滤不符合规则的非法请求(黑名单), 这些请求一律不转发到后端服务器 ...
- nginx源代码分析--读请求主体（1）
首先,读取请求体已进入HTTP要求11相,我们需要做的请求正文部分处理一些模块,所以这个模块需要注册功能在这个阶段,在阅读功能要求的身体ngx_http_read_client_request_bod ...
- 记一次nginx强制将https请求重定向http
公司要做小程序,但是发现小程序只允许https请求 所以查了查资料使用nginx重定向请求得方式做 以下是过程: 阿里云ssl证书管理控制台申请ssl证书 下载nginx 证书: 解压后得到后缀为ke ...
- nginx/ajax跨子域请求的两种现代方法以及403解决
因为面向互联网的性质,我们公司的大部分系统都采用多子域的方式进行开发和部署,以达到松耦合和分布式的目的,因此子系统间的交互不可避免.虽然通过后台的rpc框架解决了大部分的交互问题,但有些情况下,前端直 ...
- nginx限制请求之三：Nginx+Lua+Redis 对请求进行限制
相关文章: <高可用服务设计之二:Rate limiting 限流与降级> <nginx限制请求之一:(ngx_http_limit_conn_module)模块> <n ...
- NGINX: 配置跨域请求
说明: 内容全部来自 SegmentFault Developer Nginx 配置跨域请求 跨域请求失败, nginx 报错: 403 No 'Access-Control-Allow-Origin ...
随机推荐
- 第六章: SEO与交互指标
第6章: SEO与交互指标 在当今的SEO环境中,Google越来越重视用户交互指标,如页面停留时长.交互性能等.本章将深入探讨如何优化网页速度和用户交互体验,以提升SEO效果和用户满意度. 1. G ...
- SignalR服务端嵌入到WPF
用的是.net framework 4.7.2的WPF. <Window x:Class="EBServerTry.MainWindow" xmlns="http: ...
- Data aggregation and group operations in pandas
Data aggregation and group operations in pandas After loading,merging and preparing a dataset,you ma ...
- 计算机组成原理 L03 计算单元（ALU）复习-1
计算机组成原理 L03 计算单元(ALU)复习-1 进位传输函数和进位产生函数 类推得到 gi 与操作得到 0000 0000 0010 0011 pi 或操作得到 1111 1111 1111 10 ...
- 从传统搜索到智能问答：自研 RAG 系统的技术实践与工程落地
一.引言 在数字化转型浪潮下,企业知识服务体系正经历着深刻变革.如何让用户高效获取所需信息,成为提升产品竞争力和用户满意度的关键.葡萄城作为企业级开发工具与解决方案提供商,长期致力于知识服务体系的建设 ...
- socket编程浅知识
1:网络7层和tcp/ip5层 tcp协议; 三次握手 四次挥手 使用字节流进行信息交互 2:IP和端口 ip: 计算机在网络里面的唯一标识 端口: 程序在电脑里面的唯一标识 3: socket编 ...
- AI接口实现：简单实现Viper配置管理
简介 前面实现的一个简易suno-api.是使用cookie来获取suno-token发起请求的.当时并没有通过配置的方式来获取cookie,而是直接在代码中写死了cookie的值,这种做法并不好,所 ...
- 你了解CAS吗？有什么问题吗？如何解决？
什么是CAS? CAS全称Compare And Swap,比较与交换,是乐观锁的主要实现方式.CAS在不使用锁的情况下实现多线程之间的变量同步.ReentrantLock内部的AQS和原子类内部都使 ...
- 东航MU5735空难事件总结与分析
东航MU5735空难事件总结与分析 事件概述 日期:2022年3月21日 航班:东方航空MU5735(昆明长水机场→广州白云机场) 机型:波音737-800(注册号B-1791,机龄6.8年) 伤亡: ...
- 数栈技术分享：用短平快的方式告诉你Flink-SQL的扩展实现
数栈是云原生-站式数据中台PaaS,我们在github和gitee上有一个有趣的开源项目:FlinkX,FlinkX是一个基于Flink的批流统一的数据同步工具,既可以采集静态的数据,也可以采集实时变 ...