合理连接超时应设为1500毫秒，即curl_setopt($ch, CURLOPT_CONNECTTIMEOUT_MS, 1500)；需配合DNS缓存、FPM超时配置及资源释放机制，避免链路雪崩。
PHP cURL 连接超时设多少才合理
连接超时（connect_timeout）不是越长越好，也不是越短越稳。它只控制「TCP 握手完成前」的等待时间，和后续响应慢没关系。线上服务设成 3 秒以上，基本等于放任网络抖动拖垮整个请求链路。
-
curl_setopt($ch, CURLOPT_CONNECTTIMEOUT_MS, 1500)是更安全的起点——毫秒级控制，避免整秒卡顿 - 若后端是云厂商 LB 或 Kubernetes Ingress，DNS 解析可能额外耗时，建议把
CURLOPT_DNS_CACHE_TIMEOUT设为 60（秒），避免频繁查 DNS 拖慢首次连接 - 别用
CURLOPT_TIMEOUT替代连接超时：它管的是整个请求生命周期，一旦后端卡在数据库查询，你的连接超时设置就完全失效
fsockopen 超时参数容易漏掉 stream_context
直接调用 fsockopen() 时，$timeout 参数只影响连接阶段，但 PHP 默认会把 socket 置为阻塞模式，后续 fread() 可能无限挂起。真正可控的方式是用 stream_context_create() 统一管理。
- 必须显式传入 context：
fsockopen($host, $port, $errno, $errstr, 2.0, $context)，否则$timeout在某些 PHP 版本里会被忽略 - context 中要同时设
timeout和ignore_errors：['http' => ['timeout' => 3.0], 'socket' => ['timeout' => 3.0, 'bindto' => '0.0.0.0:0']]
- 注意：
stream_socket_client()比fsockopen()更可靠，它原生支持超时且返回值语义清晰，建议优先替换
PHP-FPM 子进程被超时 kill 导致连接中断
即使 cURL 或 socket 层面设置了超时，PHP-FPM 的 request_terminate_timeout 仍可能在半途中断连接，表现为 Nginx 日志里出现 upstream prematurely closed connection。
- 检查
php-fpm.conf中的request_terminate_timeout，确保它 ≥ 所有下游接口的超时总和 + 本地处理预留时间（建议至少多留 2 秒） - 如果用了
max_execution_time（比如在脚本里调set_time_limit(30)），它和 FPM 的 timeout 是叠加判断的，任一触发都会 kill 进程 - 关键点：FPM timeout 触发时不会抛出异常，而是直接终止进程——你 catch 不到，log 里也看不到堆栈，只能靠监控
slowlog和 Nginx error log 对齐时间点
超时后资源没释放导致 fd 耗尽
超时发生后，如果没主动 curl_close() 或 fclose()，cURL handle 或 socket 文件描述符可能滞留，高并发下快速占满系统 limit。
立即学习“PHP免费学习笔记（深入）”；
- 所有 cURL 请求必须包在
try...finally里，finally中强制curl_close($ch) - 使用
stream_socket_client()时，哪怕connect失败，只要返回 resource 就得fclose()，否则 fd 泄漏 - 用
lsof -p $(pgrep php-fpm)定期抽检，看是否有大量socket:[*]状态为can't identify protocol，那是典型未释放 socket
超时从来不是单点配置问题，它是连接层、应用层、网关层、容器网络层共同作用的结果。最容易被跳过的，其实是 FPM 配置和 fd 清理这两步——它们不报错，但会在流量高峰时突然让整个服务不可用。
