PHP 8.2 本身不提供负载均衡能力，必须由 Nginx、HAProxy 等外部组件实现；直接在 PHP 中用 curl 转发会导致性能断崖、无健康检查、session 失效等问题；标准方案是 Nginx 通过 upstream 分发请求至多个 PHP-FPM 实例，并统一使用 Redis 存储 session。
PHP 8.2 本身不提供负载均衡能力，它只是后端执行引擎；真正的负载均衡必须由外部组件（如 Nginx、HAProxy 或云 LB）完成。直接在 PHP 代码里“实现负载均衡”是常见误解，容易导致单点故障、状态混乱和性能瓶颈。
为什么不能用 PHP 代码做请求分发
有人尝试用 curl 或 file_get_contents 在 PHP 中手动转发请求到其他 PHP 服务器，这看似“负载均衡”，实则危险：
- 每次请求都额外增加一次 PHP 进程开销和网络延迟，吞吐量断崖式下降
- 无法做健康检查，故障节点继续收请求，用户看到 502/504
- 无法维持连接复用（keepalive），
proxy_pass能复用后端连接，PHP 手动转发每次都是新 TCP 握手 - 会话（session）、上传进度、长连接、WebSocket 等全部失效或难以处理
Nginx + PHP-FPM 的标准反向代理配置
PHP 8.2 应以 FPM 模式运行（非 Apache module），由 Nginx 统一接收 HTTP 请求并分发。关键点不是“PHP 怎么负载”，而是“Nginx 怎么把请求分给多个 PHP-FPM 实例”：
- 确保每个 PHP 服务器上运行独立的
php-fpm服务，监听本地 socket 或 TCP 端口（如127.0.0.1:9000） - 在 Nginx 主机（单独机器或容器）中定义
upstream，例如：upstream php_backend { server 192.168.1.10:9000 weight=3; server 192.168.1.11:9000 weight=2; server 192.168.1.12:9000 max_fails=3 fail_timeout=30s; } - location 中用
fastcgi_pass指向该 upstream，而非固定地址：location ~ \.php$ { fastcgi_pass php_backend; fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name; include fastcgi_params; } - 务必启用
max_fails和fail_timeout，否则宕机节点仍持续收请求
PHP 8.2 的 session 共享必须脱离文件存储
默认的 session.save_handler = files 在多服务器下完全失效——用户 A 第一次访问落到 Server1，第二次可能落到 Server2，找不到 session 文件，直接登出。
立即学习“PHP免费学习笔记（深入）”；
- 改用 Redis：在所有 PHP 服务器的
php.ini中统一设置：session.save_handler = redis session.save_path = "tcp://192.168.1.20:6379?database=1"
- 不要用 Memcached：它不支持原子性的 session 锁，高并发下可能覆盖写
- 避免数据库存 session：MySQL 表锁 + 网络延迟会让登录页明显变慢
- 验证是否生效：修改后重启
php-fpm，用phpinfo()确认Session Support显示redis
健康检查与自动剔除不能只靠 Nginx 默认机制
Nginx 的 max_fails 只对连接拒绝或超时生效，但 PHP-FPM 进程卡死、OOM 后假死、或无限循环导致响应极慢，Nginx 默认无法感知。
- 在每台 PHP 服务器上暴露一个轻量健康接口，例如
/healthz返回200 OK，且不依赖 DB/Redis - 用 Nginx 的
health_check指令（需 1.11.5+）主动探测：upstream php_backend { zone backend 64k; server 192.168.1.10:9000; server 192.168.1.11:9000; health_check uri=/healthz interval=5 fails=2 passes=2; } - 更可靠的做法是配合 Consul 或 Prometheus + Alertmanager 做多维指标判断（CPU、内存、FPM pool busy rate）
真正难的不是配通，而是当某台 PHP 服务器因 OOM 被系统 kill 后，它的 php-fpm 进程没起来，但 Nginx 还在往它发请求——这种静默失败，比报错更难排查。
