对话笔记直发:DeepSeek-API问题与Nginx超时调整说明。分类:网络基建。

DeepSeek API 问题与 Nginx 超时调整说明

1. 背景

在双机统一升级完成后,用户反馈两台服务器上的 AI-chat 出现“发送消息但无法获得回复”的现象。

经现场排查确认:

  1. 两台服务器基础健康检查均正常。
  2. 前端到后端的基础 API 链路正常。
  3. 聊天流接口请求可以发出,但前端 Nginx 日志中出现 upstream timed out while reading upstream。
  4. 后续进一步确认,本次“无回复”的主要根因是 DeepSeek 官方 API 侧问题,而不是本地数据库、登录态或核心业务代码故障。

2. 本次实际修改内容

本次为降低流式接口被代理层过早切断的概率,只修改了前端 Nginx 代理超时配置。

修改文件:

  1. frontend/nginx.default.conf

新增配置:

proxy_read_timeout 3600s;
proxy_send_timeout 3600s;
send_timeout 3600s;

保留原配置:

proxy_pass http://backend:3001/api/;
proxy_http_version 1.1;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_buffering off;
proxy_cache off;

3. 修改范围

本次修改只涉及前端容器反向代理层。

明确未修改内容:

  1. SQLite 数据库文件
  2. backend/.env 中的 DeepSeek Key
  3. 后端业务代码逻辑
  4. 用户数据
  5. 数据库路径
  6. 登录态逻辑

4. 已执行对象

本次修改已同步到以下两台服务器:

  1. 你的服务器IP(已脱敏)
  2. 你的服务器IP(已脱敏)

并已分别重建前端容器。

5. 风险判断

5.1 正面作用

该修改的目标是:

  1. 让流式聊天接口在上游响应较慢时,不被前端 Nginx 过早切断
  2. 提高 SSE/流式返回场景下的稳定性

5.2 潜在副作用

该修改的潜在副作用主要是运行层面的,而不是数据层面的:

  1. 慢请求会在前端 Nginx 上保留更久
  2. 单个异常流请求占用连接的时间更长
  3. 在高并发下,连接资源占用可能略有增加

5.3 明确无此类风险

本次修改不会直接导致:

  1. 数据损坏
  2. 数据库迁移错误
  3. 用户数据丢失
  4. DeepSeek Key 丢失
  5. 登录功能异常

6. 当前结论

既然已确认本次“发消息无回复”的主因是 DeepSeek 官方 API 侧问题,那么本次 Nginx 超时放宽不是根因修复,但属于合理的生产容错优化。

更准确地说:

  1. 根因是上游模型服务异常或响应不稳定
  2. 本次改动是降低代理层过早断流的保护性调整

7. 是否需要撤回

当前建议:不需要立即撤回。

原因:

  1. 该修改风险较低
  2. 不涉及数据与核心配置破坏
  3. 对流式聊天接口而言,较长的代理超时通常是合理的生产配置
  4. 即使 DeepSeek 恢复正常,该配置仍有助于避免未来再次因首包较慢或响应停顿而被前端代理提前切断

8. 何时考虑回滚

仅在出现以下情况时,再考虑撤回或细化:

  1. 前端容器连接占用明显升高
  2. 发现大量长时间悬挂请求影响整体服务
  3. 后续决定把长超时仅收敛到聊天流接口,而不是整个 /api/

9. 后续更优方案

如果后面要进一步优化,可以考虑比“直接撤回”更稳妥的做法:

  1. 保留当前修复作为临时稳定方案
  2. 后续将超时规则细化到聊天流接口,例如 /api/chat/.../stream
  3. 普通 API 继续使用较短超时

这样可以兼顾:

  1. 流式聊天稳定性
  2. 普通接口资源控制

10. 最终建议

当前建议口径如下:

  1. 保留本次 Nginx 超时调整,不急于撤回
  2. 将本次故障归因为 DeepSeek 官方 API 问题
  3. 如后续需要进一步优化,再将长超时从全 /api/ 收敛到聊天流接口级别

注:本文涉及的服务器公网 IP / Tailnet / 局域网 IP 已脱敏,请替换为你自己的地址。


相关: 00-索引-网络基建索引 AI-chat-项目操作规范说明书