为什么本地测试流畅的 Agent 上线后打字全卡死？本章详解长周期流式连接的底层通信痛点、Nginx 响应缓冲陷阱与 Linux 高可用守护。
传统互联网 API（查询列表、提交表单）通常在 50ms~300ms 内完成一次完整的 HTTP 请求并立即关闭连接。然而在生产级 Agent 系统中：
Nginx 默认的设计哲学是“帮后端聚合网络响应以提升吞吐”。当后端每次吐出 1 个字符时，Nginx 会默默将其塞进缓冲区，可能引入额外缓冲与延迟，实际刷新时机取决于配置和数据流。用户端表现为：等待 40 秒白屏毫无动静，最后瞬间刷出一整大屏文字！
# 在 Nginx server 块内针对 Agent 流式路由进行专门配置
location /api/agent/ {
proxy_pass http://agent_backend_upstream;
# 1. 彻底禁用响应缓冲，实现 0 延迟逐字转发
proxy_buffering off;
proxy_cache off;
# 可由上游响应头 X-Accel-Buffering: no 控制缓冲
# 2. 避免大模型长推理被默认 60s 超时提前掐断
proxy_read_timeout 600s;
proxy_send_timeout 600s;
# 3. 启用 HTTP/1.1 长连接连接池与 chunked 传输
proxy_http_version 1.1;
proxy_set_header Connection "";
chunked_transfer_encoding on;
# 4. 透传真实客户端 IP 与 Host
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
}在下方切换 Nginx 的核心配置参数，点击“模拟接收流式数据”，直观感受配置失误对用户体验造成的毁灭性打击：
由于每个在线用户在对话期间都可能保持一条持续数分钟的 SSE 长连接，并发连接数会迅速累积。
EMFILE: too many open files 导致服务器拒绝所有新请求！应按并发和资源实测后调整（例如 65536）。Restart=always 与 RestartSec=5，当大模型推理过程中偶发 OOM 或异常未捕获异常退出时，操作系统自动在 5 秒内重启拉起服务。