PHP 7.2接口超时需分层排查：先查日志定位超时源头（PHP执行、下游连接或Nginx网关），再检查default_socket_timeout、MySQL连接超时及set_time_limit(0)三处关键配置，最后用error_log打点精确定位卡点，并通过IP直连、cURL毫秒级超时等实操方案绕过DNS和连接阻塞。
PHP 7.2 老项目接口超时，页面卡住、日志里反复出现“Maximum execution time of 30 seconds exceeded”或“Connection timed out”，但错误不固定、复现困难，说明问题藏在多层叠加的旧配置和隐性阻塞中，不能只改一个参数就指望解决。
先确认是哪一层最先断掉
打开 /var/log/php-fpm/www-error.log 或项目 runtime/log 下最新日期的日志文件，用 grep -i "timeout\|timed out\|exceeded" 搜索关键词。如果看到 Maximum execution time of X seconds exceeded，说明是 PHP 自身执行超时；如果看到 Connection timed out 且紧跟着 mysql、redis 或 cURL 字样，说明是下游连接卡死；如果只有 504 Gateway Timeout 且 Nginx error.log 里有 upstream timed out，那问题大概率出在 PHP 进程没返回，而不是代码逻辑慢。
这一步不做，后面所有调优都可能打偏——比如你拼命优化 SQL，结果真实问题是 file_get_contents 在等一个 DNS 解析失败的域名。
查 PHP 7.2 的三个关键超时配置
PHP 7.2 对超时控制非常“诚实”，不会自动兜底，必须手动检查三处：
立即学习“PHP免费学习笔记（深入）”；
方法一：查 php.ini 中的 default_socket_timeout
运行 php --ini 找到加载的配置路径，然后执行：
grep "default_socket_timeout" /etc/php/7.2/fpm/php.ini
如果输出是 default_socket_timeout = 60 或更高（比如有人改成 300），这就是隐患。file_get_contents、fsockopen、stream_socket_client 等所有基于流的操作都会受它影响，而它在 7.2 下完全不随 max_execution_time 生效。必须改成 10 或更低，并重启 php-fpm。
方法二：查 mysql.connect_timeout 和 mysqli.default_timeout
这两个值默认都是 60 秒，但老项目常直接用 mysql_* 函数（已废弃）或未显式设 connect_timeout。执行：
php -r "echo ini_get('mysql.connect_timeout');"
如果返回 60，立刻在 php.ini 里加一行：
mysql.connect_timeout = 5
并确保 mysqli.default_timeout 也设为 5。注意：修改后必须重启 php-fpm，仅 reload 不生效。
方法三：检查脚本开头有没有 set_time_limit(0)
老项目常见写法是入口文件第一行就写 set_time_limit(0)，等于主动关闭 PHP 层超时保护。用 grep -r "set_time_limit(0)" ./app/ ./public/ 全局搜一遍。只要找到，立刻删掉或改成 set_time_limit(30)——这是最简单有效的保命操作。
定位具体卡在哪一行代码
第一步：在超时接口入口加时间戳日志
在控制器或路由处理函数最开头插入：
$start = microtime(true); error_log("[$start] API start\n", 3, "/tmp/php-timeout-debug.log");
第二步：在数据库查询前、cURL 执行前、file_get_contents 前各加一行：
error_log("[$start] before DB query\n", 3, "/tmp/php-timeout-debug.log");
error_log("[$start] before curl_exec\n", 3, "/tmp/php-timeout-debug.log");
第三步：请求复现后，用 tail -f /tmp/php-timeout-debug.log 观察最后一条日志是什么。如果停在 “before DB query”，说明连接池拿不到连接；如果停在 “before curl_exec”，说明第三方域名解析或 TCP 握手卡住；如果日志根本没写完，说明是 PHP-FPM worker 被占着不释放，要查是否有未关闭的 MySQL 连接或 fopen 文件句柄。
【注意】不要用 echo 或 var_dump 替代 error_log —— 超时时输出缓冲可能没刷出，日志才是唯一可信记录。
绕过 DNS 和连接阶段卡死的实操方案
很多老项目超时不是因为业务慢，而是卡在 DNS 解析或 TCP 连接建立环节。PHP 7.2 的 cURL 默认不设 CONNECTTIMEOUT，一旦 DNS 服务器响应慢或目标 IP 不通，就会傻等几十秒。
方法一：强制用 IP 替代域名测试
把接口中类似 https://api.xxx.com/v1/data 的 URL，临时替换成对应 IP（用 dig api.xxx.com +short 查），再请求一次。如果秒回，说明是 DNS 问题，需检查 /etc/resolv.conf 的 timeout 和 attempts 设置，或在 cURL 中加：
curl_setopt($ch, CURLOPT_RESOLVE, ["api.xxx.com:443:192.168.1.100"])
方法二：给所有 cURL 请求补全两个超时
在封装好的 HTTP 客户端类里，确保每次初始化后都执行：
curl_setopt($ch, CURLOPT_CONNECTTIMEOUT_MS, 3000);
curl_setopt($ch, CURLOPT_TIMEOUT_MS, 8000);
注意：用 _MS 后缀才能精确到毫秒，避免整秒截断；CONNECTTIMEOUT_MS 必须小于 TIMEOUT_MS，否则无效。
方法三：禁用 file_get_contents 的 DNS 缓存依赖
老项目常用 file_get_contents 拉配置或对账单，但它底层调用系统 getaddrinfo，受 /etc/nsswitch.conf 影响极大。直接换为 cURL 封装，或至少显式传入 stream context：
$ctx = stream_context_create(['http' => ['timeout' => 5]]); $res = file_get_contents($url, false, $ctx);
