Windows服务器部署Node.js项目：Nginx反向代理与进程守护实战

1. 为什么要把Node项目放到Windows服务器上

很多做前端或者全栈的朋友，第一次拿到一台Windows Server的远程桌面时，心里多少有点犯嘀咕：Node.js不是天生跟Linux更亲吗？为什么还要往Windows上部署？我一开始也是这个反应，直到实际接手了几个必须跑在Windows环境里的项目，才慢慢摸清了这套组合的脾气。

先说清楚这个内容到底解决什么问题。你手上有一个用Node.js写的服务，可能是一个Express或Koa的API，也可能是一个Nuxt、Next的服务端渲染应用，甚至是一个内部管理后台。现在需要把它放到一台Windows Server上长期运行，同时希望外面访问的时候走80或443端口，用Nginx做反向代理，把请求转发给Node进程。这套方案适合谁？适合那些服务器环境被限定为Windows、又不想额外折腾容器或者虚拟机的开发者，也适合中小型项目、内部系统、企业内网应用的部署场景。

Windows上跑Node并不是什么异类。Node官方一直提供Windows的安装包，npm、npx这些工具在Windows上都能正常工作。真正让人头疼的不是Node本身，而是进程守护和反向代理这两件事。在Linux上我们有systemd、pm2、supervisor，有现成的Nginx包管理安装；到了Windows，服务怎么开机自启、进程挂了怎么自动拉起、Nginx怎么配置成Windows服务，这些都需要单独处理。这篇内容就是把这几个环节一个个拆开讲透，让你照着做就能跑起来。

我踩过的第一个坑就是以为node app.js跑起来就完事了。结果远程桌面一断开，进程跟着没了；服务器一重启，服务全没了。所以部署的核心不是"能跑"，而是"稳定地、自动地、长期地跑"。围绕这个目标，下面从整体设计、环境准备、Nginx配置、进程守护到问题排查，完整走一遍。

2. 整体部署架构与方案选型思路

2.1 请求链路是怎么走的

先把整条链路在脑子里画清楚，后面每一步才知道自己在干什么。用户从浏览器发起请求，先到达服务器的80端口，这个端口由Nginx监听。Nginx根据配置的规则，把请求转发到本机的某个端口，比如3000，这个端口上跑着我们的Node进程。Node处理完业务逻辑，把响应返回给Nginx，Nginx再返回给用户。

这条链路里，Nginx扮演的是"前台接待"的角色，Node是"后台干活的"。为什么要多这一层？因为Node进程直接监听80端口有几个现实问题：一是Node进程重启的瞬间，80端口会短暂不可用，用户会看到连接失败；二是多个Node应用想共用80端口时没法直接实现；三是静态资源、HTTPS证书、压缩、限流这些事交给Nginx做更省心。反向代理的本质就是让专业的工具干专业的事。

2.2 为什么选Nginx而不是IIS

Windows服务器上自带IIS，很多人会问为什么不直接用IIS做反向代理。IIS确实可以通过ARR（Application Request Routing）模块实现反向代理，但配置起来层级多、概念绕，一个规则要在好几个地方设置。Nginx的配置文件是纯文本，改完nginx -s reload就生效，逻辑一目了然。对于Node项目来说，Nginx的配置心智负担明显更低，社区里的示例也更多，遇到问题好搜。所以除非公司强制要求用IIS，否则我一般首选Nginx。

2.3 进程守护方案怎么选

Node进程在Windows上怎么保证一直活着，这是整个部署里最关键的一环。常见方案有三种，我列个表对比一下。

pm2是Node生态里最成熟的进程管理工具，日志管理、集群模式、监控面板都有，配合pm2-windows-service可以注册成Windows服务，开机自启。nssm是一个通用的"把任意程序包装成Windows服务"的小工具，配置界面简单，适合只跑一个Node进程的场景。任务计划程序虽然也能设置开机启动，但它对进程崩溃后的自动拉起支持不好，生产环境我不建议用。

我个人的选择是：如果项目只有一个Node进程，用nssm足够，配置直观；如果项目有多个Node应用，或者需要看日志、做集群，那就上pm2。下面两套方案我都会讲，你可以按需选。

3. Windows服务器环境准备与Node安装

3.1 系统层面的前置检查

拿到服务器第一件事不是急着装东西，而是确认几个基础条件。打开PowerShell，用管理员身份运行，先看系统版本和端口占用情况。Windows Server 2016及以上都比较稳妥，2012 R2虽然还能用，但部分新版Node对系统库有要求，可能装不上。

# 查看系统版本 systeminfo | findstr /B /C:"OS Name" /C:"OS Version" # 查看80端口是否被占用 netstat -ano | findstr :80 # 查看某个PID对应的进程 tasklist | findstr "PID号"

如果80端口被IIS或者别的程序占了，要么先停掉那个程序，要么给Nginx换个端口。我遇到过一台服务器IIS默认开着，占了80，结果Nginx起不来，排查了半天才发现。所以这一步别省。

3.2 Node.js的安装与版本管理

Node安装本身很简单，去官网下载Windows的msi安装包，一路下一步就行。但有几个细节要注意。安装路径尽量不要带空格和中文，比如C:\nodejs就比C:\Program Files\node js省心，后面配环境变量、写服务路径的时候少很多麻烦。安装时勾选"Add to PATH"，这样在任意目录都能用node命令。

版本选择上，生产环境建议用LTS版本，别追最新的Current版。LTS经过更长时间的验证，稳定性有保障。如果服务器上要跑多个不同Node版本的项目，可以装一个nvm-windows来做版本切换，但要注意nvm切换版本后，之前注册的服务可能指向旧版本路径，需要重新配置。

# 验证安装 node -v npm -v # 如果公司网络访问npm慢，可以换国内镜像源 npm config set registry https://registry.npmmirror.com

装完之后，把项目代码放到一个固定目录，比如C:\apps\my-node-app。然后进入目录安装依赖。这里有个经验：生产环境安装依赖用npm ci而不是npm install，前者严格按照lock文件安装，保证每次部署的依赖版本一致，不会因为某个包偷偷升级导致线上出问题。

cd C:\apps\my-node-app npm ci --production

--production参数会跳过devDependencies，减小体积、加快安装。但如果你的构建步骤需要dev依赖（比如TypeScript编译、前端打包），那就要先完整安装、构建完，再考虑裁剪。

3.3 环境变量与配置文件处理

Node项目通常依赖环境变量来区分开发和生产配置，比如数据库地址、端口号、密钥等。Windows上设置环境变量有两种方式：一种是系统级的环境变量，在"系统属性-高级-环境变量"里加；另一种是用.env文件配合dotenv库。

系统级环境变量的好处是服务启动时能直接读到，缺点是改完要重启服务甚至重启系统才生效，而且所有用户共享，不够隔离。.env文件更灵活，但要注意别把它提交到代码仓库，里面都是敏感信息。我一般生产环境用系统级变量存数据库密码这类核心密钥，用.env存端口、日志级别这类非敏感的配置。

# 在PowerShell里临时设置环境变量（当前会话有效） $env:NODE_ENV="production" $env:PORT="3000" # 设置系统级环境变量（需要管理员权限，永久生效） [System.Environment]::SetEnvironmentVariable("NODE_ENV","production","Machine")

设置完系统级变量后，记得新开一个终端验证，因为已经打开的终端读的还是旧的环境。

4. Nginx在Windows上的安装与反向代理配置

4.1 Nginx的下载与目录结构

Windows版的Nginx是绿色包，下载下来解压就能用，不需要安装。下载地址在Nginx官网，选Windows的稳定版。解压到一个没有空格和中文的路径，比如C:\nginx。解压后的目录结构里，我们主要关心这几个：conf目录放配置文件，logs目录放日志，nginx.exe是主程序。

启动Nginx直接在命令行进到目录执行start nginx，或者双击nginx.exe。启动后用tasklist | findstr nginx能看到两个进程，一个是主进程，一个是工作进程，这是正常的。停止用nginx -s stop（快速停止）或nginx -s quit（优雅停止）。改完配置不用重启，执行nginx -s reload就行。

注意：Windows上Nginx的路径分隔符要用正斜杠/或者双反斜杠\\，单反斜杠会被当成转义字符，配置里写错路径是新手最常见的报错来源。

4.2 反向代理配置逐行拆解

打开conf/nginx.conf，找到http块里面的server块，改成下面这样。我一行行解释为什么这么写。

server { listen 80; server_name localhost; # 访问日志和错误日志 access_log logs/access.log; error_log logs/error.log; location / { proxy_pass http://127.0.0.1:3000; proxy_http_version 1.1; proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection "upgrade"; 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_cache_bypass $http_upgrade; } }

listen 80是Nginx对外监听的端口。server_name填你的域名，没有域名就写localhost或者服务器IP。proxy_pass是核心，把请求转发到本机3000端口的Node进程。

proxy_http_version 1.1和那两个Upgrade、Connection头是为了支持WebSocket。如果你的项目用了WebSocket做实时通信，不加这几行，连接会一直失败。Host头要传原始域名，否则Node里拿到的host是127.0.0.1，生成的回调地址、重定向地址都会错。X-Real-IP和X-Forwarded-For是把用户的真实IP传给Node，不然Node日志里看到的全是127.0.0.1，排查问题的时候抓瞎。X-Forwarded-Proto告诉Node原始请求是http还是https，涉及生成绝对URL的时候很重要。

4.3 静态资源与上传大小的处理

如果Node项目里还负责返回静态文件，或者有文件上传接口，Nginx这边要额外配置。静态资源交给Nginx直接返回，比让Node处理快得多。

# 静态资源缓存 location ~* \.(jpg|jpeg|png|gif|ico|css|js|woff2?)$ { root C:/apps/my-node-app/public; expires 30d; add_header Cache-Control "public, immutable"; } # 上传大小限制，默认只有1M，上传大文件会报413 client_max_body_size 50m;

client_max_body_size这个参数我强烈建议显式设置。Nginx默认限制请求体1MB，用户上传一张大图或者一个附件就会返回413错误，而Node那边根本收不到请求，日志里啥都没有，特别容易误判成前端问题。设成50m或者按业务需要调整。

4.4 把Nginx注册成Windows服务

Nginx本身不会开机自启，每次重启服务器都要手动去点一下，这显然不行。Windows上把Nginx做成服务，最省事的工具是WinSW。下载WinSW的可执行文件，改名为nginx-service.exe，放到Nginx目录，然后写一个同名的xml配置文件。

<service> <id>nginx</id> <name>Nginx Service</name> <description>Nginx reverse proxy service</description> <executable>C:\nginx\nginx.exe</executable> <logpath>C:\nginx\logs</logpath> <logmode>roll</logmode> <depend></depend> <startmode>Automatic</startmode> <stopexecutable>C:\nginx\nginx.exe</stopexecutable> <stoparguments>-s stop</stoparguments> </service>

然后在管理员PowerShell里执行.\nginx-service.exe install，再.\nginx-service.exe start。这样Nginx就变成开机自启的Windows服务了，在"服务"管理器里能看到。卸载用.\nginx-service.exe uninstall。

提示：WinSW的版本要和系统匹配，64位系统用64位版本。另外xml里的路径必须是绝对路径，相对路径服务启动时会找不到。

5. Node进程守护的两种落地方式

5.1 用nssm把Node包装成服务

nssm是个单文件小工具，下载后放到任意目录，在命令行执行nssm install 服务名会弹出一个图形界面。在"Application"标签页里，Path填node.exe的完整路径，比如C:\nodejs\node.exe；Startup directory填项目目录C:\apps\my-node-app；Arguments填入口文件app.js或者server.js。

切到"I/O"标签页，把stdout和stderr重定向到日志文件，这样Node的console输出就能落盘，出问题有据可查。切到"Exit actions"标签页，设置进程退出后自动重启，重启延迟设个几秒，避免疯狂重启刷爆日志。最后点"Install service"，服务就注册好了。

# 命令行方式安装，等价于图形界面操作 nssm install my-node-app "C:\nodejs\node.exe" "app.js" nssm set my-node-app AppDirectory "C:\apps\my-node-app" nssm set my-node-app AppStdout "C:\apps\my-node-app\logs\out.log" nssm set my-node-app AppStderr "C:\apps\my-node-app\logs\err.log" nssm set my-node-app AppExit Default Restart nssm start my-node-app

nssm的好处是配置直观，一个服务对应一个进程，日志清晰。缺点是如果项目有多个进程要管理，就得装多个服务，稍微繁琐。

5.2 用pm2管理Node进程

pm2在Windows上也能用，先全局安装，再装Windows服务支持包。

npm install -g pm2 npm install -g pm2-windows-service

然后用pm2启动应用，并生成开机自启配置。

cd C:\apps\my-node-app pm2 start app.js --name my-node-app pm2 save pm2-windows-service install

pm2 save会把当前进程列表保存下来，下次开机pm2服务启动时会自动拉起这些进程。pm2的常用命令要记牢：pm2 list看进程状态，pm2 logs my-node-app看实时日志，pm2 restart my-node-app重启，pm2 monit看CPU和内存监控。

pm2还支持集群模式，pm2 start app.js -i max会根据CPU核数启动多个实例，充分利用多核。但要注意，集群模式下多个进程共享同一个端口，Node内部会做负载均衡，如果你的应用有内存态数据（比如存在进程内存里的session），集群模式会出问题，得改成外部存储。

5.3 两种方案的取舍经验

我实际用下来，nssm更适合"一个服务一个进程"的简单场景，配置一次就不用管了，日志直接落文件，排查方便。pm2适合需要多进程、需要监控面板、需要频繁重启更新的场景，但pm2-windows-service偶尔会有服务状态和实际进程不一致的情况，需要pm2 resurrect手动恢复。

有个坑要提醒：无论用哪种方案，Node进程的工作目录一定要设对。很多项目用相对路径读配置文件，如果工作目录不对，启动就报找不到文件。nssm里是AppDirectory，pm2里是启动时的当前目录，都要确认指向项目根目录。

6. 常见问题排查与避坑实录

6.1 502 Bad Gateway怎么查

502是反向代理最常见的错误，意思是Nginx连不上后端的Node进程。排查顺序是这样的：先在服务器上netstat -ano | findstr :3000，确认Node确实在监听3000端口。如果没有，说明Node进程没起来或者崩了，去看Node的日志。如果有监听，再在服务器上用curl http://127.0.0.1:3000测试，看Node能不能正常响应。如果本机curl通、通过Nginx访问502，那问题在Nginx配置，检查proxy_pass的地址和端口对不对。

还有一种情况是Node只监听了127.0.0.1，而Nginx配置里写的是服务器公网IP，这样也连不上。Node的listen要么写0.0.0.0监听所有网卡，要么和Nginx的proxy_pass保持一致都用127.0.0.1。

6.2 端口被占用与权限问题

Windows上80端口经常被IIS、SQL Server Reporting Services之类的系统组件占用。用netstat -ano | findstr :80找到占用进程的PID，再用tasklist | findstr PID看是什么程序。如果是IIS且不需要，可以在服务里停掉并设为禁用。如果确实需要保留，就给Nginx换个端口，比如8080，然后在前端或者防火墙层面做转发。

权限问题也常见。Windows服务默认以LocalSystem账户运行，这个账户权限很高，一般不会有文件读写问题。但如果你的服务配置成了某个普通用户账户，那项目目录、日志目录的读写权限要单独授予，否则会出现"能启动但写不了日志"的诡异现象。

6.3 中文乱码与路径问题

Windows的默认编码和Linux不同，Node读文件、输出日志时可能出现中文乱码。解决办法是在启动脚本里设置chcp 65001切换到UTF-8代码页，或者在Node代码里显式指定编码。日志文件如果出现乱码，检查写入时用的编码是不是utf8。

路径问题前面提过，Nginx配置里用正斜杠，Node代码里用path.join拼接路径而不是手写字符串，这样跨平台都不会错。有个细节：Windows路径不区分大小写，但Nginx配置里如果大小写写错，某些情况下会找不到文件，养成和实际目录一致的习惯。

6.4 常见问题速查表

6.5 更新部署的正确姿势

项目要更新代码时，别直接覆盖正在运行的文件，Windows上文件被占用会覆盖失败。正确流程是：先停服务（nssm stop或pm2 stop），拉取或复制新代码，npm ci装依赖，如果有构建步骤就构建，然后启动服务。整个过程写成一个bat脚本，以后更新一键执行，减少手误。

@echo off cd /d C:\apps\my-node-app call nssm stop my-node-app git pull call npm ci --production call nssm start my-node-app echo Deploy finished at %date% %time%

这个脚本里cd /d确保切换盘符和目录，call确保命令顺序执行。实际用的时候把git pull换成你的代码同步方式即可。

7. 性能与安全上的几个加固点

7.1 开启gzip压缩

Nginx开启gzip能显著减小传输体积，对文本类响应效果明显。在http块里加下面配置。

gzip on; gzip_min_length 1k; gzip_comp_level 5; gzip_types text/plain text/css application/json application/javascript text/xml application/xml; gzip_vary on;

gzip_min_length设1k，太小的响应压缩反而增加开销。gzip_comp_level设5是压缩率和CPU消耗的平衡点，设9压缩率提升有限但CPU吃得多。图片、视频这类已经压缩过的格式不用再gzip，所以gzip_types里不包含它们。

7.2 隐藏版本号与限制访问

Nginx默认会在响应头里暴露版本号，给攻击者提供信息。在http块里加server_tokens off;就能隐藏。另外可以限制只允许特定IP访问管理接口，或者对敏感路径加访问认证。

server_tokens off; location /admin/ { allow 192.168.1.0/24; deny all; proxy_pass http://127.0.0.1:3000; }

7.3 日志切割与磁盘管理

Nginx和Node的日志会一直增长，时间长了把磁盘撑满。Windows上没有Linux的logrotate，可以用任务计划程序定期执行一个bat脚本，把旧日志改名归档，然后nginx -s reopen让Nginx重新打开日志文件。Node这边如果用的pm2，可以用pm2-logrotate模块自动切割。

# 安装pm2日志切割模块 pm2 install pm2-logrotate pm2 set pm2-logrotate:max_size 10M pm2 set pm2-logrotate:retain 7

这样单个日志文件超过10M就切割，保留最近7份，磁盘不会被日志吃满。

8. 我在这套方案上踩过的真实坑

说几个文档里不会写、但实际部署时大概率会遇到的坑。第一个是Windows防火墙。Node监听3000端口，Nginx在同一台机器上访问127.0.0.1是不经过防火墙的，所以本机测试没问题。但如果你的架构是Nginx和Node分在两台机器上，那Node所在机器的防火墙必须放行3000端口，否则Nginx那边一直502。这个坑我在分布式部署时踩过，排查了很久才想到是防火墙。

第二个是Node的内存上限。Windows上32位的Node进程默认内存上限比较低，处理大文件或者大数据量时可能崩。用64位Node，必要时启动时加--max-old-space-size=4096把堆内存上限调到4G。但别调太大，超过物理内存反而会频繁触发磁盘交换，性能更差。

第三个是服务启动顺序。如果Nginx服务和Node服务都设成自动启动，开机时可能Nginx先起来、Node还没就绪，导致前几秒的请求502。解决办法是在Nginx配置里加proxy_next_upstream重试，或者给Node服务设置启动延迟，等系统稳定后再启动。WinSW的xml里可以配<delayedAutoStart>true</delayedAutoStart>实现延迟启动。

第四个是路径里的空格。我见过项目目录叫My Node App，结果nssm配置里Arguments没加引号，Node把My当成入口文件，报找不到模块。凡是路径带空格的地方，参数都要用引号包起来，这个细节特别容易被忽略。

最后分享一个我常用的验证清单，每次部署完照着过一遍：浏览器访问域名看是否正常、查看Nginx访问日志有没有请求进来、查看Node日志有没有报错、重启服务器验证服务是否自启、模拟Node崩溃验证是否自动拉起。这五步走完，基本就能确认部署是稳的。后续如果要加HTTPS，在Nginx这层配证书就行，Node完全不用改，这也是反向代理带来的好处之一。