必须先确认FrankenPHP已接管全部PHP请求、无残留依赖且PHP-FPM进程真正终止，否则将导致502错误、空白页或配置冲突；需检查Web服务器配置是否仍指向旧FPM、验证响应头含X-Powered-By: FrankenPHP、停FrankenPHP后页面是否立即报错，并彻底停止PHP-FPM服务、清理socket及残留配置。
不能直接下线，得先确认 FrankenPHP 已完全接管流量、无残留依赖、且 PHP-FPM 进程真正终止——否则会出现 502、空白页或配置冲突。
怎么确认 FrankenPHP 已接管全部 PHP 请求
别只看服务起来了，重点是它是否真在处理你原本交给 PHP-FPM 的请求路径：
- 检查 Nginx/Apache 是否还存在
fastcgi_pass指向127.0.0.1:9000或/var/run/php/php*-fpm.sock的配置；有就删掉或注释，否则 FrankenPHP 启着，Nginx 还在往老 FPM 转发 - 用
curl -I http://yoursite.test/health.php配合frankenphp logs或journalctl -u frankenphp -n 20看响应头里有没有X-Powered-By: FrankenPHP（默认开启） - 临时停掉 FrankenPHP，再访问页面——如果立刻报错（如连接拒绝），说明流量已切过去；如果还能打开，说明 Nginx 或其他代理仍在兜底转发给 PHP-FPM
为什么必须手动停掉 PHP-FPM 再下线机器
FrankenPHP 和 PHP-FPM 可以共存，但它们默认都监听 9000 端口或争抢同一 Unix socket，不清理会直接导致 FrankenPHP 启动失败或静默降级到 classic 模式（失去 worker 常驻优势）：
- systemd 系统执行：
sudo systemctl stop php*-fpm+sudo systemctl disable php*-fpm（注意匹配实际服务名，如php8.2-fpm） - 检查残留进程：
ps aux | grep php-fpm，若还有master进程，用kill -QUIT `cat /run/php/php*-fpm.pid`平滑终止 - 删掉 socket 文件：
sudo rm -f /var/run/php/php*-fpm.sock，否则 FrankenPHP 启动时可能因权限/占用报错 - 检查 Web 服务器配置里是否还引用了
fastcgi_param相关变量（如SCRIPT_FILENAME），FrankenPHP 默认用PATH_INFO和REQUEST_URI，混用可能出路径解析错误
下线前最容易被忽略的三个点
这些地方不查，机器下线后问题会延迟爆发：
立即学习“PHP免费学习笔记（深入）”；
-
crontab或定时任务里有没有硬编码调用php /path/to/script.php却依赖php.ini中 FPM 特有配置（如opcache.enable_cli=1）？FrankenPHP 不影响 CLI，但若脚本里用了$_SERVER['REQUEST_METHOD']等 FPM 注入变量，就可能崩 - 日志轮转配置（如
/etc/logrotate.d/php*-fpm）还在运行，会持续尝试kill -USR1一个不存在的进程，报一堆No such process错误 - 监控脚本（比如 Zabbix、Prometheus exporter）是否还在采集
php-fpm.status页面或pm.status_path暴露的指标？FrankenPHP 用的是/metrics或/health，路径和格式完全不同
真正安全的下线节奏是：切流 → 停 FPM → 观察 48 小时错误日志和 5xx 报警 → 清理 cron/logrotate/监控残留 → 最后关机。中间任何一环漏掉，都可能让“已迁移”变成“半瘫痪”。
