系列文章目录
〔一〕告别Excel困境：保卫部内保系统从0到1实战——在企业内网做开发？为何死磕Windows环境下Django + Waitress + Nginx这套技术栈
〔二〕Windows部署Django避坑指南——从Python安装到HTTPS上线，11步详解

这是Django内保系统企业级开发系列的第三篇，解决服务器重启后Djanog服务无法自动恢复的问题，通过编写启动脚本和配置Windows任务计划，实现Nginx+Waitress开机自启，让服务24小时在线。

📌 写在最前面

你有没有遇到过这样的场景？

• 服务器因为打补丁、电力波动等原因意外重启，你人在外地，远程连不上，网站挂了整整一个周末。
• 每次重启，都要远程桌面进去，手动点两个启动脚本（Nginx一个窗口，Waitress一个窗口），还要担心顺序对不对。
• 领导问“为什么服务又连不上了”，你只能说“等一下，我去开一下服务”。

这根本不是“生产环境”，这是“人工值守环境”。

真正的生产服务，应该是像电波一样——你看不见它，但它24小时在线，永不消逝。

这一篇，我们就来解决这个问题：让Nginx和Django（Waitress）在Windows重启后自动启动，像电波一样持续守护。

01 回顾：前两篇文章我们做了什么？

在进入正题之前，先简单回顾一下前两篇的成果，这样你就能理解为什么第三篇要解决“开机自启”这个问题。

篇章	核心内容	产出	遗留问题
第一章	技术选型：为什么是Django + Waitress + Nginx	确定了整套技术栈	还没开始部署
第二章	手把手部署：从Python安装到HTTPS上线	Nginx和Waitress都能手动启动，网站可访问	重启后服务消失，需要手动重新启动

简单说：前两篇我们让服务“能跑”，但还没让服务“自己跑”。

这一篇，我们就来填这个坑。

02 问题的本质：服务不会自己醒来

目前，我们的系统由两个核心进程组成：

组件	启动方式	问题
Nginx（反向代理+静态文件+HTTPS）	手动执行 start nginx	重启后进程消失
Waitress（WSGI服务器，托管Django）	手动双击 start_prod.bat	重启后进程消失

服务器一旦因为更新补丁、电力波动、硬件维护等原因重启，这两个进程就像断电的收音机——彻底静默。网站自然无法访问。

解决方案： 写一个“总开关”脚本，再让Windows在开机时自动按下这个开关。

这就是本章的两个核心任务：

1. 编写一个统一的启动脚本（一个脚本同时启动Nginx和Waitress）
2. 配置Windows任务计划程序（开机时自动执行这个脚本）

03 核心任务一：写一个“总开关”脚本（.bat文件）

3.1 生产环境启动脚本 start_prod.bat

在项目根目录 D:\JingFuWang 下新建文件 start_prod.bat，内容如下：

@echo off
chcp 65001 > nul
echo ========================================
echo 保卫部内控管理系统 - 生产环境启动
echo ========================================
echo.

REM ----- 1. 启动Nginx（后台运行）-----
cd /d D:\nginx
start nginx.exe
echo [INFO] Nginx已启动

REM ----- 2. 等待3秒，让Nginx完全绑定端口 -----
timeout /t 3 /nobreak > nul

REM ----- 3. 切换到项目目录，激活虚拟环境，启动Waitress -----
cd /d D:\JingFuWang
call venv\Scripts\activate
echo [INFO] 正在启动Waitress服务器...
waitress-serve --threads=8 --listen=127.0.0.1:8000 JingFuWang.wsgi:application

pause

3.2 关键命令解释（为什么这么写？）

命令	作用	如果不这么写会怎样
@echo off	不显示命令本身，只显示输出	屏幕会刷一大堆命令，看起来很乱
chcp 65001 > nul	将命令行代码页改为UTF-8	中文会显示成乱码
cd /d D:\nginx	切换到Nginx目录（支持跨盘符）	找不到nginx.exe，启动失败
start nginx.exe	后台启动Nginx	如果不加start，脚本会卡在Nginx窗口，后面的Waitress不会启动
timeout /t 3 /nobreak	等待3秒	Nginx还没启动完，Waitress就抢端口，可能报错
cd /d D:\JingFuWang	切回项目根目录	后面的venv\Scripts\activate路径不对
call venv\Scripts\activate	激活虚拟环境	不用call的话，activate会“吃掉”后面的命令，Waitress不会启动
waitress-serve …	前台运行Waitress	这样窗口关了就停，适合调试；生产环境可以配合后台工具去掉pause

💡 为什么要等待3秒？ Nginx启动后需要一点时间初始化网络端口（绑定80/443）。如果立刻启动Waitress，有可能因为端口冲突或Nginx未就绪而产生“502 Bad Gateway”。等待3秒是一个“软同步”的小技巧，能大幅提高成功率。

3.3 开发环境启动脚本 start_dev.bat（可选）

开发环境下，我们通常不需要Nginx（或者单独启动），直接用Django自带的runserver更方便。在项目根目录创建 start_dev.bat：

@echo off
chcp 65001 > nul
echo ========================================
echo 保卫部内控管理系统 - 开发环境启动
echo ========================================
echo.

cd /d D:\JingFuWang
call venv\Scripts\activate

echo 正在启动开发服务器...
echo 监听地址: 127.0.0.1:8000
echo 自动重载: 已开启
echo.

python manage.py runserver
pause

3.4 生产环境 vs 开发环境脚本的区别

对比项	生产环境 start_prod.bat	开发环境 start_dev.bat
Web服务器	Nginx + Waitress	Django自带runserver
静态文件	Nginx直接托管，效率高	Django处理，慢但方便调试
HTTPS	Nginx配置证书，支持HTTPS	默认HTTP
代码修改	需要重启Waitress	runserver自动重载
性能	高（多线程+静态缓存）	低（单线程）
使用场景	正式上线、对外服务	本地开发、调试代码

验证： 双击 start_prod.bat，看到Nginx和Waitress都启动成功，浏览器能正常访问 https://你的IP/admin/，脚本就写对了。

04 配置Windows任务计划程序（开机自启核心）

4.1 打开任务计划程序

按 Win + R，输入 taskschd.msc，回车。
![在这里插入图片描述](https://i-blog.csdnimg.cn/direct/8dce6ea493f54fd9a7540846e5962ab8.png

4.2 创建任务

在右侧点击 “创建任务”（不要选“创建基本任务”，那样选项不全）。

4.2.1 “常规”选项卡

设置项	推荐值	说明
名称	DjangoNginxAutoStart	可自定义，建议英文无空格
描述	开机自动启动Nginx和Django应用	便于日后识别
安全选项	不管用户是否登录都要运行	重启后即使没人登录也会启动
勾选	使用最高权限运行	Nginx监听80/443端口需要管理员权限

⚠️ 点击“不管用户是否登录都要运行”后，会要求输入当前Windows管理员密码，正确输入即可。

4.2.2 “触发器”选项卡

点击“新建”：

设置项	推荐值	说明
开始任务	启动时	系统一启动就触发
延迟任务时间	1分钟	系统启动初期网络、磁盘可能未就绪，延迟可提高成功率
状态	已启用	必须勾选

⚠️ 为什么需要延迟？
系统刚启动时，网络服务、磁盘驱动可能还没完全初始化。如果脚本立即运行，可能因为Nginx无法绑定端口、虚拟环境路径未就绪等原因失败。延迟1-2分钟可以显著提高自启成功率。

4.2.3 “操作”选项卡

点击“新建”：

设置项	推荐值	说明
操作	启动程序	固定选择
程序或脚本	D:\JingFuWang\start_prod.bat	浏览选择你的启动脚本
起始于（可选）	D:\JingFuWang 非常重要！	确保脚本中的相对路径能正确找到

🔥 最容易踩的坑：如果忘记填写“起始于”，脚本中的相对路径（比如 venv\Scripts\activate 或 cd /d D:\nginx 中的相对写法）可能因为当前工作目录不是项目根目录而失败。强烈建议填写“起始于”，并且使用绝对路径。

4.2.4“条件”选项卡

取消勾选以下两项（尤其是笔记本用户）：

· “只有在计算机使用交流电源时才启动此任务”（否则笔记本用电池时不会自启）
· 其他选项保持默认

4.2.5“设置”选项卡

设置项	推荐值	说明
允许按需运行任务	勾选	方便手动测试
如果任务失败，按以下频率重新启动	勾选，间隔5分钟，最多3次	容错机制，防止临时失败
其他选项	保持默认	—

点击“确定”保存任务。

05 验证：重启一次，看看“电波”还在不在

5.1 手动测试（不重启）

在任务计划程序库中，找到刚刚创建的任务，右键 → 运行。观察是否正常启动Nginx和Waitress。

打开浏览器访问 https://19.74.8.18/admin/，确认能登录。

5.2 重启服务器测试

1. 重启服务器（或虚拟机）
2. 等待约2分钟（触发器延迟1分钟 + 系统启动时间）
3. 再次访问 https://你的IP/admin/
4. 如果能正常打开，恭喜你——你的Django服务已经成为“永不消逝的电波”了！

5.3 查看任务运行历史

在任务计划程序库中，选中任务，右侧“所选项目” → “历史记录”或“运行结果”，可以查看是否执行成功。如果状态为“0x0”表示成功，其他代码表示失败。

06 常见问题排查（最容易踩的坑汇总）

现象	可能原因	解决方法
任务计划显示“0x1”或“操作失败”	脚本路径错误或权限不足	检查“操作”中的“起始于”是否正确；确认脚本中所有路径都是绝对路径；检查是否勾选了“使用最高权限运行”
Nginx启动成功但Waitress未启动	虚拟环境未激活或Python路径错误	在脚本中先执行 cd /d D:\JingFuWang，再 call venv\Scripts\activate；检查 waitress-serve 命令是否可用（手动执行一次验证）
开机后访问网站502	Waitress启动较慢，Nginx已经转发	增加触发器中的“延迟任务时间”，比如改为2分钟；或在脚本中增加等待时间（timeout /t 10）
任务计划中任务显示“正在运行”但服务没起来	脚本卡在某个命令（如pause）	生产环境脚本中不要写pause，或者将脚本改为后台执行方式
自启动后Cookie/Session丢失	启动时用户环境不同？	自启脚本与手动启动的逻辑完全一致，一般不会。如果遇到，检查Nginx配置中是否包含 proxy_set_header Cookie $http_cookie;
任务计划中触发器显示“已错过”	系统启动时任务计划服务未就绪	增加延迟时间；或者勾选“如果过了计划开始时间，立即启动任务”

07 安全扩展预告（后续会单独成文）

本章聚焦于让服务自动跑起来，没有深入安全配置。但在生产环境中，以下内容同样重要：

· Windows服务器基础安全加固：关闭高危端口（135、139、445）、禁用默认共享、防火墙策略
· Nginx安全配置：隐藏版本号、限制请求方法、防SQL注入/XSS、IP白名单
· Django生产环境安全清单：DEBUG=False、ALLOWED_HOSTS、安全Cookie设置、HTTPS强制跳转

这些内容后续会单独整理成安全部署专题发布，欢迎关注更新。

08 小结与代码切入

这一篇，我们只做了两件事，但解决了生产环境最致命的问题：

任务	做了什么	解决了什么
编写 start_prod.bat	一个脚本同时启动Nginx和Waitress	不用每次开两个窗口，顺序不会乱，不会漏掉服务
配置Windows任务计划	开机自动执行这个脚本	重启后服务自动恢复，无需人工介入，应对补丁更新、电力波动、硬件重启

现在，我们的Django项目已经是一台“永不消逝的电波发射台”了——服务器重启，它自己醒来；你睡觉，它还在线。

知识点	具体内容	关键理解
启动脚本	start_prod.bat / start_dev.bat cd /d	跨盘符、call 激活虚拟环境、start 后台启动
生产vs开发脚本	对比表	生产用Waitress+Nginx，开发用runserver
任务计划程序	常规/触发器/操作/条件/设置	延迟时间、起始于、失败重启是关键
验证方法	手动运行、重启测试、查看历史	确认服务自动恢复

下一章我们将真正进入Django代码模块：好的代码是会“呼吸”的——用4个核心原则，构建优雅如诗的企业级系统架构，让我们一同构建整个系统的权限基石。

📌 欢迎关注，有任何问题可以在评论区交流，我会持续更新实战经验。

连载目录（已发布）：

〔一〕告别Excel困境：保卫部内保系统从0到1实战——在企业内网做开发？为何死磕Windows环境下Django + Waitress + Nginx这套技术栈
〔二〕万字长文：Windows部署Django避坑指南——从Python安装到HTTPS上线，11步详解