1. 先搞清楚：Windows版Nginx能干什么，不能干什么

1.1 我最常遇到的四类需求

先说个真实场景。前阵子一个朋友做了个小程序，后端接口已经用Java写好了，跑在本机3000端口，但他需要模拟线上环境用80端口对外提供服务，还要把前端打包后的静态文件放在一起访问。我给他装了个Nginx做反向代理，两分钟搞定。

另一类更常见的需求是前端开发。Vue或React项目npm run build之后，直接打开index.html会遇到路由刷新404、接口跨域之类的问题，而扔到Nginx下面这些问题基本消失。还有些人会在局域网里搭一台Windows主机，用Nginx挂几个静态网页，让团队内部通过IP访问。

还有一类是纯学习型需求。很多人第一次接触Nginx是在Windows上，想弄明白反向代理、负载均衡到底是什么，在Linux服务器上操作总怕搞坏生产环境，Windows本机就成了练手的最好场所。

这类需求总结下来就是四种：本地开发调试、反向代理测试、局域网静态资源服务、学习练手。这四类场景用Windows版Nginx完全够用，也是我这篇文章的适用边界。

1.2 Windows版与Linux版的差异到底在哪

先说一个很多人没意识到的点：官方对Windows版Nginx的定位是"技术预览"级别，而不是和Linux版完全对等。官方文档里明确写着Windows版使用原生Win32 API实现，而不是通过模拟层跑Linux程序，所以常规功能都在，但在高并发性能上有明显限制。

具体差异主要有三处。

第一是性能。Linux版的Nginx能轻松扛住十万并发连接，每个worker进程用epoll事件模型，异步非阻塞能力强。Windows版受限于IOCP实现的成熟度，官方建议worker_processes只配置1个，并发能力差了不止一个数量级。所以拿Windows版当生产服务器扛大流量，思路本身就偏了。

第二是进程模型。Linux版有独立的master进程和worker进程，master管理worker，worker实际处理请求。Windows版虽然也有类似结构，但进程间信号通信用的是命名事件对象，行为在一些边界场景下并不可靠，最典型的就是后面要讲的"注册成服务后nginx -s stop失效"问题。

第三是文件路径和权限模型。Linux下一切皆文件，权限靠chmod/chown那一套；Windows下路径用盘符，权限靠ACL。Nginx配置里对路径的处理习惯不太一样，比如Linux下写/usr/local/www，Windows下写D:/nginx/html的时候要注意正反斜杠和权限继承。

1.3 什么场景下建议果断用Linux

把话说明白一点，Windows版Nginx适合的是开发调试、低并发内部使用。如果你要面对的是公网生产流量、要上HTTPS证书的全链路配置、要搞复杂的负载均衡集群，那就别在Windows上折腾了，直接上Linux服务器，或者干脆用Docker跑一个nginx容器，管理维护都更省心。

另外，如果你需要Nginx和PHP-FPM配合跑动态网站，Windows下没有官方PHP-FPM支持，只能靠其他方式模拟，复杂度会高很多。这种情况下我会直接转Linux。

2. 版本下载与安装准备：这步直接决定后面是否踩坑

2.1 Stable版还是Mainline版：我的选择标准

打开Nginx官网下载页会看到两个版本入口：Mainline version和Stable version。Mainline是主线开发版，功能新但发布时间不稳定，可能会有些小改动；Stable是稳定版，经过更长时间验证，修复了已知问题。

我的选择标准很简单：生产或半生产环境一律用Stable，学习新功能才去碰Mainline。Windows上做开发调试也不是追新功能的地方，Stable就对了。

还有一个小细节，下载页面会区分nginx/Windows和nginx/Linux。Windows版提供的是zip压缩包，不要下成Linux的tar.gz。文件名一般是nginx-1.24.0.zip这种格式。

2.2 下载、校验、解压的正确流程

Nginx的下载地址是nginx.org/en/download.html，进入后找到Stable version一栏，点nginx/Windows的zip包下载。下载完建议做一下文件校验，官网页面会提供对应的校验值。用PowerShell的话，命令是这样：

Get-FileHash D:\Downloads\nginx-1.24.0.zip -Algorithm SHA256

把输出结果和官网给出的校验值对比，一致说明文件没被篡改或者下载损坏。这一步在Windows下很多人会跳过，但既然是写教程，我还是建议做一遍，几秒钟的事。

解压方面有个特别容易踩的坑：不要用系统自带的压缩文件夹功能直接双击zip然后全选拖出来，容易丢失文件属性。推荐用7-Zip或者WinRAR解压，右键解压到指定目录即可。

2.3 安装目录规划：别把Nginx放在C盘根目录

我把Nginx解压后放在D:\tools\nginx-1.24.0，注意目录里不要有中文和空格。有次看到有同事放在D:\软件\nginx 新版本（带空格和中文），启动时直接报找不到配置文件，因为中文路径的编码问题在Nginx的Win32实现里处理得并不好。

还有一点，经常有人直接把zip里的文件解压到C:\，然后nginx.exe就在C盘根目录下，配置文件、日志文件也全堆在一起，时间一长C盘一团糟，权限也容易出问题。管理员权限运行Nginx时，工作目录不同会导致相对路径解析完全不一样，这是个隐患。

建议目录结构：

D:\tools\ nginx-1.24.0\ conf\ html\ logs\ temp\ nginx.exe

如果你有多个Nginx版本，可以在D:\tools下每个版本一个独立目录，后面做升级或回滚也方便。

2.4 安装前检查：80端口是否已经被占

双击nginx.exe之前，先确认本机80端口没被占用，这是新手最容易碰到的问题，没有之一。Windows下IIS默认监听80端口，SQL Server Reporting Services也会占80，还有Skype、某些网盘工具都可能抢端口。

检查命令：

netstat -ano | findstr ":80"

如果没有任何输出，说明端口空闲。如果看到类似TCP 0.0.0.0:80的监听记录，后面那串数字就是占用进程的PID。再通过PID查进程名：

tasklist | findstr "1234"

如果是IIS（进程名w3wp.exe或System），我可以先去IIS管理器停掉默认网站，或者直接在services.msc里把World Wide Web Publishing Service停止并设为手动启动。

这个检查我每次都强调，因为绕过这个坑能省下后面排查问题的大把时间。

3. 解压即用不是玄学：Nginx首次启动与验证

3.1 目录结构一览：你真正需要关心的只有两个目录

解压完成后，Nginx整个目录结构干净得让人舒服。核心的东西就三个文件加两个目录：

你只需要关注conf和logs。新手容易犯的错是去乱改html目录里的内容，或者误删temp目录，导致启动时报mkdir失败。temp目录是Nginx运行时自动创建临时文件用的，不要动它。

3.2 首次启动的三种命令到底有什么区别

启动Nginx的命令看着简单，但三种方式行为完全不同，很多人第一次启动就懵了。

第一种是直接双击nginx.exe。窗口闪一下就消失了，你以为它没启动成功，其实Nginx已经在后台跑起来了。因为Nginx在Windows下是一个控制台程序，启动后会立刻脱离当前控制台窗口继续运行。这种方式不推荐，因为看不到任何日志输出，出了问题也不知道为什么。

第二种是在cmd里直接输入nginx.exe。在nginx目录下打开cmd，输入nginx.exe，这个终端会被Nginx占住，Nginx的日志会直接往这个终端里打。好处是能直接看到启动日志，坏处是你的cmd窗口不能关，一关Nginx就跟着停了。

第三种是我推荐的：

start nginx

start是cmd的内置命令，意思是"新开一个窗口运行后面的程序"。执行start nginx后，Nginx会在另一个独立窗口运行，原有cmd窗口立即回到可用状态。而且即使是独立窗口，你也可以随时去查看运行日志。

3.3 验证启动成功的三个层次

启动之后别急着去改配置，先验证一下到底起没起来。验证分三个层次，从浅到深。

第一层，浏览器访问。打开浏览器，地址栏输入http://localhost，如果看到Welcome to nginx!的页面，说明HTTP服务起来了，这是最直观的方法。

第二层，查进程。配置了防火墙或者浏览器开了代理时，可能页面访问不到，但Nginx其实已经起来了。这时候用：

tasklist | findstr nginx

看到至少两个nginx.exe进程就对了，Windows版Nginx也有master和worker的进程模型。

第三层，查端口。用netstat确认80端口确实被Nginx监听：

netstat -ano | findstr ":80"

找到LISTENING状态的记录，PID对应上面tasklist查到的master进程PID，说明监听正常。

3.4 遇到"Welcome to nginx"之前必经的坑

这里把前面铺垫的几个坑串起来说一下。如果你访问localhost没反应，按下面顺序排查。

首先确认端口没被占，前面第2.4节已经做过检查。其次确认启动方式，如果是双击启动的，ctrl+shift+esc打开任务管理器看进程在不在。如果进程都不在，进logs目录打开error.log，最后几行就是报错信息。

最典型的报错长这样：

bind() to 0.0.0.0:80 failed (10013: An attempt was made to access a socket in a way forbidden by its access permissions)

这就是端口被系统或其他程序独占时的报错。还有一种是：

[emerg] mkdir() "C:\nginx/temp/client_body_temp" failed

这是工作目录不对导致的，解决办法是启动前先cd到Nginx安装目录。用start nginx之前，一定先确认当前cmd工作目录就是Nginx目录。我习惯写一个bat脚本放在Nginx目录下，双击执行，脚本内容就一行：

cd /d D:\tools\nginx-1.24.0 start nginx

这样可以彻底避免工作目录的问题。后面讲开机自启动时，这个细节还会出现。

4. 开机自启动方案横评：谁才是Windows下最稳的做法

4.1 启动文件夹放快捷方式：能用但问题一堆

最"原始"的自启动方案，就是把nginx.exe的快捷方式丢进Windows启动文件夹。Win+R输入shell:startup，回车打开启动文件夹，右键创建nginx.exe的快捷方式放进去就完事了。

但这方案问题很多。第一，快捷方式默认的工作目录是C:\Windows\System32，Nginx启动时会去System32下面找conf目录，必然找不到，启动失败。你必须在快捷方式的属性里手动改"起始位置"为Nginx安装目录。第二，启动时Nginx的控制台窗口会闪出来，虽然不会一直停留，但每次开机都闪一下，很膈应。第三，这种方案启动的是普通用户权限的进程，如果后面要监听80端口，某些系统配置下可能权限不够。

能用，但只适合临时应急，不适合长期稳定。

4.2 任务计划程序：系统自带，无需额外软件

第二个方案是Windows自带的"任务计划程序"，不需要装任何第三方工具，这也是它的优势。Win+R输入taskschd.msc打开，右侧"创建任务"，关键配置在几个标签页里：

常规标签页，名称填nginx-autostart，勾选"不管用户是否登录都要运行"，勾选"使用最高权限运行"。这里有两个常用触发条件：一种是登录时触发，适合个人电脑，因为Nginx需要用户登录后才能跑；另一种是计算机启动时触发，适合服务器，因为开机就要提供服务，不依赖任何用户登录。

操作标签页是核心，新建操作，操作选"启动程序"，程序或脚本填Nginx的完整路径D:\tools\nginx-1.24.0\nginx.exe，"起始于(可选)"一栏必须填写D:\tools\nginx-1.24.0。这个字段就是任务计划里的工作目录，不填就等于在System32下面启动，又是熟悉的配方。

条件标签页里，把"只有在计算机使用交流电源时才启动此任务"取消勾选，否则笔记本用电池时不会自启。设置标签页里，勾选"如果任务失败，重新启动"。

任务计划程序的优点是不需要额外下载工具，Windows自身机制稳定。缺点有两个，一是在任务计划里配置的进程如果被手动杀掉，不会自动拉起；二是对于初学者来说，标签页太多，配置项容易漏。

4.3 NSSM注册服务：最接近Linux systemd体验的方案

第三个方案是我个人最推荐的，用NSSM（Non-Sucking Service Manager）把Nginx注册成Windows服务。NSSM是一个开源工具，专门用来把普通exe程序包装成Windows服务。它会在系统服务管理器里注册一个服务，由服务管理器统一管理，能做到开机自启、崩溃自动重启、日志重定向。

用NSSM包装之后的Nginx，在services.msc里能看到，也可以用net start/stop来控制，体验非常接近Linux下systemd管理服务的模式。

这个方案也有坑，最主要的就是前面提过的"注册为服务后，nginx -s stop会失效"的问题。原因在于：用NSSM启动的nginx.exe运行在服务会话（Session 0）里，Nginx用来接收停止信号的事件对象工作机制在服务会话下会发生变化，导致手动执行nginx -s stop时进程无法收到正确的关闭信号。解决方式很简单：不要用nginx -s stop，改用net stop nginx。这在第5章会详细展开。

4.4 其他工具补充：WinSW、sc命令

除了NSSM，Windows下还有一个常用的服务包装工具叫WinSW。它是一个单exe工具，通过一个XML配置文件把exe包装成服务。WinSW在Jenkins、GitLab Runner等CI/CD工具里用得比较多，功能也很成熟。

还有一种方式是直接用sc命令创建服务：

sc create nginx binPath= "D:\tools\nginx-1.24.0\nginx.exe" start= auto

这个方案我不推荐，因为nginx.exe不是按Windows服务规范编写的原生态服务程序，直接用sc注册，服务管理器无法正确控制它的生命周期，启动、停止都会出现各种失灵现象。NSSM和WinSW这类工具的价值就在于它们的好好服务规范，再去包装nginx的进程生命周期。

4.5 三种主流方案对比

如果只是临时玩玩，任务计划程序够了。如果是给公司内部服务用或者长期跑，直接上NSSM，一劳永逸。

5. NSSM完整实操：把Nginx变成Windows服务

5.1 NSSM的下载与放置位置

NSSM的官网是nssm.cc，下载地址在nssm.cc/download。下载下来是一个zip压缩包，解压后有win32和win64两个文件夹，根据自己的系统位数选择里面的nssm.exe。

NSSM本质上是绿色软件，不需要安装，但nssm.exe本身需要放在一个固定位置。我习惯放在D:\tools\nssm\nssm.exe，因为注册服务的时候，NSSM的服务管理功能需要持续调用这个exe，如果把它放在临时目录或者下载目录，哪天被清理了服务就废了。

配置环境变量这件事可做可不做。如果不想每次输命令都要切到nssm所在目录，可以把D:\tools\nssm加入系统PATH环境变量。但如果你主要用NSSM的图形界面，不加入也没关系。

5.2 命令行注册服务与图形界面配置

注册服务有两种方式，命令行和图形界面，我建议先用图形界面把参数看明白，之后用命令行做批量操作。

图形界面方式是先打开命令行，切到nssm所在目录：

cd /d D:\tools\nssm nssm install nginx

执行后直接弹出图形配置界面，界面很简单，几个标签页：

Application标签页里的三行是核心：

• Path（应用程序路径）：D:\tools\nginx-1.24.0\nginx.exe
• Startup directory（启动目录）：D:\tools\nginx-1.24.0
• Arguments（参数）：一般情况下留空。如果nginx.conf不是默认位置，可以加-c conf\nginx.conf

这三行的对应关系，就是我在3.2节强调的工作目录问题。Startup directory没填对，服务启动就会失败。填写完成后，点击"Install service"按钮，服务就注册好了。

命令行方式的指令是：

nssm install nginx D:\tools\nginx-1.24.0\nginx.exe

它会用默认参数直接注册服务，但默认的工作目录是nginx.exe所在目录，也就是D:\tools\nginx-1.24.0，一般不用改。注册完以后建议用下面的命令再确认参数：

nssm dump nginx

dump命令会输出当前服务所有参数，一目了然。

5.3 关键参数说明：工作目录、日志输出、重启策略

服务注册完成只是第一步，还有几个参数直接影响后续使用的稳定性。

第一个是AppDirectory（启动目录），注册服务时默认取exe所在目录，但如果你是用图形界面配的，一定要检查这一项是否填了。AppDirectory不对，Nginx连conf目录都找不到，服务必然启动失败。

第二个是日志输出。Nginx自己会写access.log和error.log，但如果Nginx启动阶段就挂了，比如nginx.conf语法错误，Nginx自己的日志可能来不及写，这时候NSSM的日志就派上用场了。在图形界面的I/O标签页里，可以设置Output（标准输出）和Error（标准错误）的日志文件路径，比如D:\tools\nginx-1.24.0\logs\nssm_out.log。我一般建议设置一个，排错时多一个信息来源。

第三个是重启策略。NSSM作为服务管理工具，最大的价值是能在进程崩溃时自动拉起。默认情况下NSSM会配置好AppExit动作，但为了更稳妥，建议设置一下：

nssm set nginx AppExit Default Restart

这条命令的含义是：如果nginx进程以异常状态退出，服务管理器自动重启它。设置之后，即使Nginx被某个异常拖垮，几秒内也会被拉起来，原本需要人工介入的事就免了。

5.4 一个容易忽略的坑：注册服务后nginx -s stop失效

第4.3节提到过这个问题，这里展开讲一下。用NSSM把Nginx注册为服务并启动后，你在命令行进到nginx目录，执行nginx -s stop或者nginx -s reload，大概率会遇到两种情况之一。

要么就是没有任何反应，Nginx进程纹丝不动还在跑；要么就是报一个类似"nginx: [error] OpenEvent("ngx_stop_xxx") failed"的错误。

nginx -s stop的原理是：Nginx的master进程在启动时会创建一个命名事件，名字通常包含进程PID，比如ngx_stop_12345。执行nginx -s stop时，命令行程序会去尝试打开这个事件并设置信号。问题在于，用NSSM启动的Nginx运行在Session 0（服务会话）里，和你打开cmd所在的交互式会话（Session 1或更高）不在同一个会话中，命名事件被Session隔离机制隔开了，命令行程序打不开这个事件，于是信号传递失败。

那么reload还有效吗？同样会失败。这是NSSM方案里最让新手困惑的点。解决办法就一条：凡是服务方式运行的Nginx，管理命令一律用服务级别的命令。重启、停止用net stop nginx / net start nginx，或者nssm restart nginx；改完配置需要重载时，用nssm restart nginx重启服务来使配置生效。

这里有个折中的小技巧：如果你实在想用nginx -s reload来做热加载，可以放弃NSSM的服务注册，改用任务计划程序。任务计划程序启动的Nginx和你的cmd在同一个交互式会话，nginx -s reload不会失效。代价就是失去崩溃自动重启的能力，看你怎么权衡了。

6. 验证自启动与故障排查：按这个顺序走，基本不迷路

6.1 自启动是否生效的验证方法

配置完开机自启后，最直接的方式是重启电脑，然后打开浏览器访问localhost看是否直接出现Nginx欢迎页。但这个验证成本高，而且出了问题不好定位。

我一般用两步来快速验证。第一步，重启后不要打开浏览器，直接看services.msc（服务管理器）里nginx服务的状态，是"正在运行"还是"已停止"。如果显示"已停止"，说明服务注册成功了但启动失败，问题就出在Nginx自身，得看日志。如果服务都不存在，说明NSSM注册环节出问题了。

第二步，确认Nginx已经监听端口。在cmd里执行netstat -ano | findstr ":80"，看到LISTENING记录，基本就稳了。

有时候登录Windows时服务启动得早，页面访问正常；但如果你在Nginx服务启动前就登录并占用了80端口，服务会启动失败。这种情况在服务管理器里看到的状态可能还是"正在运行"，但netstat查不到端口监听。遇到这种矛盾，果断看错误日志。

6.2 端口被占用的完整排查链路

端口被占用是Windows下Nginx启动失败的头号原因，它有三类典型症状：启动时cmd报bind失败、服务启动后马上就停止、浏览器访问localhost没反应。

完整排查链路长这样。先用netstat查端口：

netstat -ano | findstr ":80"

没有输出说明端口根本没被监听，问题不在这里。有输出时，看监听状态的PID。然后通过PID定位进程：

tasklist /FI "PID eq 1234"

查到进程名之后分情况处理。如果进程名是w3wp.exe，那是IIS的工作进程，去IIS管理器停止默认网站即可。如果是System（PID是4），说明HTTP.sys内核驱动占用了80端口，常见原因是IIS的HTTP.sys、SQL Server Reporting Services、或者某些Web服务。处理方式是在services.msc里找到相关服务停掉并设为手动。如果你是用的Docker，docker-proxy也经常占用端口，运行docker ps看看有哪些容器在监听80。

占用的进程实在找不到或者不想动系统服务时，还可以换个思路：干脆让Nginx监听其他端口。在nginx.conf里把listen修改为8080或者你需要的端口，只要上层没有硬性要求80，这也是个省事的做法。

6.3 防火墙放行：局域网内其他机器如何访问

Nginx在Windows本机启动成功后，本机浏览器访问localhost没问题，但局域网里的其他电脑访问http://你的IP/却打不开，十有八九是防火墙拦了。

Windows默认防火墙对入站连接是允许的，但对Nginx这种监听端口的程序，有时会弹窗询问是否允许，你没点"允许"的话，外部流量就会被拦。解决方案是自己手动建一条放行规则。

打开控制面板，找到Windows Defender防火墙，左侧点"高级设置"，左侧再选"入站规则"，右侧点"新建规则"。规则类型选"端口"，协议选TCP，特定本地端口填80（或者你Nginx监听的端口），操选"允许连接"，配置文件全勾上，名称填nginx。完成后局域网其他电脑就能访问了。

有个细节：如果你在虚拟机里跑Nginx，宿主机要访问虚拟机里的Nginx，除了Windows防火墙，还要确认虚拟机的网络模式。NAT模式下宿主机访问需要端口转发，桥接模式下直接访问虚拟机IP。这个和Nginx本身关系不大，但排查时要意识到。

6.4 服务启动失败的日志定位思路

Nginx注册为服务后启动失败，从Nginx自己的error.log看起。路径是D:\tools\nginx-1.24.0\logs\error.log，打开后看最后几行。

最常见的错误有三种。第一种是bind() to 0.0.0.0:80 failed，端口被占用，按6.2节处理。第二种是配置文件语法错误，nginx.conf某个字段写错了，这时候Nginx会在error.log里写具体行号，比如：

[emerg] "server" directive is not allowed here in D:\tools\nginx-1.24.0\conf\nginx.conf:23

这种情况用nginx -t检查语法，修复到通过为止。第三种是路径错误，比如：

[emerg] open() "D:\tools\nginx-1.24.0\conf\nginx.conf" failed (2: The system cannot find the specified file)

这种情况基本是启动目录或-c参数指向了不存在的文件。你先确认nginx.conf实际位置和NSSM里的Startup directory是否一致。

如果error.log是空的，说明Nginx压根没走到写日志那一步。这时候看Windows事件查看器，Win+R输入eventvwr.msc，Windows日志-应用程序和系统，找最近时间点与nginx或服务管理相关的错误条目。这一步能拿到很多系统层面的信息，比如依赖的DLL缺失，或者权限不足。

服务启动失败的排查顺序可以总结成一句话：Nginx自己的日志优先，NSSM/服务日志其次，Windows事件日志兜底，最后回头看配置细节。

7. 配合自启动的进阶配置：让Nginx真正为你干活

7.1 最常用的静态站点配置模板

服务已经跑起来、开机自启也搞定了，接下来就是让Nginx真正干活。先给一个静态站点能直接用起来的配置模板，扔进http块里。完整替换默认的server块也行，另开一个server块也可以。

server { listen 80; server_name localhost; root D:/wwwroot/mysite; index index.html index.htm; location / { try_files $uri $uri/ =404; } location ~* \.(js|css|png|jpg|jpeg|gif|ico|svg)$ { expires 7d; add_header Cache-Control "public, no-transform"; } }

这里的root直接指向你站点的物理目录，注意路径用正斜杠（D:/wwwroot/mysite），Nginx对反斜杠的转义处理很容易埋坑。try_files那行的作用是：如果URL对应的文件不存在，尝试加上/当目录找，再找不到就返回404，这是SPA单页应用刷新路由问题的标准解法之一。

7.2 反向代理到本机应用

本地开发最常见的需求是把80端口的请求转发到本机某个应用端口，比如Java的3000端口、Node的8080端口。在Nginx里配一个反向代理server块：

server { listen 80; server_name api.local.test; 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; proxy_set_header X-Forwarded-Proto $scheme; } }

proxy_pass是核心，它把请求转发到后端地址。proxy_set_header那几行是为了让后端应用拿到真实的客户端IP和原始请求信息，否则后端看到的所有请求都来自127.0.0.1，没法记录真实访问来源，也影响Session、日志之类的功能。

配完之后不用重启Nginx，只需：

nginx -t nginx -s reload

前提是你没把Nginx注册成服务。如果注册成服务了，nginx -s reload是失效的，就用nssm restart nginx。老规矩。

7.3 多站点配置：用include拆分conf

管理一个站点还行，但如果你要同时跑三四个站点，所有server块都堆在nginx.conf里会变得又长又乱。推荐用include指令拆分配置文件。

Nginx自带的conf/nginx.conf在http块末尾一般都会有一行：

include mime.types;

你要做的是在http块内部建一个单独目录conf/conf.d，然后在nginx.conf的http块最后加一行：

include conf.d/*.conf;

之后每个站点一个独立配置文件，比如conf/conf.d/mysite.conf、conf/conf.d/api.conf，内容就是各自的server块。这样做的好处不只是结构清晰，还可以单独禁用某个站点——把对应conf文件的扩展名改了，比如改成.bak，再reload就生效，不用动主配置。

7.4 日常维护经验：改配置、看日志、升级版本

最后说几个日常维护的实操习惯。

每次修改nginx.conf之前，先用nginx -t验证语法，确认无误再reload。这个习惯能帮你挡住90%的配置错误。如果你用了conf.d拆分方案，每次改动某个子配置文件后也要跑一遍nginx -t，因为语法错误发生在include的子文件里，Nginx一样会在启动阶段报错。

看日志方面，access.log会越滚越大，Windows下没有Linux那种logrotate机制，所以建议定期清理，或者直接写个计划任务定时删除超过N天的日志。脚本也不复杂，用PowerShell就能实现。

升级Nginx版本时，不要把新版本直接覆盖旧版本目录。正确的做法是把新版本解压到新目录，然后把旧目录的conf目录原样复制过去，注意不要用旧目录下的logs目录覆盖新版本，那些是运行时数据。完成之后用nginx -t验证，再停旧服务、启新服务。万一新版本出问题，切回旧版本也方便。

我自己在Windows下的习惯是：conf目录里的nginx.conf用版本管理工具（比如Git本地仓库）管理起来，每次改动都有记录。这看起来多此一举，但真出问题的时候，能帮你快速定位是哪次改动弄挂了服务。这个习惯在Linux服务器上同样适用。

配到这一步，你的Windows Nginx就已经不是"临时玩玩"的级别了，它是一个能开机自启、有完整日志、支持多站点、能反代本地服务的小型Web服务器。后面再遇到什么新的需求，在这个基础上做增量就行。