nginx配置的核心是理解其块状结构与指令作用域，只要掌握了全局块、events块、http块、server块和location块的层级关系，就能解决绝大多数配置难题。
nginx反向代理配置详解
nginx最常用场景是反向代理,它接收客户端请求，再转发给上游服务器，这个过程隐藏了后端真实地址，配置反向代理前，先确认nginx已安装且版本为常见稳定版。
反向代理的最小配置
在/etc/nginx/conf.d/下新建一个.conf文件，例如proxy.conf，写入：
server {
listen 80;
server_name 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;
}
}保存后执行nginx -t检查语法，再运行nginx -s reload重载配置，此时访问example.com，请求会被转发到本地8080端口的服务，这里proxy_set_header是重点，没有它，后端无法获取真实客户端IP。
带路径前缀的代理场景
当后端接口带统一前缀,比如/api/，可以这样写：
location /api/ {
proxy_pass http://192.168.1.10:3000;
}注意proxy_pass末尾是否带斜杠，会影响转发路径，如果proxy_pass http://192.168.1.10:3000;（不带斜杠），请求/api/user会完整转发；如果带斜杠写成http://192.168.1.10:3000/，/api/前缀会被剥离，转发后变成/user，这个细节经常导致接口404，排查时先看这里。
做负载均衡时如何配置上游节点
反向代理常与上游服务器组配合,在http块内、server块外定义：
upstream backend_servers {
server 192.168.1.11 weight=3;
server 192.168.1.12 weight=1;
keepalive 32;
}
server {
listen 80;
location / {
proxy_pass http://backend_servers;
proxy_http_version 1.1;
proxy_set_header Connection "";
}
}weight参数表示权重，keepalive开启连接复用，多数情况下，这种配置已经能撑住相当一部分中小型站点的流量压力。
nginx location匹配顺序与规则
location是nginx配置里最容易被误解的部分,匹配顺序错了，规则就不生效，表现就是”我明明写了这个配置，为什么没走这个逻辑”。
匹配规则的优先级
nginx location匹配遵循固定优先级，从上到下依次生效：
- 精确匹配，优先级最高
^~普通字符串匹配，一旦命中就不再做正则检查- 正则匹配，区分大小写
- 正则匹配，不区分大小写
- 通用前缀匹配，兜底使用
实际配置中,^~和用得最多，比如静态资源目录，建议使用^~
，避免正则干扰：
location ^~ /static/ {
alias /var/www/static/;
expires 30d;
}常规前缀匹配与正则匹配的差异
常规前缀匹配记录最长匹配位置,但不会立即结束，还要看后续是否有正则命中，而正则匹配一旦成功就直接使用，不再回头，业内专家指出，理解这个差异是区分初级和中级运维的分水岭。
举个例子,两个location配置：
location /images/ {
root /data;
}
location ~ \.(png|jpg)$ {
root /data2;
}访问/images/logo.png时，第一个location前缀匹配到/images/，但第二个正则也匹配了.png，最终会走/data2目录，如果希望前缀匹配优先，把第一个改成location ^~ /images/。
实际场景下的location写法建议
处理前后端分离项目时,用location区分静态资源与接口转发：
server {
listen 80;
server_name shop.example.com;
location ^~ /assets/ {
alias /opt/frontend/dist/assets/;
gzip_static on;
expires 7d;
}
location ~ \.(js|css|png|jpg|jpeg|gif|svg|woff2)$ {
root /opt/frontend/dist;
expires 30d;
access_log off;
}
location / {
proxy_pass http://backend_servers;
}
}这种配置让静态请求直接读磁盘文件,动态请求走反向代理，是电商站点的常见套路，配置完成后用nginx -t验证，再重载。
nginx如何配置ssl证书并实现http跳转https
站点启用https是标配操作,nginx配置ssl证书不算复杂，但细节容易出错。
证书文件放置路径
先确认证书文件放在哪个目录,行业共识认为，统一放在/etc/nginx/cert/目录下，方便管理，建议证书文件命名与域名对应，例如example.com.crt和example.com.key。
完整的ssl server块示例
在/etc/nginx/conf.d/ssl.conf中写入：
server {
listen 443 ssl;
http2 on;
server_name example.com;
ssl_certificate /etc/nginx/cert/example.com.crt;
ssl_certificate_key /etc/nginx/cert/example.com.key;
ssl_protocols TLSv1.2 TLSv1.3;
ssl_ciphers HIGH:!aNULL:!MD5;
ssl_session_cache shared:SSL:20m;
ssl_session_timeout 60m;
location / {
root /var/www/html;
index index.html;
}
}检查证书路径是否写错,执行nginx -t时，最常见的报错就是找不到证书文件，确保example.com.crt包含完整的证书链，可以用cat命令查看文件内容，以-----BEGIN CERTIFICATE-----开头。
强制跳转https的三种方式
使用return 301方式是首选，简单直接：
server {
listen 80;
server_name example.com;
return 301 https://$host$request_uri;
}如果使用rewrite方式，也能达到同样效果：
server { listen 80; server_name example.com; rewrite ^(.)$ https://$host$1 permanent; }
还有一种情况,站点部分页面需要强制https，部分页面允许http，可以用location内判断，但对于普通站点，return 301已经足够，配置完成后，建议用浏览器或无痕模式访问一次，确认地址栏出现锁标志。
nginx配置为何会影响性能与访问速度
配置不只是写功能,也直接决定服务器的吞吐量，nginx本身性能优异，但有些配置项必须按业务调整。
进程数与连接数调整
worker_processes建议设置为CPU核心数，可以用lscpu或nproc查看核心数，然后写入/etc/nginx/nginx.conf主配置文件顶部：
worker_processes auto;worker_connections表示单个工作进程允许的最大并发连接数，一般设置在1024到65535之间，如果服务器内存较大且并发访问量高，可以调大，events块配置示例：
events {
worker_connections 4096;
use epoll;
}use epoll是Linux下的高并发事件驱动模型，多数系统的nginx默认启用，但显式写出更直观。
启用gzip压缩减少带宽消耗
gzip能显著减小文本类响应体积,在http块内添加：
gzip on;
gzip_comp_level 6;
gzip_min_length 1k;
gzip_types text/plain text/css application/json application/javascript text/xml application/xml application/xml+rss image/svg+xml;
gzip_vary on;压缩等级不要超过6,等级过高会消耗CPU，体积减少有限，配置完成后，用浏览器开发者工具查看响应头，确认出现content-encoding: gzip。
静态文件缓存与日志优化
静态资源配置过期时间：
location ^~ /static/ {
root /data/www;
expires 7d;
access_log off;
}对于图片和字体资源,可以设置expires 30d，日志方面，高流量站点建议关闭静态资源的访问日志，避免大量无效写入拖慢I/O，访问日志本身也可以用logrotate做每日切割，在/etc/logrotate.d/nginx中配置：
/var/log/nginx/.log {
daily
missingok
rotate 14
compress
delaycompress
notifempty
create 0640 nginx adm
sharedscripts
postrotate
[ -f /var/run/nginx.pid ] && kill -USR1 `cat /var/run/nginx.pid`
endscript
}nginx配置报错与排查实操
配置再熟练,也难免遇到报错，nginx排障的核心方法是看日志和验证语法。
最常见的两种配置错误
第一种,语法错误，执行nginx -t后，报错信息会直接指出文件和行号，比如[emerg] unknown directive "proxy_pass"，说明指令拼写错误或位置不对，按照报错行号去检查即可。
第二种,权限不足，访问静态文件时返回403，多数是nginx运行用户（通常是
nginx或www-data）没有读取文件目录的权限，执行ls -l /data/www检查目录权限，再用chown或chmod修正。
使用error.log定位深层问题
即时语法正确,运行时也可能报502 Bad Gateway，这表示nginx无法连接后端服务，查看/var/log/nginx/error.log：
tail -f /var/log/nginx/error.log如果看到connect() failed (111: Connection refused)，说明后端端口没监听，如果看到upstream timed out，说明后端处理太慢，需要调大proxy_read_timeout。
常见调优参数如下：
proxy_connect_timeout 10s;
proxy_read_timeout 60s;
proxy_send_timeout 60s;参数含义明确,前端等待后端响应的超时时间，多数情况下，调大这两个值能解决超时类报错，请求体过大会返回413 Request Entity Too Large，在server块或location块中调整：
client_max_body_size 50m;默认值只有1m，上传大文件时必须改，返回301循环跳转一般是证书配置或rewrite规则写反了，检查server块中的return和rewrite语句。
Q&A：nginx配置中常见疑问解答
nginx配置中location和server的核心区别是什么？
server块定义一组监听端口和域名对应的独立站点，比如监听80端口的example.com是独立server。location块定义某个URL路径的处理规则，它位于server内部，server决定”谁来接”，location决定”接到后怎么处理”，一个server可以有多个location，但一个请求只能匹配一个location。
nginx如何开启gzip压缩并验证效果？
在nginx.conf的http块中添加gzip on; gzip_types text/css application/javascript;，然后执行nginx -t和nginx -s reload，验证方法是在浏览器开发者工具的Network面板中，打开任意一个JS或CSS资源，查看响应头是否包含content-encoding: gzip，包含则说明已生效。
nginx反向代理配置完成后，如何确认转发路径是否正确？
先用nginx -t验证语法，再查看/etc/nginx/conf.d/下配置文件的proxy_pass地址与location前缀关系，测试时，在目标路径下放置一个测试文件，修改后端的返回内容，通过浏览器访问前端地址，观察响应是否来自后端，确认无问题后，可在error.log中搜索proxy相关记录。
nginx配置的深度,取决于对请求生命周期与配置层级的理解程度，从最小的反向代理实例开始，逐步叠加location规则、ssl证书和性能参数，遇到报错时回看配置文件与日志，就能逐渐形成自己的排查路径，配置这东西，上手敲一次，比读十遍文档都管用。