客户端 timeout 设成 600 秒，晚高峰 8 个并发就把 8 个 worker 全占住，健康检查开始返回 504。第一次遇到会往复杂处想，其实漏掉的多是个小前提。
curl -m 30 https://api.example.com/v1/chat -d @req.json
curl -s -o /dev/null -w '%{http_code}' http://127.0.0.1:8080/healthz
同步阻塞调用把线程绑在请求上，超时又设得比上游实际耗时还长。上游一慢，线程全在等，新请求排不进来。这一点先确认清楚，后面就不用反复试。
「超时设置过长」这类改动最怕改一半，回滚脚本先准备好，再动生产。把这次用到的命令存进笔记，比记住结论有用，换个环境还能照着走。
改完隔一天再看一次，当场正常不代表能稳住。测试环境和线上的差别，往往就在版本号和那几行被忽略的配置上。
线上出问题先对时间点，跟发布、备份、任务执行的时刻排一排，能省掉一半功夫。
具体做法是，超时按 P99 设 30 秒 不要设成十分钟；改成异步调用或流式读取 释放等待线程；模型调用单独一个线程池做隔离；压测确认 50 并发下健康检查仍正常。
改完照着核一遍，50 并发压测时健康检查返回 200 线程池活跃数不再打满。