Nginx核心功能实操详解：反向代理、负载均衡与HTTPS配置

这些年身边凡是跟 Web 打交道的朋友不管做后端、前端还是运维最后都会在一个叫 Nginx 的东西上交汇。静态文件要它托管、Java/Python/Node 服务要它转发、上 HTTPS 要它挂证书、多站点部署要它分流。我甚至面试时经常被问“你到底怎么理解 Nginx 的核心功能”。今天这篇就从实操角度把 Nginx 真正能干的几件事聊透包括安装部署、配置结构、反向代理、负载均衡、HTTPS 和常见坑。不管你是在 Linux 上用包管理器装还是打算编译安装或者只是想在 Windows 上搭个测试环境都可以直接照着操作。1. 先搞清楚 Nginx 到底解决什么问题1.1 它在服务架构里到底扮演什么角色我一直喜欢把 Nginx 比作公司前台的接待员。用户请求到了之后先由它看一看你要找谁、要求什么、要不要先做个安全检查然后决定是直接给你回一份静态页面还是把你引导到后面的某个业务部门。这个比喻对应到技术上就是三种最常见的角色。第一种是 Web 服务器负责托管 HTML、CSS、JS、图片这些静态资源这也是 Nginx 最朴素的本职工作。第二种是反向代理业务服务往往跑在某个内网端口上Nginx 作为唯一对外的入口把请求再转发给后面的应用比如 Tomcat、Node.js、Spring Boot 服务。第三种是负载均衡器后端不止一台机器的时候由 Nginx 决定“这一个请求发给谁、那一个请求发给谁”。除此之外它还能兼职做 HTTP 缓存、流量的限流限速、URL 重写、文件共享。也就是说很多公司为了省服务器和运维成本会拿 Nginx 一层就顶掉早期架构里 F5、Apache、Squid 各自扮演的部分角色。理解这一点你就明白为什么几乎所有后端教程和面试都绕不开它。1.2 为什么高并发下它这么能扛很多人第一次听到 Nginx 和 Apache 的对比都会对“单机轻松扛几万并发”产生怀疑。这里的关键不在于参数调得多花哨而在于它的事件驱动模型。传统 Apache 的 worker 模式本质上是一个连接对应一个进程或线程。连接多了线程和进程的数量就上去了操作系统光是切换上下文就忙不过来。Nginx 用的是事件驱动、异步非阻塞 I/O一个 worker 进程同时盯着成千上万个连接谁有数据来了就处理谁没有数据就继续等着。这就像餐厅里一位服务员同时服务好几桌客人而不是每桌客人配一个服务员。Linux 上 Nginx 依赖 epoll 这种 I/O 多路复用机制来实现“少量进程管海量连接”这也是它能在 C10K、甚至更高并发场景下存活的原因。不过要注意所谓高并发是有边界的Nginx 擅长的是高并发下的接入和转发。一旦涉及复杂计算、业务逻辑它仍然需要把请求交给 PHP-FPM、Tomcat、Node.js 这些真正干活的进程去处理。1.3 什么场景该用它什么场景别硬上结合我的实际经验Nginx 最适合做这几类事静态资源托管和动静分离把图片、前端打包产物交给 Nginx 直接返回不用穿透到后端语言。反向代理和网关对外隐藏后端服务细节统一做域名、证书、日志和限流。负载均衡通过 upstream 把流量分给后端多台机器。简单缓存与文件分享配合 proxy_cache 或 autoindex 模块可以解决很多临时需求。不适合硬上的是两类。一类是动态业务逻辑比如有人问“Nginx 支持 JSP 吗”准确答案是它本身不执行 JSP也不能直接跑 PHP 代码它只是把这些动态请求原样转给 Tomcat、PHP-FPM 去处理。另一类是复杂的服务治理比如服务注册发现、熔断降级、分布式链路追踪这些更适合交给 API 网关或 Service Mesh 组件。把适合的活儿交给适合的工具这才是一个成熟的架构判断。2. Nginx 安装与升级少走弯路的方法2.1 包管理器安装最省心但要注意软件源绝大多数时候我推荐新手先用系统包管理器安装快、省事、卸载也干净。在 Ubuntu/Debian 上直接apt install nginx在 AlmaLinux 9、Rocky Linux、CentOS 上可以dnf install nginx或yum install nginx。但这里有个容易踩的坑CentOS 系默认仓库里没有 Nginx需要先启用 EPELExtra Packages for Enterprise Linux仓库。AlmaLinux 9 上装完 EPEL 之后dnf install nginx才有效。装完后的配置文件通常在/etc/nginx/nginx.conf默认站点目录在/usr/share/nginx/html站点配置文件一般放在/etc/nginx/conf.d/下。如果你在下载软件包时速度不理想可以使用国内软件镜像站把系统源替换成对应厂商的镜像源再执行安装命令。镜像站提供的是和官方同步的 RPM 包或 DEB 包版本相对稳定。不过要注意系统仓库里的版本往往不是最新主线版比如某些老系统源里还是 1.20 左右的版本。对普通场景够用但如果想用新模块、新协议就得考虑编译安装或者使用官方维护的源。装完最好跑一下nginx -v确认版本再systemctl enable --now nginx设置开机自启。看到nginx: the configuration file /etc/nginx/nginx.conf syntax is ok这一行说明基础环境没问题。2.2 编译安装自定义模块与内网离线部署需要自定义模块、升级版本、或者系统仓库版本太旧的时候编译安装是绕不开的路线。网上关于编译 Nginx 的教程很多我补充几个实际有用的点。编译之前先装依赖核心是 gcc 编译器、make、PCRE正则支持、zlib压缩支持和 OpenSSLHTTPS 支持。如果是在 Debian/Ubuntu 系一行apt install build-essential libpcre3-dev zlib1g-dev libssl-dev就能搞定在 AlmaLinux 9 上则对应dnf install gcc make pcre-devel zlib-devel openssl-devel。下载源码后最关键的步骤是./configure。一个典型的生产配置参数是./configure \ --prefix/usr/local/nginx \ --with-http_ssl_module \ --with-http_v2_module \ --with-stream \ --with-http_gzip_static_module \ --with-pcre/path/to/pcre-8.45 \ --with-pcre-jit这里特别说一下--with-pcre/path/to/pcre-8.45。早期版本里Nginx 官方推荐的 PCRE 是 8.x 系列其中 8.45 是兼容性很好、社区验证较多的版本如果你从 PCRE 官网下载源码建议优先选它。如果不指定--with-pcre很多发行版会自动使用系统自带的正则库但指定源码路径能保证编译环境可控尤其在内网、离线环境下更稳。内网离线部署是我遇到过比较多的场景。比如一台 aarch64 架构的纯内网服务器既没有外网也没有配置软件源。这时提前准备两样东西就很重要一是依赖库的离线 RPM 包或者 DEB 包在能联网的同体系机器上用dnf download或apt download拉下来再拷进去安装二是 Nginx 源码包和 pcre 源码包拷贝进去后执行./configure make make install。因为整个过程不依赖外部网络只要本机依赖齐全就可以顺利完成编译安装。编译安装完的 Nginx不会自动生成 systemd 服务文件需要手动写一个[Unit] Descriptionnginx - high performance web server Afternetwork-online.target [Service] Typeforking PIDFile/usr/local/nginx/logs/nginx.pid ExecStart/usr/local/nginx/sbin/nginx ExecReload/usr/local/nginx/sbin/nginx -s reload ExecStop/usr/local/nginx/sbin/nginx -s quit PrivateTmptrue [Install] WantedBymulti-user.target放到/etc/systemd/system/nginx.service后执行systemctl daemon-reload systemctl enable --now nginx即可。2.3 平滑升级让服务不重启也能换版本线上服务一旦跑起来最怕的就是因为升级 Nginx 导致瞬间断连。好在 Nginx 提供了平滑升级能力可以做到几乎不中断请求。平滑升级的原理是给旧进程发送特定信号让新 master 接手。传统做法是直接向 master 进程发送USR2信号启动新版本再用WINCH关闭旧 worker。实际执行中我更喜欢make upgrade这条路前提是你在同一个源码目录里完成了新版本编译。具体步骤是先下载新版本源码解压后执行./configure参数要和旧版本保持一致如果加了新模块记得提前确认依赖然后make但不要make install因为不能覆盖正在运行的文件接着用make upgrade它会自动完成二进制替换、发送信号、切换进程这一整套动作。执行完nginx -v查看版本号确认已经是新版本再观察现有连接。如果你的nginx -v和nginx -V分不清这里有个小知识小写-v只显示版本号大写-V会显示版本号和全部编译参数排查模块问题时代差就靠-V来确认。2.4 Windows 环境快速上手与图形化管理工具很多人在 Windows 上只是想搭个本地测试环境复制粘贴一遍 Nginx 配置。Windows 版 Nginx 不用安装去官网下载 zip 压缩包解压即可。解压出来直接双击nginx.exe就能跑默认页面可以在浏览器访问本机端口看到。启动和停止命令是nginx.exe -s stop、nginx.exe -s reload。Windows 上踩坑的点主要有两个一是解压路径别带中文和空格有些隐藏字符问题会让你排查半天二是 Windows 下没有 systemd不能用systemctl操作只能通过命令行。对于实在不想动手敲命令和改配置文件的朋友可以试试 Nginx Proxy ManagerNPM这类图形化反向代理工具尤其在 Docker 环境下部署很流行它把证书申请、域名绑定、代理规则都做成了 Web 表单。Windows 上也有一些开源的管理前端项目把起停、reload、日志查看做成图形界面。不过我要说实话真正上了生产环境命令行和配置文件始终是最可靠的方式图形工具适合快速验证和中小团队内部使用真出了问题大多数人最后还是回到nginx -t和日志上来。3. 看懂 nginx.conf配置结构的核心骨架3.1 三大配置块与指令作用域学习 Nginx 配置第一件事不是背指令而是理解结构。一份最基本的nginx.conf长这样user nginx; worker_processes auto; error_log /var/log/nginx/error.log notice; pid /var/run/nginx.pid; events { worker_connections 1024; } http { include /etc/nginx/mime.types; default_type application/octet-stream; server { listen 80; server_name example.com; location / { root /usr/share/nginx/html; index index.html index.htm; } } }整体分三大块。最外层main区域配置进程级参数比如worker_processes、error_log、pid。events块配置连接处理模型比如worker_connections决定每个 worker 进程最多同时处理多少连接。http块内部才是我们日常打交道的业务配置里面可以包含多个server每个server下又可以有多个location。指令是有作用域的。比如root写在server里会对这个站点所有请求生效写在某个location里则只对该路径生效。理解作用域之后很多“配置不生效”的问题就迎刃而解了。3.2 多站点部署主域名与二级域名怎么共处一台服务器部署多个网站是 Nginx 最常见的应用场景之一。很多人误以为需要多个 IP 或多个端口其实关键在server_name和listen的组合。看一下这个例子server { listen 80; server_name example.com www.example.com; root /var/www/main; index index.html; } server { listen 80; server_name blog.example.com; root /var/www/blog; index index.html; } server { listen 80; server_name admin.example.com; root /var/www/admin; }浏览器访问不同域名Nginx 会按server_name选择匹配的配置块。如果你想让 example.com 的所有二级域名统一指向某个服务可以用泛域名server_name *.example.com;如果访问的是没有匹配到任何server_name的域名怎么办Nginx 会选用default_serverlisten 80 default_server;我习惯把默认 server 配置成一个 404 页面或者跳转页避免别人把没备案、未绑定的域名解析过来后顺手访问到你某个本不该对外开放的站点。3.3 静态文件服务的 root 与 alias 辨析配置静态文件时root和alias的区别是我见过出错率最高的问题之一。root的含义是“把 location 匹配到的 URI 直接拼接到 root 后面”。比如location /static/ { root /var/www/assets; }请求/static/logo.png实际寻找的文件是/var/www/assets/static/logo.png。注意/static/这一段路径也保留了下来。而alias的含义是“用 alias 内容替换掉 location 匹配的路径”。比如location /static/ { alias /var/www/assets/; }请求/static/logo.png实际寻找的文件是/var/www/assets/logo.png。/static/这一层被替换掉了。从配置习惯上看当我希望某个静态目录对外路径和真实磁盘路径不一致时用alias更合适绝大多数时候root配在server层再配合location做精细控制就够了。判断标准很简单你心里要始终清楚“客户端请求的 URL 最终对应磁盘上哪个文件”用curl -I验证返回状态码能避免无数个路径错误。3.4 搭建简单的文件共享目录autoindex之前有热搜词叫“nginx autoindex 在线文件浏览”这确实是很实用的功能。它让 Nginx 在没有额外文件服务的情况下直接把某个目录变为浏览器可访问的下载列表。核心配置只有几行location /files/ { alias /data/files/; autoindex on; autoindex_exact_size off; autoindex_format html; charset utf-8; }autoindex on开启目录列表autoindex_exact_size off让文件大小显示为可读的 MB/GB 而不是字节autoindex_format html确保输出为标准 HTML 页面浏览器打开就能看到文件列表并点击下载。实际使用中我还会叠加一层访问控制避免整个目录裸奔到公网location /files/ { alias /data/files/; autoindex on; allow 192.168.1.0/24; deny all; }这样只在局域网内能浏览公网访问一律 403。对内部工具包、安装包、临时文件分发来说比搭一套 OSS 或网盘轻量得多。4. 反向代理与负载均衡Nginx 最值钱的能力4.1 反向代理的工作原理与 proxy_pass 写法反向代理是 Nginx 在生产里使用频率最高的核心功能。它的本质是“代理服务器接收客户端请求再向后端应用服务器发起请求把结果返回给客户端”。对客户端来说它只跟 Nginx 说话完全感知不到后端的存在。配置一个简单的代理到 Tomcatserver { listen 80; server_name java.example.com; location / { proxy_pass http://127.0.0.1:8080; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; } }把 8080 端口的 Tomcat 服务藏在 Nginx 后面之后外部用户访问java.example.com就能正常打开 JSP 页面了。这也就是为什么开头说“Nginx 虽然不支持 JSP却能通过反向代理让 JSP 服务对外正常可用”。这里最关键、也最容易出错的是proxy_pass末尾到底加不加 URI。举个例子location /api/ { proxy_pass http://backend:8080/; }请求/api/user/list会被转发到http://backend:8080/user/list。/api/被替换成/这就是加了末尾/的效果。如果不加location /api/ { proxy_pass http://backend:8080; }请求/api/user/list会原样转发到http://backend:8080/api/user/list。很多人调整路径时栽在这里改了半天以为是网络问题其实是 URI 替换规则没搞清楚。我的建议是每次改完proxy_pass先用脚手架后端或者curl观察实际收到的 URL确认路径符合预期再放量。4.2 负载均衡策略不只是简单的轮询后端不止一台机器时就用upstream定义一组后端upstream backend_servers { server 192.168.1.10:8080 weight2; server 192.168.1.11:8080 weight1; server 192.168.1.12:8080 backup; }默认是轮询每个请求按顺序轮流分发。常用策略有下面几种策略配置方式适用场景轮询不写任何参数后端配置接近、无状态服务权重weight2机器性能差异大的混合集群ip_haship_hash;需要会话粘连、基于 IP 的一致性分发least_connleast_conn;请求处理时间差异大、连接数不均衡的集群备用节点backup主节点全部故障时才启用配合健康检查参数upstream backend_servers { server 192.168.1.10:8080 max_fails2 fail_timeout10s; server 192.168.1.11:8080 max_fails2 fail_timeout10s; }Nginx 会在fail_timeout时间内累计失败max_fails次后暂时把该节点标记为不可用自动把流量切到其他节点。这是最基础、最实用的被动健康检查机制。如果后端程序偶尔崩溃重启这个机制能帮你自动完成流量摘除。4.3 后端连接复用upstream keepalive 的关键配置很多人在反向代理场景里会遇到后端压力大的问题排查下来往往不是后端代码弱而是 Nginx 和后端之间频繁建立 TCP 连接。默认情况下Nginx 每转发一个请求都要和后端新建一个 TCP 连接请求结束后又关闭。高并发下仅握手开销就能拖垮后端。解决办法是开启 upstream 长连接复用upstream backend_servers { server 192.168.1.10:8080; keepalive 32; } server { location / { proxy_pass http://backend_servers; proxy_http_version 1.1; proxy_set_header Connection ; } }keepalive 32表示 Nginx 每个 worker 进程最多保持 32 个空闲连接供复用。proxy_http_version 1.1是必须的因为 HTTP/1.0 默认不支持连接复用。proxy_set_header Connection ;是为了清掉默认请求头里的Connection: close让连接能保持。这部分有过一个很有代表性的热搜词“nginx 1.30.4 upstream keepalive 压测”实践中我也验证过开启 keepalive 后后端看到的 TCP 连接数量会明显下降接口平均耗时也能低几个毫秒甚至更多。压测后端的性能瓶颈经常就藏在这层不经意的连接复用配置里。4.4 正向代理一个被忽视的边界能力搜索里还有“nginx 正向代理”这个概念。正向代理和反向代理的区别一句话就能讲清楚反向代理代表后端服务器接收请求客户端只知道代理而不知道后端正向代理代表客户端去访问目标服务器目标服务器只知道代理而不知道真正的客户端是谁。在合规的运维场景里Nginx 正向代理可以用来做内网统一出口、访问审计、缓存加速。但我要给你一个务实的劝告生产环境里不建议用 Nginx 做面向公网的正向代理出口。一方面 Nginx 在这块的能力和适配性不如专业代理网关另一方面一旦配置不当把端口暴露在公网很容易变成人人可用的开放代理引发安全和合规问题。真要做统一出口建议选择运维体系内的专业代理组件并配合身份认证和审计能力。5. HTTPS 接入从证书到强制跳转5.1 证书准备与文件格式把站点从 HTTP 升级到 HTTPS首先要有证书和私钥。最省钱的方案是申请免费证书例如 Lets Encrypt、零信或者各大云厂商提供的免费证书。申请完成后你会拿到两类核心文件。一类是证书文件常见后缀.crt、.pem有些证书服务商给的是fullchain.pem里面包含站点证书和中间证书部署时直接用这个文件最省心。另一类是私钥文件后缀通常是.key这个文件千万不能泄露权限建议设置为 600。存放位置我习惯放在/etc/nginx/ssl/下面按域名区分目录/etc/nginx/ssl/example.com/fullchain.pem /etc/nginx/ssl/example.com/example.com.key5.2 配置 SSL 的完整 server 块在server块里挂证书核心配置如下server { listen 443 ssl; server_name example.com; ssl_certificate /etc/nginx/ssl/example.com/fullchain.pem; ssl_certificate_key /etc/nginx/ssl/example.com/example.com.key; ssl_protocols TLSv1.2 TLSv1.3; ssl_ciphers HIGH:!aNULL:!MD5; root /var/www/example; index index.html; }注意listen 443 ssl是标准写法如果是 Nginx 1.25 及以上版本HTTP/2 可以直接写http2 on;放在 server 块里而不用像旧版本那样写在listen 443 ssl http2中。这个细节很多人不清楚升级版本后配置报错的概率不小。配置完成后先用nginx -t验证语法再nginx -s reload。如果证书路径写错、证书文件缺失启动时会直接报错拒绝启动。5.3 HTTP 流量 301 跳转到 HTTPS做完 HTTPS 之后接下来要解决的是“用户访问 http://example.com 还是 HTTP”的问题。最常见的做法是单独留一个 80 端口 server统一做跳转server { listen 80; server_name example.com www.example.com; return 301 https://$host$request_uri; }这条配置会返回 301 状态码浏览器自动跳到对应的 HTTPS 地址。$host保留原域名$request_uri保留原路径和参数用户从哪个链接过来就跳到等价的 HTTPS 链接上体验最顺滑。5.4 HTTPS 配置踩过的坑第一个坑是证书链不完整。部分服务商只给你站点证书不提供中间证书浏览器就会提示“证书不受信任”。解决方法是把站点证书和中间证书合并成 fullchain 文件或者在配置里分别指定ssl_certificate和ssl_trusted_certificate。第二个坑是证书和域名不匹配。一张证书可能只覆盖example.com而不覆盖www.example.com如果拿它配置给后者访问时就会报安全警告。最好申请包含泛域名的证书或者把域名统一跳转到其中一个主域名再挂证书。第三个坑是多站点共用证书时写错路径。服务器上部署了多个站点每个 site 配置都引用同一个证书文件如果其中一个路径写错、证书过期会导致 reload 失败。每次更新证书后记得批量检查所有配置文件。还有一个容易忽略的安全习惯老版本 Nginx 或依赖库存在安全通告时一定要及时升级比如之前社区关注过的 Nginx 缓冲区错误类漏洞最终解法都是升级到修复版本。对于公网服务保持软件版本更新不是可选操作是底线。6. 高并发场景下的性能调优清单6.1 worker 数量与连接数的估算方法很多人调优 Nginx 第一个想改的就是worker_processes但这个参数并没有越大的说法。最佳实践是一般设为 CPU 逻辑核心数或者直接用autoworker_processes auto;然后看worker_connectionsevents { worker_connections 10240; }一个简单的估算公式是Nginx 理论最大并发连接数 ≈worker_processes × worker_connections。如果服务器是 8 核每个 worker 连接数 10240理论最大并发约 81920。但这只是极限值实际还要考虑每个连接占用的文件描述符、内存、后端处理能力。先把系统文件描述符限制放开否则连接数一高就报 too many open filesworker_rlimit_nofile 65535;同时在系统层面调大ulimit -n。我用过的机器通常并发估算都是这么来的单机静态资源承载 3-5 万并发连接反向代理场景可能压到几千到上万因为上游处理速度和连接复用才是真正的瓶颈。6.2 gzip 压缩与静态资源缓存同样是静态资源开没开压缩传输量能差出好几倍。一个常用配置gzip on; gzip_comp_level 5; gzip_min_length 1k; gzip_types text/plain text/css application/javascript application/json image/svgxml; gzip_vary on;gzip_comp_level我一般用 5再高的压缩率对 CPU 消耗明显收益却不大。图片本身大多已经压缩过不需要再做 gzip所以gzip_types里只列文本类型资源。缓存方面利用客户端浏览器缓存减少重复请求location ~* \.(js|css|png|jpg|jpeg|gif|svg|woff2)$ { expires 30d; add_header Cache-Control public, immutable; }让带版本号的静态资源在浏览器里缓存 30 天能极大减少回源压力。特别注意不带 hash 的文件不要加immutable否则你更新文件后用户浏览器还在用旧缓存。6.3 连接超时与 keepalive 参数的取舍连接超时对性能和资源占用影响很大几个常见参数keepalive_timeout 65; client_body_timeout 10; client_header_timeout 10; send_timeout 10;keepalive_timeout控制客户端与 Nginx 的空闲连接保持时间。65 秒是默认值但高并发场景下我通常调到 20-30 秒避免太多空闲连接占满文件描述符。client_header_timeout和client_body_timeout控制读取请求头和请求体的超时时间太大会被慢速连接拖住资源太小又可能误杀正常用户。前面提到的 upstream keepalive 也同样影响连接效率。客户端到 Nginx 的长连接和后端到 Nginx 的长连接是两个方向各自独立调优。四层能力除外这些都是七层 HTTP 场景里最值得花时间抠的点。7. 常见问题排查实录7.1 403 Forbidden 到底是谁在拒绝访问出现 403第一反应是“谁拒绝了我”。Nginx 返回 403 主要有四种原因index index.html配置里指定的首页文件不存在目录下没有可访问的默认页面。目录权限问题。比如根目录没有执行权限。Linux 下目录至少要有x权限才能被访问文件要有r权限。很多人把权限配成了644目录结果就是 403。autoindex off状态下目录没有默认首页文件Nginx 又不允许列目录就会拒绝访问。显式访问控制比如deny all;。排查步骤一般是先看错误日志error.log里通常会明确写directory index ... is forbidden或者Permission denied顺着日志定位会快很多。7.2 [emerg] 开头的启动失败怎么定位启动 Nginx 时如果看到nginx: [emerg]一类的报错说明配置里有严重问题进程无法正常启动。常见原因有两个。一是端口被占用。比如 80 端口已经被其他 Web 服务占用启动时就会报address already in use用ss -lntp看一下端口占用即可。二是配置里写了不存在的路径。Windows 环境下常见的报错格式是nginx: [emerg] createfile() D:/phpstudy_pro/www/admin2.com/nginx.htaccess failed (2: The system cannot find the file specified)这种基本都是配置文件里引用的目录在机器上不存在或者盘符写错、路径拼错。按报错中的路径去检查是否存在创建目录或修正路径就好。排查流程就四步先nginx -t给出具体错误行号再打开对应配置文件检查语法和路径确认资源是否存在最后重新加载。[emerg]类错误不要靠反复重启解决每次重启前都过一遍nginx -t才是正规操作。7.3 改了配置不生效先查这三件事配置改了服务也 reload 了可效果没出来。这种情况下我建议依次检查三件事。第一真的 reload 了吗很多人改了/etc/nginx/nginx.conf但站点配置在/etc/nginx/conf.d/*.conf忘记确认include是否覆盖了这个路径。或者执行了nginx -s reload后没有报错但进程实际加载的还是旧配置可以看 master 进程启动时间确认。第二浏览器缓存干扰。改了静态资源、加了跳转但浏览器还在用旧缓存强制刷新或者用无痕窗口试一次再说。第三server_name 冲突。请求进来后 Nginx 会按一定优先级匹配server_name如果两个 server 块里的域名有重叠可能命中你没想到的那个。用curl -H Host: example.com直接模拟请求观察实际返回的响应头很快就能判断。7.4 日志是最后的排查武器排查 Nginx 问题我几乎不看界面直接开日志。error.log记录错误信息有debug、info、notice、warn、error等级别。遇到奇怪问题把error_log级别调到debug请求进来后日志会详细记录每一层匹配过程定位完再调回notice避免日志爆炸。access.log记录所有请求状态码是核心线索。看到大量 499说明客户端提前断开多数是超时配置看到 502说明 Nginx 连不上后端看到 504说明后端处理超时。实时排查可以用tail -f /var/log/nginx/access.log /var/log/nginx/error.log另一个窗口发请求日志会同步输出问题定位效率极高。7.5 面试和实战里高频出现的几个问题既然热搜里反复出现“nginx 面试题”我顺便把高频问题做个精简回答。第一个问题Nginx 支持 JSP 吗答案是不支持但不影响使用。它可以把 JSP 请求反向代理给 Tomcat由 Tomcat 执行 JSP 后返回结果这就是常见的前后端分离架构。第二个问题负载均衡有哪些策略默认轮询、权重、ip_hash、least_conn、backup 备用节点部分商业版本还支持一致性哈希和主动健康检查。第三个问题反向代理 proxy_pass 加不加末尾斜杠有什么区别加斜杠会替换 location 匹配部分不加则原样转发接口路径错乱多半出在这个细节上。第四个问题Nginx 为什么会返回 502 Bad Gateway本质是 Nginx 无法从后端收到有效响应原因可能是后端服务没启动、端口不通、超时或者后端进程崩溃。先 telnet 测试后端端口再看 error.log思路比背命令重要。最后分享一点个人习惯无论多着急改配置永远先nginx -t再 reload这条路我走了很多年救过无数线上事故。改动前把当前配置文件备份一份改完验证后再删几个文件而已但关键时刻能让你十分钟内回滚。遇到诡异问题先开 debug 日志再把日志调回去别在错误日志的海洋里瞎猜。Nginx 的文档和社区非常成熟但真正把它用顺手靠的还是亲手踩一遍坑再把这些经验沉淀成属于自己的检查单。