如果你的服务器只在白天被用到晚上和周末基本在空转你多半想过同一个问题能不能让它在没人访问的时候睡过去来访问时再把它叫醒传统反向代理不解决这个问题。nginx、Traefik、Caddy 在调度时都默认后端“永远在线”后端一旦关机或休眠它们只能返回 502 或 504。Doormouse 是一个把 Wake-on-LAN 内建到反向代理里的项目后端允许休眠代理负责发魔法包、等人醒、再把请求转发过去。先给判断Doormouse 的价值不在“转发有多快”而在于它把电源管理和流量路由做进了同一个状态机。这个思路正好切中自建机房、家庭实验室、按需编译服务器这类场景的痛点——机器可以继续省电但外部访问体验仍然接近“随时可用”。近几年大家聊 fast reverse proxy几乎都在比 QPS、延迟和内存占用而 Doormouse 换了一个角度不是让代理更快而是让后端可以更省。这篇文章会从问题出发讲清楚反向代理 Wake-on-LAN 的架构思路、WOL 的前置条件、一个最小可用的实现示例、常见坑以及什么场景才适合用这种方案。1. Doormouse 到底解决了什么问题1.1 传统反向代理的“永远在线”假设绝大多数反向代理的模型是这样的客户端把请求打到代理代理按照路由规则转发给后端。这个模型有一个隐藏前提——后端必须稳定在线。代理自身的健康检查、负载均衡、熔断全部建立在这个假设之上。问题在于真实世界里不是所有服务器都需要 7×24 小时在线家里的 NAS、监控、下载机白天偶尔用晚上基本空闲团队的自建编译服务器只有提交代码时才需要跑构建任务边缘站点的小型服务白天有流量夜间几乎没有访问测试环境、预发布环境通常只有工作时间有人用。这些机器如果常年开机电费、噪音、硬件损耗都是实打实的成本如果随手关掉又会在别人想要访问时变得不可用。过去只能二选一要么浪费电要么牺牲可用性。1.2 “按需唤醒”才是真正要解决的问题Doormouse 的思路可以概括成一句话机器可以睡代理负责叫醒它。当请求到达 Doormouse 时如果目标后端处于休眠状态代理会先发送 Wake-on-LAN 魔法包然后等待后端完成开机、系统启动、服务就绪再把请求转发过去。整个过程对客户端来说只是第一个请求变慢了几十秒后续请求恢复正常。这和云服务里的自动扩缩容有本质区别。云上的做法是“发现流量上涨→创建新实例→等待就绪→加入负载均衡”而 WOL 方案是“发现请求到来→通过局域网把硬件唤醒→等待系统启动→转发流量”。前者需要额外购买计算资源后者只是复用已有的物理机器。1.3 适用场景与不适合的场景方案冷启动延迟额外成本适用场景常驻在线0电费、资源长期占用对延迟敏感的生产服务云自动扩缩容秒到分钟按量计费的云资源流量有明显峰谷的线上服务WOL 按需唤醒30 秒到数分钟几乎为零复用现有硬件家庭实验室、自建机房、编译/测试服务器从材料看Doormouse 更适合延迟不敏感、低频访问、希望降低空闲功耗的场景。如果业务要求每个请求都在 500ms 内返回那任何 WOL 方案都不适合因为硬件的开机时间决定了它不可能做到“秒回”。2. 三个核心技术点反向代理、Wake-on-LAN、Magic Packet2.1 反向代理补齐了什么反向代理通常承担路由、负载均衡、TLS 终止、访问控制等职责。Doormouse 在这个基础上增加了一个能力感知后端电源状态并在需要时发起唤醒。这里真正容易踩坑的地方是很多人把 WOL 当成一个独立工具来用唤醒之后就不知道下一步该干什么了。但实际上“唤醒”只是第一步代理还要处理“等待就绪”“请求排队”“何时再次休眠”这一整条链路。如果只发魔包不等人启动请求照样会失败。2.2 Wake-on-LAN 的工作原理Wake-on-LAN 是网卡的一项硬件能力。网卡在主机休眠或关机后仍然保持低功耗供电并监听网络中的 Magic Packet。收到针对自己 MAC 地址的 Magic Packet 后网卡会向主板发出唤醒信号让整台机器开机。Magic Packet 的格式非常固定6 字节的连续0xFF目标机器的 MAC 地址重复 16 次整个包一共 6 16 × 6 102 字节。这段数据通常通过 UDP 发送目标端口一般是 9discard或 7echo目标地址是子网广播地址或全局广播地址。也就是说只要局域网内有人发出这个包指定 MAC 的机器就会被唤醒。用十六进制看一个以AA:BB:CC:DD:EE:FF为 MAC 的 Magic Packet 大致长这样FF FF FF FF FF FF AA BB CC DD EE FF AA BB CC DD EE FF ...总共重复 16 次2.3 为什么 WOL 不能单独解决问题只依赖 WOL 的话你会发现几个尴尬的问题网卡收到 Magic Packet 后只是“通电开机”不代表操作系统已经启动操作系统启动后业务服务还需要初始化端口才真正可访问如果服务还没就绪代理就把请求转发过去用户会收到连接拒绝机器唤醒后多久没人访问又应该再次休眠谁来决策这些问题的答案是需要一个像 Doormouse 这样的调度者它同时掌握“机器当前状态”和“流量是否到来”两个信息才能做出合理的唤醒和休眠决策。单纯发 WOL 包解决不了完整链路。2.4 与“fast reverse proxy”话题的关系如果要讨论 Doormouse 和 fast reverse proxy 的关系更准确的定位是Doormouse 优化的是能源成本而不是请求延迟。一台睡着的后端启动可能需要 30 秒到 3 分钟在这个量级面前代理转发请求的微秒级差异已经不是关键因素。它真正要保证的是状态机严谨、超时可控、失败可观测。3. 系统架构与状态机设计3.1 核心组件一个完整的 WOL 反向代理方案至少包含四个部分前端流量入口监听 HTTP/HTTPS 请求承担反向代理的常规职责后端注册表记录每台后端的 IP、端口、MAC 地址、健康检查方式WOL 发送模块根据后端 MAC 和目标网段构造 Magic Packet 并发送健康检查与状态管理轮询后端端口管理状态迁移和超时。3.2 后端状态机从设计上看每台后端的生命周期可以抽象成五个状态状态含义触发条件sleeping休眠中空闲超时后进入waking唤醒中收到请求且状态为 sleeping发送 Magic Packetready已就绪健康检查通过active处理请求中有请求正在转发idle已空闲一段时间没有请求等待休眠状态迁移的关键点是sleeping 状态收到请求时代理不能直接把流量转发给后端而要先把状态切换成 waking发送 Magic Packet然后进入健康检查轮询。等到健康检查通过后才能把请求转发出去。只考虑到位这个层面的代码会非常脆弱。比如客户端在等后端启动的过程中超时了代理应该怎么处理后端启动到一半失败了代理要不要重试这些都需要在状态机设计阶段想清楚。3.3 更稳妥的超时与重试策略实际项目中更推荐的做法是健康检查超时设置为后端最慢启动时间的 1.5 倍以上健康检查使用 TCP 端口探测而不是 ICMP ping因为 ping 通不代表服务就绪如果健康检查失败返回 504 Gateway Timeout并在响应头里带Retry-After让客户端稍后重试如果客户端愿意等待代理可以短暂挂起连接但必须设置代理侧的总超时时间避免连接被客户端或中间层提前断开。4. 前置条件让一台机器具备可被 WOL 唤醒的能力WOL 能不能成功很多时候不是代理配置的问题而是机器本身没准备好。这一节按 BIOS、操作系统、网络三个层面整理前置条件。4.1 BIOS/UEFI 设置不同主板对 WOL 的表述不一样常见选项有Wake on LAN、Power On By PCI-E、Wake On Magic Packet、Resume By PCI Device等。无论名称怎么变目标都是让系统在 S3/S4/S5 状态下接受网卡唤醒信号。有几个细节很容易踩坑部分主板开启了 ErP / Deep Sleep / 节能模式后会切断 5V 待机电源网卡彻底断电WOL 直接失效PCIe 网卡和板载网卡的选项位置不同老主板可能只在板载网卡上支持 WOL如果机器是笔记本电脑多数 Wi-Fi 网卡在休眠时并不会监听网络建议使用有线网卡。4.2 操作系统与网卡驱动设置BIOS 打开还不够操作系统里的网卡驱动也要允许 Magic Packet 唤醒。在 Linux 下可以用ethtool查看和设置# 查看当前网卡是否支持并开启 WOL ethtool eth0 | grep -i wake # 开启 Magic Packet 唤醒 sudo ethtool -s eth0 wol g注意ethtool设置的参数重启后会丢失。要持久化可以写一个 systemd 服务在网络就绪后重新设置# /etc/systemd/system/wol-enable.service [Unit] DescriptionEnable Wake-on-LAN on eth0 Afternetwork.target [Service] Typeoneshot ExecStart/usr/sbin/ethtool -s eth0 wol g [Install] WantedBymulti-user.targetsudo systemctl daemon-reload sudo systemctl enable --now wol-enable.serviceWindows 用户的路径是设备管理器 → 网卡属性 → 电源管理 → 勾选“允许此设备唤醒计算机”和“只允许幻数据包唤醒计算机”。4.3 网络层面的要求WOL 依赖广播因此代理和目标后端最好处于同一个二层广播域内。如果跨网段路由器默认不会转发广播包常见的解决办法是开启 directed broadcast 转发或者在目标网段内部署一个小 agent 来代发 Magic Packet。其他容易忽略的点为后端机器配置静态 IP 或 DHCP 保留地址防止唤醒后 IP 变化导致代理找不到后端交换机上不要启用会阻塞广播风暴的异常策略如果开启了防火墙放行 UDP 9 端口的入站广播。从实际经验看先把ethtool、BIOS、网络三层全部验证通过再来配代理会少踩一大半的坑。5. 完整示例配置与代码实现这一节给一个最小可用的实现思路。Doormouse 的具体配置字段和命令请以项目 README 为准下面示例主要演示核心逻辑。5.1 配置示例可以用 YAML 描述后端注册信息# doormouse.yaml演示结构具体字段以项目文档为准 proxy: listen: 0.0.0.0:8080 idle_sleep_after: 600 # 后端空闲多少秒后允许再次休眠 backends: - name: build-server host: 192.168.1.50 port: 80 mac: AA:BB:CC:DD:EE:FF wake_timeout: 120 # 最多等待 120 秒 health_check: host: 192.168.1.50 port: 22 # 用 SSH 端口判断系统已就绪这个示例里的health_check值得注意。选哪个端口不是随意的如果只是判断“系统是否开机”用 SSH 的 22 端口就够如果要判断“业务是否可用”应该探测业务本身的端口比如 80 或 443。端口探测能反映出的信息越接近真实服务状态代理的转发就越安全。5.2 发送 Magic Packet 的 Python 实现# wol.py import socket def send_magic_packet(mac: str, broadcast: str 255.255.255.255, port: int 9) - None: mac_hex mac.replace(:, ).replace(-, ).replace(., ) if len(mac_hex) ! 12: raise ValueError(f非法 MAC 地址: {mac}) mac_bytes bytes.fromhex(mac_hex) # Magic Packet 6 字节 0xFF 目标 MAC 重复 16 次 magic_packet b\xff * 6 mac_bytes * 16 with socket.socket(socket.AF_INET, socket.SOCK_DGRAM) as sock: sock.setsockopt(socket.SOL_SOCKET, socket.SO_BROADCAST, 1) sock.sendto(magic_packet, (broadcast, port))核心逻辑只有三行转换 MAC 地址、拼装 102 字节的 Magic Packet、通过 UDP 广播发送。SO_BROADCAST必须设置否则普通 UDP socket 默认不允许发送到广播地址。5.3 健康检查等待逻辑# health.py import socket import time def wait_for_port(host: str, port: int, timeout: int 120, interval: int 3) - bool: deadline time.time() timeout while time.time() deadline: try: with socket.create_connection((host, port), timeout2): return True except OSError: time.sleep(interval) return False这里用固定间隔轮询比较简单但要注意后端启动的前几秒端口连接失败是正常的不要因此马上判定失败。真正的失败是超时还没连上。如果想更优雅可以用指数退避前几次间隔短一些越到后面间隔越长。5.4 把 WOL 和健康检查串起来的后端状态对象# minimal_proxy.py —— 演示核心状态机逻辑 from wol import send_magic_packet from health import wait_for_port class Backend: def __init__(self, name, host, port, mac, wake_timeout120): self.name name self.host host self.port port self.mac mac self.wake_timeout wake_timeout self.state sleeping # sleeping - waking - ready def wake(self): if self.state sleeping: send_magic_packet(self.mac) self.state waking print(f[{self.name}] 已发送 WOL 魔法包状态 - waking) def wait_ready(self): if self.state ! waking: return self.state ready if wait_for_port(self.host, self.port, timeoutself.wake_timeout): self.state ready print(f[{self.name}] 健康检查通过状态 - ready) return self.state ready这段代码把本文前面讲的状态机变成了可运行的最小实现。真实代理还需要接入流量转发、并发控制、空闲计时但核心思想是一样的sleeping 状态下不转发先唤醒再等待最后才转发。6. 运行结果与效果验证6.1 手动验证 WOL 是否生效配代理之前先手动验证 WOL 链路是否通。在另一台同网段机器上安装wakeonlan工具# 安装 wakeonlan 工具 sudo apt install wakeonlan # 向目标机器的 MAC 发送魔法包 wakeonlan AA:BB:CC:DD:EE:FF正常输出类似Waking up AA:BB:CC:DD:EE:FF然后去目标机器上看它是否启动。如果机器毫无反应不要急着怀疑代理先回到第 4 节检查 BIOS、网卡驱动和网络广播。6.2 通过 Doormouse 验证完整流程代理启动后从客户端发起一次请求curl -v http://doormouse-ip:8080/预期行为第一次请求会观察到明显的等待时间日志里出现“发送 WOL 魔法包”后端开机完成后日志出现“健康检查通过”请求最终成功返回之后立刻再发一次请求响应时间恢复正常说明后端已进入 ready 状态。如果第一次请求直接返回 502/504优先查看代理日志中健康检查的报错信息。常见的失败有两种Magic Packet 根本没发出去或者后端系统无法在超时时间内启动完成。6.3 判断成功与失败的指标一个 WOL 反向代理方案是否合格可以从四个角度判断唤醒成功率发送 Magic Packet 后后端是否总能开机就绪判断正确率健康检查会不会误判“已就绪”首次请求成功率用户第一次访问时代理能否在不丢请求的前提下完成唤醒和转发空闲休眠是否误伤是否存在未完成的请求机器就被休眠了。7. Doormouse 与 WOL 方案的常见问题排查问题现象可能原因排查方式解决方案发出 Magic Packet 后机器不启动BIOS 中 WOL 选项未开启或 ErP/Deep Sleep 切断了待机供电检查 BIOS 电源管理选项和网卡 WOL 参数开启对应选项关闭会断电的深度节能模式Linux 下ethtool设置后重启失效WOL 参数没有持久化重启后重新执行ethtool eth0查看用 systemd 服务或 udev 规则持久化设置Windows 下能关机不能休眠唤醒网卡驱动未勾选“允许此设备唤醒计算机”检查设备管理器电源管理页勾选“只允许幻数据包唤醒计算机”跨网段发送 Magic Packet 失败路由器不转发广播包确认代理与后端是否在同一个广播域开启 directed broadcast或在目标网段部署 WOL agent代理等待后仍然返回 504后端启动时间超过wake_timeout查看代理日志中的等待耗时调大超时时间或优化后端开机/服务启动速度健康检查通过但业务请求仍失败探测端口不是业务端口检查health_check配置将探测端口改为业务服务端口而不是 22 或 80 等笼统端口后端刚休眠就被唤醒有定时任务或监控探针在持续访问查看代理访问日志和客户端来源为唤醒源配置白名单或延长空闲休眠时间8. 使用边界与工程建议8.1 什么时候不该用 DoormouseWOL 按需唤醒不是银弹下面这些场景应该避开对首包延迟要求苛刻的生产服务。后端开机时间再短也有几十秒不适合直接承担线上主流量后端是虚拟化宿主机或容器节点。容器和虚拟机通常需要宿主机先启动WOL 只能唤醒物理机无法直接唤醒 VM后端处于不同广播域且无法部署辅助 agent 的复杂网络。跨网段 WOL 配置成本会明显上升。8.2 安全边界要注意Magic Packet 本身不包含认证信息也没有加密保护。任何处于同一广播域内的人只要知道目标 MAC 地址都可以发送 Magic Packet 把机器唤醒。这在私网家庭环境问题不大但如果代理暴露在公网必须做好访问控制代理对外只暴露 HTTP 服务不要暴露 UDP 9 的 WOL 端口在代理层加认证例如 Basic Auth、Token 或 mTLS把代理和需要唤醒的后端放在同一个受信网络里必要时划分 VLAN并限制广播域范围记录 WOL 事件的日志方便事后审计谁触发了唤醒。8.3 健康检查与休眠协调机器要被安全地休眠需要满足一个条件当前没有正在处理的请求。更稳妥的做法是把休眠判断权交给任务或会话层代理侧维护“活跃连接数”活跃连接为 0 时才开始空闲计时后端侧如果运行了长期任务比如编译任务任务结束前不应休眠如果使用 systemd 管理休眠可以在休眠前调用一个钩子脚本检查代理的连接状态再决定是否真正挂起。8.4 可观测性WOL 方案一旦出问题排查成本比普通代理高因为链路里多了一个“硬件开机”环节。建议至少记录这些指标每次 WOL 触发的目标、时间、结果从发送 Magic Packet 到健康检查通过的总时长健康检查失败次数与原因后端进入休眠的时间点。把“唤醒耗时”单独作为一个指标看待能帮你判断瓶颈在硬件启动、系统启动还是服务启动而不是把所有问题都归到代理上。9. 总结与后续学习方向Doormouse 真正有意思的地方不是“反向代理”本身而是它把两个原本不相关的系统——流量路由和电源管理——缝合在了一起。它适合那些机器需要省电、但又不希望完全不可达的场景。如果你家里有 NAS、自建编译机或者团队里有低频使用的测试服务器这类方案值得认真试一次。建议的实践路径很明确先在目标机器上把 BIOS、网卡驱动、网络广播三层 WOL 前置条件验证通过再用小的 Python 脚本测通 Manual Wake最后接入 Doormouse 配置完整链路。这样即使后续遇到问题你也能判断问题出在硬件层还是代理层。下一步可以继续研究几个方向一是后端启动顺序与服务依赖管理二是代理队列与客户端超时策略的配合三是如何在容器化环境里让物理机和虚拟机协同工作。把这些都理清楚之后你就拥有了一套真正能落地的“按需唤醒”基础设施。