标签： php-fpm
-
一次 WordPress 生产站间歇性 502 故障排查记录。阿里云 ECS 一度出现 CPU 100%、Load 超过 9、PHP-FPM Socket 队列达到 510/511，大量请求返回 499 和 502。通过分析 Nginx 日志发现，最近 20000 条请求中有 18455 条携带 Sogou web spider/4.0 User-Agent，并以每分钟约 500～700 次的频率持续遍历网站。随后在 EdgeOne 中通过 *Sogou* User-Agent 规则进行边缘拦截，Sogou UA 请求降至 0，PHP-FPM 队列恢复为 0/511，CPU 空闲率最高恢复到 97%，后台连续请求全部返回 HTTP 200。此次排查说明，服务器出现性能瓶颈时，不应急于升级配置，应先确认异常流量和真正的资源消耗来源。
-
这篇博客记录了一次 WordPress 核心升级失败的完整排查过程：在从 WordPress 7.0 升级到 7.0.1 时，后台反复出现 524 超时和“另一更新正在进行”的提示。通过检查 `core_updater.lock`、WordPress 当前版本、升级临时目录、文件权限以及 EdgeOne 转发状态，最终确认 WordPress 核心文件并未半升级，问题主要集中在经过 CDN 代理后的后台长请求超时。文章进一步总结出：前台页面适合继续走 EdgeOne 缓存，而 WordPress 后台更新、插件安装等维护操作，后续应考虑通过独立后台域名或源站直连方式处理，以避免 CDN 对后台长请求造成干扰。
-
个人博客出现 504 Gateway Timeout，排查发现服务器因恶意扫描和分布式爬虫导致严重过载。内存被过多的 PHP-FPM 进程耗尽，引发负载飙升。通过降低 PHP-FPM 进程数以适配硬件配置，在 Nginx 层面封禁恶意扫描 IP 及爬虫 IP 段，并重启 ECS 清理积压进程，最终解决了资源耗尽问题，恢复了服务正常响应。
-
文章针对 curl 请求 https 网址时响应为 false 的问题进行了排查分析。通过 var_dump 检查请求返回值为 false 后，操作过程是在 php.ini 中配置 openssl.cafile 路径。重启 php-fpm 服务后，问题得到解决，不再响应 false，完成了对 curl 请求异常的修复。
-
文章记录了一个 GraphQL API 耗时长达 7 秒的排查过程。经 Laravel Telescope 和独立客户端测试，实际执行时间仅约 1.8 秒。问题根源在于 Windows 10 环境下的 Nginx 与 PHP FastCGI 默认只能同时处理单一请求，导致请求排队。通过调整 Nginx 配置并启动多个 php-cgi 进程绑定不同端口，实现了并发处理。最终刷新页面测试，请求耗时缩短至 2 秒左右，符合预期。
-
针对 Nginx 与 FastCGI 环境下日志表数据量达到 GB 级时，查询最后一页出现 504 Gateway Time-out 超时的问题，通过分析定位了本地环境与生产环境的配置差异。在本地增加 fastcgi_read_timeout 并调整 PHP 脚本最大执行时间后问题解决，但在生产环境中排查发现，由于请求经过 Kong 网关，超时原因出在网关层面而非后端服务，最终确认由运维人员处理网关配置。
-
文章针对 LNMP 环境下访问实际存在的文件却报错 No input file specified 的问题进行了分析。通过验证 Nginx 配置、检查日志及排查进程，发现错误并非配置不当，而是由于 9000 端口被占用导致 php-fpm 启动失败。停止占用端口的服务使 php-fpm 成功启动后，接口恢复正常响应。