Express控制器含Axios/Node HTTPS请求时无法发送响应问题咨询

核心根因 #

Node HTTP/HTTPS和Express的res.send()不存在已知的交互兼容问题，你遇到的现象是Webhook服务商（Wix）主动超时断连导致的：

• Wix官方Webhook的超时阈值为5秒，如果你代码中await的第三方请求耗时超过这个阈值，Wix会主动断开客户端和你的服务之间的TCP连接。当你后续执行res.send()时，请求连接已经被销毁，自然无法发送响应，所以Ngrok抓不到返回包。
• 你自己用curl、Ngrok重放请求时，客户端不会主动断开连接，所以不管异步请求耗时多久都能正常拿到响应，这就是两类请求的核心差异。
• 另外你的原生HTTPS请求工具函数写法存在不规范问题：你监听的是响应的close事件触发resolve，正确应该监听end事件。close是TCP连接完全关闭的事件，触发时机晚于数据接收完成的end事件，极端情况会导致Promise延迟resolve，进一步放大超时风险。

修复方案 #

1. 修正HTTPS请求工具写法 #

把res.on('close', () => { resolve(data.toString()) })改为监听end事件：

res.on('end', () => {
  resolve(data.toString())
})

2. 解耦Webhook响应和耗时逻辑 #

Webhook接收接口的核心原则是最快速度返回响应，所有耗时的业务逻辑（包括第三方请求、数据库操作等）都应该异步执行，不要阻塞响应返回：

const handler = async (req, res) => {
  console.log('RECEIVED WIX WEBHOOK')
  // 先返回响应，避免Wix超时断连
  res.send({ success: true })
  // 异步执行耗时逻辑，不需要await
  setImmediate(async () => {
    const result = await request({
      hostname: 'example.com',
      port: 443,
      path: '/',
      method: 'GET',
    })  
    console.log('GOT RESULT:', result)
    // 后续其他业务逻辑
  })
}

如果逻辑复杂度高、请求量较大，建议引入专业异步队列处理，避免进程重启导致任务丢失。

3. 可选：排查耗时瓶颈 #

如果确实需要同步等待第三方请求结果再返回，可以加日志打印各步骤耗时，优化第三方请求的速度，确保整体耗时控制在5秒以内：

const handler = async (req, res) => {
  const start = Date.now()
  console.log('BEFORE REQUEST')
  const result = await request({/* 请求配置 */})
  console.log('REQUEST COST:', Date.now() - start, 'ms')
  return res.send({ success: true })
}

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