流量高峰时，源站连接池仅允许16个连接，代理却排着数百请求，随后大量报504；源站CPU、内存却不高。重启代理仅能短暂缓解，说明瓶颈可能在建连、复用、占满到超时链路，而非PHP代码。只盯“连接数高”，容易误判代理、PHP与数据库的联动瓶颈。
如果你正在选机器，或者想先把线路和配置跑通再谈长期方案，可以先看看这几家的线路说明和技术参数：bunnyproxy（海外服务器），先看清带宽线路、流量策略和退款条款，再决定要不要迁。
先确认池统计的是已建连接、活动请求还是等待任务。代理访问上游会经历建连、空闲连接复用、等待槽位和等待响应；同为504，根因却可能完全不同。
建连阶段应拆开DNS、TCP、TLS与首包耗时。池未满却频繁新建，可能是握手变慢、上游限制并发，或健康检查误杀可复用连接。复用阶段看Keep-Alive空闲时长、命中率及首包延迟；响应体未读完、空闲连接无法共享，也会形成假性耗尽。
活动连接达到上限后，新请求进入等待队列。应同时记录池水位、等待任务数、取连接耗时和总超时。等待吃满超时预算时，请求可能尚未到达源站便返回504；此时扩大PHP-FPM或数据库连接数，只会把压力推向更深处。
对齐同一分钟的四组证据：代理的建连失败率、池等待时长与状态码；源站的当前连接和请求耗时；PHP-FPM的活跃、饱和进程数；数据库的活跃会话、锁等待与慢查询。只有“水位接近上限且等待队列增长”才能确认池耗尽；连接不高却大量超时，应查TLS、路由和丢包。
还要排除两类假象。健康检查抖动会让高频检查及失败重试挤占业务槽位，应降低频率、错峰并预留容量。慢请求级联则因SQL变慢使PHP进程久占连接，代理重试放大并发；盲目抬高池上限，往往先撞上上游并发限制。
联动调优先找最慢层：数据库慢就优化索引、缩短事务并限制连接；PHP慢就检查同步I/O、阻塞调用和FPM队列；再校准代理池大小、Keep-Alive复用与超时比例。可用ServLlama汇总水位、等待队列和时序，上线前按峰值压测，确认重试率与数据库连接数下降。
排查时不要只盯“活跃连接数”。连接池水位应同时记录已借出连接数、空闲数、等待队列长度、等待超时数、借用时长，以及连接创建和销毁速率，并按来源、接口拆分占用。若活跃数逼近上限、等待队列增长且借用时间异常长，先查连接是否未归还；若创建持续失败，再查网络、认证、存活探测与驱动配置。抓取线程栈，确认请求阻塞在获取连接、建立连接还是归还连接，比盲目调大池子更有效。
还要核对Keep-Alive 复用是否真实发生。负载均衡器、网关、WAF 与源站可能各自维护连接；一层复用失效，源站就会面对大量短连接，并消耗握手、TLS 握手和文件描述符。用连续请求观察连接 ID、建立时间及首字节时间，确认空闲连接是否被服务端或中间设备提前清理。池中“空闲”不等于可用，超时或已关闭的连接应在借出前重建。
连接池耗尽常只是结果，限制可能来自更上游。核对各依赖的上游并发限制、连接上限、限流阈值和队列策略，并确认限制维度是实例级、节点级还是单 IP 级。健康检查若与业务共用连接池，或频率过高、阈值过窄，会造成健康检查抖动：实例反复摘除和恢复，流量不断重分配，剩余实例的连接迅速占满。应让检查流量使用独立池，并将其结果与池等待曲线按分钟对齐。
若池等待与接口延迟同时升高，重点检查慢请求级联。慢下游占住源站连接和线程，后续请求继续排队，继而触发超时、重试与断路器，进一步放大并发。可先按下游拆分连接池、隔离慢接口、限制重试，并传递统一的截止时间。定位时把请求拆成 DNS、连接、池等待、首字节和下载阶段，结合数据库或远程接口耗时，确认哪一层没有及时释放资源。
最终按这份可执行检查清单收口：①导出池水位和等待队列，确认首次饱和时间；②按来源、接口定位长期占用连接的请求；③抽查连接 ID 与生命周期，验证 Keep-Alive 复用及异常回收；④核对各层并发上限、限流与重试预算；⑤将健康检查和业务指标按分钟对齐；⑥拆分慢请求各阶段耗时；⑦隔离或限流后复测，确认等待队列、创建率和错误率同步下降。指标恢复且无隐藏重试，才算真正解除耗尽。
