写这篇文章之前先说说我自己的经历。我最早接触 NSSM 是在维护一堆老旧 Windows 服务器的时候当时有一批内部工具、Python 脚本和第三方 exe 需要做成开机自启、崩溃自动拉起、后台静默运行的状态。试过计划任务试过 sc create也试过自己封装 Windows API绕了一圈下来最后发现 NSSM 这个工具最省心。它全名叫 Non-Sucking Service Manager直译过来就是“不坑爹的服务管理器”这个名字起得很实在。它能把任意 exe、bat、脚本注册成 Windows 服务几行命令就能搞定不用写一行代码。这篇文章不是官方文档的翻译是我把这些年用 NSSM 部署服务的经验整理了一遍。里面会讲清楚 NSSM 解决了什么问题、怎么用 GUI 和命令行注册服务、日志怎么配置、启动失败怎么排查最后还给了一个用 NSSM 部署 Python 脚本的完整例子。无论你是运维、后端开发还是自己瞎折腾的小白照着做基本都能跑起来。1. 为什么需要 NSSMWindows 服务的核心痛点1.1 普通程序和 Windows 服务的本质区别Windows 服务是一种特殊的进程它跟普通程序最大的区别在于“生命周期托管”。普通程序是你登录电脑之后双击运行的关掉窗口程序就没了注销系统进程就杀掉开机之后还得手动点一次。Windows 服务则不同它由 SCM服务控制管理器统一管理可以在系统启动时自动拉起不需要用户登录运行在独立的会话里而且 SCM 会持续监控服务进程状态进程意外退出时可以按照预设策略自动重启。这种“开机自启 无人值守 崩溃拉起”的特性正是很多后台工具需要的。但问题是Windows 本身只默认提供了一部分现成的服务模板。如果你手上只有一个普通的 exe 程序或者一个维护脚本想让它变成“受托管”的服务系统并没有直接给你一个按钮。这时候就有两种思路要么自己写一个服务包装器用 C/C 或 .NET 写一个符合 SCM 接口规范的 exe在里面拉起子进程要么用现成的第三方工具把普通程序包装成服务。NSSM 属于后者。1.2 常规方案的槽点sc 命令、计划任务和 srvany先泼一盆冷水网上很多教程说的“用 sc create 把程序变成服务”只适用于那些本身是合法服务程序的 exe。sc create 只是往系统注册表里写了一条服务配置它并不改变目标程序的性质。如果你的程序没有实现服务事件处理逻辑比如没有在启动时向 SCM 报告 SERVICE_RUNNING 状态服务管理器会在 30 秒左右判定启动超时然后报错 1053。这就像你让一个完全不懂规章制度的人去窗口办业务流程层面根本不认可卡死在第一步。计划任务Task Scheduler倒是能开机执行程序但它的定位是“任务触发”不是“服务托管”。比如它不会像服务那样提供稳定的重启策略程序崩溃之后计划任务默认就停了它也不在独立的 Session 0 里运行用户在锁屏或注销时可能影响任务执行日志方面更是基本等于没有。所以计划任务适合每天定时跑一次备份脚本不适合常驻后台的服务进程。还有一个历史遗留工具叫 srvany是 Windows Resource Kit 里的老组件也可以把程序包装成服务。但它已经很久没有更新配置方式繁琐对 64 位系统支持差而且程序内部的退出码、日志输出、崩溃处理全都靠你自己写脚本兜底实在不推荐。我当年被 srvany 坑过几次之后转投 NSSM从此再没换过。1.3 NSSM 的方案优势与适用场景NSSM 的核心思路很简单它把一个普通程序当成子进程来管理然后自己扮演“服务进程”的角色。你通过 NSSM 注册服务时系统里注册的 exe 是 nssm.exe 本身而 NSSM 负责在你指定的路径启动目标程序。这样一来目标程序不需要实现任何 Windows 服务的通信协议只要它能在命令行里被正常启动就能被包装成服务。NSSM 把程序的标准输出和标准错误重定向到指定的日志文件崩溃退出时自动重新拉起还支持配置退出动作、环境变量、依赖关系、延迟启动等可以说把“服务化”需要的功能都包圆了。我个人总结下来NSSM 最适合这些场景在 Windows 服务器上部署用 Python、Node.js、Java、Go 写的常驻进程尤其是不想用各自生态里的守护工具时。把内部开发的内部工具 exe 注册成开机自启的后台服务比如消息队列消费者、文件监控脚本、同步程序等。把维护用的 bat 批处理、PowerShell 脚本包装成服务让它们在系统启动后自动运行并记录运行日志。它的安装方式也很讨喜下载下来就是一个独立的 nssm.exe不需要安装不支持 DLL 依赖拷贝到服务器就能用。2. NSSM 快速上手下载安装与两种注册方式2.1 下载版本与初始环境准备去 NSSM 的官方主页nssm.cc下载压缩包就行里面会提供 32 位和 64 位两个版本的 nssm.exe。很多新手第一次就栽在这里在 64 位系统上注册服务时如果误用了 32 位版本的 nssm.exe服务本身也许能注册成功但后续启动某些程序时可能会出现各种诡异问题比如环境变量错乱、文件重定向到 SysWOW64 目录等。我的建议是64 位操作系统的服务器一律拷贝 64 位版本到 C:\Windows\System32 或单独的部署目录避免混用。如果你还不确定当前系统位数直接在命令行输入 echo %PROCESSOR_ARCHITECTURE%输出 AMD64 就是 64 位x86 就是 32 位。接着把 nssm.exe 放到一个固定目录比如 C:\tools\然后把该目录加到系统 PATH 环境变量里或者把 nssm.exe 复制到 C:\Windows\System32 下。这样后续在任意路径下都能直接调用 nssm 命令不用每次写全路径。注意修改 PATH 后要重开一个命令行窗口才会生效。2.2 图形界面注册适合交互式配置NSSM 自带了一个图形配置界面虽然不是很花哨但非常直观。在命令行执行nssm install MyService这里的 MyService 是你想给服务起的名字。执行后会弹出一个窗口包含几个选项卡。在 Application 选项卡里需要填写三样东西Path目标程序的完整路径。可以点右边的按钮选择比如你的 Go 编译出来的 app.exe、Python 的 python.exe 等。Startup directory工作目录通常指程序运行时要读取配置文件的目录。这里有个坑很多人不填结果程序启动时报“找不到配置文件”因为工作目录默认继承的是系统目录不是 exe 所在目录。Arguments启动参数。比如你想运行python D:\script\server.pyPath 填C:\Python39\python.exeArguments 填D:\script\server.py而不是把整个命令行都塞进 Path。填完之后可以切换到 Process 选项卡设置退出动作。我一般会把 Exit action 设为Restart崩溃或退出后自动重启。I/O 选项卡则用来配置日志输出把 stdout 和 stderr 重定向到文件下面会详细讲。配置好之后点 Install service 按钮服务就创建成功了。之后可以用命令 nssm start MyService 启动它。GUI 方式的好处是每一项配置都有说明和备选值适合刚开始接触、想看清楚有哪些选项的读者。缺点是不能自动化所以生产环境我更推荐命令行方式。2.3 命令行注册一条命令完成部署命令行方式才是 NSSM 的“正确打开方式”。注册一个服务的基本格式是nssm install 服务名 程序路径 [参数...]比如我要把 D:\tools\agent.exe 注册成服务执行nssm install MyAgent D:\tools\agent.exe如果目标程序需要参数直接跟在后面nssm install MyAgent D:\tools\agent.exe --config production.yaml这种方式注册出来的服务默认会使用目标 exe 所在的目录作为工作目录退出行为默认是 Exit退出后不重启日志默认不记录。要调整这些配置得借助 nssm set 命令。比如设置工作目录nssm set MyAgent AppDirectory D:\tools设置服务失败后自动重启nssm set MyAgent AppExit Default Restart设置自动启动nssm set MyAgent Start SERVICE_AUTO_START如果只是临时测试可以设成 SERVICE_DEMAND_START手动启动。常见的 Start 值还有 SERVICE_DISABLED用于禁用服务。对于批量部署我习惯写一个部署脚本把 nssm install 和 nssm set 串在一起。比如注册一个 Python 服务nssm install PyService C:\Python39\python.exe D:\code\server.py nssm set PyService AppDirectory D:\code nssm set PyService AppStdout D:\logs\pyservice.log nssm set PyService AppStderr D:\logs\pyservice_err.log nssm set PyService AppRotateFiles 1 nssm set PyService AppRotateBytes 10485760 nssm set PyService Start SERVICE_AUTO_START nssm start PyService这几行配置里AppStdout 和 AppStderr 指定了日志输出文件AppRotateFiles 开启日志轮转AppRotateBytes 设置了超过 10MB 就自动切分。整套流程下来一个开机自启、自动重启、带日志切分的服务就落地了全程不超过一分钟。3. 服务管理、日志配置与进阶玩法3.1 服务的启停、删除与状态查询服务注册好之后日常管理经常用到的几个命令如下nssm start 服务名 nssm stop 服务名 nssm restart 服务名 nssm status 服务名 nssm remove 服务名执行 nssm remove 时默认会弹窗确认如果希望静默删除加 confirm 参数nssm remove 服务名 confirm注意删除前最好先停止服务避免文件被服务进程占用导致 nssm.exe 或目标程序文件删除失败。另外如果你想修改服务参数可以再执行一次 nssm edit 服务名会重新打开 GUI 界面或者继续用 nssm set 修改单个参数。这里提醒一句服务名里尽量不要带空格或特殊字符尤其是从命令行安装时空格会导致 SCM 注册的服务名不完整。不同 NSSM 版本在 handle 空格时的行为略有差异但加引号的规则是一致的路径含空格就用引号包起来。3.2 日志输出与按大小轮转避免日志无限膨胀NSSM 对日志的处理是比较完善的一块值得单独拿出来讲。默认情况下程序的标准输出stdout和标准错误stderr不会记录到任何文件这在调试服务问题时是灾难性的因为服务运行在后台出错时你根本看不到控制台。所以强烈建议注册服务时顺手配置日志AppStdout标准输出重定向路径比如 D:\logs\service.log。AppStderr标准错误重定向路径可以单独指向另一个文件方便区分错误和正常信息。如果程序本身会写日志文件比如使用 Python logging 模块那 AppStdout 可以不配置但如果程序有未捕获异常traceback 会打到 stderrAppStderr 还是建议留着。日志轮转这块NSSM 提供了两个关键参数AppRotateFiles 和 AppRotateBytes。AppRotateFiles 置 1 表示启用轮转AppRotateBytes 设置触发轮转的字节数。比如设置 1048576010MB当日志文件达到这个大小NSSM 会将当前日志改名为 service-20250101-143000.log 之类的带时间戳文件再新建 service.log 继续写。如果你的程序长期运行且输出量大强烈建议开启轮转否则磁盘会被日志文件塞满。我见过一台服务器因为 Python 脚本每秒钟打印一行状态结果 3 天时间把整个 C 盘写满服务直接就崩了。3.3 退出动作、环境变量与启动依赖配置NSSM 的 AppExit 参数控制服务退出后的行为。比如目标程序正常退出退出码 0时希望服务自动重启设置为nssm set MyService AppExit Default Restart目标程序遇到特定退出码时执行不同动作比如退出码 3 时关机退出码 4 时重启电脑。Default表示对所有未单独声明的退出码生效。如果是 SQL Server 或某些需要先启动的服务可以设置服务依赖nssm set MyService DependOnService MSSQLSERVER这样系统会确保 MSSQLSERVER 先启动再启动你的服务。多依赖用\0分隔命令行里写起来有点绕一般我只在 GUI 里设置多个依赖。环境变量方面如果目标程序需要特定的环境变量不要只在系统设置里改因为服务在 Session 0 中运行用户环境变量对服务进程不生效。建议用 nssm set 设置一个独立的配置nssm set MyService AppEnvironmentExtra MY_CONFIG_PATHD:\config API_KEYxxxxNSSM 支持多条环境变量每条用引号包住。这种设计的好处是环境变量的作用域只针对这个服务不会污染全局环境非常利于多服务隔离。3.4 实战案例用 NSSM 把 Python 脚本部署成后台服务在 Windows 服务器上部署 Python 脚本最容易踩的坑就是“关掉命令行服务就没了”。用 NSSM 就能彻底解决这个问题。假设我现在有一个 Flask 服务代码在 D:\code\webapp启动命令是python app.py --port8080需要开机自启和自动重启。注册命令如下nssm install WebApp C:\Python39\python.exe D:\code\webapp\app.py --port8080 nssm set WebApp AppDirectory D:\code\webapp nssm set WebApp AppStdout D:\logs\webapp.log nssm set WebApp AppStderr D:\logs\webapp_err.log nssm set WebApp AppRotateFiles 1 nssm set WebApp AppRotateBytes 10485760 nssm set WebApp AppExit Default Restart nssm set WebApp Start SERVICE_AUTO_START nssm start WebApp这里重点解释两个细节。第一AppDirectory 一定要设置为代码所在目录。因为 Flask 通常要读取 templates、static 等相对路径资源如果工作目录是系统目录程序会报模板找不到。第二如果 Python 脚本依赖某个虚拟环境Path 不要填 python.exe而是填虚拟环境里的 python.exe比如C:\venv\app\Scripts\python.exe。因为服务进程不会加载用户安装的全局包直接指定虚拟环境解释器最干净。部署完成后可以用 nssm status WebApp 查看是否处于 SERVICE_RUNNING 状态。如果进程立刻退出大概率是代码本身报错了先看日志文件。有了日志调试起来就方便得多。4. 常见问题与排查技巧实录4.1 初始化安装时发生异常x64/x86 不匹配问题很多网友反馈注册服务时弹出“初始化安装时发生异常”或者服务安装成功后启动时报“配置了 x64 版本但初始化失败”之类的错误。这类问题十有八九是 NSSM 版本和目标程序位数不一致导致的。具体来说如果你把一个 32 位程序包装成服务理论上用 32 位 NSSM 是正解但如果你在 64 位系统上用 32 位 nssm.exe 注册然后目标程序是 64 位 exe系统在服务环境初始化时就会发生兼容性异常。解决方法很粗暴统一使用 64 位 NSSM 管理 64 位程序32 位程序则单独放到 x86 路径下用 32 位 NSSM 注册。不要图省事混着用。另外如果目标程序是一个 bat 脚本注意 NSSM 默认会用 CreateProcess 直接执行bat 文件在服务环境下容易被安全软件拦截最简单的办法是把 bat 交给 cmd.exe 处理Path 填C:\Windows\System32\cmd.exeArguments 填/c D:\script\run.bat。4.2 服务启动后立刻退出或提示 1053 / 1058 错误错误 1053服务没有及时响应启动请求是 NSSM 新手遇到最多的错误之一。原因通常是注册服务时Path 填成了一个不存在的文件或者填了没有权限访问的路径。NSSM 启动目标程序时如果失败会向 SCM 返回启动失败SCM 就报 1053。解决办法是先用命令行手动运行一下 Path Arguments确认命令能正常跑起来。错误 1058服务被禁用则是服务启动类型被设为 Disabled或者在组策略里禁用了相关服务。这种情况运行nssm set 服务名 Start SERVICE_AUTO_START就能解决。还有一种隐蔽情况服务依赖的服务没有启动。例如你在 DependOnService 里写了某个不存在的服务SCM 会一直等待依赖项最终导致超时报错。排查时可以用sc queryex 服务名查看依赖关系是否正常。4.3 日志没输出或者日志时间戳不对如果你配置了 AppStdout 但文件里没有内容先确认程序是否真的往标准输出打印了信息。有些程序自带日志框架比如 Java 的 logback、Python 的 logging这些日志是程序内部直接写到文件里跟 NSSM 的重定向没关系。这种情况下AppStdout 没有内容反而是正常的。你可以故意在代码里 print 一行测试再重启服务看有没有输出。另一个细节是NSSM 默认用系统时区记录日志切分后的时间戳。如果服务器时区设置不对切分出来的日志文件名会“晚”或“早”几个小时。这不算 bug但如果你要做日志归档最好把系统时区固定为 UTC8 或 UTC并在命名规则里加上时区标识。4.4 用户注销或锁屏后服务就停了很多人在本机调试时发现锁屏之后服务就好像挂了。这通常不是服务本身停了而是程序可能依赖了用户会话资源。比如某些 GUI 程序在 Session 0 中无法显示窗口就主动退出了。NSSM 默认允许程序“与桌面交互”但现代 Windows 系统里服务在 Session 0 中运行界面是隐藏的任何依赖可见窗口的程序都会出现问题。解决方案是不要用 NSSM 包装需要图形界面的程序如果非用不可可以考虑把程序改成命令行模式或者用独立进程方式调用。还有一点容易被忽略如果服务是“手动启动”用户注销后服务保持运行状态这本身是正常的但如果服务配置了“在登录时启动”请确认启动类型到底是 SERVICE_AUTO_START 还是 SERVICE_DEMAND_START。很多教程里说“开机自启”就是指 SERVICE_AUTO_START不要混。4.5 常见问题排查速查表现象大概率原因处理建议服务无法启动报 1053目标程序路径不对或程序本身启动失败手动运行命令验证检查 Path / Arguments服务启动后立刻停止目标进程秒退或退出码非 0配置 AppStdout / AppStderr 查日志服务启动类型是禁用Start 参数未设置设为 SERVICE_AUTO_START日志目录没有文件输出到了 stderr或程序自带日志同时配置 AppStdout 和 AppStderr32 位/64 位不匹配NSSM 版本与目标程序位数不一致换对应位数 NSSM 重新注册注销后服务退出程序依赖交互桌面改为无界面模式或不用 NSSM开机不自启注册时 Start 为手动执行 nssm set 服务名 Start SERVICE_AUTO_START我自己在实际部署里还经常遇到一个问题改了代码重启服务后程序还是旧版本。这通常是因为 Python 或 Node.js 有缓存机制服务重启后加载了旧的 pyc 文件或 require 缓存。解决办法是服务停止后把__pycache__目录删掉或者用nssm restart 服务名重启两次。有点土但确实有效。4.6 另外分享两个提升效率的小技巧第一个是用 NSSM 管理多个服务时可以写一个批量脚本统一管理启停顺序。比如当前有两三个服务之间有启动依赖先在 bat 里按顺序执行 nssm start 服务A、服务B、服务C中间用 timeout 命令隔几秒比在服务管理器里一个个点要方便得多。第二个是备份服务配置。NSSM 的服务配置存放在注册表HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\服务名下但直接改注册表风险大。更安全的方式是写一份部署 bat把 nssm set 系列命令留存下来换机器时直接跑一遍就能恢复服务。我一直习惯在项目的 deploy 目录下放一个install_service.bat作用跟 docker-compose.yml 类似服务器重装后三分钟就能把服务全部拉起来。NSSM 这个工具我用到现在最深刻的体会是它的设计哲学就是“把运维的重复劳动压缩到最少”。注册服务、设置日志、配置重启策略这些在原生 Windows 工具链里要折腾半小时的活NSSM 几条命令就完成了。最后还是那句老话生产环境服务一定要开日志、一定要配自动重启、一定要在部署脚本里留好回滚方案。NSSM 能做的是把程序“变成”服务但真正让服务稳定跑下去的还是我们部署时多想一步的那些细节。
