NSSM 注册 Windows 服务：日志重定向与自动重启

微软专家

在 Windows 上把普通程序做成常驻服务，系统自带的 sc.exe 往往不是合适工具：它主要面向原生 Windows 服务程序，对普通 EXE、批处理或 Python/Node 脚本支持有限，日志重定向和崩溃重启也需要额外配置。srvany 虽然能包装普通程序，但需要手工改注册表，而且程序退出后服务状态可能仍显示为运行中。NSSM（Non-Sucking Service Manager）就是针对这类问题出现的服务包装器，本文按实际部署流程梳理它的能力、命令和注意事项。

NSSM 的定位与版本

NSSM 是一个约 300KB 的单文件工具，官网为 nssm.cc，绿色免安装，32/64 位均可使用。它最后稳定版本为 2.24（2014 年），但至今仍被广泛使用。作者在官网说明中提到，srvany 等工具的问题在于不处理以服务方式运行的应用程序的失败：程序已经退出，服务却可能仍显示为已启动。NSSM 会监控运行中的服务，在进程死亡后将其重启，因此服务状态更可信。

从历史背景看，微软在 2003 Resource Kit 之后没有再更新 srvany，官方一直没有补上“把普通程序包装成可监控服务”这块空缺，而 NSSM 免费、单文件、无依赖，因此即使正式版停在 2014 年仍被大量项目采用。

核心能力与适用场景

NSSM 支持把任意可执行文件注册为服务，包括 .exe、.bat、.cmd、Python 脚本、Java JAR、Node.js 应用等。它提供自动重启能力，程序崩溃后可自动重启，并可配置重启延迟，这是 sc.exe 和 srvany 不具备的。它还能把 stdout/stderr 重定向到文件，并支持日志文件轮转，方便排查问题。工具同时提供 GUI 和命令行两种模式：nssm install <服务名> 打开图形化配置界面，也支持纯命令行操作，适合自动化脚本。服务可设置专属环境变量，nssm.exe 本身无需安装。

与同类方案相比，取舍比较清楚：sc.exe 是系统内置，但只能注册原生 Windows 服务程序，普通 EXE/脚本无法直接注册，参数配置复杂，日志重定向和自动重启不足；srvany 需要手动编辑注册表，配置繁琐且容易出错，不支持自动重启和日志管理；WinSW 通过 XML 文件配置，适合需要版本控制的场景（如 CI/CD），但配置不如 NSSM 直观，且需要 .NET 运行时环境。NSSM 更轻量，更适合快速部署。

常用命令速查

安装服务（GUI）：nssm install [<servicename>]
静默安装：nssm install <servicename> <app> [<args> ...]
编辑服务：nssm edit <servicename>
查询参数：nssm get <servicename> <parameter> [<subparameter>]
设置参数：nssm set <servicename> <parameter> [<subparameter>] <value>
重置参数：nssm reset <servicename> <parameter> [<subparameter>]
移除服务（GUI）：nssm remove [<servicename>]
静默移除：nssm remove <servicename> confirm
服务管理：nssm start/stop/restart/status <servicename>
日志轮转：nssm rotate <servicename>

示例：把 Python 静态服务器注册成服务

先准备 webroot 目录和 index.html，再创建 log 目录以及两个空日志文件。示例中的 index.html 内容为：

2. <h1> hello nssm </h1>
3. <p> website run as windows services. </p>

复制代码

然后用 PowerShell 获取 Python 的实际路径：

2. (Get-Command python).Source

复制代码

原文中查询结果为 C:\Python311\python.exe，而安装命令里写的是 C:\Python313\python.exe，实际执行时应以 Get-Command 输出为准，避免路径不一致。命令行安装与日志配置如下：

2. nssm install demo-http C:\Python311\python.exe "-m http.server 8899"
3. nssm set demo-http AppDirectory D:\linxingyang\workspace\2026-10-21-nssm-example\webroot
4. nssm set demo-http AppStdout D:\linxingyang\workspace\2026-10-21-nssm-example\log\access.log
5. nssm set demo-http AppStderr D:\linxingyang\workspace\2026-10-21-nssm-example\log\error.log

复制代码

这里设置 AppDirectory 是为了让程序以 webroot 为工作目录运行，否则静态文件可能按其他目录解析；AppStdout 和 AppStderr 分别接收正常输出和异常输出。

如果使用 GUI，执行 nssm install demo-http 打开安装界面。在 Application 标签页填入 python.exe 路径、webroot 目录和启动参数 -m http.server 8899；在 I/O 标签页填入 Output 和 Error 对应的日志路径；最后点击 Install service。

安装完成后启动并查看状态：

2. nssm start demo-http
3. nssm status demo-http

复制代码

随后浏览器访问对应端口即可验证服务是否正常。需要删除时，先停止再静默移除：

2. nssm stop demo-http
3. nssm remove demo-http confirm

复制代码

落地时的注意事项

服务名需要自行指定并保持唯一，安装前先确认没有同名服务。日志文件所在目录要提前创建，否则重定向可能失败；路径中包含空格时，参数要用引号包裹。修改服务配置后，通常需要 restart 服务才会按新配置运行。NSSM 的日志轮转可以通过 nssm rotate <servicename> 切换日志文件，适合长期运行的服务控制单个日志体积。如果程序本身依赖特定工作目录、环境变量或端口，应在上线前分别通过 AppDirectory、环境变量配置和端口检查确认。

整体来看，NSSM 解决的是“普通程序如何以可监控、可重启、可留日志的方式常驻 Windows”这一实际问题。它不适合替代所有原生服务开发，但在脚本、Python/Node 应用、批处理任务快速服务化方面，比手工配置 srvany 或只用 sc.exe 更直接。若团队需要把服务配置纳入版本控制，可以评估 WinSW；若程序本身就是原生 Windows 服务，则继续使用 sc.exe 即可。

热心网友4

感谢分享，这篇整理得很实用，尤其是把 NSSM 和 sc.exe、srvany、WinSW 的取舍讲清楚了。之前用 srvany 就遇到过进程挂了但服务状态还显示运行中的情况，确实容易误判。 几个点印象比较深：一是 AppDirectory 的设置，这个细节很容易被忽略，不设的话 Python 起静态服务器会按别的目录找文件，排查起来挺费劲；二是日志重定向和 rotate 的组合，长期跑的话确实需要，不然日志文件会一直涨；三是命令速查那张表，静默安装和静默移除的写法直接能抄来用，省得每次翻文档。 另外看到楼主提到“可配置重启延迟”，但后面的命令和示例里没展开，不知道是在 GUI 的哪个标签页里配，还是用 set 命令改某个参数？这块如果能补一句就更完整了。还有帖子最后“适合长期”后面好像被截断了，不知道是不是日志轮转那部分没发完。 总之按这个流程走下来，把普通 EXE 或脚本做成服务并带日志和自动重启，基本够用了。NSSM 虽然版本停在 2.24，但胜在单文件无依赖，临时部署和脚本化安装都很顺手。

热心网友5

感谢分享，这篇把 NSSM 的定位和实际部署流程讲得挺清楚，尤其是“查询结果和安装命令里路径不一致要以实际输出为准”这个提醒，很多人就是照着教程复制粘贴踩坑的。 补充几点我自己用下来的体会： 一是服务默认以 LocalSystem 账户运行，如果程序依赖当前用户的环境变量、用户目录下的配置，或者要访问网络共享，可能会找不到东西，这时候可以用 nssm set 服务名 ObjectName 指定运行账户，比在那里猜半天强。 二是日志目录除了要提前建好，还得确认服务运行账户对目录有写权限，LocalSystem 一般没问题，换成普通账户后经常卡在这里。 三是日志轮转虽然方便，但如果程序一直占着日志文件句柄，轮转行为要留意一下，最好配合定期清理或者用日志收集工具，不然长时间跑还是会堆很大。 四是 GUI 和命令行混着用没问题，但线上部署建议把安装和 set 参数写成脚本留档，后面迁移机器或者重建服务直接跑一遍，比回忆当时点了哪些选项靠谱。 另外楼主的正文最后好像被截断了，“适合长期”后面没接上，不知道是不是还有一段没发出来。整体内容很实用，收藏了。

热心网友1

感谢整理，流程和命令讲得很清楚，尤其是路径那个坑提醒得对，示例里 311 和 313 不一致确实容易照抄出错，用 (Get-Command python).Source 取值最稳妥。 补充几个实际部署时踩过的点，供后面的人参考： 一是 Python 的输出缓冲。直接把 python -m http.server 的 stdout 重定向到 AppStdout，日志可能长时间是空的，因为非终端环境下 stdout 是块缓冲。加 -u 参数，或者设环境变量 PYTHONUNBUFFERED=1（nssm set 服务名 AppEnvironmentExtra PYTHONUNBUFFERED=1），日志才能实时落盘。 二是日志会无限增长。设了 AppStdout/AppStderr 之后默认不轮转，长期跑很容易把磁盘吃满。除了手动 nssm rotate，可以配 AppRotateFiles 1、AppRotateOnline 1、AppRotateBytes 之类的参数，让 NSSM 按大小自己切。 三是崩溃重启的行为可调。默认进程退出就拉起，如果程序本身启动即崩（比如工作目录或参数写错），会变成高频重启刷日志。用 AppThrottle 设重启间隔，用 AppExit 按退出码配置 Restart/Ignore/Exit，会稳很多。 四是权限差异。默认以 LocalSystem 运