最快方式是用curl绕过Nginx直连后端：若流式响应正常，则问题锁定在Nginx代理层；重点测TTFB（time_starttransfer），理想≤200ms，超500ms说明后端或Nginx转发有瓶颈；需加-N禁用curl缓冲，并结合stdbuf、ts观察分块到达节奏，验证proxy_buffering是否关闭。
直接用 curl 绕过 Nginx 测后端，是判断问题出在哪儿的最快方式。如果直连后端流式响应正常，那基本就能锁定是 Nginx 代理层的问题。
测首字节延迟（TTFB）
首字节时间反映的是从发起请求到收到第一个数据块的耗时，对 AI 对话体验非常关键。用带时间戳的 curl 即可快速测量：
curl -N -s -w "TTFB: %{time_starttransfer}s\n" http://localhost:8080/chat -H "Accept: text/event-stream"- 重点关注
time_starttransfer值，理想应 ≤200ms；若超过 500ms，说明后端处理或 Nginx 转发有瓶颈 - 加
-N参数禁用 curl 自身缓冲，避免干扰结果
测长连接稳定性（30秒+空闲保持）
SSE 或流式接口常需维持几十秒甚至数分钟的连接。测试重点不是“能不能连上”，而是“空闲时会不会断”：
- 启动一个持续接收的 curl：
curl -N http://your-domain.com/chat -H "Accept: text/event-stream" - 不发送任何数据，只观察连接是否在 30–60 秒后被主动关闭（出现
Empty reply from server或连接中断） - 若中断，大概率是
proxy_read_timeout设置过短，或后端未发心跳（如: ping注释行）
测真实流式行为（分块到达 vs 一次性刷出）
流式效果是否被破坏，不能只看最终结果，要看数据抵达的节奏：
- 用
curl -N加stdbuf -oL强制行缓冲：stdbuf -oL curl -N http://... | ts "%H:%M:%.S" - 观察每行输出的时间戳间隔：理想是每生成一个 token 就立刻打印一行（如每 100–300ms 一行）
- 如果前几秒没输出，然后突然刷出 5–10 行，说明 Nginx 缓冲未关（
proxy_buffering on）或proxy_busy_buffers_size过大
压测并发长连接下的内存与延迟表现
单连接正常不代表线上稳定。AI 接口常面临突发连接涌入，需验证 Nginx 在压力下的行为：
- 用
hey或vegeta启动 100+ 并发 SSE 连接，持续 2 分钟：hey -c 100 -z 2m -H "Accept: text/event-stream" https://your-domain.com/chat - 监控 Nginx 进程内存（
ps aux --sort=-%mem | head -5），若单 worker 内存超 500MB，需检查proxy_buffer_size和proxy_busy_buffers_size - 记录各连接的 TTFB 分布，P95 > 800ms 就说明存在排队或缓冲积压
