不能直接用 Nginx 做 Swoole 进程间负载均衡，因为 Swoole Worker 进程不独立暴露端口，而是由 Master 统一调度、共享监听 socket；Nginx upstream 需多个独立服务实例，故须启动多个 Swoole Server 进程（不同端口），再由 Nginx 反向代理分发请求。
为什么不能直接用 Nginx 做 Swoole 进程间负载均衡
Swoole 的 Worker 进程本身不对外暴露 HTTP 端口（除非启用了 http_server 模式），它通常只监听一个 TCP 端口，由 Master 进程统一调度。Nginx 的 upstream 负载均衡针对的是多个独立后端服务实例，而单个 Swoole 进程（哪怕开了 8 个 worker_num）仍是同一个进程组、共享同一个监听 socket —— Nginx 无法感知内部 worker 负载，也压根不需要介入。
真正要做的不是“给 Swoole 进程做负载”，而是：让多个 Swoole 实例组成集群，再由反向代理分发请求。
启动多个 Swoole 实例的正确姿势
靠改 worker_num 不等于横向扩容；必须跑多个独立的 Swoole Server 进程，监听不同端口或不同 IP。
- 每个实例用唯一
pid_file和log_file，避免冲突 - 端口不能重复：比如用
9501、9502、9503 - 若用
task_worker，确保task_ipc_mode不依赖本地文件（推荐2，即 msgqueue） - 所有实例连接同一套 Redis / MySQL，避免状态不一致
示例启动脚本片段：
php server.php --port=9501 & php server.php --port=9502 & php server.php --port=9503 &
对应代码里读取 $argv 或环境变量来动态设置 $server->set(['port' => $port])。
Swoole 6.1.1 是一个专为 PHP 设计的高性能事件驱动并发网络引擎。作为稳定版，它修复了编译时对 zlib 依赖的缺失及 curl 模块的内存安全风险。该版本支持协程、多线程与多进程架构，内置 TCP/HTTP/WebSocket 服务器，能够显著提升 PHP 在微服务、实时通信等场景下的执行效率与并发能力。
Nginx upstream 配置的关键参数
把上面三个端口注册进 Nginx 的 upstream，但默认轮询容易出问题：
- WebSocket 场景必须加
proxy_http_version 1.1和Upgrade头，否则连接秒断 - 长连接要设
keepalive 32，不然频繁建连压垮 Swoole 的reactor - 健康检查不能只靠
max_fails=1，建议配合fail_timeout=30s和自定义health_check（需 Nginx Plus 或 OpenResty） - 如果 Swoole 启用了 SSL，Nginx 要终止 TLS，不要透传；否则
$_SERVER['HTTPS']会丢失
最小可用配置：
upstream swoole_cluster {
server 127.0.0.1:9501 max_fails=3 fail_timeout=30s;
server 127.0.0.1:9502 max_fails=3 fail_timeout=30s;
server 127.0.0.1:9503 max_fails=3 fail_timeout=30s;
}
Session 共享和定时任务怎么不翻车
Swoole 是常驻内存的，$_SESSION 默认存在进程内，多实例下天然不共享；定时任务（如 tick）在每个实例里都会执行一遍 —— 这两点最容易被忽略。
- Session 必须外置：用 Redis 驱动，配置
session.save_handler = redis+session.save_path = "tcp://127.0.0.1:6379" - 避免用
onTimer做全局任务，改用分布式锁（Redis SETNX）+ 单点触发 - 如果用 Swoole 的
Table存共享数据，它只在当前进程有效，跨实例无效 - 日志别写本地文件，统一走
syslog或 ELK，否则查问题时要翻三台机器
复杂点在于：负载均衡只是入口层的事，真正的难点藏在状态管理、时序控制和故障收敛上 —— 端口配得再顺，Redis 挂了整个集群照样雪崩。
