先说结论这套 Nginx Tomcat 的动静分离 负载均衡方案是 Java Web 项目从单机走向集群的第一道坎也是我近几年帮团队做架构升级时最常用到的基础组合。Nginx 处理静态文件的高并发能力和 Tomcat 处理动态业务的稳定性各有分工两者配合下来既能扛住流量又能降低后端压力。只要你手里有一个 Java Web 项目不管规模大小这篇文章的思路和配置都能直接用。我会从为什么需要这套架构讲起再到实际部署、Nginx 配置、会话保持、压测验证最后把日常最容易踩的坑都整理出来。一套架构的选型从来不是越新越好而是越适合自己团队越好。Nginx Tomcat 的组合到今天依然是中小型 Java Web 项目最稳的起点之一值得你花半小时把整条链路跑通。1. 动静分离与负载均衡的设计思路1.1 动静分离到底在解决什么问题很多刚接触这套架构的人会有一个疑问Tomcat 本身也能处理静态资源为什么非要把图片、CSS、JS 抽出来交给 Nginx最直接的原因是性能差异。Tomcat 内部是一个 Servlet 容器请求进来后要经过 Connector、Engine、Host、Context、Servlet 这条链路每多一层处理就会消耗 CPU 和内存。哪怕只是一个读取文件的简单请求Tomcat 也会走一遍完整的容器过滤链。而 Nginx 是用事件驱动模型实现的核心就是一个高性能的静态文件服务器读取本地文件、直接响应请求整个过程基本不依赖后端业务逻辑。我打个比方Tomcat 就像一位专业知识扎实的工程师你让他画图纸、写代码、解决复杂问题他做得很好但如果你让他同时去处理一万个文件复印的活儿他也应付得来只是成本高得吓人。Nginx 则像一个专门做收发件的窗口只负责把文件、静态资源快速传递出去不掺和业务自然速度快、并发高。一台普通配置的 Tomcat默认配置下能够稳定支撑的并发连接数大概在几百这个量级而 Nginx 单机扛几万并发连接是很常见的事。动静分离就是把静态资源这种高频率、低计算量的请求从 Tomcat 手里接过来让 Tomcat 专心处理 JSP、Spring MVC、接口这类真正需要计算的任务。这样两边的资源利用率都能上来整个系统的吞吐量也跟着上涨。1.2 负载均衡解决的是单点瓶颈如果说动静分离是替 Tomcat 减负那负载均衡就是替 Tomcat 增加人手。单台 Tomcat 的能力是有上限的哪怕你把它堆到性能最优也总有扛不住的时候。尤其是在用户量上涨之后数据库压力先不谈单是应用服务器这一层线程池满、连接超时、CPU 飙涨这些问题就会轮流出现。这个时候你不是去压榨单台机器而是应该横向扩展部署两台、三台甚至更多 Tomcat 节点让 Nginx 作为统一的入口把请求分发到后端的各个节点上。分发的过程就是负载均衡。Nginx 会根据配置的算法把请求合理地送到不同的 Tomcat 上。一台挂了其他节点继续工作这就是故障转移流量大了多加两台 Tomcat水平扩容这就是弹性扩展。我当年负责的一个模拟项目日活冲到一定程度后单台 Tomcat 频繁出现 Connection refused高峰时段用户明显感觉页面打开变慢。后来接入 Nginx 做负载均衡后端从一台扩到三台 TomcatQPS 翻了一倍多慢请求比例大幅下降关键是整个过程不需要改动任何项目代码只是把部署拓扑改了一下。这种“不改代码、只改架构”的提升对业务来说是最安全的优化方式。1.3 适合这套架构的典型场景Nginx Tomcat 动静分离与负载均衡的组合最适合这几类情况第一类是传统的 Java Web 项目用 JSP、Servlet 开发静态资源放在 Web 应用目录下。这种项目一般已经有了 Tomcat 部署基础引入 Nginx 是在前端加一层改动成本最低。第二类是团队服务器资源有限的小型项目。没有专门的 CDN也没有微服务网关把所有静态资源直接交给 Nginx 托管相当于用最低的成本获得了接近 CDN 的静态资源加速效果。第三类是正在从单机向集群演进的项目。比如你原本只有一台服务器客户越来越多准备再加机器这时候用 Nginx 做统一入口和负载均衡是最平滑的过渡方式。当然如果你的项目已经上了 Spring Cloud 这类微服务框架通常会搭配 Gateway 或专门的流量网关Nginx 更多是作为最外层入口存在。但在内层服务之间做负载均衡的思路和这里讲的 Nginx upstream 机制本质上是一脉相承的。2. 环境准备与基础部署2.1 组件版本怎么选部署这套环境需要三样东西JDK、Tomcat、Nginx。版本搭配其实没有太多玄学关键是稳定两个字。我自己的习惯是优先选择 Linux 平台用 CentOS 7 或者 Ubuntu 20.04 这类长期支持版本。JDK 我一般用 8 或 11Tomcat 8.5 或 9.0Nginx 用 1.20 左右的稳定版就可以。这套组合经过大量生产环境验证踩过坑的人比较少社区资料也多遇到问题容易查。下表是我常用的版本组合你可以直接照着来组件推荐版本下载说明JDK8u202 或 11.0.x注意别用最新大版本部分 Tomcat 旧版本不兼容Tomcat8.5.x 或 9.0.x两个版本 API 差异不大部署方式一样Nginx1.20.x稳定版自带常用模块无需编译扩展操作系统CentOS 7 / Ubuntu 20.0464 位系统内存至少 2G这里有一个细节Tomcat 和 JDK 版本的兼容性不是所有版本都能随便配。比如 Tomcat 10 采用的是 Jakarta EE 规范包名从 javax.* 换成了 jakarta.*这意味着部署在 Tomcat 9 上好好的 WAR 包放到 Tomcat 10 很可能会启动报错。如果你项目还在用老代码保守一点选 Tomcat 9 更省心。2.2 安装部署三步走创建目录结构。我习惯把软件都放在 /usr/local 下面项目数据放在 /data这样软件和业务数据分开后续备份也清晰。我常做的目录结构大概是这样的mkdir -p /usr/local/nginx mkdir -p /usr/local/tomcat-node1 mkdir -p /usr/local/tomcat-node2 mkdir -p /data/static下载并解压。这里以 Tomcat 为例wget https://archive.apache.org/dist/tomcat/tomcat-9/v9.0.54/bin/apache-tomcat-9.0.54.tar.gz tar -zxvf apache-tomcat-9.0.54.tar.gz -C /usr/local/tomcat-node1 --strip-components1Nginx 的安装也类似如果使用 yum 或 apt 安装记得确认版本不是太旧。我个人偏好的方式是直接官网下载源码包然后编译安装虽然多几步命令但这样以后想加第三方模块比如 HTTP 健康检查模块重编一次就能带上灵活性更高。启动服务验证。先启动 Tomcat默认监听 8080 端口看到 Tomcat 的欢迎页就说明 Java 环境没问题/usr/local/tomcat-node1/bin/startup.sh curl -I http://127.0.0.1:8080再启动 Nginx默认监听 80 端口/usr/local/nginx/sbin/nginx curl -I http://127.0.0.1这一步验证的是最基础的链路Nginx 能访问、Tomcat 能访问。后面的动静分离和负载均衡都要在这两个基础上叠加配置。2.3 部署测试项目与静态资源为了后面真正验证动静分离的效果不能光看欢迎页得准备一个有点业务量的测试项目。先准备一个最简单的 Java Web 项目。假如你有一个叫 demo 的 WAR 包直接丢到 Tomcat 的 webapps 目录下然后把 Tomcat 的默认 ROOT 目录清空避免干扰测试。这里用的是一个很简单的做法rm -rf /usr/local/tomcat-node1/webapps/ROOT cp demo.war /usr/local/tomcat-node1/webapps/ROOT.war我这里把 WAR 包部署成 ROOT 的原因是希望访问 / 就直接进入项目不需要在 URL 里再带项目名。生产环境不建议这么搞但测试环境这样最省事。然后准备静态资源。动静分离的前提是 Nginx 有一个静态资源目录我们准备把项目的图片、CSS、JS 都搬到这里。先在 /data/static 下面建好目录结构mkdir -p /data/static/static/css mkdir -p /data/static/static/js mkdir -p /data/static/static/img echo body{background:#f0f0f0;} /data/static/static/css/demo.css echo console.log(static js) /data/static/static/js/common.js注意我把静态资源放在 /data/static 下面但请求路径上还会有一层 static 前缀这是刻意为之。如果你直接请求 http://127.0.0.1/static/css/demo.cssNginx 会在 root 指定的 /data/static 下面找 static/css/demo.css也就是实际路径 /data/static/static/css/demo.css。这种对应关系要理清楚不然配置很容易出错。3. Nginx 核心配置动静分离落地3.1 配置负载均衡 upstream 池Nginx 的负载均衡核心是 upstream 模块。它定义了一组后端服务器Nginx 会把请求按照某种策略分发给这组服务器。在最简单的情况下配置长这样upstream tomcat_pool { server 127.0.0.1:8081 weight1; server 127.0.0.1:8082 weight1; }upstream 这个名字可以自定义我习惯用 tomcat_pool这样一眼就能看出它的用途。server 指令后面跟的是后端 Tomcat 的地址和端口。这里有个权重参数 weight默认值是 1表示两台机器分配到的请求数量相当。如果你的服务器性能不同可以给高性能的机器加大权重比如 weight2它能分到两倍的请求量。这个参数在扩容的时候很实用比如新机器配置高你先给它权重大一些让流量逐步倾斜过去观察几天没问题再调整。3.2 location 规则实现动静分离动静分离的核心是通过 location 匹配规则把不同后缀的请求引导到不同的处理位置。静态资源请求交给 Nginx 本地文件系统动态请求反向代理给 Tomcat。最典型的配置如下server { listen 80; server_name localhost; # 静态资源请求交给 Nginx 直接处理 location ~* \.(css|js|png|jpg|jpeg|gif|bmp|ico|svg)$ { root /data/static; expires 7d; access_log off; } # 动态请求统一转发给 Tomcat 集群 location / { proxy_pass http://tomcat_pool; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; } }这段配置我建议你实际敲一遍因为里面有几个极易出错的细节。第一正则匹配 location 用了 ~* 前缀表示不区分大小写。如果你想要精确控制可以用 ~ 表示区分大小写。但实际生产环境中文件后缀大小写的问题经常出现所以用 ~* 更稳妥。第二root 后面跟的路径要和实际静态资源的存放路径完全一致否则会 404。第三expires 7d 是让浏览器对这些静态资源缓存 7 天这个参数对减少请求量的帮助非常大尤其在图片多、JS/CSS 文件多的项目里一次全量缓存能省下大量重复请求。这里有一个非常重要的匹配顺序问题。Nginx 的 location 匹配不是按从上到下依次匹配的而是先做前缀匹配再做正则匹配正则匹配到的优先级更高。换句话说即使下面那条 location / 也能匹配上 /static/css/demo.css但由于上面那条正则 location 更精确最终请求还是会交给静态资源处理。这正是动静分离能够生效的本质原因。3.3 proxy_pass 结尾斜杠的坑proxy_pass 的 URI 处理逻辑是很多新手踩坑的重灾区值得单独拿出来讲一讲。先看两种写法proxy_pass http://tomcat_pool;和proxy_pass http://tomcat_pool/;区别在于结尾多了一个斜杠。当 proxy_pass 后不带 URI也就是没有路径部分时Nginx 会把原始请求的 URI 原封不动地传给后端。当 proxy_pass 后带 URI 时Nginx 会把 location 匹配的部分替换成 proxy_pass 中指定的路径再传给后端。举个例子如果请求是 http://127.0.0.1/api/user/info使用 proxy_pass http://tomcat_pool; 时后端 Tomcat 收到的是 /api/user/info。使用 proxy_pass http://tomcat_pool/; 时后端 Tomcat 收到的是 /user/info因为 /api 部分被替换掉了。你写配置时必须是完全清楚这两种写法的语义差异才能避免走弯路。我在给生产环境排错时遇到过后端接口正常、前端却 404 的情况最后定位到就是 proxy_pass 结尾多了一个斜杠导致的。若是你有不确定的我会这样检查凡是没有特殊替换需求的我会统一写成不带 URI 的 proxy_pass让请求 URI 原样透传这样理解和排查都简单。3.4 关键代理参数逐一说明动态请求交给 Tomcat 时并不是简单转发就完事还涉及几个 HTTP 头参数这些参数会在后端接收请求时发挥作用。proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;第一行设置 Host 头。如果不设置后端 Tomcat 收到的请求 Host 会是 Nginx 自身的地址比如 127.0.0.1这会给基于 Host 做虚拟主机或域名判断的后端应用带来困扰。设置成 $host 后后端拿到的就是真实的访问域名。第二行设置 X-Real-IP。Nginx 和后端 Tomcat 之间的连接源 IP 永远是 Nginx 所在机器的 IP这样后端就无法获取真正的客户端 IP。通过 X-Real-IP 这个头把客户端的真实 IP 传给后端。第三行是 X-Forwarded-For它会在原有值的基础上追加客户端的 IP。如果中间还有多层代理这个头会累积起来形成一个 IP 列表最左边的就是最原始的客户端 IP。除了请求头超时参数也很关键。我会在 proxy 配置里加上这几行proxy_connect_timeout 5s; proxy_read_timeout 10s; proxy_send_timeout 10s;connect_timeout 是 Nginx 和后端 Tomcat 建立 TCP 连接的超时时间。如果 Tomcat 已经挂了但端口还能被探测到这个参数决定了 Nginx 多久会放弃。read_timeout 和 send_timeout 则是两次读写操作之间的间隔超时单位是秒。如果你的后端有耗时较长的接口比如文件导出这几个值需要调大否则 Nginx 会在中间主动断开连接前端就会看到 504。如果你的系统有文件上传功能还要加上 client_max_body_size 限制。默认情况下 Nginx 限制了请求体大小为 1MB超过这个大小直接返回 413。很多人部署完上传功能小文件正常大文件就失败不用怀疑十有八九是这里的问题。按需改大例如client_max_body_size 20m;4. 负载均衡算法与会话保持4.1 默认轮询与权重轮询Nginx 负载均衡默认使用轮询算法也就是请求按时间顺序逐一分配到不同的后端服务器。两台 Tomcat 的话第一个请求去 A第二个去 B第三个又回到 A循环往复。这种算法实现简单后端服务器配置均衡时效果还不错。加权轮询则是在轮询的基础上加入了 weight 参数。Nginx 会根据权重比例来分配请求例如upstream tomcat_pool { server 127.0.0.1:8081 weight2; server 127.0.0.1:8082 weight1; }这样分配的结果是8081 端口上的 Tomcat 接收大约三分之二的请求8082 接收大约三分之一。这种模式适合后端服务器配置不对等的场景比如一台是 4 核 8G一台是 2 核 4G前者完全可以承担更多流量。4.2 ip_hash 实现会话保持光有轮询还不够。如果你的项目使用了 Session 保存用户登录状态而且还没有做 Session 共享默认的轮询策略会带来一个很严重的问题用户第一次请求被分到 A 节点登录状态存在了 A 节点上第二次请求被分到 B 节点B 节点发现没有这个用户的 Session于是把你踢回登录页。解决这个问题最简单的办法是使用 ip_hash 负载均衡策略。它的原理很简单Nginx 会根据客户端 IP 计算出一个哈希值同一个 IP 的请求始终会被定向到同一台后端服务器。这样用户只要第一次登录时落在某台机器上后续的请求也都会落在这台机器上Session 的问题就避免了。upstream tomcat_pool { ip_hash; server 127.0.0.1:8081; server 127.0.0.1:8082; }需要注意的是ip_hash 适合在一个办公室、同一个出口 IP 访问的场景下使用。但在移动网络环境下用户的出口 IP 可能会频繁变化这种情况下 ip_hash 的效果就会打折扣。4.3 后端节点健康检查与故障转移Nginx 的 upstream 里有两个参数和故障转移密切相关max_fails 和 fail_timeout。默认情况下max_fails 为 1fail_timeout 为 10 秒。意思是Nginx 在 10 秒内只要发现后端服务器有 1 次请求失败就会在接下来的 10 秒内把这台服务器标记为不可用请求不再分配给它。过了这个时间窗口Nginx 再尝试一次如果能连通就重新恢复调度。我一般会按业务情况调整这些参数例如upstream tomcat_pool { server 127.0.0.1:8081 max_fails3 fail_timeout30s; server 127.0.0.1:8082 max_fails3 fail_timeout30s; }将 max_fails 提高为 3是为了避免一次性故障就触发下线毕竟有些错误是临时性的。fail_timeout 增加到 30 秒也是为了让节点下线后有足够的时间恢复。这里有一个容易误解的点Nginx 的主动健康检查机制定期向后端发探测请求是商业版才带的功能开源版默认只有被动的健康检查也就是靠真实请求来判断后端是否可用。如果你需要主动探活可以使用第三方健康检查模块或者在 Nginx 前面再加一层探测脚本。4.4 生产环境 Session 共享的更优解ip_hash 是治标不治本的方案。虽然能解决会话保持问题但它也带来一个缺点一旦某台 Tomcat 宕机这台机器上所有的用户 Session 都会丢失用户被迫重新登录。而且这种粘性会话会让负载分配不均匀某些大流量 IP 可能会长期集中在一台机器上。生产环境我更推荐集中式 Session 管理。常见方案是把 Session 统一存放到 Redis 等缓存中间件中所有 Tomcat 节点都从同一个地方读写 Session。这样不管请求落到哪个节点都能拿到一致的会话数据彻底摆脱对 ip_hash 的依赖。实现方式通常有两种。一种是使用 Spring Session在项目里引入依赖后Tomcat 的 Session 会被透明地替换成 Redis 存储对业务代码完全无感。另一种是在 Tomcat 层面配置 Session Manager使用官方提供的 Redis Session Manager 扩展。我的建议是如果项目很小、短期不想动代码先用 ip_hash 过度是可以接受的。但如果项目已经开始集群化部署为了未来的扩展和维护尽早接入集中式 Session 才是正路。Session 共享这件事越早做越轻松等项目规模大了再改涉及的面就会广很多。5. 验证与压测效果到底如何5.1 用 curl 验证动静分离是否生效配置改完了先不要急着压测用 curl 随手验证一下每个请求被谁处理了。Nginx 响应静态文件和 Tomcat 响应请求响应头里有明显区别。先看动态请求的响应curl -I http://127.0.0.1/demo/index.jsp观察响应头中的 Server 字段。如果这条请求经过 Nginx 转发给 TomcatServer 字段会显示 Apache-Coyote/1.1这是 Tomcat 的标识。如果是 Nginx 直接返回的Server 字段会显示 nginx。再验证静态资源curl -I http://127.0.0.1/static/css/demo.css如果响应头里的 Server 是 nginx并且带有 Expires 和 Cache-Control 头说明静态资源确实被 Nginx 接管了动静分离在生效。我还习惯检查一下访问日志Nginx 的 access.log 里静态资源请求和动态接口请求的来源地址都指向客户端 IP而后端 Tomcat 的访问日志里来源地址是 Nginx 的 IP。这一点也可以用来辅助确认链路是否正常。5.2 用 ab 压测对比单机与集群配置验证通过后可以做一次简单的压测对比看看负载均衡带来了多少提升。这里我使用 Apache ab 工具如果你没有装 Apache也可以用 wrk 或 vegeta。先压单台 Tomcat 作为基线ab -n 2000 -c 100 http://127.0.0.1:8081/demo/index.jsp我这里的模拟结果是 QPS 大概在 9000 左右平均响应时间 10ms。当然这个数据跟你机器配置和页面复杂度密切相关重点是看对比趋势。然后通过 Nginx 访问两台 Tomcatab -n 2000 -c 100 http://127.0.0.1/demo/index.jsp在同样的并发情况下QPS 通常会提升到单台的 1.8 倍到 2 倍。这里有一个比较重要的指标是失败率Failed requests如果出现大量失败说明后端某一台节点可能存在性能瓶颈或者配置不当。5.3 观察后端日志确认真实命中还有一种更直接的验证方式是同时打开两台 Tomcat 的访问日志观察请求是否真的被分发到了两台机器。tail -f /usr/local/tomcat-node1/logs/localhost_access_log.txt tail -f /usr/local/tomcat-node2/logs/localhost_access_log.txt同时发起一批请求你会发现两台机器的日志都在滚动。这里有个细节如果你使用了 ip_hash同一个 IP 的请求只会出现在一台机器的日志里如果你用的是默认轮询请求会交替出现在两台机器上。这个验证步骤虽然简单但在排查“负载均衡不生效”这类问题时特别关键因为它能直接定位问题到底出在 Nginx 配置还是出在后端节点。6. 常见问题与排查技巧实录6.1 静态资源 404 或样式丢失这是动静分离里最常见的问题。页面能打开但 CSS、JS、图片全部 404页面完全变形。排查路径基本上就两条。第一条是看 Nginx 的错误日志通常会给出具体的文件路径。如果日志显示 no such file or directory说明路径拼接出了问题。需要检查 root 指定的目录和 URL 路径之间的映射关系是否一致。给你一个快速验证的方法根据请求 URL 和 root 配置手动拼接出 Nginx 期望的物理路径然后在服务器上用 ls 确认这个文件是否存在。比如请求是 /static/css/demo.cssroot 是 /data/static那 Nginx 找的文件就是 /data/static/static/css/demo.css。第二条排查路径是看浏览器开发者工具里的实际请求 URL。如果你项目里的 CSS 引用路径是绝对路径 /static/css/demo.css那就没有问题。如果引用的是 project/static/css/demo.css 这种相对路径通过负载均衡入口访问时很可能会因为 Nginx 转发路径的细微差异导致路径错乱。6.2 Session 丢失用户频繁掉登录状态用户登录后操作着操作着就被踢回登录页这是负载均衡引入后最典型的问题。如果你没有配置 ip_hash也没有 Session 共享那出现这个问题几乎是一定的。排查方式很简单用两个不同浏览器登录系统或者同一浏览器开普通窗口和隐身窗口观察登录后在两台 Tomcat 的日志里有没有都出现请求。如果确认是 Session 问题通常有两种解法小项目临时用 ip_hash 顶上生产环境上 Redis 共享 Session。我之前接手的某跨平台系统项目就遇到过这个坑当时技术负责人图省事用了轮询结果上线第二天就收到大量掉线反馈临时改 ip_hash 先应急同时安排研发花了两天时间接入了集中式 Session才彻底解决。6.3 后端应用获取不到客户端真实 IP做完负载均衡之后后端 Tomcat 记录的客户端 IP 全部变成了 Nginx 的 IP导致日志分析、用户定位功能全部失效。这个问题前面已经提过需要在 Nginx 配置里加上 X-Real-IP 和 X-Forwarded-For 请求头同时在后端 Tomcat 的 server.xml 里给 Engine 或 Host 配置 RemoteIpValve这样 Tomcat 才会信任 Nginx 传过来的 IP 头并把它作为实际的客户端地址。Valve classNameorg.apache.catalina.valves.RemoteIpValve remoteIpHeaderX-Forwarded-For protocolHeaderX-Forwarded-Proto /这里有一个安全细节如果你是直接暴露在公网的 Nginx任何客户端都可以伪造 X-Forwarded-For 头。所以在让 Tomcat 信任这个头之前要确保只有 Nginx 的流量能到达 Tomcat而不是让 Tomcat 端口也直接暴露在公网。否则伪造这个头可以让后端记录到错误的 IP。6.4 50X 错误速查最后整理一个 50X 错误的排查速查表直接对照处理。错误码常见原因处理动作502 Bad Gateway后端 Tomcat 未启动、端口错误、防火墙拦截检查后端服务状态、端口连通性503 Service Unavailable后端节点全部失败被下线检查后端节点恢复情况调大 fail_timeout504 Gateway Timeout后端接口响应超时调大 proxy_read_timeout排查后端慢查询413 Request Entity Too Large上传文件超过 Nginx 限制调大 client_max_body_size502 是出现频率最高的排查时先用 telnet 或 nc 探测后端端口是否通再确认 Tomcat 进程是否存活。如果后端服务是好的Nginx 还是 502那就要检查 upstream 里是否配置了错误的地址或者后端节点是否被之前的失败请求触发了临时下线。504 则要区分情况。如果只是某一个长时间的接口偶尔超时调大 proxy_read_timeout 就能解决。如果后端接口普遍响应缓慢那要排查的是 Tomcat 线程池、数据库慢查询和应用本身的性能问题调大超时只是掩耳盗铃。搭这套架构从开始到落地我通常半天内就能完成真正耗时的是后续的慢慢调优和排错。最后再分享一个小技巧每次改完 Nginx 配置先跑一遍 nginx -t 检查语法再执行 nginx -s reload不要直接用 restart。Reload 会平滑切换配置让正在处理的请求不中断这在生产环境里是必须养成的好习惯。这套架构不复杂但每一个细节都值得认真对待。
