ip_hash在phpEnv中仅保证同IP请求路由固定，但无法解决session数据分散问题；需配合Redis共享存储或改造为HTTP服务才能真正实现会话保持。

ip_hash 在 phpEnv 环境下能用，但不能直接解决会话保持问题——它只保证同一 IP 的请求打到同一台后端 PHP 服务器，而 session 数据本身仍分散在各服务器本地文件中。真正在用 phpEnv 搭建多 PHP 实例负载均衡时，光配 ip_hash 是不够的。

Nginx Hosting

通过服务器本地nginx实例实现零认证静态游戏托管。作为所有浏览器游戏的主要部署方式，无需登录、无需令牌、无需用户操作。

下载

---

ip_hash 配置写法与生效前提

• phpEnv 默认使用 Nginx + PHP-FPM 架构，但它的 upstream 多数是单机（比如 127.0.0.1:9000），必须手动改成多台 PHP-FPM 实例地址，否则 ip_hash 根本没意义
• upstream 块里加 ip_hash; 后，Nginx 会自动禁用 weight、backup、down 等指令，加了就报错：
  nginx: [emerg] "weight" parameter is incompatible with "ip_hash"
• 真实客户端 IP 必须传入，否则哈希的是代理 IP（如 127.0.0.1），所有请求都落到同一台后端：
  proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
• IPv4 地址只取前三个字节哈希（192.168.1.x → 视为同一组），内网 NAT 环境下容易出现“多个用户被绑死一台服务器”的过载现象

---

为什么 phpEnv 下 ip_hash 容易失效

• phpEnv 自带的 Nginx 配置通常不启用 upstream，而是直连本机 fastcgi_pass 127.0.0.1:9000，你得手动改造成反向代理模式：
  • 把 PHP-FPM 实例分别监听不同端口（如 9001、9002）或不同 socket 路径
  • 在 http 块外定义 upstream php_backend { ip_hash; server 127.0.0.1:9001; server 127.0.0.1:9002; }
  • 把 location ~ .php$ 里的 fastcgi_pass 换成 proxy_pass <a href="https://www.php.cn/link/6ec52fc9886c13b7f97e5c5dee505909">https://www.php.cn/link/6ec52fc9886c13b7f97e5c5dee505909</a>（注意：这就不再是 FastCGI 协议了，得确保后端跑的是 HTTP 接口，不是 PHP-FPM 原生协议）
• 更现实的做法是：保留 FastCGI，但把多台 PHP-FPM 当作独立 HTTP 服务起起来（比如用 Swoole 或 Workerman 封装一层），否则 Nginx 无法用 proxy_pass 转发到 PHP-FPM

---

替代方案：不依赖 ip_hash 的会话保持

• 直接改 PHP 配置，把 session 存到共享存储：
  session.save_handler = redis
session.save_path = "127.0.0.1:6379"
  （phpEnv 自带 Redis，开箱即用）
• 或存数据库：
  session.save_handler = mysqli
session.save_path = "localhost;3306;root;password;session_db"
• 如果坚持用文件存储，必须用 NFS 或 rsync 同步 session.save_path 目录，但延迟和锁竞争会导致登录态随机丢失

---

ip_hash 最容易被忽略的一点：它完全不管 session 数据是否存在。后端某台机器宕机，Nginx 会剔除它并重哈希，用户下次请求就落到新机器上——而新机器根本没有老 session 文件，登录态直接清零。真正的会话保持，从来不是靠路由固定，而是靠数据统一。