Spring Boot生产部署必须用Nginx反向代理的5大核心原因

1. 为什么用Nginx部署Spring Boot Jar包，而不是直接java -jar？

你刚写完一个Spring Boot项目，本地测试跑得飞快，打包成jar后双击也能启动，但一上线就卡壳——用户访问时要么打不开，要么超时，要么连不上。这时候有老同事拍着你肩膀说：“别直接java -jar了，上Nginx。”你心里嘀咕：我这又不是Web服务器，又没HTML页面，加个Nginx不是多此一举？其实，这不是“加一层”，而是补上生产环境里最基础、最关键的三块拼图：反向代理、静态资源卸载、请求入口统一管控。

Nginx在这里根本不是替代Spring Boot，而是做它做不到、也不该做的事。Spring Boot内嵌的Tomcat或Jetty，本质是应用容器，专注业务逻辑执行；而Nginx是专业的边缘网关，天生擅长处理海量并发连接、SSL终止、路径重写、负载分发和故障隔离。举个生活化的例子：Spring Boot就像一家餐厅的主厨，负责把食材变成菜；Nginx则是餐厅门口的迎宾+前台+保安+点单系统——它不炒菜，但它决定谁进门、走哪条通道、菜单怎么展示、高峰期怎么分流、有人闹事怎么隔离，还能顺手把饮料和纸巾（静态资源）提前备好，不让厨师反复跑腿。

实际项目中，我见过太多团队踩坑：某公司把Spring Boot直接暴露在公网，用8080端口对外服务，结果被扫描器盯上，三天内遭遇27次目录遍历试探；另一家没配Nginx，前端Vue项目和后端jar全挤在一个端口，跨域问题改了八版配置还是403；还有团队用systemd直接托管jar，结果日志没分离、OOM崩溃后不自动拉起、HTTPS证书更新要重启整个应用……这些问题，Nginx一条proxy_pass指令+几行location规则就能根治。

更关键的是，Nginx让部署具备了“可演进性”。今天你只有一个jar，明天可能拆成用户服务、订单服务、支付服务三个jar，后天要接入API网关或灰度发布——只要Nginx配置层保持稳定，后端服务可以自由增减、替换技术栈，甚至混用Java/Go/Python，完全不影响用户访问体验。这种解耦能力，是直接裸跑jar永远无法提供的底层弹性。

所以，这不是“要不要加Nginx”的问题，而是“什么时候必须加Nginx”的问题。答案很明确：只要这个Spring Boot服务要面向真实用户、要长期在线、要应对不确定流量，就必须加Nginx——它不是锦上添花，而是生产环境的准入门槛。

2. 整体架构设计与方案选型逻辑

2.1 为什么选反向代理模式，而不是正向代理或直接监听？

先厘清一个常见误解：很多人以为Nginx部署Spring Boot就是“让Nginx去调用jar”，这没错，但关键在于“怎么调”。我们采用的是反向代理（Reverse Proxy），而非正向代理（Forward Proxy）。两者的本质区别在于：正向代理代表客户端去访问目标服务器（比如浏览器配置代理IP），而反向代理代表服务器接收所有外部请求，再按规则分发给后端真实服务。对用户而言，他只和Nginx打交道，完全不知道背后是Java还是PHP，是单机还是集群。

为什么必须是反向代理？因为Spring Boot jar默认绑定localhost:8080，这是典型的“仅本机可访问”策略。如果直接把jar绑定到0.0.0.0:8080并开放防火墙端口，等于把应用容器直接暴露在互联网上——没有请求过滤、没有连接数限制、没有SSL卸载、没有路径隔离。而Nginx作为反向代理，天然形成一道屏障：它监听80/443端口接收用户请求，再以内部网络（如127.0.0.1:8080）安全地转发给Spring Boot，彻底隔绝外部对应用端口的直接访问。

提示：绝对不要在生产环境将Spring Boot的server.address设为0.0.0.0并开放该端口。这是高危操作，等同于拆除服务器防火墙的最后一道门。

2.2 为什么不选Apache HTTPD或Caddy？

Apache历史悠久，模块丰富，但对现代微服务场景略显笨重。它的进程模型（prefork/workers）在高并发短连接场景下内存开销大，配置语法冗长，且对WebSocket支持需额外编译模块。Caddy确实优雅，自动HTTPS、配置简洁，但其插件生态和企业级运维工具链（如日志分析、监控集成、配置热加载稳定性）目前仍不如Nginx成熟。某次我们为某高校教务系统做压测，Caddy在持续10万并发连接下出现偶发502错误，排查发现是其默认的HTTP/2流控阈值与Spring Boot的Keep-Alive设置冲突；而Nginx经多年打磨，在同等条件下稳如磐石。

我们最终选择Nginx，核心基于三点硬指标：

1. 连接承载能力：epoll事件驱动模型，单机轻松支撑10万+并发连接，内存占用仅为Apache的1/3；
2. 配置可靠性：nginx -t语法检查+nginx -s reload平滑重载，线上零停机变更已成标配；
3. 生态兼容性：与Prometheus、Grafana、ELK日志体系深度集成，运维脚本、Ansible角色、Docker镜像均高度标准化。

2.3 静态资源到底放哪？Nginx托管 vs Spring Boot内置

Spring Boot默认通过spring.resources.static-locations提供静态资源服务（如/static下的JS/CSS/图片）。但在生产环境，这会带来两个隐形成本：一是JVM堆内存被大量缓存静态文件占用，GC压力增大；二是每次HTTP请求都要经过Spring MVC拦截链，哪怕只是下载一个1KB的favicon.ico，也要走一遍DispatcherServlet——性能损耗可达30%以上。

我们的方案是：所有静态资源由Nginx直接响应，Spring Boot只专注动态API。具体做法是，在Nginx配置中用location精确匹配静态路径前缀（如/assets/,/images/,/js/），并指向磁盘上的物理目录：

location ^~ /assets/ { alias /var/www/myapp/assets/; expires 1y; add_header Cache-Control "public, immutable"; }

这里^~表示前缀匹配优先级最高，确保不会被后续的/通配规则覆盖；expires 1y强制浏览器长期缓存；immutable告诉浏览器该资源内容永不改变，可跳过ETag验证。实测下来，首页加载时间从1.2秒降至0.4秒，CDN回源流量下降65%。

注意：Spring Boot中必须关闭静态资源处理，否则会出现Nginx和Spring Boot双重响应冲突。在application.yml中添加：

spring: web: resources: add-mappings: false

2.4 HTTPS终结为何必须在Nginx层完成？

Spring Boot虽支持server.ssl.*配置启用HTTPS，但存在严重缺陷：密钥和证书直接放在应用代码中，版本管理困难；TLS握手由JVM处理，性能远低于Nginx的OpenSSL原生实现；更致命的是，一旦应用重启，SSL会话缓存丢失，导致用户首次访问TLS握手耗时激增。

正确做法是：Nginx做SSL终止（SSL Termination）。它监听443端口，用OpenSSL解密HTTPS请求，再以明文HTTP协议（http://127.0.0.1:8080）转发给Spring Boot。这样做的好处是：

• TLS卸载由专业网络层完成，CPU消耗降低40%；
• 会话复用（Session Resumption）、OCSP Stapling等高级特性开箱即用；
• 证书更新只需重载Nginx，无需重启Java应用；
• 可集中管理HSTS、CSP、X-Frame-Options等安全头。

我们曾对比过：同一台4核8G服务器，Nginx终结HTTPS时QPS达8200；而Spring Boot自建HTTPS时QPS仅4900，且在高并发下频繁出现javax.net.ssl.SSLException: handshake timed out。

3. 核心配置详解与实操步骤

3.1 Nginx基础配置结构解析

Nginx配置不是一堆指令的堆砌，而是一个有层级、有继承、有作用域的树状结构。理解其骨架，才能避免“改了一行，全站崩掉”的惨剧。核心配置文件通常位于/etc/nginx/nginx.conf，其标准结构如下：

# 全局块：影响整个Nginx进程 user nginx; worker_processes auto; worker_rlimit_nofile 65535; events { # 事件块：定义连接处理模型 use epoll; worker_connections 65535; } http { # HTTP块：所有HTTP服务的基础配置 include /etc/nginx/mime.types; default_type application/octet-stream; # 日志格式、超时时间、压缩等全局设置 log_format main '$remote_addr - $remote_user [$time_local] "$request" ' '$status $body_bytes_sent "$http_referer" ' '"$http_user_agent" "$http_x_forwarded_for"'; # 虚拟主机块：每个server就是一个独立站点 server { listen 80; server_name example.com; location / { proxy_pass http://127.0.0.1:8080; } } }

关键点在于：http块内的配置（如log_format、gzip）对所有server生效；而server块内的配置（如listen、server_name）只对该虚拟主机有效；location块则进一步细化到URL路径级别。这种层级设计，让复杂配置变得可维护。

实操心得：永远不要在http块里写proxy_pass！它必须出现在location或server块内。我曾帮某电商团队排查一个诡异问题：他们把proxy_pass写在http块，导致所有server都默认转发到同一个后端，结果用户访问A网站却看到B网站的内容——这就是作用域误用的典型后果。

3.2 Spring Boot Jar包部署前的必要准备

部署不是把jar丢到服务器就完事。一个健壮的生产级jar包，需要提前做好五件事：

第一，禁用内嵌Tomcat的HTTP端口暴露。
在application.yml中明确指定绑定地址为localhost，防止意外监听外网：

server: address: localhost port: 8080

这样即使防火墙策略失效，外部也无法直连8080端口。

第二，配置合理的线程池与连接超时。
Spring Boot默认Tomcat最大线程数200，对高并发不够。我们根据Nginx的proxy_read_timeout（通常设为60秒）反推，将Tomcat的connection-timeout设为65秒，避免Nginx等待超时而Tomcat还在处理：

server: tomcat: max-connections: 10000 accept-count: 100 max-threads: 200 min-spare-threads: 50

第三，启用Actuator健康检查端点。
Nginx可通过/actuator/health探针判断应用是否存活。在pom.xml中加入：

<dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-actuator</artifactId> </dependency>

并配置application.yml：

management: endpoint: health: show-details: when_authorized endpoints: web: exposure: include: health,info,metrics,prometheus

第四，日志输出重定向到文件。
避免System.out.println污染控制台，使用Logback配置滚动文件：

<!-- logback-spring.xml --> <appender name="FILE" class="ch.qos.logback.core.rolling.RollingFileAppender"> <file>/var/log/myapp/app.log</file> <rollingPolicy class="ch.qos.logback.core.rolling.TimeBasedRollingPolicy"> <fileNamePattern>/var/log/myapp/app.%d{yyyy-MM-dd}.%i.log</fileNamePattern> <timeBasedFileNamingAndTriggeringPolicy class="ch.qos.logback.core.rolling.SizeAndTimeBasedFNATP"> <maxFileSize>100MB</maxFileSize> </timeBasedFileNamingAndTriggeringPolicy> </rollingPolicy> </appender>

第五，制作systemd服务单元文件。
让jar包像系统服务一样管理，支持开机自启、日志查看、状态监控：

# /etc/systemd/system/myapp.service [Unit] Description=My Spring Boot Application After=network.target [Service] Type=simple User=appuser WorkingDirectory=/opt/myapp ExecStart=/usr/bin/java -Xms512m -Xmx1024m -jar /opt/myapp/myapp.jar Restart=always RestartSec=10 StandardOutput=journal StandardError=journal [Install] WantedBy=multi-user.target

启用服务：sudo systemctl daemon-reload && sudo systemctl enable myapp && sudo systemctl start myapp。

3.3 Nginx核心代理配置逐行说明

以下是一份经过千次生产验证的Nginx配置模板，我们逐行拆解其设计意图：

upstream backend { server 127.0.0.1:8080 max_fails=3 fail_timeout=30s; # 可扩展为多实例：server 192.168.1.10:8080; server 192.168.1.11:8080; } server { listen 80; server_name myapp.example.com; return 301 https://$server_name$request_uri; # 强制HTTP跳转HTTPS } server { listen 443 ssl http2; server_name myapp.example.com; # SSL证书配置（路径根据实际调整） ssl_certificate /etc/letsencrypt/live/myapp.example.com/fullchain.pem; ssl_certificate_key /etc/letsencrypt/live/myapp.example.com/privkey.pem; ssl_trusted_certificate /etc/letsencrypt/live/myapp.example.com/chain.pem; # 安全加固：禁用弱协议和加密套件 ssl_protocols TLSv1.2 TLSv1.3; ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384; ssl_prefer_server_ciphers off; # HSTS头：强制浏览器后续只用HTTPS访问 add_header Strict-Transport-Security "max-age=31536000; includeSubDomains; preload" always; # 防止MIME类型嗅探攻击 add_header X-Content-Type-Options nosniff; # 防止点击劫持 add_header X-Frame-Options DENY; # CSP策略（根据实际资源调整） add_header Content-Security-Policy "default-src 'self'; script-src 'self' 'unsafe-inline' 'unsafe-eval'; style-src 'self' 'unsafe-inline'; img-src 'self' data:;"; # 静态资源路径映射 location ^~ /static/ { alias /var/www/myapp/static/; expires 1y; add_header Cache-Control "public, immutable"; } location ^~ /uploads/ { alias /var/www/myapp/uploads/; expires 1h; } # API接口代理（关键！） location /api/ { proxy_pass http://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; proxy_set_header X-Forwarded-Host $host; proxy_set_header X-Forwarded-Port $server_port; # 超时设置（必须大于Spring Boot的处理时间） proxy_connect_timeout 5s; proxy_send_timeout 60s; proxy_read_timeout 60s; # 缓冲区优化（防大响应体截断） proxy_buffering on; proxy_buffer_size 128k; proxy_buffers 4 256k; proxy_busy_buffers_size 256k; # WebSocket支持（如项目用到） proxy_http_version 1.1; proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection "upgrade"; } # 根路径代理（适配前端History路由） location / { proxy_pass http://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; proxy_set_header X-Forwarded-Host $host; proxy_set_header X-Forwarded-Port $server_port; proxy_connect_timeout 5s; proxy_send_timeout 30s; proxy_read_timeout 30s; } # 健康检查端点（供Nginx主动探测） location /actuator/health { proxy_pass http://backend/actuator/health; proxy_cache_valid 200 302 10m; proxy_cache_valid 404 1m; proxy_cache_use_stale error timeout updating http_500 http_502 http_503 http_504; } }

重点参数解读：

• upstream backend：定义后端服务组，max_fails=3 fail_timeout=30s表示连续3次失败后，30秒内不再将请求发给该节点，实现自动故障隔离。
• proxy_set_header系列：必须透传原始请求信息，否则Spring Boot的@RequestHeader("X-Forwarded-For")或ServletRequest.getRemoteAddr()会拿到127.0.0.1，丢失真实用户IP。
• proxy_buffering on：开启缓冲，避免Nginx边收边转导致大文件响应被截断；proxy_buffer_size设为128k是经验值，能容纳大部分HTTP头。
• proxy_http_version 1.1+Upgrade头：这是WebSocket代理的关键，缺一不可，否则前端new WebSocket("wss://...")会报400错误。

注意：proxy_pass末尾的/符号至关重要。proxy_pass http://backend/;表示将/api/user重写为/user转发；而proxy_pass http://backend;（无斜杠）则原样转发为/api/user。务必根据Spring Boot的server.servlet.context-path配置匹配。

3.4 Let's Encrypt免费证书自动化部署

HTTPS不能靠手动拷贝证书维持。我们采用Certbot + Nginx插件实现全自动续期：

第一步，安装Certbot：

sudo apt update sudo apt install certbot python3-certbot-nginx -y

第二步，首次申请证书（需域名DNS已解析到该服务器IP）：

sudo certbot --nginx -d myapp.example.com

Certbot会自动修改Nginx配置，添加SSL相关指令，并重载服务。

第三步，验证自动续期：

# 手动测试续期流程（不实际更新证书） sudo certbot renew --dry-run # 查看续期任务（Ubuntu默认已创建systemd timer） sudo systemctl list-timers | grep certbot

Certbot默认每天凌晨2:15和下午2:15各运行一次续期检查，证书到期前30天自动更新。我们额外添加一个监控钩子，在续期成功后发送通知：

# 编辑 /etc/letsencrypt/renewal-hooks/deploy/notify.sh #!/bin/bash if [ "$RENEWED_LINEAGE" = "/etc/letsencrypt/live/myapp.example.com" ]; then echo "$(date): SSL certificate renewed for myapp.example.com" | mail -s "SSL Renewal Alert" admin@example.com fi

实操心得：Certbot的--nginx插件虽方便，但会覆盖你手动写的Nginx配置。因此，所有自定义配置（如安全头、静态资源路径）必须写在server块内，且Certbot生成的SSL配置块应放在自定义块之后。我们习惯把自定义配置放在/etc/nginx/conf.d/myapp-custom.conf，Certbot生成的SSL配置在/etc/nginx/sites-enabled/myapp，通过include顺序控制优先级。

4. 实操全流程与关键环节验证

4.1 从零开始的完整部署流水线

我们以一台全新的Ubuntu 22.04服务器为例，演示从环境初始化到服务上线的完整步骤。全程可复制粘贴执行，每一步都有明确目的：

阶段一：系统初始化

# 创建专用用户，禁止root登录 sudo adduser appuser sudo usermod -aG sudo appuser sudo sed -i 's/PermitRootLogin yes/PermitRootLogin no/' /etc/ssh/sshd_config sudo systemctl restart sshd # 更新系统，安装基础工具 sudo apt update && sudo apt upgrade -y sudo apt install curl wget git unzip vim htop -y # 安装Java 17（Spring Boot 3.x要求） sudo apt install openjdk-17-jdk -y java -version # 验证输出包含"17.x.x" # 安装Nginx sudo apt install nginx -y sudo systemctl enable nginx sudo systemctl start nginx curl -I http://localhost # 应返回200 OK

阶段二：部署Spring Boot Jar包

# 创建应用目录，上传jar包（此处用wget模拟） sudo mkdir -p /opt/myapp sudo chown appuser:appuser /opt/myapp sudo -u appuser wget -O /opt/myapp/myapp.jar https://example.com/releases/myapp-1.0.0.jar # 创建日志目录 sudo mkdir -p /var/log/myapp sudo chown appuser:appuser /var/log/myapp # 创建systemd服务文件 sudo tee /etc/systemd/system/myapp.service > /dev/null << 'EOF' [Unit] Description=My Spring Boot Application After=network.target [Service] Type=simple User=appuser WorkingDirectory=/opt/myapp ExecStart=/usr/bin/java -Xms512m -Xmx1024m -jar /opt/myapp/myapp.jar Restart=always RestartSec=10 StandardOutput=journal StandardError=journal [Install] WantedBy=multi-user.target EOF sudo systemctl daemon-reload sudo systemctl enable myapp sudo systemctl start myapp # 验证应用启动 sudo systemctl status myapp # 看到"active (running)" sudo journalctl -u myapp -f # 实时查看日志，确认无ERROR curl -s http://localhost:8080/actuator/health | jq . # 应返回{"status":"UP"}

阶段三：配置Nginx反向代理

# 备份默认配置 sudo cp /etc/nginx/nginx.conf /etc/nginx/nginx.conf.bak # 创建自定义配置 sudo tee /etc/nginx/conf.d/myapp.conf > /dev/null << 'EOF' upstream backend { server 127.0.0.1:8080 max_fails=3 fail_timeout=30s; } server { listen 80; server_name myapp.example.com; return 301 https://$server_name$request_uri; } server { listen 443 ssl http2; server_name myapp.example.com; ssl_certificate /etc/ssl/certs/ssl-cert-snakeoil.pem; ssl_certificate_key /etc/ssl/private/ssl-cert-snakeoil.key; # 临时用自签名证书，后续替换为Let's Encrypt ssl_protocols TLSv1.2 TLSv1.3; add_header Strict-Transport-Security "max-age=31536000; includeSubDomains; preload" always; location / { proxy_pass http://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; proxy_connect_timeout 5s; proxy_send_timeout 30s; proxy_read_timeout 30s; } } EOF # 测试配置语法 sudo nginx -t # 必须显示"successful" # 重载Nginx sudo systemctl reload nginx # 验证Nginx代理是否生效 curl -I http://myapp.example.com # 应返回301跳转 curl -Ik https://myapp.example.com # 应返回200，且有Strict-Transport-Security头

阶段四：申请正式SSL证书

# 安装Certbot sudo apt install certbot python3-certbot-nginx -y # 申请证书（需确保myapp.example.com DNS已指向此服务器IP） sudo certbot --nginx -d myapp.example.com # Certbot会自动修改配置并重载Nginx，验证 sudo nginx -t sudo systemctl reload nginx curl -Ik https://myapp.example.com # 检查证书是否为Let's Encrypt签发

阶段五：静态资源与安全加固

# 创建静态资源目录 sudo mkdir -p /var/www/myapp/static sudo chown -R appuser:appuser /var/www/myapp # 将前端构建产物（如dist目录）复制进去 # sudo -u appuser cp -r /path/to/dist/* /var/www/myapp/static/ # 修改Nginx配置，添加静态资源块（在server块内） sudo sed -i '/location \//i \ location ^~ /static/ {\ alias /var/www/myapp/static/;\ expires 1y;\ add_header Cache-Control "public, immutable";\ }' /etc/nginx/conf.d/myapp.conf # 添加安全头（在server块内） sudo sed -i '/add_header Strict-Transport-Security/a \ add_header X-Content-Type-Options nosniff;\ add_header X-Frame-Options DENY;\ add_header Content-Security-Policy "default-src \'self\'; script-src \'self\' \'unsafe-inline\' \'unsafe-eval\'; style-src \'self\' \'unsafe-inline\'; img-src \'self\' data:;";' /etc/nginx/conf.d/myapp.conf sudo nginx -t && sudo systemctl reload nginx

4.2 关键环节验证清单与预期结果

部署完成后，必须逐项验证，不能只看“页面打开了”。以下是生产环境必须通过的12项验证点，附带验证命令和预期输出：

注意：第8项“真实IP透传”是高频出错点。如果返回127.0.0.1，请检查Spring Boot中是否配置了server.forward-headers-strategy=framework（Spring Boot 2.2+）或server.tomcat.remoteip.remote-ip-header=x-forwarded-for（旧版），并在Nginx中确认proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;已正确设置。

4.3 性能压测与瓶颈定位

部署完成不等于高枕无忧。我们用wrk进行基础压测，定位潜在瓶颈：

第一步，安装wrk：

sudo apt install build-essential libssl-dev git -y git clone https://github.com/wg/wrk.git cd wrk make sudo cp wrk /usr/local/bin/

第二步，基准压测（模拟100并发，持续30秒）：

wrk -t12 -c100 -d30s https://myapp.example.com/actuator/health

预期结果：QPS应在800+，平均延迟<50ms。若QPS低于300，需排查。

第三步，分层诊断：

• Nginx层瓶颈：sudo nginx -T \| grep worker_connections确认连接数上限；sudo ss -s查看当前连接数；sudo nginx -V 2>&1 \| grep -o with-http_v2_module确认HTTP/2已启用。
• 网络层瓶颈：sudo iftop -P 443观察443端口实时流量；sudo netstat -s \| grep -i "retransmitted"检查TCP重传率（>2%需关注）。
• Spring Boot层瓶颈：jstack $(pgrep -f myapp.jar)查看线程阻塞；jstat -gc $(pgrep -f myapp.jar) 1s监控GC频率；curl https://myapp.example.com/actuator/metrics/jvm.memory.used查看内存使用。

我们曾遇到一个典型案例：压测QPS卡在420，jstat显示Full GC每分钟2次。排查发现application.yml中-Xmx1024m设置过小，而应用缓存了大量用户会话。将-Xmx提升至2048m后，QPS跃升至1100，Full GC消失。

实操心得：永远不要凭感觉调优。先用wrk定性，再用jstat/ss/iftop定量，最后用jstack/jmap定位。某次我们发现Nginx的worker_connections 65535看似很大，但ulimit -n系统限制只有1024，导致实际并发上限被卡死——这就是“配置了等于没配”的经典陷阱。

5. 常见问题与独家排查技巧实录

5.1 502 Bad Gateway：最痛的“黑屏”

502错误意味着Nginx成功连接到后端，但后端返回了无效响应。这是生产环境最高频的故障，原因多样，我们按发生概率排序：

原因1：Spring Boot未启动或崩溃

• 现象：curl http://localhost:8080/actuator/health返回Failed to connect
• 排查：sudo systemctl status myapp看服务状态；sudo journalctl -u myapp -n 50查最近50行日志；sudo ss -tlnp \| grep :8080确认端口是否监听
• 解决：重启服务sudo systemctl restart myapp；若反复崩溃，检查/var/log/myapp/app.log中的OutOfMemoryError或数据库连接超时

原因2：Nginx与后端超时时间不匹配

• 现象：Nginx日志/var/log/nginx/error.log中出现`up