把 reverse proxy 和 Wake-on-LAN 放在同一个项目里最直接的实际意义就是让已经休眠的后端服务器在收到请求时被自动唤醒而不是 24 小时开机空转。Doormouse 就是这么个反向代理——它接收客户端请求发现后端离线或睡眠时先发一个 Wake-on-LAN 魔术包把服务器叫醒等操作系统和服务都就绪了再把请求继续转发过去。这篇文章适合自己维护家用服务器、实验室机器、内部开发环境或 CI 构建机的人看。比起代理转发本身真正值得研究的其实是那个“发现后端睡着 - 唤醒 - 等待就绪 - 转发”的判断链路。1. 它到底解决什么问题反向代理不再默认“后端必须常开”1.1 传统反向代理的隐含前提Nginx、Caddy、Traefik 这类反向代理转发请求时都隐含一个前提后端必须在线。后端如果关机或休眠代理只能返回 502 或 504不会主动做任何补救。这对生产环境是合理的因为高可用系统的后端本来就该一直运行。但对家庭服务器、实验室开发机、内部工具站来说24 小时在线非常浪费。功耗、发热、噪音时间一长都是实际成本。更常见的情况是某台机器一周用不了几次却为了偶尔一次访问必须一直开着或者等用户上门前手动开机。1.2 按需唤醒才是真实需求Doormouse 解决的场景可以概括为“低频访问 按需拉起”家用 NAS 或 HomeLab 里的 Web 服务白天偶尔有人访问。开发团队的测试环境、演示环境只在工作时间用。CI 构建机或渲染节点只有提交代码、跑构建时才需要。内网工具站比如网盘、笔记、监控面板访问频率不高。这些服务的共同特点是单次请求频率低但对首次请求的延迟容忍度高。一次请求触发唤醒等 30 到 90 秒操作系统启动对使用者来说可以接受。换来的是机器大部分时间处于休眠状态需要的时候才被叫醒。1.3 为什么由反向代理来做“唤醒决策”有人会说我自己写个脚本检测到请求就发魔术包不也行可以但要做的事比想象多需要一个稳定入口把流量先接到一台“总不睡觉”的机器上。要判断后端是“真挂了”还是“只是睡着了”。要维护每个后端对应的 MAC 地址组织唤醒报文。要等待启动完成而不是发完包就 504。要处理多个请求同时到达时的去重避免重复发唤醒包。要有超时、日志、失败提示方便排查。把这些逻辑单独拆成一个组件由反向代理统一管起来就是 Doormouse 的定位。它本质上不是更快的代理而是更懂“睡眠-唤醒”场景的代理。“fast reverse proxy”这个说法我觉得应该理解为决策链路快而不是单纯转发性能高。唤醒判断、等待重试这些动作如果被塞进外部脚本每次都跨进程通信那才真的快不起来。2. 先拆原理魔术包、UDP 广播和请求等待链路2.1 Wake-on-LAN 的核心机制WoL 本身并不复杂。要唤醒一台机器需要往目标网卡发送一个“魔术包”Magic Packet。这个包的结构是6 个字节的 0xFF后面连续 16 次重复目标网卡的 MAC 地址总共 102 字节部分实现还带尾部。通常通过 UDP 发往 7 号或 9 号端口目标地址可以是广播地址例如192.168.1.255。目标机器能醒过来的前提有三个网卡在系统休眠或关机状态下仍然供电并且开启 WoL 功能。主板支持从 S3、S4 甚至 S5 状态唤醒BIOS/UEFI 里相关选项处于开启状态。魔术包能顺利到达目标网卡。发送方和目标需要在同一个二层广播域内或者网络设备允许定向广播。“能收到包”和“能把机器叫醒”是两回事。实践中很多人会先在本机用wakeonlan命令手动测一次。如果能唤醒再接入代理如果不行先解决网卡和主板设置不要急着调代理参数。2.2 反向代理如何在两条路径之间切换Doormouse 的请求处理路径可以拆成两条正常路径客户端请求进来Doormouse 检查后端健康状态。如果后端在线且服务正常直接按普通反向代理转发。唤醒路径如果后端状态不正常Doormouse 先判断这个后端是否配置了 WoL 唤醒信息。如果有就发送魔术包然后进入等待循环持续探测后端是否恢复恢复后再转发原始请求。这里的“状态不正常”需要定义清楚。常见做法是代理层维护最近一次健康检查结果或者直接尝试连接后端的 TCP 端口、HTTP 健康检查接口。后一种更直观但也更慢。我建议配置两层判断先看 TCP 端口是否可达端口通了再看 HTTP 健康检查是否返回预期状态码。端口可达不代表服务可用但至少能排除“系统没起来”这种最常见的情况。2.3 Doormouse 实际承担的三个角色简单说它同时担任入口、唤醒控制器、就绪判断器。入口对外提供统一地址所有访问后端的请求先到它这里。唤醒控制器根据后端配置、MAC 地址、UDP 广播方式组织魔术包。就绪判断器唤醒后按一定频率检查后端状态决定何时放行请求。这种分工决定了它的配置项不会只有“上游地址”和“监听端口”还必须有“唤醒超时”“健康检查间隔”“失败策略”这类字段。后面配置部分会展开。3. 跑起来之前先确认硬件、网络和软件条件3.1 硬件和系统层先测一次手动唤醒部署前最容易忽略的是目标机器的电源管理状态。WoL 对硬件有硬性要求不是装个软件就能解决。需要确认主板电源管理支持 S3/S4/S5 唤醒BIOS/UEFI 里有“Wake on LAN”“Power On By PCI-E”“Resume by PCI Device”等选项。网卡有线网卡支持 WoL。无线网卡在部分平台也可以但稳定性不如有线建议优先用有线。系统Windows 需要在设备管理器里开启“允许此设备唤醒计算机”Linux 需要用 ethtool 查看并开启 Wake-on例如ethtool -s eth0 wol g。功耗状态有些主板在 S5 关机状态下也能被唤醒有些只支持 S3 睡眠。具体以主板说明为准。我第一次配置这类环境时会先手动跑一遍排查流程把机器睡眠用另一台机器执行wakeonlan MAC看能否唤醒。如果能才继续做代理对接如果不能先回硬件层调整这一步省不了。3.2 网络层广播域和 ARP 的坑WoL 的魔术包最佳发送方式是同一广播域内的广播包。这里有三个常见网络问题如果 Doormouse 和目标机器不在同一个二层网络单纯发广播包没有意义。要么部署在同一个网段要么启用路由器的子网定向广播功能要么配置为向目标网卡 IP 发送单播魔术包需要网络设备支持并且要维护 ARP 表。交换机端口如果开了端口隔离、BPDU Guard 或严格的 IGMP Snooping广播包可能到不了目标网卡。目标机器休眠后交换机上的 ARP 表项可能过期。代理如果缓存了旧的 ARP 记录直接按单播发送可能失败。对比之下发广播地址更稳妥。因此建议先简化网络把 Doormouse 和目标服务器放在同一个网段哪怕 VLAN 里单独划一块也比跨三层转发好排查。3.3 软件层运行环境和权限Doormouse 本身的运行环境以项目文档为准。常见反向代理类工具会提供二进制或容器镜像运行要求一般是一台 7x24 小时开机的入口机器可以是小主机、路由器旁的工控机也可以是云上的轻量实例。能访问到目标服务器所在网段能发送 UDP 广播包。需要开放一个对外监听端口并配置到目标服务器的转发规则。配置文件里写好每个后端的地址、MAC 地址、唤醒参数。注意入口机器不能也进入休眠。如果代理自己都睡了请求来了没人发魔术包整套机制就失效了。权限方面发送 UDP 包通常不需要特殊权限但绑定 80/443 端口时Linux 下可能需要 root 或CAP_NET_BIND_SERVICE。这些按实际部署环境处理即可。4. 按实际过程拆一遍请求进来后发生了什么4.1 第一步请求先落在入口客户端访问某个域名或 IP流量首先到达 Doormouse。此时它做普通反向代理都会做的事根据主机名或路径找到对应的后端记录。这一步的关键是让代理能区分“哪个后端对应哪个请求”。管理多个服务器时这个映射尤其重要否则容易出现“请求 A 的流量把后端 B 唤醒了”的错乱。4.2 第二步判断后端当前状态Doormouse 需要快速判断后端是否可用。判断方式通常有三种TCP 探测尝试连接后端端口超时短一点比如 2 到 5 秒。HTTP 健康检查请求一个健康检查路径看返回码。失效计数连续 N 次失败后才认定后端离线避免单次抖动触发唤醒。我建议把“离线判定”和“唤醒触发”分开。离线判定可以慢一点比如连续 3 次 TCP 连接失败才进入唤醒流程。否则后端只是重启瞬间抖动一下代理就疯狂发魔术包没有意义。4.3 第三步发送魔术包一旦确认后端需要唤醒Doormouse 查表得到 MAC 地址和端口构造魔术包并发送。发送时有几个细节广播地址要填对。比如配置成192.168.1.255UDP 包会发到整个网段目标机器才能收到。发送次数要合理。有的实现对丢包敏感会连续发 2 到 3 次每次间隔几秒。但发送频率别太高否则会重复唤醒也可能被交换机限速。同一时刻多个请求并发时正确的做法是“合并唤醒”。一旦某个后端已经被唤醒后来的请求进入等待队列而不是再发一遍魔术包。4.4 第四步等待启动完成并转发发送魔术包后需要等待目标机器完成启动。注意这里不只是操作系统起来还要等服务进程就绪。判断标准最好是一个健康检查接口返回成功而不是单纯 ping 通。等待阶段最影响体验的是“等待多久”。后端不同启动时间差异很大轻量 Linux 机器可能 20 到 40 秒。Windows 加一堆自启动服务可能要 60 到 120 秒。虚拟机宿主上的虚机还要叠加宿主启动时间。所以超时时间必须可配置并且给每个后端单独设置不能用同一个默认值硬套所有机器。4.5 失败处理和超时判断如果等待超时后端仍然不可达Doormouse 需要给出明确错误响应。这里有个设计问题触发唤醒的那个请求到底是一直等到后端起来还是先返回“正在唤醒”。两类设计各有取舍同步等待请求挂住等后端起来后自动转发。客户端体验最简单但要求代理和后端都在合理超时内完成浏览器、网关不能等太长时间。先返回状态立即返回 503 或 502提示“服务器正在唤醒请稍后重试”同时设置Retry-After响应头。客户端重试时可能已经就绪。实际使用中我倾向先按同步等待但把总超时控制住。如果后端启动时间在 90 秒以上就要考虑客户端是否愿意等。有的实现会折中第一次请求触发唤醒并返回明确状态后续轮询由客户端发起直到后端就绪。这个取舍没有绝对对错看你的访问方能不能接受等待。5. 配置思路和参数建议5.1 后端记录的常见字段Doormouse 的具体配置语法以项目 README 和示例配置为准。这里给一个通用示意帮助理解概念proxy: listen: :8080 wake_timeout: 90s health_check_interval: 5s backends: - name: web-server address: 192.168.1.20:8080 mac: AA:BB:CC:DD:EE:FF broadcast: 192.168.1.255 wol_port: 9 health_check: port: 8080 path: /healthz expected_status: 200 boot_timeout: 90s fallback_action: error这些字段的含义是address后端实际监听地址。mac目标网卡 MAC 地址唤醒时必须。broadcast魔术包发送目标通常填目标网段的广播地址。wol_port魔术包发送端口UDP 7 或 9。health_check就绪判断方式端口探测或 HTTP 路径。boot_timeout从发包到认为唤醒失败的时间。fallback_action唤醒失败后的行为比如返回错误还是转到备用后端。注意这是示意配置不是 Doormouse 的真实配置格式。实际使用时以项目的官方示例为准不要直接套用。5.2 关键参数怎么定几个参数需要根据自己的环境调整而不是照抄默认值boot_timeout先手动测一次目标机器从关机到服务可用的实际时间再加上 20% 到 30% 的余量。测得 60 秒就配 75 到 90 秒。health_check_interval太短会增加探测压力太长会延长“已经就绪但还没被转发”的等待。建议 3 到 5 秒。唤醒失败重试次数一般发送 2 到 3 次魔术包即可。超过 3 次还醒不了基本是网络或硬件问题重试再多也没用。并发等待队列上限如果同时有很多请求进来要设置上限避免代理因为等待线程过多而耗尽资源。5.3 日志和状态查询的用途这类工具调试时日志比什么都重要。至少要看得到何时判定后端离线。何时发送魔术包发往哪个 MAC。何时探测到后端就绪。何时超时超时时间是多久。哪些请求被转发哪些被拒绝。如果 Doormouse 支持类似/status的接口就更方便。没有也没关系把日志按天滚动保存排查时从日志时间线倒推即可。6. 常见坑从“没醒”到“醒了但没转发”6.1 魔术包发了但服务器没醒优先级最高的排查顺序手动用wakeonlan测试一次确认不是代理配置问题。检查 MAC 地址是否填对尤其是虚拟机网卡、多网卡机器。检查广播地址是否正确代理和后端是否在同一 VLAN。检查主板 BIOS/UEFI 的唤醒选项。检查系统电源设置。Windows 还要关掉快速启动否则休眠状态下的唤醒行为会变得很怪。看交换机是否隔离广播或限制未知目标广播包。这里最容易搞混的是“机器有没有进入真正可唤醒的睡眠状态”。有的系统配置成混合睡眠实际是休眠加睡眠魔术包不一定能触发。先手动测再谈代理。6.2 服务器醒了但代理还在等待如果机器已经运行代理却迟迟不转发多半是健康检查的“就绪条件”设置得不合适只做了 TCP 探测但服务进程还没起来端口没监听。健康检查路径返回 500但服务本身可以响应业务请求。启动等待期间代理探测频率太低错过了服务就绪的时点。解决办法是调整健康检查路径最好用一个独立、无副作用的状态接口例如/healthz并且确认返回状态码和预期一致。6.3 第一个请求总是超时这是按需唤醒方案最核心的体验问题。客户端如果设置的连接超时是 10 秒而服务器启动需要 60 秒第一次请求必然报错。要缓解这个问题对代理本身的读超时、连接超时设置放宽至少大于 boot_timeout。如果客户端可控制让客户端在收到“正在唤醒”提示后重试。场景允许时使用同步等待模式同时提前告知用户首次访问可能需要较长时间。不要把“第一次请求必然很慢”当成缺陷。它是这种架构的天然代价配置时把预期写清楚比事后解释好得多。6.4 并发唤醒和重复发送多个用户在服务器休眠时同时访问最容易出现的现象是代理对同一台机器连续发送多个魔术包。虽然魔术包多发几次不至于损坏设备但会让问题变乱日志里也看不清楚到底是谁触发了唤醒。合理行为是某个后端一旦进入唤醒流程后续请求只进入等待队列不重复发包。唤醒成功的时点统一通知所有等待请求。如果你的实现发现每次请求都触发一次唤醒那就要检查去重和唤醒状态标记是否生效。6.5 它不适合什么要说清楚边界。Doormouse 这种按需唤醒方案不适合高并发生产系统。唤醒等待会让请求堆积任何抖动都可能放大成大面积超时。延迟敏感的服务。首次访问 30 到 90 秒的延迟不是所有业务都能接受。依赖链复杂的服务。如果数据库、缓存、认证服务都进入睡眠代理只唤醒一个节点没有意义因为请求还会在下一个节点卡住。适合的场景是低频、内部、对首次延迟容忍度高的服务。如果每天访问量只有几十次每次都能接受等几十秒这个方案就有明显价值。7. 和主流方案的对比以及落地建议7.1 对比几种省电方案方案优点缺点适合场景服务器一直开着简单、无延迟耗电、发热、噪音高可用生产定时开关机省电、规律无法应对临时访问使用时间非常固定手动远程唤醒灵活需要人工介入少数运维人员使用代理按需唤醒自动、灵活首次延迟高、配置复杂一些低频内部服务Doormouse 属于最后一种。它把“手动远程唤醒”升级为“自动触发唤醒”代价是引入一个常开入口和一套健康判断逻辑。7.2 对比 Nginx 自写唤醒脚本如果不引入 Doormouse用 Nginx 加外部脚本理论上也能做但要自己处理如何让 Nginx 在后端失败时调用唤醒脚本。唤醒脚本如何拿到 MAC 地址、广播地址、唤醒端口。如何等待、重试、通知 Nginx 重新转发。多个后端、多个请求并发时如何控制。这些逻辑堆在一起代码的可维护性会迅速下降而且 Nginx 的失败处理通常不是为“长时间等待后端启动”设计的。Doormouse 的价值就是把“失败检测-唤醒-等待-重试”打包成反向代理的原生能力。但也要承认Nginx 生态成熟、功能覆盖广Doormouse 这类项目更适合特定场景或自托管爱好者。7.3 我的落地建议真正开始用之前我建议分四步走先手动触发一次 WoL确认目标机器能被唤醒。用最小配置把 Doormouse 跑起来只配一台后端。单条请求测试休眠后端请求进来看日志确认唤醒、等待、转发链路完整。再逐步加多后端、加健康检查、加大并发等待队列最后才考虑接入正式域名或对外端口。整个过程中日志和启动耗时记录是最重要的验证依据。第一次跑通后把“从发包到服务就绪”的实际时间记下来写进配置备注后面调参就有参照了。还有一点经验不要把网络里所有机器都挂到这个方案下。至少要保证 DNS、网关、代理入口这些基础服务不依赖被唤醒的节点否则会出现“代理醒了数据库但代理自己查不了 DNS”的循环依赖。8. 这类工具真正值得关注的点我看到这类工具时最关心的不是它支持多少种代理特性而是它在真实网络里能不能稳定跑通“唤醒-等待-转发”这条链路。Doormouse 的价值正好落在这里它把低频访问服务器从“必须常开”变成了“按需起来”。如果你家里或团队里正好有一台不常用但偶尔必须访问的机器可以先手动确认 WoL 可用再把它接到类似的代理方案里。只要把硬件、网络、超时参数这三件事处理好这个思路是能长时间稳定用的。踩过几次之后我的体会是很多问题不是工具能力不够而是前置环境和输入材料没有处理干净。魔术包发不出去先查广播域和网卡设置服务器起来了但代理不转发先查健康检查条件第一次请求超时先查客户端超时和代理总超时的匹配关系。把这几条链路理顺按需唤醒这套玩法就基本没有大的障碍了。