问题背景
在 NAS/fnOS 上用 UpSnap 管理局域网设备唤醒时，目标 Windows 台式机的 IP、MAC、子网掩码看起来都正确，但点击唤醒没有效果。容器、网络广播和目标电脑的设置都有可能影响结果，需要顺着连接过程逐项核对。
最后解决问题的是目标电脑主板 BIOS 中的网卡唤醒开关。启用后，这台电脑关机时网口灯仍然亮着，UpSnap 也能正常唤醒它；此前关机后网口灯会熄灭。下面保留从 Windows 检查到 BIOS 设置的排查过程。
UpSnap 配置证据
UpSnap 运行在 Linux NAS 的 Compose 中，host 网络和能力设置参考了 UpSnap 5.4.1 官方 Compose 示例。这样发包直接使用宿主机的网络，便于处理局域网广播。
核心配置片段：
services:
upsnap:
image: ghcr.m.daocloud.io/seriousm4x/upsnap:5.4.1
container_name: base_upsnap
restart: unless-stopped
network_mode: host
cap_add:
- NET_RAW
cap_drop:
- ALL
security_opt:
- no-new-privileges:true
environment:
- TZ=Asia/Shanghai
- UPSNAP_HTTP_LISTEN=0.0.0.0:8090
volumes:
- /vol1/1000/volumes/upsnap/data:/app/pb_data这里保留当时的镜像版本、8090 端口和 NAS 数据目录。镜像使用了 DaoCloud 镜像地址，也可以按官方示例改用 ghcr.io/seriousm4x/upsnap:5.4.1；数据目录应按自己的磁盘布局调整。
UPSNAP_SCAN_RANGE 在官方示例中用于设备发现，手动填写设备时不必为了唤醒而额外写死扫描网段。
配置校验命令：
docker compose -f deploy/fnos/base/docker-compose.yml config --quiet校验结果无输出，退出码为 0，说明 Compose 语法通过。该步骤只验证配置结构，不代表 WOL 一定可用。
这是原部署文件的位置。独立保存为当前目录的 compose.yaml 时，可以用下面的命令检查并启动，再在浏览器打开 http://NAS的局域网IP:8090 添加设备：
docker compose -f compose.yaml config --quiet
docker compose -f compose.yaml up -d upsnap
docker compose -f compose.yaml logs --tail 100 upsnapWindows 侧检查命令
先确认当前在线时的有线网卡、MAC 和链路状态：
Get-NetAdapter | Format-Table -Auto Name,InterfaceDescription,Status,MacAddress,LinkSpeed关键输出已脱敏：
Name InterfaceDescription Status MacAddress LinkSpeed
以太网 Realtek PCIe GbE Family Controller Up 00-E2-69-**-**-8F 1 Gbps这个结果证明目标机器使用的是有线 Realtek 网卡，且 UpSnap 中填写的 MAC 与系统识别到的物理网卡一致。
确认 IP 和网关：
Get-NetIPConfiguration -InterfaceAlias '以太网' |
Format-List InterfaceAlias,IPv4Address,IPv4DefaultGateway,DNSServer关键输出已脱敏：
InterfaceAlias : 以太网
IPv4Address : {192.168.2.x}
IPv4DefaultGateway : {192.168.2.1}如果子网掩码为 255.255.255.0，该网段的广播地址应为 192.168.2.255。这说明 UpSnap 里 IP/掩码字段本身不是明显错误点。
网卡唤醒能力检查
检查 Realtek 驱动暴露的 WOL 和节能属性：
Get-NetAdapterAdvancedProperty |
Where-Object {
$_.DisplayName -match 'Wake|魔术|Magic|WOL|Shutdown|关机|唤醒|PME|Energy|节能|EEE|Green|绿色' -or
$_.RegistryKeyword -match 'Wake|Wol|Magic|PME|EEE|Energy|Green'
} |
Select-Object Name,DisplayName,DisplayValue,RegistryKeyword,RegistryValue |
Format-Table -Auto关键输出：
Name DisplayName DisplayValue RegistryKeyword
以太网 魔术封包唤醒 开启 *WakeOnMagicPacket
以太网 样式比对唤醒 开启 *WakeOnPattern
以太网 关机 网络唤醒 开启 S5WakeOnLan
以太网 节能乙太网路 开启 *EEE
以太网 环保节能 开启 EnableGreenEthernet
以太网 Advanced EEE 关闭 AdvancedEEE
以太网 网络唤醒和关机连接速度 10 Mbps 优先 WolShutdownLinkSpeed这个输出能得出两个结论：
- Windows 驱动侧的核心 WOL 选项已经开启，包括魔术包唤醒和 S5 关机网络唤醒。
- Realtek 的节能以太网和绿色节能仍处于开启状态，后续应作为影响关机链路的候选项处理。
再确认 Windows 是否允许该设备唤醒系统：
powercfg /devicequery wake_armed关键输出：
Realtek PCIe GbE Family Controller这说明该网卡已经在 Windows 的可唤醒设备列表中。
快速启动检查
检查快速启动注册表值：
Get-ItemProperty `
-Path 'HKLM:\SYSTEM\CurrentControlSet\Control\Session Manager\Power' `
-Name HiberbootEnabled -ErrorAction SilentlyContinue |
Select-Object HiberbootEnabled输出：
HiberbootEnabled
----------------
1单看这个值会怀疑 Windows 快速启动影响 WOL。但继续检查系统可用睡眠状态：
powercfg /a关键输出：
休眠
尚未启用休眠。
快速启动
休眠不可用。因此本次不能把快速启动作为已确认根因。注册表值存在，但系统当前休眠不可用，快速启动也不可用。
主板和 BIOS 证据
读取主板型号：
Get-CimInstance Win32_BaseBoard |
Select-Object Manufacturer,Product,Version,SerialNumber |
Format-List关键输出：
Manufacturer : MAXSUN
Product : MS-Challenger H610M-D
Version : V5读取 BIOS 信息：
Get-CimInstance Win32_BIOS |
Select-Object Manufacturer,SMBIOSBIOSVersion,ReleaseDate |
Format-List关键输出：
Manufacturer : American Megatrends International, LLC.
SMBIOSBIOSVersion : 5.27
ReleaseDate : 2023/9/27不同主板的选项名称不同，可能出现 Wake on LAN、PME 或 PCIe 唤醒等字样。例如 ASUS 的 WOL 设置说明使用 Power On By PCI-E。这个名称只用于帮助查找，不能据此把其他品牌的菜单路径套到这块铭瑄主板上。
最后解决：在 BIOS 中启用网卡唤醒
Windows 侧已经启用了魔术包唤醒和 S5 网络唤醒，但目标电脑关机后网口灯仍然熄灭。这个现象让我把排查重点转向主板，而没有继续反复修改 UpSnap 的设备记录。
最后在主板 BIOS 中启用网卡唤醒，保存设置并重新进入系统，再正常关机，问题就解决了。前后变化很直接：
- 修改前：关机后网口灯熄灭，UpSnap 无法唤醒电脑。
- 修改后：关机后网口灯仍亮，UpSnap 可以唤醒电脑。
复现这一步时，保持电脑电源线接通、电源开关开启，网线和交换机连接不变。在 BIOS 中打开网卡唤醒，保存后正常关机，先观察这台机器的网口灯，再从 UpSnap 发起唤醒，确认电脑实际启动。
网口灯是这次很有效的现场线索，但灯亮不能单独证明 WOL 已配置成功，灯灭也不能严格等同于整机完全断电。不同网卡有不同的指示灯和低功耗行为。Microsoft 的系统电源状态说明区分了 S5 软关机与 G3 机械断电：系统关机后仍可能保留部分待机供电，完全断开电源则无法接收网络唤醒请求。
因此，这次的结论是这台电脑需要在 BIOS 中启用网卡唤醒，Windows 网卡属性里的开关不能代替主板设置。没有留下 ErP、Fast Boot 或 Realtek 节能项变更后的对照记录，不能把它们也写成这次已经确认的原因。
其他机器仍然失败时怎样继续查
查主板手册时，可以留意原排查清单中的这些选项名称：
Wake On PME
Power On By PCI-E
Resume By PCI-E Device
PCI-E Device Wake Up
PME Event Wake Up还可以核对下面这些电源设置是否影响该机型关机后的网卡供电，不需要为了套用清单一次全部关闭：
ErP
EuP
Deep Sleep
Fast Boot原来的 Realtek 排查清单还包括以下两项；只有继续排查时才逐项调整、观察并记录结果：
节能乙太网路
环保节能如果 BIOS 和驱动设置已经核对，仍要区分 UpSnap 与发包路径的问题，可以从同一网段的 Linux 宿主机直接发送魔术包。下面保留原来的独立发包方案，TARGET_MAC 必须换成目标有线网卡的完整 MAC，广播地址也要按实际子网调整；它是排障方法，不是本次新增的成功测试日志：
docker run --rm --network=host alpine sh -c \
"apk add --no-cache awake && awake -b 192.168.2.255 -p 9 TARGET_MAC"awake 的命令说明中，-b 指定广播地址，-p 指定目标端口。若所用 Alpine 仓库没有这个包，改用宿主机已有的 WOL 工具；软件包安装失败不等于魔术包已经发出。若直接发包能唤醒而 UpSnap 不能，再回头查设备记录、广播地址和容器日志；如果两者都失败，再核对交换机、VLAN、网络隔离和目标机器电源状态。