sub2api大规模部署，多实例负载均衡会话共享Redis方

sub2api是常见的订阅转换和API中转工具，单实例部署时一旦流量上涨，容易出现响应慢、连接超时等问题。
把服务拆成多个实例后，又遇到一个棘手情况：用户在A节点登录成功，请求被负载均衡转发到B节点时却提示未登录。
这个问题的根本原因是会话（Session）默认保存在本机内存里，多节点之间互相不认识。
解决办法是用Redis集中保存会话，让所有实例读写同一份数据。
下面按零基础可操作的方式，从准备到验证一步步讲清。

需要准备哪些环境

开始之前，先确认你手上有这些东西：

• 两台或以上服务器节点，建议系统为 Debian、Ubuntu 或 CentOS，已安装 Docker 或可直接运行二进制文件。
• 一个可用的 Redis 服务，可以是单独一台机器，也可以部署在节点之外，保证所有 sub2api 实例都能访问。
• 一台负载均衡入口机，使用 Nginx 做反向代理和流量分发。
• sub2api 服务端程序包，版本建议以官方仓库或发行页说明为准，部署前先确认是否支持配置外部 Redis 环境变量。

如果实例数量不多，也可以把 Redis 装在其中一个节点上，但生产环境建议独立部署，避免单点故障。

部署多个sub2api实例并接入Redis

先按常规方式部署第一个实例，确认能启动后，再复制到其他节点。
这里以 Docker 方式为例，其他部署方式原理一致。

每个 sub2api 节点都需要配置以下环境变量，指向同一个 Redis 实例：

REDIS_HOST=10.0.0.5
REDIS_PORT=6379
REDIS_PASSWORD=yourpassword
REDIS_DB=0

启动命令参考如下：

docker run -d \
  --name sub2api-node1 \
  -p 8081:8080 \
  -e REDIS_HOST=10.0.0.5 \
  -e REDIS_PORT=6379 \
  -e REDIS_PASSWORD=yourpassword \
  -e REDIS_DB=0 \
  your-sub2api-image:latest

第二个节点换端口和容器名，例如 8082、sub2api-node2，其余参数保持一致。
如果用的是宝塔面板，可以在 Docker 管理器里创建容器时填写同样的环境变量，操作路径为：Docker → 容器 → 添加容器。

需要留意的是，不同版本的 sub2api 对环境变量的命名可能不同，有些版本使用 SESSION_REDIS_URL 或 REDIS_URL。
如果不确定，先查看项目的 README 或在启动日志中搜索 redis 字样，确认读取配置的位置，不要照抄别人配置而不校验。

配置Nginx负载均衡和会话保持提示

在入口机上编辑 Nginx 配置，例如 /etc/nginx/conf.d/sub2api.conf，内容如下：

upstream sub2api_backend {
    server 10.0.0.10:8081;
    server 10.0.0.11:8082;
}

server {
    listen 80;
    server_name api.example.com;

    location / {
        proxy_pass http://sub2api_backend;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
    }
}

由于已经用 Redis 共享会话，负载均衡策略可以不用设置 ip_hash，默认轮询即可，流量分配更均匀。
如果你需要长连接或 WebSocket 支持，再按实际情况补充 proxy_http_version 1.1 等参数。

配置完成后测试并重载：

nginx -t
nginx -s reload

部署后的验证步骤

执行以下检查，确认 Redis 会话共享真正生效：

1. 在 A 节点登录 sub2api 后台，记录当前会话 ID（可从浏览器 Cookie 中查看 sessionid 之类的字段）。
2. 手动修改 hosts 或使用 curl，把请求打到 B 节点，验证是否仍处于登录状态。
3. 直接查看 Redis 中是否写入会话数据：

redis-cli -h 10.0.0.5 -a yourpassword KEYS 'session:*'

如果能看到类似 session:xxxx 的 key，说明会话确实已集中存储。
然后再执行一次登录、刷新页面、调用接口的操作，确认功能完整。

常见问题和避坑清单

• 登录状态经常丢失：先检查所有实例的 REDIS_DB 是否一致，如果实例间使用不同的数据库编号，Redis 会自然隔离数据。
• Redis 连接超时：确认安全组或防火墙已放行 Redis 端口，且 Redis 配置文件 bind 允许远端访问，同时设置足够强的密码。
• Nginx 502 错误：多半是后端实例没启动或端口写错，执行 docker ps 看容器状态，再用 curl 127.0.0.1:8081 检查节点是否可访问。
• 会话已存 Redis 但页面仍提示未登录：检查 Cookie 的 domain 和 path 是否保持一致，多个域名共用会话时需要配置 Cookie 作用域。
• 频繁强制登录：确认各节点系统时间是否同步，时间偏差过大会导致签发的会话票据校验失败。

另外提醒一句，Redis 服务本身要开启持久化（RDB 或 AOF），否则重启 Redis 后所有会话直接丢失，用户会全部掉线。
如果只是临时测试，可以不开启，但生产环境务必打开。

总结

sub2api 多实例部署的关键是把会话存储从本地内存搬到 Redis，让 Nginx 代理的每个节点都能读取同一份登录状态。
部署时重点检查环境变量名、Redis 网络连通性和 Cookie 配置，配合 Nginx 轮询即可实现横向扩展。
完成以上配置后，建议对节点逐个重启测试，确认没有节点掉线后再切生产流量。
如果你在实际操作中遇到其他报错，先看日志中的 Redis 连接记录，大多数问题都能从那里找到线索。