swoole本身不支持跨实例负载均衡，worker_num仅控制单机进程调度；真正的集群级负载均衡必须依赖nginx upstream（http/https）、swoole\proxyserver（tcp）或客户端lb（微服务rpc场景）。
直接结论：Swoole 本身不支持跨实例负载均衡
Swoole 的 worker_num 只控制单机内工作进程数量，属于 reactor → worker 的本地调度，和「把请求分发到多台机器上的不同 Swoole 实例」完全无关。想靠改 worker_num 实现集群级负载均衡，注定失败。
Nginx upstream 是最稳的 HTTP/HTTPS 负载入口
生产环境几乎都用 Nginx 做反向代理层，关键不是“能不能配”，而是参数漏一项就出问题：
- WebSocket 必须加
proxy_http_version 1.1、proxy_set_header Upgrade $http_upgrade和proxy_set_header Connection "upgrade"，否则握手直接 400 - 长连接要设
keepalive 32，不然每个请求重建 TCP，reactor 线程瞬间被打满 -
max_fails=3 fail_timeout=30s是底线，只写max_fails=1容易因网络抖动误判节点宕机 - 如果 Swoole 自己启了 HTTPS（
Swoole\Http\Server+ SSL），Nginx 必须 terminate TLS，不能透传；否则$_SERVER['HTTPS']永远为空，$_SERVER['HTTP_X_FORWARDED_PROTO']也拿不到
TCP 代理场景优先用 Swoole\ProxyServer
当后端是自定义 TCP 服务（非 HTTP），且不想引入 Nginx，可用 Swoole 内置的 Swoole\ProxyServer 类快速搭代理层：
Swoole 6.1.1
下载
Swoole 6.1.1 是一个专为 PHP 设计的高性能事件驱动并发网络引擎。作为稳定版，它修复了编译时对 zlib 依赖的缺失及 curl 模块的内存安全风险。该版本支持协程、多线程与多进程架构，内置 TCP/HTTP/WebSocket 服务器，能够显著提升 PHP 在微服务、实时通信等场景下的执行效率与并发能力。
-
load_balance参数支持SWOOLE_PROXY_ROUNDROBIN（轮询）、SWOOLE_PROXY_RANDOM、SWOOLE_PROXY_WEIGHTED -
server_list数组填的是真实后端地址，不是本机端口；例如['host' => '192.168.1.10', 'port' => 8080] - 心跳检测靠
heartbeat_check_interval和heartbeat_idle_time控制，但注意它不自动剔除节点——得自己监听onClose或onError手动维护可用列表 - 该组件仅在 Swoole 4.8+ 稳定版中默认启用，低版本需确认是否编译了 proxy 模块
客户端 LB 适合微服务间 RPC 调用
当你的架构里存在「Swoole 服务 A 主动调用 Swoole 服务 B」这类内部通信，又不想让 Nginx 成为单点瓶颈时，才考虑在 PHP 代码里实现客户端负载均衡：
- 典型做法是启动时从 Consul/Etcd 拉取
service-b的健康节点列表，缓存到内存 - 每次发起 RPC 前，用轮询或最少连接策略选一个节点，再用
Swoole\Coroutine\Http\Client或Swoole\Coroutine\Socket发请求 - 必须自己处理节点失效：比如请求超时或返回 5xx 后，临时标记该节点为不可用，并触发后台异步健康检查
- 别在每次请求都重新拉配置——Consul 的 watch 接口或 etcd 的 watch event 才是正确姿势
真正容易被忽略的是健康感知粒度：Nginx 的 max_fails 只看连接层失败，而业务级异常（如后端返回 {"code":503,"msg":"db down"}）它完全看不见。这类逻辑必须下沉到应用层或用 OpenResty + Lua 补齐。
