Ubuntu服务器上Fetch API流式响应失效问题求助

核心问题分析 #

本地macOS能正常分块接收后端流响应，Ubuntu生产环境却一次性接收，结合HTTPS和304的异常，大概率是代理/服务器的响应缓冲机制导致，其次是后端响应头配置缺失。

分步解决方案 #

1. 修复后端响应头与输出逻辑 #

Express默认不会强制开启分块传输，且生产环境可能缓冲输出，需手动配置：

// 在接口开头添加响应头配置
res.set({
  'Transfer-Encoding': 'chunked', // 明确开启分块传输
  'Cache-Control': 'no-cache, no-store, must-revalidate', // 禁用所有缓存
  'Connection': 'keep-alive',
  'Content-Type': 'text/plain; charset=utf-8' // 根据实际返回内容调整，避免JSON类型被代理解析缓冲
});

// 修改LLM的token回调，增加flush强制发送
{
  handleLLMNewToken(token: string) {
    res.write(token);
    res.flush(); // 强制Node.js立即输出分块，避免缓冲
  },
}

注意：不要设置Content-Length头，分块传输不需要这个，否则会触发代理的完整响应缓冲。

2. 关闭反向代理（如Nginx）的响应缓冲 #

Ubuntu生产环境通常会用Nginx做反向代理，默认会缓冲所有响应直到完整，需在对应location块中添加：

location /v1/embedding/ask {
  proxy_pass http://your-backend-upstream;
  proxy_buffering off; # 核心：关闭代理缓冲
  proxy_cache off;
  proxy_set_header Connection '';
  proxy_http_version 1.1; # 确保HTTP/1.1支持分块
  chunked_transfer_encoding on;
}

修改后重启Nginx：sudo systemctl restart nginx

3. 修复POST请求返回304的异常 #

POST请求返回304违反HTTP规范，是缓存机制错误触发导致：

• 后端登录接口添加响应头：res.set('Cache-Control', 'no-cache, no-store')
• 前端Fetch请求显式禁用缓存：

const response = await fetch(`${domainConfig.BACKEND_DOMAIN_NAME}/v1/embedding/ask`, {
  method: 'POST',
  body: JSON.stringify(body),
  headers: {
    'Content-Type': 'application/json',
  },
  cache: 'no-store' // 强制禁用缓存
});

4. 验证排查 #

用curl直接测试后端接口，确认分块是否生效：

curl -v https://your-backend-domain/v1/embedding/ask -X POST -H "Content-Type: application/json" -d '{"prompt": "your-test-query"}'

如果curl能实时看到token输出，说明后端配置正常，问题在前端或代理；如果仍是一次性输出，检查Node.js HTTPS服务器是否有额外缓冲配置。

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