Express API返回重复100 Continue响应的排查与解决咨询

咱们先拆解这个重复100 Continue响应的可能成因，再对应给出解决办法：

可能的成因 #

1. 反向代理与后端服务的双重触发 #

100 Continue是HTTP协议中用于告知客户端可以发送请求体的响应，通常只有当请求携带Expect: 100-continue头时才会触发。但从你的请求示例看，客户端没发这个头——那大概率是Nginx和Express都在处理请求时主动触发了这个响应：

• Nginx作为反向代理，若默认配置中对Expect头的处理逻辑有偏差，可能会先返回一次100 Continue；
• 后端Express应用的中间件（比如body-parser，它默认会自动处理100 Continue）又再次触发了一次响应，最终导致两次重复。

2. 服务器端的WAF/防火墙插入额外响应 #

从你提供的响应里的Set-Cookie（比如WASID_HAG、WAAK_HAG这类标识）来看，你的服务器环境很可能部署了Web应用防火墙（WAF）或者类似的安全设备。这类设备有时会在请求链路中自动插入100 Continue响应，再加上Nginx/Express本身的响应，就会出现重复。而本地环境没有这类安全设备，所以不会有这个问题。

3. 代理配置的遗留问题 #

你提到之前用Express作为反向代理，后来切换到Nginx但问题未解决——可能是之前的Express代理配置有残留的逻辑（比如强制发送100 Continue的代码），或者Nginx的配置继承了之前的错误设置。

解决办法 #

第一步：禁用Nginx对Expect头的处理 #

在Nginx对应location的配置块中添加以下指令，让Nginx忽略客户端的Expect头（即使存在），避免触发第一次100 Continue：

location /<my-endpoint> {
    # 其他代理配置...
    proxy_set_header Expect "";
    proxy_pass http://your-express-upstream;
}

这个配置会清空请求中的Expect头，后端Express就不会收到触发100 Continue的信号，自然不会再返回这个响应。

第二步：检查Express中间件的设置 #

如果第一步没解决，检查Express中是否有手动处理100 Continue的代码。比如有些开发者会手动调用req.continue()，如果不小心调用了两次（比如在多个中间件里重复处理），就会返回两次响应。可以排查所有涉及请求体处理的中间件，确保没有重复触发的逻辑。

第三步：排查服务器端安全设备 #

如果前两步都无效，联系你的服务器运维团队，检查部署在Nginx前端的WAF、防火墙或负载均衡设备——这类设备有时会被配置为自动插入100 Continue响应，需要调整它们的规则，避免重复发送。

关于本地环境与服务器环境的差异 #

本地没有这个问题，核心原因就是服务器环境存在额外的网络层/安全层设备（比如WAF、防火墙），或者Nginx的默认配置与本地不同。本地通常是直接请求Express，没有中间代理或安全设备，自然不会触发多次100 Continue。

内容的提问来源于stack exchange，提问作者Oskar