Nginx这个名字，后端和运维的朋友每天都要打交道。部署前端项目要用它，给后端接口做反向代理要用它，负载均衡、HTTPS证书、日志切割，几乎每个环节都有它的影子。我当年刚接触时也被一堆配置项搞得头大，location、proxy_pass、upstream这些东西看着就懵。后面踩了不少坑，才把整条链路理顺。这篇博文就按“速成”的思路来写，不铺开讲理论，直接从“把服务跑起来”到“能接真实项目”，把日常工作里最常用到的Nginx技能讲透。无论你是刚转行做运维的新人，还是被临时拉去配服务器的后端开发，看完这篇基本能上手处理绝大多数场景。
很多人一学Nginx就去啃官方文档，结果几千页的Manual直接把人劝退。我的经验是，Nginx入门不需要全套知识，你只需要搞懂三件事：怎么装、怎么配、怎么查日志。这三件事搞定了，你就能解决90%的日常问题。剩下的10%，遇到再搜也不迟。
1. 先搞清楚Nginx到底在解决什么问题
1.1 Nginx的角色定位
网上把Nginx吹得天花乱坠，什么高并发、高性能、异步非阻塞，这些词汇对于一个刚入门的人来说其实没有任何帮助。我换个方式给你讲。
你把Nginx想象成一个物业前台。访客来了，先到前台，前台根据访客要拜访哪户人家，告诉他去几栋几单元；如果他要找的人不在，前台还能帮忙把消息记录下来，等他回来了再转交。这个“告诉访客去哪找对应服务”的动作，就是反向代理；如果小区有多栋楼都住着同一个公司的人，前台帮忙分流让访客分别去不同楼找人，这就是负载均衡；如果访客只是想在楼下大堂看看宣传册，不用上楼，前台直接递给他一份，这就是静态资源服务。
这样一比喻就清楚了。Nginx是一个高性能的HTTP服务器和反向代理服务器，它站在用户请求和后端服务之间，统一接收请求，再按照你配置的规则把请求转发给对应的处理程序。我们日常工作中90%的Nginx配置，都是围绕着“转发规则”来做的。
1.2 速成的正确姿势：按场景学配置
很多教程喜欢把Nginx的配置文件从头到尾一行行讲，这对新手来说其实是灾难。因为配置文件里的几十个指令，你实际工作中可能一年都用不到一半。
我的建议是，按场景去学。你遇到了“前端页面打不开”的问题，就去查server块怎么配；你遇到了“接口请求503”，就去查proxy_pass怎么配；你遇到了“服务器扛不住高并发”，再去研究upstream和负载均衡策略。场景驱动学习，效率远高于从第一行读到最后一行的“教科书式学习”。
这篇文章后面所有的内容，我都按照这个思路来组织。每个章节解决一类真实场景，你把这个场景对应的配置吃透，下次再遇到类似问题就能直接拍板。
2. 安装与启动：先把Nginx跑起来
2.1 Linux环境下的安装与启动命令
绝大多数生产环境都是Linux，所以先从Linux说起。以CentOS和Ubuntu两个最常见的发行版为例。
CentOS/RHEL系列使用yum安装，但默认源里的Nginx版本通常比较老，建议先添加Nginx官方源再安装：
# 添加官方源 sudo rpm -Uvh http://nginx.org/packages/centos/7/noarch/RPMS/nginx-release-centos-7-0.el7.ngx.noarch.rpm # 安装 sudo yum install -y nginx # 启动 sudo systemctl start nginx # 设置开机自启 sudo systemctl enable nginx # 查看运行状态 sudo systemctl status nginxUbuntu/Debian系列用apt安装：
sudo apt update sudo apt install -y nginx # 启动 sudo systemctl start nginx # 开机自启 sudo systemctl enable nginx还有一个容易被新手忽略的细节：改完配置后要测试配置文件语法是否正确。用nginx -t，如果输出syntax is ok和test is successful，再执行重载。千万不要改完配置直接重启服务，万一语法写错了，服务可能会直接挂掉，线上业务就断了。
# 测试配置语法 nginx -t # 配置无误后重新加载 nginx -s reloadreload和restart的区别得说清楚。reload是平滑重载，Nginx会先检查新配置语法，然后把旧的worker进程慢慢停掉，用新配置启动新的worker进程，正在处理的请求不会中断。而restart是强制重启，所有连接都会断开。生产环境里尽量用reload，不要用restart。
如果你是Ubuntu 14.04这类老系统，没有systemd，那就会用到init.d脚本。/etc/init.d/nginx start、/etc/init.d/nginx stop、/etc/init.d/nginx reload，这套老命令现在虽然用得少了，但在一些存量服务器上还是能碰到。
2.2 Windows环境部署Nginx
Windows服务器上部署Nginx也很常见，尤其是Windows Server 2016、2019这些系统。Nginx官方提供了Windows版本，直接去官网下载zip压缩包，解压就能用，不需要安装。
下载的时候注意看版本号，Windows版本没有官方预编译的稳定版标识，建议选择mainline版本以外的stable稳定版。解压出来的目录结构是这样的：
C:\nginx-1.24.0\ ├── conf\ # 配置文件目录 ├── contrib\ ├── docs\ ├── html\ # 默认站点目录 ├── logs\ # 日志目录 ├── temp\ └── nginx.exe # 主程序Windows下启动Nginx直接在命令行里执行：
cd C:\nginx-1.24.0 start nginx.exe注意这里要用start，不用start的话，命令行窗口会被Nginx进程占住，关掉窗口Nginx就停了。用start启动后，Nginx会在后台运行。
停止和重载的命令：
nginx.exe -s stop # 强制停止 nginx.exe -s reload # 重新加载配置 nginx.exe -t # 测试配置语法Windows下改端口是高频操作。很多人装完Nginx发现启动不了，进去看日志才发现是80端口被占用。IIS、SQL Server Reporting Services这些服务都会抢80端口。改端口很简单，打开conf目录下的nginx.conf，找到listen 80;，改成你想要的端口，比如listen 8080;，保存后执行nginx -s reload即可。
我个人的经验是，Windows机器上最好把Nginx注册成Windows服务来管理，不然每次开机都要手动启动。用NSSM（Non-Sucking Service Manager）这个小工具，一行命令就能把nginx.exe注册为服务：
nssm install nginx "C:\nginx-1.24.0\nginx.exe" nssm set nginx AppParameters "-p C:\nginx-1.24.0" nssm start nginx这样Nginx就能跟随Windows开机自启，也能通过服务管理器统一管理。
2.3 安装后的第一件事：验证进程与页面
无论哪种系统，装完Nginx后都要做两件事：确认进程活着、确认页面能打开。
# 确认进程存在 ps -ef | grep nginx # 确认端口监听 netstat -tlnp | grep 80 # 用curl抓取默认页面 curl http://localhost如果看到了Welcome to nginx!的页面，恭喜你，Nginx已经跑起来了。接下来所有的工作，都是基于这个跑起来的服务做配置。
3. 配置文件逐段拆解：nginx.conf到底写了什么
3.1 从整体结构入手：全局块、events块、http块
Nginx的默认配置文件路径在Linux下通常是/etc/nginx/nginx.conf，Windows下在conf\nginx.conf。打开这个文件，整体结构大致是这样的：
# 全局块：全局生效，通常配置运行用户、worker进程数等 user nginx; worker_processes auto; # events块：配置连接处理机制 events { worker_connections 1024; } # 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 { listen 80; server_name localhost; location / { root /usr/share/nginx/html; index index.html index.htm; } } }我见过不少新手一上来就盯着location看，其实整个配置文件的骨架就三段：全局块管的是Nginx进程本身跑在什么环境下；events块管的是连接怎么处理；http块管的是网页服务怎么做。你理解了这三层，配置文件在你眼里就不是天书了。
这里有个高频面试题也是高频实际疑问：worker_processes和worker_connections到底怎么设置？worker_processes建议设为CPU核心数，可以用auto自动检测；worker_connections表示每个worker进程能同时保持的最大连接数。两者相乘，大致就是Nginx能支撑的最大并发连接数。机器是4核CPU，worker_processes设置为4，worker_connections设置为1024，最大并发就是4096，这个指标对你评估服务器容量有直接参考意义。
3.2 server块和location块是配置的核心
server块代表一个虚拟主机。一个Nginx可以配置多个server，通过listen的端口号和server_name的域名来区分请求应该交给哪个server处理。
location块是server内部的路由规则。它匹配的是URL中域名后面的路径部分。举个实际例子：
server { listen 80; server_name example.com; # 匹配所有请求 location / { proxy_pass http://backend_server; } # 以/api开头的请求 location /api/ { proxy_pass http://api_server; } # 以.png结尾的请求 location ~ \.png$ { root /data/images; } }关于location的匹配规则，网上讨论很多，我直接给你一个优先级结论：
=精确匹配，优先级最高，匹配到了直接使用，不再往下找^~前缀匹配，如果匹配到了，且是最长前缀，就不再看正则~和~*正则匹配，按书写顺序匹配，找到即停/通用前缀匹配，兜底规则，所有请求都匹配
这个优先级背下来就行，实际配置里最常用的是location /、location /api/和location = /，后两个是健康检查常配的路径。
3.3 修改配置后如何让改动生效
这里必须要强调完整流程了。我见过太多生产事故，都是因为改完配置直接restart导致的。
正确的操作流程是：
# 第一步：修改配置文件（建议先备份原始文件） cp nginx.conf nginx.conf.bak # 第二步：检查语法 nginx -t # 第三步：平滑重载 nginx -s reloadnginx -t这个命令太重要了。它会帮你检查配置文件语法，如果有错误，会明确告诉你第几行有问题。我在真实项目里养成一个习惯，凡是涉及配置变更，哪怕只是改一个数字，也要走一遍nginx -t再reload，这个习惯帮我避免了好几次线上故障。
4. 三大高频实战场景一次讲透
4.1 反向代理：一个入口访问多个内部服务
公司内部往往有很多服务：Java的Spring Boot应用、Python的Flask应用、Node.js服务，各自跑在不同的端口上。总不能每个服务都让用户记一个端口去访问，这时候Nginx就派上用场了。
我举个例子。一台服务器上有两个服务：
- Java服务跑在8080端口，处理
/api/请求 - Vue前端跑在3000端口，处理静态页面
使用Nginx做一个反向代理，统一从80端口入口：
server { listen 80; server_name www.example.com; # 前端页面请求转发到Vue开发服务器 location / { proxy_pass http://127.0.0.1:3000; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; } # API请求转发到Java后端 location /api/ { 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; } }这里有个关键点：proxy_set_header这三行大部分人都知道要配，但很多人不理解为什么。我来解释一下。
Nginx做反向代理时，后端服务收到的请求来源是Nginx本身，而不是真实的客户端。X-Real-IP和X-Forwarded-For这两个头就是用来传递真实客户端IP的。后端应用读取访问日志或者做用户行为分析时，如果没有这两个头，拿到的IP全是Nginx服务器的IP，那日志就没有任何分析价值了。
另外说一句，代理到TongWeb这类国产Java中间件时，配置方式基本一样，都是location加proxy_pass。TongWeb有时候对请求头校验更严格，proxy_set_header Host $host;必须配上，否则后端拿到的Host是内网IP，可能会触发一些校验逻辑。
4.2 负载均衡：upstream后端集群配置
一台服务器扛不住流量了怎么办？最直接的办法是多加几台服务器，然后用Nginx把请求分发到各个服务器上。这就是负载均衡。
Nginx的负载均衡通过upstream指令实现。我在实际项目里最常用的配置是这样的：
upstream backend_cluster { # 不写任何策略的话，默认是轮询 server 192.168.1.10:8080 weight=3; server 192.168.1.11:8080 weight=1; server 192.168.1.12:8080 backup; } server { listen 80; server_name example.com; location / { proxy_pass http://backend_cluster; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; } }上面这个配置里，192.168.1.10和192.168.1.11是两台正常的后端服务器，请求会按照3:1的比例轮询分发。192.168.1.12是备用服务器，只有前两台都挂了才会接手请求。这种“主备+权重”的混合架构，处理中小规模流量的高可用场景已经足够了。
Nginx支持几种负载均衡算法，我整理了一下：
| 算法 | 关键字 | 适用场景 |
|---|---|---|
| 轮询 | 默认 | 后端服务器配置相近的场景 |
| 加权轮询 | weight | 服务器性能有差异的场景 |
| IP哈希 | ip_hash | 需要客户端会话保持的场景 |
| 最少连接 | least_conn | 请求处理时间差异大的场景 |
| 一致性哈希 | hash $request_uri | 需要按URL分发的缓存场景 |
这里最大的坑在于会话保持。如果后端应用用了Session，没有做分布式Session共享，那你用了默认的轮询策略后，用户第一次请求被分到A服务器登录了，第二次请求被分到B服务器，B服务器没有这个用户的Session，就会提示未登录。最简单的解决办法是用ip_hash，让同一个IP的请求始终保持在同一台服务器上。当然，更好的方案是改造后端，使用Redis等中间件做Session共享，但那属于后端开发的范畴，这里不展开。
如果后端是OpenShift这类容器平台上的服务，反向代理配置也是同样的思路。OpenShift的路由本身可以做流量分发，但如果你的集群没有暴露外部路由，或者需要通过统一的Nginx入口管理多个集群服务，就可以把OpenShift的服务地址直接写进upstream：
upstream openshift_service { server myapp-myproject.apps.internal.example.com:443; } server { listen 8443 ssl; server_name myapp.example.com; location / { proxy_pass https://openshift_service; proxy_set_header Host myapp-myproject.apps.internal.example.com; } }需要注意HTTPS后端和SSL证书的头传递问题，这种场景下proxy_ssl_server_name on;和proxy_set_header要配合着设置，否则后端证书校验会失败。
4.3 部署Vue3等静态项目：root与alias的区别
前后端分离的项目越来越多，前端构建出来的dist目录直接交给Nginx托管，部署方式堪称最简单但又最容易配错的一个场景。很多人在两个指令上栽过跟头：root和alias。
先说结论：
root会把location中的路径拼接到root指定的目录后面alias会用alias指定的目录直接替换location中的路径
举个例子。访问http://example.com/vue3/，假设项目文件在/data/projects/vue3/dist目录下：
使用root配置：
location /vue3/ { root /data/projects/vue3/dist; }实际访问路径是/data/projects/vue3/dist/vue3/，明显不对，会404。因为root会把URL中的/vue3/拼上去。
使用alias配置：
location /vue3/ { alias /data/projects/vue3/dist/; }实际访问路径是/data/projects/vue3/dist/，这才是正确的结果。因为alias用后面的路径直接替换了/vue3/这个前缀。
这个坑我见过太多次了。新手部署Vue项目，用root配置半天打不开页面，打开F12看到404，第一反应是后端接口问题，查了一圈才发现是路径映射错了。
部署Vue3项目还有一个绕不开的问题：history路由。Vue3默认使用history模式的话，URL里没有#号，比如http://example.com/user/1。这个路径在Nginx层面是不存在的文件，直接访问会404。解决方案是加一个try_files指令：
server { listen 80; server_name example.com; root /data/projects/demo/dist; index index.html; location / { try_files $uri $uri/ /index.html; } location /api/ { proxy_pass http://backend_api; } }try_files $uri $uri/ /index.html的含义是：先查找请求对应的真实文件，找不到就尝试找目录，目录也找不到就返回index.html。这样无论前端路由怎么跳，刷新页面时Nginx都会返回前端入口文件，再由Vue Router接管并渲染对应页面。
Windows服务器上部署Vue3项目思路一样，只是路径分隔符要写成Windows风格，alias D:/projects/vue3/dist/;。注意Windows下路径末尾的斜杠也别落下，不然路径拼接时会出问题。
5. Docker部署Nginx并挂载多个项目目录
5.1 镜像版本怎么选
Docker化部署在现在的环境里几乎成了标配。使用docker pull nginx拉取镜像时，很多人直接不写版本号，拉个latest回来。我个人建议明确指定版本号，比如docker pull nginx:1.21.5。
原因很简单：latest标签会跟随上游更新而变化，今天拉的是1.24，过阵子再拉可能就变成1.26了，大版本迭代往往伴随着配置指令行为的变化，可能会导致你的配置文件突然失效。生产环境明确锁定版本号，之后的部署行为才是可预期、可复现的。
# 拉取指定版本 docker pull nginx:1.21.5 # 查看本地镜像 docker images | grep nginx5.2 挂载多项目目录的目录设计
用Docker跑Nginx最大的优势之一就是挂载宿主机目录，这样修改配置文件和部署前端代码时都不需要重新构建镜像。
以一台要部署三个项目目录的服务器为例，我会这样设计目录结构：
/opt/nginx/ ├── conf.d/ # 存放各个项目的server配置文件 │ ├── project-a.conf │ ├── project-b.conf │ └── project-c.conf ├── html/ │ ├── project-a/ # 项目A的静态文件 │ ├── project-b/ # 项目B的静态文件 │ └── project-c/ # 项目C的静态文件 ├── logs/ │ ├── access.log │ └── error.log └── nginx.conf # 主配置文件容器启动命令：
docker run -d \ --name nginx \ -p 80:80 \ -p 443:443 \ -v /opt/nginx/nginx.conf:/etc/nginx/nginx.conf:ro \ -v /opt/nginx/conf.d:/etc/nginx/conf.d:ro \ -v /opt/nginx/html:/usr/share/nginx/html:ro \ -v /opt/nginx/logs:/var/log/nginx \ --restart=always \ nginx:1.21.5这里我解释几个关键参数的含义。-p 80:80是把宿主机的80端口映射到容器的80端口，只有做了这个映射，外部的请求才能进入容器内的Nginx。-v是挂载目录，冒号前面是宿主机路径，后面是容器内路径，:ro表示只读挂载，防止容器内进程意外修改配置。--restart=always确保Docker服务重启后容器会自动拉起，这是生产环境的保命配置。
启动完成后，进容器验证一下Nginx是否正常：
# 进入容器 docker exec -it nginx bash # 测试配置文件语法 nginx -t # 查看当前生效的配置 nginx -T如果你使用的是docker compose，配置会更清晰：
version: '3.8' services: nginx: image: nginx:1.21.5 container_name: nginx ports: - "80:80" - "443:443" volumes: - /opt/nginx/nginx.conf:/etc/nginx/nginx.conf:ro - /opt/nginx/conf.d:/etc/nginx/conf.d:ro - /opt/nginx/html:/usr/share/nginx/html:ro - /opt/nginx/logs:/var/log/nginx restart: always要注意的是，Docker容器内的Nginx配置路径和物理机有所区别，比如/etc/nginx/conf.d/这个目录在部分官方镜像的默认nginx.conf里是通过include指令引入的。如果你改了主配置或者新增了conf.d下的文件，必须reload或重启容器才生效：
# 执行nginx -t并reload docker exec nginx nginx -t docker exec nginx nginx -s reload还有一种场景是编译Nginx时动态链接第三方库，比如要添加http_sub_module做反向代理内容替换、添加http_stub_status_module做状态监控。官方镜像默认是不带这些模块的，需要自己编译或者找包含这些模块的镜像。如果你只是需要字符替换功能，Nginx内置的sub_filter指令其实就够了，改一下配置就能用：
location / { proxy_pass http://backend; sub_filter '旧内容' '新内容'; sub_filter_once off; }这个指令在做反向代理时替换页面文本很有用，比如后端返回的静态资源路径是/static/，你希望通过Nginx改成CDN地址/cdn/static/，就能用sub_filter实现。
6. 日志、SSL与常见问题排查
6.1 日志路径与常见定位手段
日志是排查Nginx问题时最重要的线索，也是很多新手最容易忽视的部分。默认情况下，Nginx的访问日志和错误日志路径在：
- Linux：
/var/log/nginx/access.log和/var/log/nginx/error.log - Windows：nginx安装目录下的
logs\access.log和logs\error.log - Docker：启动时
-v挂载的宿主机目录，比如上面的/opt/nginx/logs/
调试的时候优先看error.log，里面会记录具体的错误原因。比如端口被占用、配置文件语法错误、worker进程启动失败，都会在这里留下记录。
我举个例子。启动Nginx时报错，错误日志里写[emerg] bind() to 0.0.0.0:80 failed (98: Address already in use)，这说明80端口被占用了。排查方法：
# 查看80端口被哪个进程占用 lsof -i :80 # 或 netstat -tlnp | grep 80拿到占用进程的PID后，确认是可杀掉的进程就停掉，再重新启动Nginx。这个问题的出现频率极高，尤其是Windows机器，IIS默认监听80端口，安装Nginx后经常冲突。
日志还有一个使用场景：核对请求有没有打到预期的后端。客户反馈“某个接口特别慢”，你先打开access.log，看看对应接口的request_time和upstream_response_time两个字段，基本就能判断是Nginx层慢还是后端服务慢。
6.2 配置HTTPS：私钥类型与证书链
现在部署HTTPS几乎成了标配。Nginx配置HTTPS的核心就是证书和私钥。很多人在这一块遇到迷惑：Nginx支持哪几种类型的私钥？
Nginx支持的是PEM格式的私钥，内容以-----BEGIN PRIVATE KEY-----或-----BEGIN RSA PRIVATE KEY-----开头。常见的私钥类型包括：
| 私钥格式 | Nginx是否支持 | 说明 |
|---|---|---|
| PEM | 支持 | 最常见的格式，文本可读 |
| DER | 需要转换 | 二进制格式，需要转成PEM |
| PFX/P12 | 不支持直接使用 | Windows常见的证书格式，需转换 |
| JKS | 不支持 | Java环境常见，需转成PEM |
如果你拿到的是PFX格式的证书（很多Windows服务器申请证书时会导出成这个格式），就不能直接给Nginx用，需要先用OpenSSL转换：
# 将PFX格式证书转为PEM格式证书和私钥 openssl pkcs12 -in certificate.pfx -out certificate.pem -nodes转换完成后，Nginx配置大概是这样的：
server { listen 443 ssl; server_name example.com; ssl_certificate /etc/nginx/ssl/example.crt; ssl_certificate_key /etc/nginx/ssl/example.key; ssl_protocols TLSv1.2 TLSv1.3; ssl_ciphers HIGH:!aNULL:!MD5; location / { proxy_pass http://backend; } }配置HTTPS时我最常遇到的坑，是证书文件路径写错或者证书链不完整。访问时一直报“证书无效”，但浏览器查看证书看不出问题。这种情况多半是部署时只上传了站点证书，没有上传中间证书链。正确的做法是把站点证书和中间证书合并成一个文件，或者用ssl_trusted_certificate指定证书链文件。
6.3 常见问题速查表
最后把高频问题整理成一张速查表，方便你实际排查时对照使用。
| 现象 | 可能原因 | 排查思路 |
|---|---|---|
| 首页显示Welcome to nginx而不是自己项目的页面 | server块的root或index配置没生效 | 检查server_name和listen配置，是否匹配了当前访问的域名和端口 |
| 页面404 | root路径不对或location匹配不到 | 检查root/alias路径，检查location块的匹配规则 |
| 接口能通但前端页面刷新404 | 前端使用的是history路由 | 给location / 加上try_files配置 |
| 502 Bad Gateway | 后端服务没启动或端口不对 | 检查proxy_pass指向的内网地址和端口能否访问 |
| 504 Gateway Timeout | 后端处理请求超时 | 适当增大proxy_read_timeout参数 |
| 403 Forbidden | 权限问题 | 检查静态文件目录的Linux读写权限，index文件是否存在 |
| 启动时报Address already in use | 端口被其他进程占用 | lsof或netstat查端口占用，停掉冲突进程或改Nginx监听端口 |
这里额外说一个排查效率技巧：每次修改Nginx配置后，如果出现异常，第一反应不要直接百度错误信息，而是先做两个动作：
# 1. 测试配置语法 nginx -t # 2. 查看错误日志最近20行 tail -n 20 /var/log/nginx/error.log这两个命令能解决80%的Nginx问题。剩下的20%才是配置逻辑层面的问题，需要结合上文提到的location匹配规则、proxy_pass路径拼接等知识去分析。
还有一个处理方案值得一提：当你手头恰好没有测试环境，又不敢直接动生产配置，可以复制一份Nginx配置，修改listen端口，比如改成8081，然后单独启动一个Nginx实例去做验证。确认没问题后再去改生产配置。这个操作我做过不止一次，稳妥可靠。
等你把上面这些场景都跑通了，Nginx的基本盘就算拿下了。后面再遇到更复杂的场景，比如HTTP/2、gzip压缩调优、缓存配置、限流防刷、日志按天切割，都是基于这篇文章的骨架去扩展。我自己刚接触Nginx时也是从“配一个能用的代理”开始的，很多指令只有亲手配过、踩过坑才记得牢。如果这篇文章能帮你少走几个弯路，那目的就达到了。
