一台Nginx服务器，向代扛着几万台并发连接，理负后端三台Tomcat却闲得发慌。载均这不是向代什么玄学，是理负反向代理加负载均衡的基本盘。

先搞清楚一件事：用户访问的载均是Nginx的80端口，Nginx再把请求转给内网里的向代应用服务器。用户根本不知道后端有几台机器，理负也摸不到真实IP。载均这就叫反向代理——代理的向代是服务器，不是理负用户。

负载均衡，载均说白了就是向代把活儿分给多个人干。三台机器，理负每台配置一样，载均Nginx按策略分流量。最常用的策略是轮询，一人来一次，公平得很。但真实场景里，机器性能有差异，老机器处理慢，新机器闲着，这时候就得用权重。weight=2，意思是有三份请求，这台机器拿两份，另一台拿一份。简单粗暴，但管用。

还有个细节，很多人忽略。后端服务有状态怎么办？比如用户登录了，session存在Tomcat里。轮询把请求分到不同机器，用户刚在A机器登录，下一个请求跑到B机器，session丢了，用户被踢下线。这问题怎么解？ip_hash策略，让同一个IP的请求固定打到同一台机器。但ip_hash也有坑，公司出口IP就一个，几百号人全被分到一台机器上，负载均衡直接失效。所以现在更推荐用Redis做session共享，或者干脆把服务改成无状态的，JWT一签，谁还关心session在哪儿。

配一个最小可用的负载均衡，其实就十几行配置。upstream块定义后端服务器列表，server块里location / 加上proxy_pass http://backend。但真正的坑在细节里：proxy_set_header Host $host，这个必须加，不然后端拿到的Host是Nginx的IP，重定向全乱套。proxy_set_header X-Real-IP $remote_addr，不然后端日志里全是Nginx的IP，查问题查到怀疑人生。

健康检查这块，Nginx默认是不做主动检查的。后端挂了一台，它照样把请求转过去，然后用户看到502。要么靠第三方模块，要么自己写脚本定时探测，把挂掉的机器从upstream里摘掉。这活儿不复杂，但很多初学的人压根没想到——负载均衡不是配完就完事，得考虑机器挂了的场景。

再说个实际案例。我之前调过一个接口，平均响应时间200ms，但偶尔飙到5秒。查了半天，发现Nginx配了keepalive 32，但后端Tomcat的keepalive超时时间设得太短。连接池里的连接被Tomcat关了，Nginx不知道，还在复用，结果每次都要重新建连。把两边的keepalive参数调成一致，问题就没了。这种问题，配置文档里不会直接告诉你，得靠经验踩坑。

最后说点主观的。很多人一上来就上K8s、上Service Mesh，觉得Nginx太老土。但中小公司，三台机器，一个Nginx，搞定90%的场景。别为了技术而技术。Nginx的配置虽然看着像天书，但核心逻辑就那么几条，花一个下午就能吃透。剩下的，就是不断遇到问题、解决问题、再遇到新问题的循环。

负载均衡不是银弹。它解决的是可用性和吞吐量的问题，但引入的新问题——session管理、连接超时、日志排查——一样不少。用好了，它是你架构里的定海神针；用不好，它就是给你添堵的那根刺。