我最早折腾nginx的时候，也是老老实实在Windows上开个cmd窗口，敲一行start nginx，然后那个黑窗口就一直得挂在那边。窗口一关，服务就没了。后来换机器、重启系统，还得手动去点一下。最麻烦的是有一次服务器因为更新自动重启了，我人又不在电脑前，网站直接躺平了半天。自打那次之后，我就下定决心，必须让nginx以Windows系统服务的方式跑起来。这篇文章就是拿我自己踩过的坑和实践总结出来的经验，把“将nginx注册为Windows系统服务”这件事从头到尾给你讲透，保证你能照着抄作业。

对于运维新手、个人站长，或者工作中需要在Windows环境里跑nginx做反向代理和静态资源服务的开发者来说，这篇文章能直接解决你“开机自启”、“后台运行”、“崩溃自动拉起”这三个核心诉求，不用再去碰那些乱七八糟的第三方工具。

1. 为什么非要把nginx在Windows上跑成服务

1.1 命令行启动nginx的四个常见痛点

用命令行方式启动nginx，短时间开发测试没问题，但一旦进入长期运行或者生产环境，问题很快就暴露出来了。我大概总结了一下，主要是下面四个痛点，你看看你中了几个。

第一个痛点是进程和终端窗口强绑定。只要那个cmd窗口被关闭——不管是你手滑点错了，还是系统重启后没重新打开——nginx主进程就会收到终止信号，整个服务直接结束。这个我在项目交付的时候踩过，客户第二天早上反馈网站打不开，我远程一看，就是前一晚系统打了个补丁自动重启了，命令行窗口没恢复。

第二个痛点是开机不能自启。Windows开机之后，所有进程都需要手动去拉起。虽说可以把启动命令丢进“启动”文件夹或者计划任务里，但那个黑窗口依然存在，每次开机都得弹一个cmd窗口出来，不但丑，而且容易被误关。

第三个痛点是进程守护缺失。nginx在Windows上跑久了，偶尔会因为极端情况出现进程假死或者异常退出。命令行方式下没有守护机制，进程没了就是没了，不会自动重新拉起。这对于需要稳定提供服务的场景来说，完全不可接受。

第四个痛点是权限和桌面会话绑定。普通命令行启动的进程和当前用户会话是绑在一起的。如果锁屏、注销或者切换用户，进程行为可能会变得不可预期。而Windows服务是一种由服务控制管理器（SCM）统一管理的特殊进程，从机制上天然躲避了上面这些问题。

1.2 服务方式与普通方式的核心差异

Windows服务和普通应用程序最大的区别在于：它没有界面，由系统服务控制管理器统一管理，并且可以配置为“自动启动”、“手动启动”或“禁用”。把nginx注册成服务之后，它的运行身份、启动时机、失败恢复策略全都交给操作系统去管，这就省去了很多人为干预。

服务方式带来的直接好处有三个。一是开机之后、用户登录之前就可以启动，网站和接口的可用性大大提升。二是进程不再依附于某个cmd窗口，关桌面、注销会话都不会影响它继续运行。三是可以设置失败重启策略，进程退出了系统自动帮你拉起来，这在生产环境里是救命级别的特性。

当然，服务方式的劣势也有，比如配置修改和日志查看有时候反而比命令行方式麻烦一点。不过这些都有标准解法，后面我会在实操环节里详细说明。总的来说，只要你打算让nginx在Windows上持续跑一周以上，注册成服务是唯一正确的选择。

2. 方案怎么选：winsw、NSSM还是sc命令

2.1 三种主流方案的横向对比

在讲具体操作之前，先把“用什么工具”这个前置问题说清楚。Windows上把任意可执行文件注册为服务，官方自带的有一个sc命令，第三方工具里比较主流的是NSSM（Non-Sucky Service Manager）和winsw。我三种方式都试过，这里直接给你横向对比结果。

从适用场景来看，sc命令太原始了，只负责“注册服务”这一个动作，服务挂了不会自动拉起，日志也没人管，所以我基本上只拿它来做应急处理。winsw胜在配置轻量、文档也比较友好，适合那些把配置纳入版本管理的团队。NSSM则是“开箱即用”的整合型方案，不仅注册服务的时候方便，还自带日志重定向和进程监控功能，对小团队和个人站长来说是最稳妥的选择。

2.2 为什么多数场景优先用NSSM

我个人在Windows环境里给nginx做服务化，用得最多的是NSSM，原因有三个。

第一，NSSM对“进程退出时自动重启”这件事处理得特别好。它在服务里挂了一个管理者进程，时刻盯着被管理的目标进程。一旦发现目标进程非正常退出，它可以按照预设策略自动拉起，这个能力正好补足了sc命令的短板。对于nginx这种本身就比较稳定的程序来说，加上这层守护之后，我基本可以做到“部署完就不再管它”。

第二，NSSM把日志重定向做成了内置功能。它可以把被管理进程的标准输出和标准错误输出分别写入指定的日志文件，还会自动按日期拆分。我之前的做法是直接让它把nginx的access_log和error_log重定向到统一目录，排查问题的时候一个地方全看完了，体验非常好。

第三，NSSM支持通过命令行进行参数配置，这意味着你的整个操作过程可以脚本化。比如通过nssm set nginx AppDirectory C:\nginx、nssm set nginx AppParameters -p D:\conf\nginx.conf这样的命令，就可以把一套标准配置固化成脚本。以后换机器部署的时候，跑一遍脚本就全搞定了，不用再在GUI界面里点点点。

不过要说清楚的是，NSSM并不是完全没有毛病。它的守护进程是用“轮询”方式判断被管理进程是否还在运行的，个别极端情况下可能有一两秒的延迟，但对nginx这种本身就不依赖瞬时切换的应用场景来说，毫无影响。再加上它在Windows 7到Windows 11上都表现稳定，综合下来它是我最推荐的选择。

3. 上手实操：用NSSM把nginx注册成Windows服务

3.1 准备工作与运行原理

在动手之前，先把基本功弄扎实。NSSM的下载安装极其简单，去它的官网下载对应架构的压缩包，解压之后你就能得到一个nssm.exe文件。把它放到一个固定目录里，比如C:\tools\nssm\，后面所有命令都通过这个全路径来调用。

nginx这边我默认你已经有了一份能正常跑的配置，比如nginx.exe -t校验通过。给一个非常关键的建议：先把nginx进程彻底停掉。如果你已经通过命令行把nginx跑起来了，不先关掉的话，后面注册服务时大概率会遇到端口被占用的问题，因为旧进程还占着80或者8080这些监听端口。简单跑一句nginx.exe -s stop，或者打开任务管理器把残留的nginx进程全部结束掉。

为什么NSSM能把nginx注册成服务？它的原理说穿了其实很简单：NSSM本身会注册成一个Windows服务，而这个服务启动时要执行的动作，就是去运行你指定的那个可执行文件。换句话说，NSSM给你当了一个“代理”，你在系统服务列表里看到的是nginx这个服务名，但实际被SCM管理的进程是这个服务名背后对应的NSSM进程树。

nginx在Windows上是支持“前台运行”的吗？这里要特别说明一个容易混淆的点：start nginx这种启动命令会让nginx以后台守护方式运行，但当你把nginx的主程序nginx.exe直接交给NSSM去执行时，它实际上是以前台方式运行的。前台运行的好处是NSSM可以准确感知到nginx进程什么时候退出，从而触发重启策略。如果不小心用了带start的包装脚本，NSSM反而会盯着那个中间cmd进程，起不到守护作用了。

3.2 安装服务的具体配置

第一步，以管理员身份打开PowerShell或者cmd。这一步非常关键，因为注册系统服务本质上是在修改系统配置，普通权限会直接报“拒绝访问”。

第二步，执行安装命令。假设你的nginx解压在D:\nginx-1.26.2，NSSM放在C:\tools\nssm\nssm.exe，那么先执行：

C:\tools\nssm\nssm.exe install nginx

这个命令会弹出一个图形配置界面。如果你不喜欢用GUI，完全可以直接用纯命令行参数设置关键项。我个人习惯两种方式混着用：先用命令把最核心的路径和参数设置好，再打开GUI检查一遍可选配置。

配置界面里最需要关心的几个字段（无论你用GUI还是命令行，原理都一样）：

• Application Path: 必须指向nginx.exe这个实际可执行文件，而不是启动脚本。默认填D:\nginx-1.26.2\nginx.exe。
• Startup directory: 工作目录。这个一定要填对，否则nginx启动的时候会找不到相对路径下的配置文件。默认填D:\nginx-1.26.2。
• Arguments: 如果需要指定不同的配置文件路径，可以在这里填-p D:\nginx-1.26.2这种参数。如果你用的是nginx默认路径，这里留空就行。

用命令行一次性设置的命令是这样的：

C:\tools\nssm\nssm.exe set nginx AppDirectory D:\nginx-1.26.2 C:\tools\nssm\nssm.exe set nginx Application D:\nginx-1.26.2\nginx.exe C:\tools\nssm\nssm.exe set nginx AppParameters -p D:\nginx-1.26.2 C:\tools\nssm\nssm.exe set nginx AppExit Default Restart

这里最后一行AppExit Default Restart的意思是：不管进程是因为什么原因退出，默认都执行“重启”动作。这就实现了“进程挂了自动拉起”的核心诉求。

如果你用的是GUI，还需要在“Process”选项卡里确认一下“Startup directory”是否已经自动带出来了。NSSM在这方面做得比较智能，会根据Application Path自动推导工作目录，但最好还是自己确认一遍，避免后续找不到conf或logs目录。

3.3 服务的日常运维操作

注册好服务之后，日常的启停操作就变得非常简单了。你可以在服务管理器里找到名为nginx的服务，右键手动启动；也可以用命令行操作：

# 启动 net start nginx # 停止 net stop nginx # 查看服务状态 sc query nginx # 删除服务 sc delete nginx

需要注意的一点是，net stop nginx在给nginx做平滑退出的时候，行为和命令行里的nginx -s quit不完全一样。NSSM会先尝试向nginx进程发送停止信号，如果在一段时间内没有响应，就会强制结束。通常情况下，只要nginx没有在处理复杂的长连接请求，停止过程都是瞬间完成的。

至于修改配置之后的生效问题，这里有一个我踩过很多次坑的经验：修改nginx.conf之后，先执行nginx -t校验配置，再执行net stop nginx && net start nginx或者用NSSM自带的nssm restart nginx重启服务。有人问为什么不执行nginx -s reload，其实也可以，但通过服务方式运行的时候，reload的写法取决于你有没有指定工作目录。如果在NSSM里设置了正确的AppDirectory，直接在命令行执行D:\nginx-1.26.2\nginx.exe -s reload是可以生效的。但为了保险起见，在Windows服务模式下我通常直接重启服务，反正nginx的启动速度极快，毫秒级完成，不会产生什么可感知的抖动。

关于开机自启动，安装服务时默认的启动类型就是“自动”，所以你不需要额外配置。如果之前在命令行里放了一个开机脚本或者计划任务，记得清理掉，避免重复启动导致端口冲突。

4. 进阶选择：winsw的XML配置方式

4.1 环境准备

如果你喜欢“一切皆配置”的管理方式，那么winsw可能更适合你的口味。winsw的核心思路是：你提供一个XML文件，里面写清楚要运行什么程序、传什么参数、日志怎么记、进程挂了怎么办，然后通过winsw这个exe来安装和卸载服务。

winsw的下载也很好找，GitHub上有release包。需要注意对应Windows系统的.NET版本，Windows 10和Windows Server 2016以上版本都是用.NET Framework 4.6.1版本，选择对应的exe即可。下载下来之后，把WinSW-x64.exe重命名为一个看起来舒服的名字，比如nginx-service.exe，然后放在一个固定目录。

接下去，创建一个和exe同名的XML文件，比如nginx-service.xml。winsw就是通过这种“同名exe和xml配对”的约定来识别配置的。这一点很容易被忽略，很多新手拿到手会随便起名，结果运行的时候发现完全找不到配置。

4.2 XML配置详解

下面是我在实际项目里用过的一份可复用配置，我直接贴出来并逐项说明含义：

<service> <id>nginx</id> <name>nginx</name> <description>High-performance HTTP server and reverse proxy</description> <executable>D:\nginx-1.26.2\nginx.exe</executable> <arguments>-p D:\nginx-1.26.2</arguments> <workingdirectory>D:\nginx-1.26.2</workingdirectory> <log mode="roll-by-time"> <pattern>yyyyMMdd</pattern> </log> <onfailure action="restart" delay="10 sec"/> <onfailure action="restart" delay="20 sec"/> <serviceaccount> <domain>NT AUTHORITY</domain> <user>LocalSystem</user> </serviceaccount> </service>

一个个来看关键节点。id是服务的唯一标识，安装后你在服务管理器里看到的名称通常就是这个；name是显示名称，可以写得友好一点；executable指向nginx主程序；arguments传入-p参数的意义在于指定nginx的prefix路径，这样它能正确找到conf和logs目录；workingdirectory用来设置工作目录，对nginx这种对相对路径敏感的程序来说特别重要。

log mode="roll-by-time"是winsw自带的日志滚动策略，我这里设置为按天切割，这样日志文件不会无限膨胀。如果你完全不想让winsw干预日志，也可以使用mode="none"，然后让nginx自己写日志文件。

onfailure节点是winsw的自动重启策略，我配置了两层：第一次失败后10秒重启，第二次失败后20秒重启。这两条规则对于应对瞬时故障非常有效。如果连续多次启动失败，winsw会放弃重启并把状态标记为错误，这样能被监控系统感知到。

serviceaccount指定服务运行身份，使用NT AUTHORITY\LocalSystem是权限最高的本地系统账户。如果是给nginx用，这个账户没有问题，因为你只是需要它监听80或443端口并读取本地文件。如果公司对安全要求严格，可以用一个权限受限的专用账户，然后把nginx目录的读写权限授权给这个账户。

4.3 安装服务及验证

配置写好后，安装过程非常简单。管理员身份打开cmd，切换到exe所在目录，然后执行：

nginx-service.exe install nginx-service.exe start

看到返回 ”Service 'nginx' was installed successfully“ 之类的内容，说明服务已经注册成功了。接着打开任务管理器，切换到“服务”选项卡，你应该能看到nginx服务正在运行，而且进程列表里确实多了一个nginx.exe。

验证自启动策略的时候，可以直接在任务管理器里把nginx进程结束掉，然后盯着服务状态，正常情况下几秒钟之内NSSM或者winsw就会把它自动拉起来。这个验证实验我第一次做的时候还挺兴奋的，因为这就意味着以后nginx挂了，系统真的会自己“满血复活”。

如果你要卸载服务，执行nginx-service.exe uninstall即可。注意，卸载之前最好先停掉服务，否则可能会留下一些残留状态，虽然不影响使用，但看着不舒服。

用winsw这种方式还有一个额外好处，就是你可以把整个nginx目录连同那个XML配置文件打成压缩包备份。换服务器时，解压之后改一下路径，再执行一次install命令，服务就完整迁移过去了，连配置带程序全部搞定，几乎没有学习成本。

5. 常见问题与排查技巧实录

5.1 问题速查表

下面这个表是我在给多台Windows机器部署nginx服务时，真实遇到过的经典问题，我把现象、原因和解决办法一次性整理给你。

5.2 内存占用与配置重载

一个很多人都会忽略的问题：在Windows下运行nginx服务，如果你反复重新加载配置，偶尔会出现内存占用缓慢上升的情况。这通常是因为某些旧连接还在established状态，进程没有及时释放资源。遇到这种情况不用慌，选一个低峰时段重启一次服务即可。

重启服务的命令在前面已经写过了，我在这里再强调一下标准动作：先校验配置，再重启服务。完整的组合命令是这样：

D:\nginx-1.26.2\nginx.exe -t net stop nginx net start nginx

如果你用的是NSSM，可以把中间那两步替换成C:\tools\nssm\nssm.exe restart nginx。实测下来，NSSM的restart命令是先后台停止再启动，整个过程行云流水，比自己去服务管理器里点两下要高效得多。

还有一个关于reload的细节，Windows下nginx -s reload并不是百分百可靠。尤其在服务化运行之后，如果你指定的工作目录前缀不对，执行reload时nginx可能找不到新配置。这就是我前面反复强调工作目录重要的原因。对于Windows环境，我个人更建议直接重启服务，不用纠结于reload这件事。

5.3 日志维护与防磁盘占满

服务跑起来之后，日志会持续增长。如果你没有给nginx配置日志切割，error.log和access.log会越来越大，最后把C盘或D盘塞满。这个问题我在一台长时间运行的文件服务器上遇到过，当时磁盘直接100%，系统卡到几乎无法操作。

如果你的日志输出由NSSM接管，可以通过NSSM的GUI界面设置日志文件大小上限，比如每个日志文件超过5MB就自动滚动。如果日志由nginx自己管理，最简单有效的办法是给nginx.conf里的access_log和error_log加上日期变量，或者使用外部工具做定时切割。Windows任务计划配合PowerShell脚本是一种完全免费且可控的做法，脚本内容也很简单，核心逻辑就是“把当前日志改名备份，然后向nginx发送USR1信号或重启服务”。

这里再分享一个我自己的习惯：无论服务跑得多么稳定，我都会在每个月的固定时间检查一次磁盘空间，顺手清理或者归档一下老的日志。这样看似简单的小习惯，能避免很多“半夜收到磁盘告警”的闹心事。

6. 从注册服务到无人值守运维

把nginx注册为Windows系统服务，本质上是用“操作系统机制”替代“人工干预”。它解决的不仅仅是“开机自启”这一个点，而是建立起一套无人值守的运维基础：进程由SCM统一管理，崩溃后自动拉起，日志有统一出口，启停只需一条命令。这套模式对个人站长、中小企业运维甚至开发环境都适用，部署一次省心很久。

最后分享一个我踩过几次坑之后总结的小经验：修改任何配置之前，先备份一份nginx.conf；执行重启之前，一定先跑一遍nginx -t；服务日志不要放任不管，设置好切割或者定期检查。把这三件事养成习惯，nginx在Windows上跑得稳，你的心态也会稳很多。