简介：这份资源面向需要在Windows环境下管理多台设备的IT运维人员与Python学习者，提供一套自动远程批量关机的脚本方案，解决逐台手动关机效率低、易遗漏的问题。压缩包共3个文件，包含1个py脚本与2个txt说明文档，整体仅923B，轻量易取，脚本可直接参考或改造使用。内容围绕WMI远程管理展开，涉及通过win32com.client建立远程连接、调用Win32_ComputerSystem的Shutdown方法执行软关机或强制关机，并以IP列表遍历实现批量下发命令，同时提示管理员权限、目标机远程管理策略配置以及用户名密码的安全存放方式。已有897人学习下载，适合希望快速掌握远程批量关机思路、并在此基础上扩展重试与超时等健壮性处理的读者参考借鉴。
1. 机房巡检收尾那点事：为什么我最终选了 Python 批量远程关机
凌晨一点半，实验室的灯还亮着，三十多台 Windows 工作站跑完最后一轮渲染任务，风扇声像一群不肯落地的直升机。手动一台台点“开始→关机→确定”，点到最后手都麻了，还漏了两台，第二天被导师问“昨晚那几台怎么还开着”。这就是我最初折腾批量远程关机的真实动机——不是炫技，是实在受不了重复劳动。
这份资源要解决的核心问题很具体：在 Windows 环境下，用 Python 脚本对局域网内多台 Windows 主机发起自动、批量的远程关机。它适合谁？适合手里管着几台到几十台 Windows 机器、又不想逐台登录操作的人——实验室管理员、测试机维护者、小型机房值守人员。关键词里的“自动”“远程关机”“批量关机”“windows”“python”五个词，基本就是它的全部能力边界。下面我按“先跑通一台，再扩到一批，最后处理翻车”的顺序拆开讲。
2. 远程关机的底层通道：WMI、RPC 与 shutdown 命令怎么选
2.1 三条常见技术路线对比
Windows 上让另一台机器关机，绕不开三个东西：shutdown命令、WMI（Windows Management Instrumentation）、以及基于 RPC 的远程调用。它们不是并列关系，而是层层包裹——shutdown /m底层走的就是 RPC，WMI 也能调Win32_OperatingSystem的Shutdown方法。
| 路线 | 调用方式 | 依赖服务 | 适用场景 | 主要限制 |
|---|---|---|---|---|
| shutdown 命令 | shutdown /s /m \\目标IP | RPC、Remote Registry | 快速脚本、临时操作 | 报错信息模糊，权限要求高 |
| WMI | wmic /node:IP或 Pythonwmi库 | WMI 服务、DCOM | 需要读取状态再关机 | 配置复杂，防火墙端口多 |
| PsExec 类工具 | 远程执行进程 | Admin$ 共享、SMB | 需要执行任意命令 | 需额外工具，易被杀软拦截 |
我一般优先用shutdown命令，因为它最轻，不需要额外装库，Python 里一个subprocess就能调。但它的坑也最多，后面避坑章节会细说。
2.2 为什么用 Python 而不是批处理
批处理也能写for循环调shutdown，但一旦要处理“哪些机器在线”“失败重试”“记录日志”“并发控制”，bat 就力不从心了。Python 的优势在于：可以用concurrent.futures做并发，用subprocess拿返回码，用logging落日志，用ipaddress生成网段。这些在几十台机器的场景下不是锦上添花，是刚需——串行关机等一台超时 30 秒，三十台就是十五分钟。
2.3 前置条件：目标机器必须打开什么
远程关机不是发个包就完事，目标 Windows 主机必须满足几个条件，缺一个就报“拒绝访问”：
- Remote Registry 服务：默认手动启动，远程 RPC 调用需要它。设为自动并启动。
- 防火墙规则：入站放行“Windows Management Instrumentation (WMI)”和“Remote Service Management”相关规则，或者临时关闭域内防火墙测试。
- 账号权限：发起端使用的账号必须是目标机的管理员组成员，且目标机不能是空密码账号（Windows 默认禁止空密码远程登录）。
- 网络发现：同一网段或路由可达，能 ping 通是基本前提。
这些条件在域环境里通常由组策略统一配好，但在工作组环境（比如实验室临时搭的机器）里，得一台台确认。我习惯先拿一台当“小白鼠”，跑通了再批量。
import subprocess def shutdown_one(ip, timeout=10): """ 对单台 Windows 主机发起远程关机 :param ip: 目标主机 IP :param timeout: 子进程超时秒数，防止卡死 :return: (ip, 是否成功, 返回信息) """ cmd = f'shutdown /s /t 0 /m \\\\{ip} /f' try: # capture_output 捕获 stdout/stderr，text 让输出为字符串 result = subprocess.run( cmd, shell=True, capture_output=True, text=True, timeout=timeout ) if result.returncode == 0: return ip, True, "关机指令已发送" else: return ip, False, result.stderr.strip() or result.stdout.strip() except subprocess.TimeoutExpired: return ip, False, "超时，目标无响应"这段代码是整套脚本的最小单元。shutdown /s表示关机，/t 0表示立即执行（延迟 0 秒），/m \\IP指定远程目标，/f强制关闭正在运行的程序——不加/f时，如果有未保存的文档，目标机会弹窗等待，远程场景下没人点确认，就会一直挂着。timeout参数是血泪经验：网络不通时shutdown命令可能卡很久，不设超时整个批量任务会被一台机器拖死。
提示：
/t 0和/f组合会直接丢弃未保存内容，生产环境慎用，测试机随意。
3. 从单台到批量：IP 列表、并发与日志三件套
3.1 IP 来源：文件读取还是网段扫描
批量关机的第一步是拿到目标列表。常见做法有两种：一是维护一个hosts.txt，每行一个 IP；二是给一个网段，先 ping 扫描再关机。前者可控，后者省事但容易误伤。
我一般用文件方式，因为“哪些机器该关”是个业务判断，不该交给脚本猜。文件格式就一行一个 IP，允许#开头注释：
# 渲染组 192.168.1.101 192.168.1.102 # 测试组 192.168.1.201读取时过滤空行和注释，顺便去重：
def load_targets(path): """从文本文件加载 IP 列表，忽略空行和 # 注释""" targets = [] with open(path, "r", encoding="utf-8") as f: for line in f: line = line.strip() if not line or line.startswith("#"): continue targets.append(line) # 去重但保持顺序 return list(dict.fromkeys(targets))dict.fromkeys是去重的常用技巧，比set好的地方是保留原始顺序，日志读起来符合直觉。
3.2 并发控制：线程池不是越多越好
三十台机器串行关机，每台哪怕只花 2 秒，也要一分钟。用线程池并发，能把时间压到几秒。但线程数不是越大越好——shutdown命令本身会创建进程，线程太多反而抢资源，而且目标机可能扛不住同时涌入的连接。
from concurrent.futures import ThreadPoolExecutor, as_completed def shutdown_batch(targets, max_workers=8): """并发批量关机，max_workers 控制同时发起的关机数""" results = [] with ThreadPoolExecutor(max_workers=max_workers) as executor: future_map = { executor.submit(shutdown_one, ip): ip for ip in targets } for future in as_completed(future_map): ip = future_map[future] try: results.append(future.result()) except Exception as e: results.append((ip, False, f"异常: {e}")) return resultsmax_workers=8是我在几十台规模下比较稳的值。机器少可以调到 4，上百台可以到 16，但再高收益递减，还容易触发目标机的连接限制。as_completed保证谁先返回先处理谁，不会因为某台慢而阻塞日志输出。
3.3 日志与结果核对：别关完就完事
批量操作最怕“以为都关了，其实有几台没关”。所以每次执行都要落日志，记录时间、IP、成功与否、失败原因。日志用标准logging模块，同时输出到控制台和文件：
import logging def setup_logger(log_file="shutdown.log"): logger = logging.getLogger("batch_shutdown") logger.setLevel(logging.INFO) fmt = logging.Formatter("%(asctime)s [%(levelname)s] %(message)s") # 文件处理器，追加模式 fh = logging.FileHandler(log_file, encoding="utf-8") fh.setFormatter(fmt) # 控制台处理器 ch = logging.StreamHandler() ch.setFormatter(fmt) logger.addHandler(fh) logger.addHandler(ch) return logger执行完打印一个汇总表，成功多少、失败多少、失败的是哪些 IP。失败列表可以直接复制出来，排查后重跑——脚本要支持“只对失败的重试”，而不是每次全量重来。
注意：日志文件别放在会被关机影响的机器上，发起端自己别被关进去。
4. 避坑与排查：远程关机最常见的五类翻车
4.1 现象：提示“拒绝访问(5)”
原因：发起端账号不是目标机管理员，或目标机禁用了空密码远程登录，或 Remote Registry 服务没启动。
解决：确认账号在目标机Administrators组；用net use \\IP\IPC$ /user:管理员账号先建立凭据会话再关机；检查组策略“账户：使用空密码的本地账户只允许进行控制台登录”是否被启用。
4.2 现象：命令返回成功，但机器没关
原因：shutdown返回 0 只代表指令送达，不代表目标机执行了。目标机可能因为有待保存文档、有程序阻止关机、或电源策略拦截。
解决：加/f强制关闭；如果仍不关，去目标机事件查看器看“系统”日志里User32或Kernel-Power的记录；确认目标机没有处于“演示模式”或接了不允许关机的策略。
4.3 现象：部分机器超时，脚本卡住
原因：网络不通或目标机防火墙拦截，shutdown命令在等 RPC 响应。
解决：subprocess.run必须带timeout；批量前先并发 ping 一轮，把不在线的剔掉，减少无效等待。
4.4 现象：关机后无法再次远程唤醒
原因：这是关机不是重启，Wake-on-LAN 需要网卡和主板支持，且关机后网卡仍供电。
解决：如果后续要远程开机，关机前确认目标机 BIOS 和网卡驱动开启了 WOL；否则只能现场开机。这个坑我在实验室踩过，关得爽，第二天全员现场按电源键。
4.5 现象：杀软或安全软件拦截 shutdown 调用
原因：部分终端防护会把远程shutdown当成可疑行为。
解决：在目标机安全软件里把发起端 IP 或shutdown.exe加入白名单；或者改用 WMI 方式，但 WMI 同样可能被拦。没有银弹，只能按环境调。
5. 进阶：把关机做成可调度、可回滚的例行任务
5.1 用计划任务做定时批量关机
脚本跑通后，下一步是让它自动在固定时间执行。Windows 任务计划程序里建一个基本任务，触发器设为每天 23:30，操作设为python.exe D:\scripts\batch_shutdown.py，起始目录填脚本所在目录。注意“不管用户是否登录都要运行”要勾上，否则锁屏后不执行。
5.2 加一个“预演模式”再真关
直接批量关机风险高，我后来给脚本加了一个--dry-run参数：只 ping 和打印将要关机的列表，不真正调用shutdown。确认列表无误后再去掉参数执行。这个习惯救过我好几次——有一次 IP 文件里混进了一台正在跑重要任务的机器，预演时看到了，及时删掉。
import argparse def parse_args(): parser = argparse.ArgumentParser(description="Windows 批量远程关机") parser.add_argument("--file", default="hosts.txt", help="IP 列表文件") parser.add_argument("--workers", type=int, default=8, help="并发数") parser.add_argument("--dry-run", action="store_true", help="只预演不关机") return parser.parse_args()argparse让脚本从“改代码调参数”变成“命令行传参”，配合计划任务和手动执行都方便。--dry-run是布尔开关，不加就是真关，加了就只打印。
5.3 验证关机结果：ping 轮询确认
指令发出去不等于关掉了。执行完等 30 秒，再对目标列表做一轮 ping，还在线的就是没关成功的，单独列出来。这个“发指令→等待→验证”的闭环，比只看shutdown返回码可靠得多。
import subprocess def check_offline(ip): """ping 一次，返回 True 表示已离线（关机成功）""" # -n 1 发一个包，-w 1000 超时 1 秒 result = subprocess.run( f"ping -n 1 -w 1000 {ip}", shell=True, capture_output=True, text=True ) return result.returncode != 0ping返回非 0 通常意味着目标不可达，结合关机场景可以判定为已关机。但要注意：有些机器关机后网卡仍响应 ARP，ping 可能还通，这时以shutdown返回码和事件日志为准。
从那以后我每次批量关机前都强制走一遍--dry-run，确认列表、确认时间、确认没有漏网的重要机器，再真刀真枪执行。希望帮到你。
本文还有配套的精品资源，点击获取
