技术教程 2026-07-07 · 约 8 分钟

AI 顾问不通了？从 Nginx 到飞书 Webhook 的全链路排查指南

一、症状：页面在转，但没有回复

用户打开网站，点击 AI 顾问聊天按钮，对话窗口弹出来了，输入问题后发送——然后一直转圈，没有回复。

同时，原本应该在飞书群里弹出的客户咨询通知，也悄无声息。

这是一个典型的 AI 客服故障场景。不涉及 UI 层面的 bug，问题出在数据流的中段——从浏览器到 AI 后端再到通知渠道的某个环节断了。

二、排查框架：逐层收缩

面对「断连」类故障，最有效的方法是自顶向下逐层排查，每次缩小一半嫌疑范围：

1. 浏览器 → 公网 — 网站首页能打开吗？F12 看请求状态码
2. Nginx → 后端 — 公网访问 /api/chat 返回什么？
3. 后端进程 — 服务在运行吗？端口多少？
4. 后端 → 飞书 — 直接 cURL 飞书 Webhook 能通吗？

三、实战：502 追凶

第一步，访问首页 https://www.ai-singualliance.com — 正常 200。F12 打开开发者工具，Network 选项卡，发送一条聊天消息。POST /api/chat 返回 502 Bad Gateway。

502 意味着：Nginx 将请求转发到了某个后端，但那个后端拒绝了连接。Nginx 的 error log 通常是破案关键：

2026/07/07 09:30:00 [error] connect() failed (111: Connection refused)
while connecting to upstream,
upstream: "http://127.0.0.1:5000/api/chat"

错误信息直接告诉了我们：Nginx 试图将请求转发到 127.0.0.1:5000，但 5000 端口上没有人接。

四、交叉验证：5000 端口 vs 8080 端口

用 ss -tlnp 查看服务器所有监听端口：

# ss -tlnp | grep -E '5000|8080'
LISTEN  0  128  0.0.0.0:5000  0.0.0.0:*   users:(("gunicorn",pid=...))
LISTEN  0  128  0.0.0.0:8080  0.0.0.0:*   users:(("python3",pid=...))

两个端口都在监听。但 5000 是 Gunicorn（负责某套 API），8080 是 server_full.py（负责 AI 客服和飞书通知）。

用 cURL 直接测试 8080 端口：

$ curl -X POST http://127.0.0.1:8080/api/chat \
  -H "Content-Type: application/json" \
  -d '{"message":"你好"}'
{"reply":"你好！我是奇点境相AI顾问，有什么可以帮你的？"}

8080 工作正常。但 Nginx 将请求转发到了 5000。问题锁定在 Nginx 配置。

五、根因：Nginx proxy_pass 指向错误端口

查看 nginx.conf 中 HTTPS 443 server block 的 /api/ 位置配置：

# /etc/nginx/nginx.conf （HTTPS server block）
location /api/ {
    proxy_pass http://127.0.0.1:5000/api/;  # ❌ 指向 gunicorn
    proxy_set_header Host $host;
    proxy_set_header X-Real-IP $remote_addr;
    ...
}

5000 端口运行的是 Gunicorn + server:app（一个旧 API 服务），而真正处理 /api/chat 和 /api/feishu/notify 的 server_full.py 跑在 8080。

六、修复：一个 sed 命令

# 1. 备份
cp /etc/nginx/nginx.conf /etc/nginx/nginx.conf.$(date +%Y%m%d_%H%M%S).bak

# 2. 修改 proxy_pass 目标
sed -i 's|proxy_pass http://127.0.0.1:5000/api/;|proxy_pass http://127.0.0.1:8080;|' /etc/nginx/nginx.conf

# 3. 检查语法并重载
nginx -t && systemctl reload nginx

注意 proxy_pass 从 http://127.0.0.1:5000/api/; 改为 http://127.0.0.1:8080; 时，尾部少了 /api/。这是因为 5000 版本有 /api/ 路径后缀（路径会被拼接），而 8080 版本的 server_full.py 直接在根路径 / 上处理所有路由。

七、遍历验证

重载 Nginx 后，从三个角度验证链路完整性：

# 1. 本地验证
$ curl -s -o /dev/null -w "%{http_code}" http://127.0.0.1:8080/api/chat
200

# 2. 公网验证
$ curl -s -o /dev/null -w "%{http_code}" https://www.ai-singualliance.com/api/chat
200

# 3. 飞书通知链路
$ curl -s -X POST https://www.ai-singualliance.com/api/feishu/notify \
  -H "Content-Type: application/json" \
  -d '{"text":"测试消息"}'
{"status":"ok","feishu_response":{"StatusCode":0,"msg":"success"}}

# 4. 潜在客户提交表单链路
$ curl -s -X POST https://www.ai-singualliance.com/api/lead-capture \
  -H "Content-Type: application/json" \
  -d '{"name":"测试","contact":"13800138000","project":"AI","need":"咨询"}'
200

四个端点全部返回 200。飞书群里也收到了测试推送消息。

八、这类问题的共性模式

这次故障暴露了一个在成长型 Web 项目中很常见的架构债务：

• 两个 HTTP 服务竞争同一个域名下的 API 路径 — Gunicorn 跑旧 API（5000），server_full.py 跑新功能（8080），但 Nginx 只配了一个位置指向旧的
• 配置分散 — sites-enabled 下的解耦文件写了正确的端口，但 nginx.conf 主文件直接写死的配置优先级更高
• systemd vs nohup 混合管理 — 两个服务都是用 systemd 的 auto-restart 管理的，但运维过程中过渡期没有被清晰清理

九、预防措施

1. Nginx 配置只通过 sites-enabled 管理 — 避免直接在 nginx.conf 写 server block
2. 用一个 systemd 服务管理单一 HTTP 服务 — 旧服务退役时明确清理端口占用
3. 监控链路 — 设置公网端点的定时健康检查（每 5 分钟 curl 一次，失败时飞书告警）
4. 全量测试 — 上游引用改完配置后，需要全链路过一遍（本地 → 公网 → 后端回调）

---

有问题或想了解更多？
联系奇点境相AI顾问 · 返回博客首页