Workerman 5.2.3 启动报 proc_open 禁用，本质是其底层 fork 子进程或执行系统命令时被 PHP disable_functions 拦截；需检查 CLI 模式 php.ini 中该函数是否被禁用，并依安全策略选择白名单申请或改用无 proc_open 依赖的启动模式。
Workerman 5.2.3 启动时报 proc_open 禁用，本质不是 Workerman 自己要用它，而是其底层在尝试 fork 子进程或执行系统命令（比如检测环境、加载扩展、启动子 Worker）时，被 PHP 的 disable_functions 拦截了。这个函数常被内网加固策略默认禁用，尤其在 CentOS/RHEL 类系统上。
确认是否真被禁用
运行这条命令快速验证：
php -r "echo function_exists('proc_open') ? 'ok' : 'fail';"如果输出 fail，说明确实被禁用；若输出 ok，问题可能出在其他地方（比如权限、SELinux 或路径）。
检查 disable_functions 配置位置
Workerman 启动用的是 CLI 模式下的 PHP，所以要查 CLI 的 php.ini，不是 Web 服务器（如 Nginx + PHP-FPM）的配置：
- 执行 php --ini 查看实际加载的 ini 文件路径
- 打开对应 php.ini，搜索 disable_functions
- 常见被禁用列表里会包含：
proc_open,proc_get_status,shell_exec,exec,passthru,system等
安全合规前提下的解决办法
内网环境通常不允许直接放开 proc_open，推荐以下两种稳妥方式：
-
方案一：改用非 proc_open 依赖的启动模式
在启动脚本中显式关闭自动检测和子进程派生逻辑，例如：
Worker::$daemonize = false; // 不后台化，方便调试<br>Worker::$pidFile = ''; // 不写 PID 文件<br>// 启动前手动预检扩展，跳过 runtime 自检<br>if (!extension_loaded('pcntl') || !extension_loaded('posix')) {<br> die('pcntl or posix extension not loaded');<br>} -
方案二：申请白名单（推荐）
向运维/安全部门提交工单，说明 Workerman 5.2.3 在 CLI 模式下需调用
proc_open完成多进程初始化（官方文档明确要求），仅限本地回环调用，不对外发起网络请求，风险可控。附上 PHP 官方对proc_open的安全说明链接。
临时绕过（仅限测试环境）
若确需快速验证，可临时修改 CLI 的 php.ini（注意不是 FPM 的）：
disable_functions = pcntl_alarm,pcntl_fork,pcntl_waitpid,...把 proc_open 从该行中删掉，然后重启 PHP CLI 环境（无需重启 Web 服务）。完成后务必恢复，避免引入安全审计风险。
