核心是两步：Tomcat多实例需修改8005、8080、8009端口避免冲突；Nginx通过upstream定义后端池并用proxy_pass转发请求，配合proxy_set_header传递真实客户端IP等关键头信息。
用 Nginx 给多个 Tomcat 实例做负载均衡，核心是两步：让每个 Tomcat 能独立运行不端口冲突，再让 Nginx 把请求合理分发过去。关键不在 Java 代码本身，而在服务部署和 Nginx 配置的协同。
Tomcat 多实例必须改端口
同一台机器上起多个 Tomcat，三个端口必须互不重复：HTTP 访问端口（默认 8080）、Shutdown 端口（默认 8005）、AJP 端口（默认 8009）。比如：
- Tomcat1：HTTP → 8080，Shutdown → 8005，AJP → 8009
- Tomcat2：HTTP → 8081，Shutdown → 8006，AJP → 8010
- Tomcat3：HTTP → 8082，Shutdown → 8007，AJP → 8011
修改位置都在 conf/server.xml 文件中，对应 `./startup.sh）并确认端口监听正常（netstat -tuln | grep :808[12]）。
Nginx upstream 定义后端池
在 Nginx 的 nginx.conf 或 conf.d/*.conf 中添加 upstream 块，列出所有 Tomcat HTTP 地址：
立即学习“Java免费学习笔记（深入）”；
你接手一个需求时，是不是经常这样："改一个小字段 → 结果把不相关的代码也改了"、"需求说得很模糊 → 做着做着发现跑偏了"、"数据库加个字段 → 上线才发现漏了数据兼容"、"做了个新功能 → 一个月后自己都忘了当时怎么设计的"、"写到一半被中断 → 再回来不知道从哪继续"；这个 Skill 就是专门解决这些问题的。 它会自动探测你的项目环境（JDK、Spring Boot、ORM、数据库、前端框架），记在
upstream tomcat_backend {
server 127.0.0.1:8080;
server 127.0.0.1:8081;
server 127.0.0.1:8082;
}
这定义了一个名为 tomcat_backend 的服务组。支持多种调度策略：
- 轮询（默认）：请求依次分发
-
weight=2：加权轮询，如server 127.0.0.1:8080 weight=3;表示该实例承担 3 倍流量 -
max_fails=3 fail_timeout=30s：连续失败 3 次，30 秒内不再转发请求
反向代理配置要带关键 Header
在 server 块里，把请求代理到 upstream，并补全真实客户端信息：
location / {
proxy_pass http://tomcat_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;
}
这几行很重要：Host 保证 Tomcat 正确解析虚拟主机；X-Real-IP 和 X-Forwarded-For 让 Java 应用能拿到用户真实 IP，而不是 Nginx 的本地地址；否则日志、限流、安全校验都会出问题。
Session 一致性不能只靠 Nginx
Nginx 的 ip_hash 可强制同一 IP 总打到同一台 Tomcat，但不推荐——它破坏负载均衡公平性，且 NAT 环境下多个用户共用一个出口 IP，会集中压垮某台实例。
更稳妥的做法是：由 Tomcat 集群自身处理 session 共享，例如：
- 启用 Tomcat 的
DeltaManager或BackupManager（需配置cluster节点） - 使用 Redis 存储 session（推荐，解耦强、扩展性好）
- 应用层无状态化，session 数据存在前端 Cookie（加密签名）或数据库
