nginx配置的核心答案一句话说透：搞懂nginx.conf的层级结构、location匹配优先级和proxy_pass转发逻辑，你就能应对绝大多数业务场景。
打开一台新服务器的nginx.conf，新手往往对着几百行配置发懵，其实nginx配置由若干配置块组成，每个块负责一类职责，层级关系理顺后,配置就是搭积木。
nginx配置文件在哪里？目录结构决定操作起点
不少运维新手搜”nginx配置文件在哪里”，得到的答案五花八门，原因在于安装方式不同，路径差异明显,常见分布如下：
- Debian/Ubuntu通过apt安装：主配置文件在/etc/nginx/nginx.conf
- CentOS/RHEL通过yum安装：同样在/etc/nginx/nginx.conf
- 源码编译安装：默认在/usr/local/nginx/conf/nginx.conf
- Docker镜像部署：多数镜像路径为/etc/nginx/nginx.conf
主配置文件只是入口，真正管站点的是它通过include指令引入的子配置，Debian系默认拉入/etc/nginx/sites-enabled/下的文件，CentOS系通常拉入/etc/nginx/conf.d/.conf，这种拆分让每个站点独立成文件，排查范围小,改动互不影响。
日志位置同样固定，访问日志在/var/log/nginx/access.log，错误日志在/var/log/nginx/error.log，排错第一步永远先看error.log,这条经验能省下大量抓瞎时间。
nginx配置详解：全局块、events块与http块的职责边界
nginx.conf三级结构是骨架：全局块定进程，events块定连接模型，http块管请求处理,三者职责不交叉。
全局块：管进程运行
全局块放在配置文件最顶部,直接作用于nginx进程：
user nginx;：worker进程运行身份，权限过大有安全风险，生产环境禁用root运行worker_processes auto;：设为auto让nginx按CPU核心数自动派生worker进程error_log /var/log/nginx/error.log warn;：错误日志级别，线上一般用warn或errorpid /var/run/nginx.pid;：主进程PID存放位置
events块：管连接模型
events块紧跟在全局块后,核心参数就两个：
worker_connections 1024;：单个worker进程能同时保持的最大连接数，1024是保守默认值use epoll;：Linux高并发场景下显式指定epoll事件模型，比默认的select性能好
http块与server块的嵌套关系
http块是所有web请求的入口,内部先做通用设置再嵌套server：
include mime.types;：让nginx根据文件后缀识别Content-Type，漏掉它静态资源加载会乱sendfile on;：零拷贝发送文件，减少内核态和用户态之间的拷贝keepalive_timeout 65;：客户端长连接超时时间
server块相当于一台虚拟主机，由listen指定端口、server_name绑定域名，访问请求到达nginx后，先说http块公共配置，再按端口和域名落入对应server块,最后在server块内部匹配location。
nginx location匹配规则优先级到底怎么排
location是nginx配置里最容易被写错的环节。”nginx location匹配规则优先级”在搜索引擎里常年有热度，说明踩坑的人确实多,优先级排序如下：
| 匹配方式 | 语法示例 | 优先级 |
|---|---|---|
| 精确匹配 | location = /login |
最高 |
| 前缀匹配 | location ^~ /static/ |
高 |
| 正则匹配 | location ~ .(gif|jpg)$ |
中 |
| 普通前缀匹配 | location /api/ |
低 |
| 兜底匹配 | location / |
最低 |
匹配流程按顺序走：先看有没有精确匹配，命中直接结束；再看有无^~前缀命中，命中后不再查正则；随后才轮到正则匹配，区分大小写、不区分，按书写顺序从上往下找；正则全部落空后，走最长普通前缀匹配，最后才是location /兜底。
一个实际场景的location组合
前后端分离项目常见的一组location配置：
location = /favicon.ico {
log_not_found off;
access_log off;
}
location ^~ /static/ {
alias /data/www/static/;
expires 30d;
}
location ~ .(js|css|png)$ {
expires 7d;
add_header Cache-Control "public";
}
location /api/ {
proxy_pass http://backend_server;
}
location / {
root /data/www/dist;
index index.html;
}
这个组合的妙处在于：图标精确匹配直接短路，静态资源走前缀命中不碰正则，动态请求按正则规则单独设缓存，接口转发到后端,其余全部落到前端页面。
正则匹配的坑
正则里的点号匹配任意字符，写location ~ .php$时反斜杠不能省，否则把xphp这类路径也放进来了，花括号在正则里是量词语法，匹配字面量时建议给整个正则加引号，除非必要，优先用前缀匹配替代正则,可读性和性能都更好。
nginx反向代理与负载均衡配置方法
反向代理是nginx使用频率最高的能力，核心指令就一个：proxy_pass。
proxy_pass基础配置
location /api/ {
proxy_pass http://192.168.1.10: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;
}
proxy_pass的写法有个细节坑：带不带尾部斜杠，转发路径完全不同。
proxy_pass http://后端/;：会去掉location匹配的前缀，访问/api/user实际转给后端/userproxy_pass http://后端;：保留完整路径，访问/api/user转给后端/api/user
地址带表示重写路径，不带表示透传，这两行差一个字符,排查转发404时先看这里。
upstream负载均衡策略怎么选
多个后端节点用upstream块统一声明,再让proxy_pass指向upstream名字：
upstream backend {
server 192.168.1.10:8080 weight=3;
server 192.168.1.11:8080;
server 192.168.1.12:8080 backup;
}
三种常用策略对比：
| 策略 | 配置关键词 | 适用场景 |
|---|---|---|
| 轮询 | 默认策略 | 后端机器配置均衡 |
| 加权轮询 | weight |
异构机器按性能分配流量 |
| 会话保持 | ip_hash |
用户session存在单台机器内存中 |
backup标记的节点平时不接流量，主节点全部宕机才启动,用来做高可用兜底很实用。
前后端分离项目完整示例
upstream api_server {
ip_hash;
server 192.168.1.10:8080;
server 192.168.1.11:8080;
}
server {
listen 80;
server_name demo.example.com;
location /api/ {
proxy_pass http://api_server;
}
location / {
root /data/www/dist;
index index.html;
try_files $uri $uri/ /index.html;
}
}
前端路由用history模式时，刷新页面会请求不存在的真实路径，try_files $uri $uri/ /index.html这行把请求回退到入口页,是SPA部署的标配写法。
nginx性能优化配置清单
性能优化不像网上说的那样玄乎，多数场景把下面几项调到位,效果立竿见影。
进程数与连接数
worker_processes auto让nginx按CPU核数派生进程，业内专家指出，进程数超过CPU核心数反而因上下文切换损耗性能，auto是最稳妥的选择。worker_connections配合调大，比如10240，单机并发承载能力就上去了，两者相乘得到理论最大并发连接数,实际值还要考虑内存和带宽。
gzip压缩
gzip on; gzip_comp_level 5; gzip_min_length 1k; gzip_types text/plain text/css application/json application/javascript image/svg+xml; gzip_vary on;
静态资源开启gzip后传输体积能缩小一大截，压缩级别5是性价比平衡点,调太高CPU开销大收益却有限。
静态资源缓存
location ^~ /static/ {
alias /data/www/static/;
expires 30d;
add_header Cache-Control "public";
}
expires 30d让浏览器把静态资源缓存30天，二次访问直接走本地，完全不消耗服务器带宽,版本化文件名配合永久缓存是前端性能优化的常用组合。
nginx配置https证书的实操步骤
申请证书后，配置步骤分两段：先改443的server块,再做80跳转。
server块添加SSL参数
server {
listen 443 ssl;
server_name demo.example.com;
ssl_certificate /etc/nginx/ssl/demo.example.com.pem;
ssl_certificate_key /etc/nginx/ssl/demo.example.com.key;
ssl_protocols TLSv1.2 TLSv1.3;
ssl_session_timeout 5m;
ssl_session_cache shared:SSL:50m;
# 站点原有location配置原样保留
}
证书文件路径可以自定义，关键是nginx进程对证书文件有读取权限，否则启动直接报错，SSL配置完成后记得把站点内所有http资源链接改成https,否则浏览器地址栏的锁标识带警告。
http强制跳转https
server {
listen 80;
server_name demo.example.com;
return 301 https://$host$request_uri;
}
80端口只做301跳转，让所有http流量自动切到443。$host和$request_uri是nginx内置变量，保留原始域名和路径,域名下多路径资源迁移不用逐条改。
nginx配置完先做这三项检查
配置改完别急着重启,按顺序做三件事：
- 执行
nginx -t验证语法，输出syntax is ok说明配置没写错 - 执行
nginx -s reload平滑重载，reload不中断现有连接，新配置立即生效 - 确认防火墙放行端口，改了listen端口后先检查firewalld或iptables规则
常见的403是目录权限或索引文件缺失，404基本是root路径配错，502则是后端服务没起来或网络不通，这三类问题占据nginx排错的相当一部分场景，定位时先对号入座看error.log,再根据关键字搜具体解决方案。
nginx配置能力靠的是多写多踩坑，把上面几块核心逻辑吃透，日常开发和运维场景基本够用，剩下的边角知识,遇到具体需求时查官方文档比背配置更高效。
nginx配置常见问题解答
Q1：nginx配置反向代理后出现502 Bad Gateway怎么排查？
502表示nginx连不上后端，先确认后端服务进程是否存活，用curl http://127.0.0.1:端口本地测试通不通，再查看error.log中是否有connect() failed (111: Connection refused)，有则说明后端端口监听异常或防火墙拦截，若后端正常但请求响应慢，检查proxy_read_timeout和proxy_connect_timeout是否设置过短，按这个顺序排查,大多数502都能定位。
Q2：改完nginx配置怎样让改动生效？
先执行nginx -t验证语法，确认无误后执行nginx -s reload，reload是平滑重载，会重新读取配置并启动新的worker进程，同时优雅关闭旧worker进程，已建立的连接不受影响,不需要执行重启或重新编译。
Q3：nginx配置的location正则什么时候需要转义？
在和正则匹配中，点号匹配任意字符，想匹配字面量点号必须写成.；斜杠不需要转义；花括号在正则里表示量词，遇到建议转义或整体加引号，行业共识认为，正则复杂度越高维护成本越大,能用前缀匹配解决的场景不要引入正则。