Workerman不能运行在Apache或Nginx下，它是与二者并列的常驻socket服务，仅依赖php-cli启动，须通过反向代理而非嵌套方式配合Nginx，且Apache几乎无法合理兼容。
Workerman 不能、也不该运行在 Apache 或 Nginx 下 —— 它和它们是并列关系，不是嵌套关系。 把 Workerman 当成 PHP-FPM 那样的“被调用者”，是初学者最常踩的架构认知坑。
Workerman 启动方式只依赖 php-cli，不走任何 Web 服务器
Workerman 的本质是一个常驻内存的 socket 服务进程，启动命令永远是 php start.php start（或带 -d 参数后台运行）。它自己监听端口（比如 0.0.0.0:2346），直接收发 TCP/UDP/WebSocket 数据，中间不经过 Apache/Nginx 的 HTTP 请求分发链路。
- 如果你在 Apache 的 DocumentRoot 下放一个
start.php并试图用浏览器访问它，只会触发一次 PHP 执行，Workerman 根本起不来 —— 因为它需要持续运行，而 Web 服务器每次请求都新建销毁 PHP 进程 - 常见错误现象：
502 Bad Gateway或Connection refused，往往是因为误以为 Nginx 转发到start.php就能启动 Workerman，实际只是执行了一次就退出了 - 正确做法：确保
start.php在命令行下可独立运行，且用户有权限监听目标端口（如非 root 用户不能监听:80）
Nginx 和 Workerman 是反向代理关系，不是容器关系
生产环境里 Nginx 常见作用是反向代理到 Workerman 的本地端口，但它不是“运行”Workerman，而是“转发流量”。这个分工必须明确，否则配置容易错位。
- WebSocket 场景下，Nginx 必须显式透传
Upgrade和Connection头，否则协议升级失败，客户端卡在 pending 状态；漏配proxy_http_version 1.1是高频错误 - HTTP 场景下，
proxy_pass http://127.0.0.1:8080中的端口号必须和 Workerman 实际监听的端口完全一致，且不能和 Nginx 自身listen端口冲突 - 不要在 Nginx 配置里写
fastcgi_pass或调用php-fpm—— Workerman 不走 FastCGI 协议，这么配一定 502
Apache 下几乎无法合理配合 Workerman
Apache 缺乏对 WebSocket 升级头的原生支持，mod_proxy 代理配置复杂、稳定性差，官方文档也明确不推荐。即使强行用 ProxyPass，也极容易出现连接中断、超时重置等问题。
- 典型报错：
Proxy Error: Connection refused或客户端收到ERR_CONNECTION_CLOSED - 如果已有 Apache 环境且无法换 Nginx，更现实的做法是让 Workerman 直接监听公网端口（如
:8000），前端用防火墙或 CDN 控制访问，而非强塞进 Apache 流程 - Apache 的
mpm_event模块虽支持长连接，但和 Workerman 的事件循环模型不兼容，两者共存只增加运维负担，无实际收益
真正容易被忽略的是端口与权限的耦合性：Workerman 进程一旦以某个用户身份启动，其监听端口、日志路径、PID 文件路径的读写权限就必须全程匹配，哪怕反向代理层换成了 Nginx，底层 Workerman 的运行边界依然由 CLI 用户决定 —— 这和 Apache/Nginx 的 master-worker 用户分离机制完全不同。
