AI 服务 502/504 怎么排查？Nginx、后端服务和超时配置

AI 服务部署在 VPS 上，跑着跑着突然 502 或 504，Nginx 返回空白页或者超时提示。这不是你一个人遇到，我排查过不下 30 个类似案例，问题基本集中在 Nginx 反向代理配置、后端服务状态、以及超时设置三块。别急着重装系统，按下面步骤走，十分钟内能定位。

502/504 常见原因分析

502 Bad Gateway 意味着 Nginx 作为反向代理，收到了上游后端服务的无效响应；504 Gateway Timeout 则是后端在规定时间内没响应。对于 AI 服务（比如 Ollama、Open WebUI、n8n 调用的 AI Agent），这两种错误高频出现，原因通常是：

• Nginx 配置没正确转发请求

• 后端服务没启动或崩溃

• 后端处理请求耗时超过 Nginx 超时限制

• VPS 资源（内存/CPU）不足，导致后端进程被杀死或响应极慢

Nginx 反向代理配置排查

proxy_pass 写错或指向无效地址

最常见坑：`proxy_pass` 后的 URL 末尾少了 `/`，或者端口写错。检查你的 Nginx 配置：

nginx
server {
listen 80;
server_name yourdomain.com;

location / {
proxy_pass http://127.0.0.1:8080; # 这里注意是否带斜杠
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
}
}

如果后端服务监听在 8080，但 Nginx 配置里写成了 8081，自然 502。建议用 `curl -v http://127.0.0.1:8080` 先确认后端本身能响应。

缓冲和头部设置不对

AI 请求可能携带大 payload（比如上传图片或长文本），Nginx 默认缓冲区可能不够。加以下配置：

nginx
proxy_buffering off;
proxy_request_buffering off;
proxy_http_version 1.1;
proxy_set_header Connection "";

特别是使用 WebSocket 或流式响应（如 Open WebUI、Claude Code 的流式输出）时，`proxy_http_version 1.1` 和关闭缓冲是必须的。

后端服务状态检查

服务是否存活

不管是 Docker 部署还是直接 systemd 运行，先确认进程在跑：

docker ps | grep ollama
docker logs <容器ID> –tail 50

systemctl status open-webui
journalctl -u open-webui -n 50 –no-pager

常见错误：Docker 容器重启策略没设，OOM 被杀后没自动拉起。建议加 `–restart unless-stopped`。

端口监听确认

用 `ss -tlnp` 或 `netstat -tlnp` 看后端服务是否在预期端口监听。比如 Ollama 默认 11434，Open WebUI 默认 8080。如果端口没监听，服务可能启动失败，查看日志找原因（比如 GPU 驱动缺失、模型加载失败）。

超时配置不足

这是 AI 服务 504 的头号元凶。AI 模型推理时间可能很长（尤其大模型或复杂 Agent 任务），Nginx 默认 `proxy_read_timeout` 只有 60 秒。如果你部署了 Hermes Agent 或 Codex 做自动化任务，一个 Agent 循环可能跑几分钟。

Nginx 层超时调整

在 `location` 或 `http` 块里增加：

nginx
proxy_connect_timeout 60s;
proxy_read_timeout 300s; # AI 推理可能超过 5 分钟，设长点
proxy_send_timeout 60s;

对于流式响应，建议 `proxy_read_timeout` 设到 600s 甚至更长，或者根据业务需求调整。

后端服务自身超时

有些 AI 框架（如 Ollama、vLLM）有自己的超时参数。比如 Ollama 的 `OLLAMA_HOST` 环境变量、`OLLAMA_KEEP_ALIVE` 等。如果 Nginx 超时设了 300s，但 Ollama 默认请求超时只有 120s，依然会 504。检查后端文档，统一超时配置。

资源耗尽导致 502/504

VPS 内存不足时，Linux 的 OOM Killer 会杀掉最占内存的进程（通常是 Ollama 或模型推理进程）。此时 Nginx 会返回 502。排查方法：

free -h

dmesg | grep -i oom

journalctl -k | grep -i "out of memory"

如果频繁 OOM，要么升级 VPS 内存，要么限制模型使用的内存（比如 Ollama 设置 `OLLAMA_NUM_PARALLEL` 为 1，或使用量化模型）。

老鸟叮嘱避坑

1.不要直接改 Nginx 全局超时到很大值：全局设 600s 会拖垮 VPS 连接数，建议只在特定 location 里加大。
2.日志是救命稻草：先看 `/var/log/nginx/error.log`，再看后端日志。很多 502 是因为后端返回了 HTTP 500，Nginx 转成 502。
3.Docker 网络模式：如果后端是 Docker 容器，Nginx 在宿主机，`proxy_pass` 不能写 `localhost` 或 `127.0.0.1`，除非容器用了 `–network host`。否则要用容器名或 `172.17.0.x` 地址。
4.AI Agent 类服务注意流式响应：如果用了 Claude Code 或 Hermes Agent，它们可能通过 SSE（Server-Sent Events）返回数据，Nginx 必须关闭缓冲并保持长连接。

FAQ

Q1: AI 服务偶尔 502 但重启后正常，是什么原因？
A: 大概率是内存不足导致进程被 OOM Killer 杀掉。检查 `dmesg | grep oom`，确认后要么加内存，要么降低模型并发。

Q2: Nginx 返回 504，但后端日志显示请求已处理完成？
A: 可能是后端处理时间超过了 Nginx 的 `proxy_read_timeout`，但后端在超时后才返回。可以看后端日志里的处理耗时，然后调大 Nginx 超时。

Q3: 我部署了 Open WebUI + Ollama，外网访问经常 502，内网正常。
A: 检查 Nginx 的 `proxy_set_header Host` 和 `proxy_set_header X-Forwarded-For`，同时确保 DNS 解析正常。另外，如果用了 CDN，CDN 超时也可能导致 502。

Q4: 使用 Docker 部署时，Nginx 容器怎么访问 Ollama 容器？
A: 使用 Docker Compose 时，服务名可以直接作为 hostname。例如 `proxy_pass http://ollama:11434;`。注意网络要自定义 bridge，并配置 `depends_on`。

Q5: 502 错误日志里出现 “upstream prematurely closed connection” 是什么意思？
A: 后端主动断开了连接。常见原因：后端进程崩溃、OOM、或者请求体太大导致后端拒绝。检查后端日志和资源使用。

Q6: AI Agent 调用 MCP 工具时返回 504，怎么调？
A: MCP 调用可能涉及外部 API 请求，超时要分两层：Nginx 到 Agent 的超时，以及 Agent 到外部 API 的超时。建议在 Agent 配置里加大请求超时，同时调大 Nginx 的 `proxy_read_timeout`。

排查 502/504 时，别被表象迷惑。先确认后端服务活着，再看 Nginx 配置和超时，最后查资源。大部分 AI 服务部署问题都出在这三个环节，一个一个排除，基本能解决。