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，需要先启用 EPEL（Extra 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（压缩支持）和 OpenSSL（HTTPS 支持）。如果是在 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] Description=nginx - high performance web server After=network-online.target [Service] Type=forking 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 PrivateTmp=true [Install] WantedBy=multi-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 Manager（NPM）这类图形化反向代理工具，尤其在 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_server：

listen 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 说话，完全感知不到后端的存在。

配置一个简单的代理到 Tomcat：

server { 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 weight=2; server 192.168.1.11:8080 weight=1; server 192.168.1.12:8080 backup; }

默认是轮询，每个请求按顺序轮流分发。常用策略有下面几种：

配合健康检查参数：

upstream backend_servers { server 192.168.1.10:8080 max_fails=2 fail_timeout=10s; server 192.168.1.11:8080 max_fails=2 fail_timeout=10s; }

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，首先要有证书和私钥。最省钱的方案是申请免费证书，例如 Let's Encrypt、零信，或者各大云厂商提供的免费证书。

申请完成后，你会拿到两类核心文件。一类是证书文件，常见后缀.crt、.pem，有些证书服务商给的是fullchain.pem，里面包含站点证书和中间证书，部署时直接用这个文件最省心。另一类是私钥文件，后缀通常是.key，这个文件千万不能泄露，权限建议设置为 600。

存放位置我习惯放在/etc/nginx/ssl/下面，按域名区分目录：

/etc/nginx/ssl/example.com/fullchain.pem /etc/nginx/ssl/example.com/example.com.key

5.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 逻辑核心数，或者直接用auto：

worker_processes auto;

然后看worker_connections：

events { worker_connections 10240; }

一个简单的估算公式是：Nginx 理论最大并发连接数 ≈worker_processes × worker_connections。如果服务器是 8 核，每个 worker 连接数 10240，理论最大并发约 81920。但这只是极限值，实际还要考虑每个连接占用的文件描述符、内存、后端处理能力。

先把系统文件描述符限制放开，否则连接数一高就报 too many open files：

worker_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/svg+xml; 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 的文档和社区非常成熟，但真正把它用顺手，靠的还是亲手踩一遍坑，再把这些经验沉淀成属于自己的检查单。