部署至Cloud Foundry的Express服务始终1分钟超时问题排查

问题根源复盘 #

你碰到的这个1分钟超时问题，核心原因就是Cloud Foundry的GoRouter——这个组件是PCF/PWS用来把外部请求转发到你的应用的反向代理，它默认有1分钟的空闲连接超时规则。而且Pivotal Web Services作为多租户平台，确实不允许单个用户修改这个全局配置，毕竟会影响所有租户。

你之前在代码里试的server.setTimeout()、express-timeout中间件这些方法之所以没用，是因为这些都是控制你的Node.js服务本身的超时，而GoRouter是在你的服务和客户端之间的中间层，它的超时规则完全独立，和你的应用配置不搭边。

关于“无数据ping”的可行性 #

你问能不能不用发大量空格，用空字符或者空字符串来保活？这里得说清楚：

• 空字符串（""）肯定不行——因为它不会产生任何实际传输的字节，GoRouter会觉得连接还是空闲的，照样超时。
• 空字符（\0）是可行的——它是一个合法的ASCII字节，GoRouter会把它当成有效传输，从而重置超时计时器。

不过这里有个小坑：如果你的响应是JSON或者普通文本，空字符可能会让客户端的解析器报错。所以更稳妥的方式是发送兼容性更好的占位符，比如单个空格（ ）或者换行符（\n），虽然会多几个字节，但几乎不会影响响应大小，而且所有客户端都能正常处理。

另外，要实现这种中途保活，必须用HTTP分块传输编码——也就是不要给响应设置固定的Content-Length，让Express自动用chunked模式发送响应。如果设置了固定长度，GoRouter会一直等完整响应，中途发的字节只会被当成响应内容的一部分，起不到保活的作用。

具体代码实现 #

给你一个Express的示例，用空格做保活，同时保证响应合规：

app.get('/long-running-job', (req, res) => {
  // 开启分块传输，不设置Content-Length
  res.set('Transfer-Encoding', 'chunked');
  res.set('Content-Type', 'application/json');

  // 每10秒发一个空格，重置GoRouter超时
  const keepAlive = setInterval(() => {
    // 用res.write发送，不能用res.send（会直接结束响应）
    res.write(' ');
  }, 10000);

  // 模拟2分钟的长任务（超过GoRouter默认超时）
  setTimeout(() => {
    clearInterval(keepAlive);
    // 发送最终的响应内容
    res.end(JSON.stringify({ status: 'done', result: 'your-data-here' }));
  }, 120000);
});

更优雅的替代方案 #

如果保活的方式还是让你觉得别扭，那可以换个思路——把长任务改成异步模式：

1. 客户端发起请求后，服务端立即返回一个唯一的任务ID
2. 客户端每隔一段时间用这个ID轮询服务端，获取任务进度或结果
3. 任务完成后，服务端返回最终结果

这种方式完全避开了GoRouter的超时限制，而且更符合HTTP的无状态设计理念，也更容易排查问题。

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