部署于Google Cloud Run的Express服务器返回204状态码时触发502 Bad Gateway错误排查问询

我之前在Cloud Run上部署Express服务时遇到过完全一样的问题——本地运行正常，返回200状态码也没问题，唯独返回204时会被转换成502，错误提示也是upstream connect error or disconnect/reset before headers. reset reason: protocol error。折腾一阵后发现，问题出在响应处理方式不符合Cloud Run代理的HTTP协议规范，结合你的代码和配置，给你几个具体的修复点：

1. 修复sendStatus的参数错误 #

你的代码里写的是res.sendStatus('204');，但res.sendStatus()方法接受的是数字类型的状态码，不是字符串！当你传入字符串'204'时，Express会把它当成状态描述文本，实际返回的状态码可能异常，或者内部处理时产生格式问题，导致Cloud Run代理判定为协议错误。

2. 移除多余的res.end()调用 #

res.sendStatus()方法已经帮你完成了三件事：设置状态码、配置对应状态文本、结束响应流。手动调用res.end()会导致重复结束响应，触发HTTP协议层面的错误，Cloud Run代理检测到后就会返回502。

修正后的代码 #

把你的端点代码改成这样：

app.post('/', [cors(corsConfig), jsonParser], async (req, res) => {
  res.setTimeout(timeout, () => {
    log('timeout');
    // 使用数字状态码，无需额外调用res.end()
    res.sendStatus(204);
  });
});

额外排查和优化点 #

• 检查CORS中间件配置：确保cors中间件不会在204响应中添加不必要的头（比如强制设置Content-Length），204响应要求完全没有响应体，任何表示存在body的头都会被Cloud Run代理判定为协议错误。
• 升级Node.js版本：你使用的Node.js 12已结束生命周期（EOL），虽然这不一定是直接原因，但升级到LTS版本（比如18或20）可以避免旧版本的HTTP响应处理bug，同时提升安全性。
• 重新部署验证：修改代码后，记得重新构建Docker镜像并部署到Cloud Run，确保所有配置生效。

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