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管理workerworker实际处理请求。Windows版虽然也有类似结构但进程间信号通信用的是命名事件对象行为在一些边界场景下并不可靠最典型的就是后面要讲的注册成服务后nginx -s stop失效问题。第三是文件路径和权限模型。Linux下一切皆文件权限靠chmod/chown那一套Windows下路径用盘符权限靠ACL。Nginx配置里对路径的处理习惯不太一样比如Linux下写/usr/local/wwwWindows下写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整个目录结构干净得让人舒服。核心的东西就三个文件加两个目录文件/目录作用nginx.exe可执行文件启动和停止都靠它conf/nginx.conf核心配置文件HTTP服务器行为都在这里定义conf/mime.types文件扩展名和MIME类型的映射一般不手动改html/默认站点根目录里面有index.html和50x.htmllogs/日志目录access.log记录访问error.log记录错误你只需要关注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 nginxstart是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节已经做过检查。其次确认启动方式如果是双击启动的ctrlshiftesc打开任务管理器看进程在不在。如果进程都不在进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启动文件夹。WinR输入shell:startup回车打开启动文件夹右键创建nginx.exe的快捷方式放进去就完事了。但这方案问题很多。第一快捷方式默认的工作目录是C:\Windows\System32Nginx启动时会去System32下面找conf目录必然找不到启动失败。你必须在快捷方式的属性里手动改起始位置为Nginx安装目录。第二启动时Nginx的控制台窗口会闪出来虽然不会一直停留但每次开机都闪一下很膈应。第三这种方案启动的是普通用户权限的进程如果后面要监听80端口某些系统配置下可能权限不够。能用但只适合临时应急不适合长期稳定。4.2 任务计划程序系统自带无需额外软件第二个方案是Windows自带的任务计划程序不需要装任何第三方工具这也是它的优势。WinR输入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体验的方案第三个方案是我个人最推荐的用NSSMNon-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命令除了NSSMWindows下还有一个常用的服务包装工具叫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注册服务是NSSM是是高强烈推荐如果只是临时玩玩任务计划程序够了。如果是给公司内部服务用或者长期跑直接上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.exeStartup directory启动目录D:\tools\nginx-1.24.0Arguments参数一般情况下留空。如果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 nginxdump命令会输出当前服务所有参数一目了然。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管理器停止默认网站即可。如果是SystemPID是4说明HTTP.sys内核驱动占用了80端口常见原因是IIS的HTTP.sys、SQL Server Reporting Services、或者某些Web服务。处理方式是在services.msc里找到相关服务停掉并设为手动。如果你是用的Dockerdocker-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事件查看器WinR输入eventvwr.mscWindows日志-应用程序和系统找最近时间点与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/mysiteNginx对反斜杠的转义处理很容易埋坑。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服务器。后面再遇到什么新的需求在这个基础上做增量就行。
