曙光云 - 全球网络加速服务商

Clash Meta 休眠后订阅不更新怎么办？手动刷新与唤醒排查

更新于 2026-10-20 · shuguangcloud.shop

简答：合盖一晚后发现节点还是旧的，先不要急着修改 interval：据 mihomo Issue #3327 报告，proxy-providers 在系统休眠后可能不会立即补刷，唤醒后手动更新或重启内核可用于恢复和定位。若手动更新成功，重点查休眠后的定时触发；若手动更新失败，再查订阅地址、DNS、TLS、代理路径和返回格式。

定义：本文所说的“休眠后订阅不更新”，包含 mihomo 的 proxy-providers 定时拉取延迟，以及图形客户端 Profile 更新或系统后台限制导致的未更新，不把这几种机制当成同一个参数问题。

30 秒速查卡：先判断是哪一类问题

唤醒后订阅不更新的快速分流
现象优先判断先做什么
唤醒后手动更新马上成功，自动更新晚了更接近休眠后的定时触发延迟记录休眠前、唤醒后和实际更新时间；临时手动刷新
手动更新也失败更接近下载、解析或加载链路失败查 timeout、401、403、404、DNS、TLS 和 YAML 日志
只有锁屏或后台运行时失败更接近系统后台限制或客户端被挂起检查 Windows、Android 的后台任务权限；iOS 前台打开后手动更新

这是排查顺序，不是对每台设备必然出现的行为。先保留最后一份可用配置和 Provider 缓存，不要为了“重新导入”直接删除旧配置。

先分清 Profile 订阅和 proxy-providers

“订阅”在不同客户端里可能指两种对象，操作入口也不同。图形客户端的 Profile 或订阅列表通常代表整份远程配置；配置文件中的 proxy-providers: 则代表 mihomo 单独管理的代理集合。

两个更新入口的区别
对象识别方法更新方式应观察的结果
Profile 或远程配置客户端的“订阅”“配置”“Profile”列表在该列表中点击更新或右键更新；菜单名称以当前版本界面为准配置文件更新时间、配置名称或文件内容发生变化
mihomo proxy-providers配置中出现 proxy-providers:进入客户端的代理集合、Provider 或代理提供者入口，更新指定 ProviderProvider 的更新时间、节点数量或日志中的 Provider 更新记录变化

如果你使用的是图形客户端，先查看 Profile 列表中对应条目的“最后更新时间”，再查看 Provider 页面或日志。只修改 proxy-providers.interval，不能替代 Profile 的整份配置更新；反过来，Profile 更新时间变化，也不代表每个 Provider 都已经重新下载。

mihomo 官方配置文档说明，proxy-providers.interval 是更新 Provider 的时间，单位为秒；health-check.interval 是健康检查间隔，同样以秒计，但作用不同。MetaCubeX 官方 proxy-providers 配置文档

为什么休眠后会延迟：Issue #3327 报告了什么

截至 2026 年 10 月 20 日，mihomo Issue #3327 仍显示为 Open。报告者在 Linux 上使用最小配置复现，正式版 Mihomo Meta v1.19.32 和一个 Alpha 版本都出现了相同现象：设备休眠后，Provider 没有在唤醒瞬间刷新，而是在继续清醒约一个 interval 后才更新。这里的“约一个 interval 后刷新”是该 Issue 的复现记录，不是所有系统和版本都已确认的统一行为。mihomo Issue #3327：订阅更新因系统休眠未在正确时间触发

因此，修改 health-check.interval 通常不能解决 Provider 文件没有重新下载的问题；把 proxy-providers.interval 改短，也不能据此保证唤醒后立即补刷。Issue 中提出的墙钟判断、监听系统唤醒事件等内容属于报告者建议，是否已经进入你正在使用的内核版本，应以 mihomo 官方发布页和对应版本说明为准。

搜索时如果看到 Issue #3337，不要把它当作本问题的依据。该页面讨论的是 URL-test 代理组在节点失效后的自动切换问题，与休眠后 Provider 更新延迟不是同一个故障。

按证据排查：手动更新成功还是失败

  1. 记录环境：记下客户端名称、客户端版本、mihomo 内核版本、操作系统、休眠前时间、唤醒时间和 Profile 或 Provider 的最后更新时间。
  2. 先走正确入口：使用 Profile 的，在订阅或配置列表更新整份配置；使用 proxy-providers 的，在代理集合或 Provider 入口更新指定代理集合。不要把两个入口混用。
  3. 手动更新并看日志：更新成功时，观察更新时间、节点数量和 Provider 内容是否变化；更新失败时，搜索 timeout、401、403、404、dns、tls、yaml 和 provider。
  4. 分别测试更新路径：如果配置支持，分别尝试直连更新和通过代理更新。当前代理失效时，通过代理下载订阅可能形成循环；直连被 DNS、TLS 或网络环境阻断时，也可能需要客户端支持的代理更新路径。
  5. 保留旧配置：如果更新后节点数量变成零，先恢复或保留旧的可用文件，再检查订阅返回内容是否仍是 mihomo 支持的格式。不要把含有 Token 的完整订阅地址发到公开工单、截图或群聊中。

如果手动更新成功，但休眠后自动更新延迟，可以先把“唤醒后手动更新”作为临时恢复方式；如果手动更新也失败，就不要继续围绕休眠定时器改参数，应转向订阅请求和解析链路。

Windows：用唤醒事件触发 Provider 刷新

Windows 可以用任务计划程序监听系统日志中的 Power-Troubleshooter、事件 ID 1，在设备从睡眠恢复后调用 mihomo 外部控制器。该事件配置方式在 Microsoft Q&A 的任务计划程序示例中有说明；不同睡眠类型和硬件可能记录不同事件，创建后应实际测试。Microsoft Q&A：使用 Power-Troubleshooter 事件触发唤醒任务

  1. 先在 mihomo 或客户端的“外部控制”“Clash 设置”或配置文件中查看真实的 external-controller 地址和端口，并确认 secret。不要默认使用 127.0.0.1:9090；Issue #3327 的复现配置实际使用过 127.0.0.1:19090。
  2. 先手动验证刷新接口。下面的 PowerShell 脚本使用 curl.exe，Provider 名称会先做 URL 编码；请将地址、Provider 名称和 secret 文件路径换成自己的值：
    $api = "http://127.0.0.1:19090"
    $providerRaw = "YOUR_PROVIDER"
    $provider = [uri]::EscapeDataString($providerRaw)
    $secret = (Get-Content "$env:USERPROFILE\.mihomo-secret" -Raw).Trim()
    curl.exe --fail-with-body -sS -X PUT -H "Authorization: Bearer $secret" "$api/providers/proxies/$provider"
  3. 将脚本保存为本地文件，例如 C:\Tools\refresh-mihomo.ps1。secret 文件只保存 Token，并限制普通用户访问；不要把真实 Token 写进公开脚本。
  4. 打开“任务计划程序”，选择“创建任务”。在“触发器”中选择“发生事件时”，日志选“系统”，来源填 Power-Troubleshooter，事件 ID 填 1；在“操作”中调用 powershell.exe，参数填写 -NoProfile -ExecutionPolicy Bypass -File C:\Tools\refresh-mihomo.ps1。
  5. 先让电脑睡眠再唤醒，查看任务历史和 mihomo 日志。如果客户端或内核尚未恢复监听端口，可在脚本中加入短暂重试；如果你的设备没有记录该事件，应以事件查看器实际记录为准，不要把此触发器当作所有 Windows 设备的保证。

接口文档规定，更新指定代理集合使用 PUT /providers/proxies/{providers_name}，成功响应为 HTTP 204。Provider 名称含中文、空格或特殊字符时必须 URL 编码，否则可能得到 404。MetaCubeX 官方 API 文档

Linux：使用 systemd 唤醒钩子调用刷新脚本

systemd 官方文档说明，放在 /usr/lib/systemd/system-sleep/ 的可执行文件会在休眠前后被调用；恢复后第一个参数为 post。官方同时提醒，这类脚本属于本地使用的方式，应用若能使用更正式的唤醒接口，应优先采用应用接口。systemd-suspend.service 官方文档

  1. 先确认 API 地址、端口、secret 和 Provider 名称。将 secret 保存到只有运行 mihomo 的用户可读的文件，例如 /etc/mihomo/secret，执行 chmod 600 /etc/mihomo/secret。
  2. 创建文件 /usr/lib/systemd/system-sleep/mihomo-provider-refresh，写入以下最小示例；它只在恢复后执行，并等待控制端口短暂可用：
    #!/bin/sh
    [ "$1" = "post" ] || exit 0
    api="http://127.0.0.1:19090"
    provider_raw="YOUR_PROVIDER"
    provider=$(python3 -c 'import urllib.parse,sys; print(urllib.parse.quote(sys.argv[1], safe=""))' "$provider_raw")
    secret=$(cat /etc/mihomo/secret)
    i=0
    while [ "$i" -lt 20 ]; do
    if curl --fail-with-body -sS -X PUT -H "Authorization: Bearer $secret" "$api/providers/proxies/$provider"; then
    exit 0
    fi
    i=$((i+1))
    sleep 2
    done
    exit 1
  3. 执行 chmod 700 /usr/lib/systemd/system-sleep/mihomo-provider-refresh，然后测试一次 systemctl suspend，唤醒后查看 mihomo 日志和 systemd 日志。
  4. 如果 Provider 名称只含字母、数字、下划线和短横线，也建议保留编码步骤；名称含中文、空格或特殊字符时，不编码很容易把接口错误误判成 mihomo 故障。
  5. 回滚时删除该钩子文件，或执行 chmod 600 后移出该目录；不要只删除 secret 而保留会持续报错的脚本。

这个方案只负责唤醒后发起一次更新，不能修复订阅地址失效、认证失败、TLS 错误或 Provider 内容解析失败。

macOS、Android 和 iOS 的处理边界

macOS：合盖唤醒后先前台打开客户端，分别查看 Profile 的最后更新时间和 Provider 的更新时间，再执行对应入口的手动更新。若前台打开后才恢复，需继续区分客户端后台行为和 mihomo 定时器问题；本文不把 iOS 后台文档当作 macOS 行为依据。

Android：锁屏后不更新时，先进入系统设置中的应用、电池或后台使用页面，找到实际运行 mihomo 的客户端，取消“受限制”的后台策略，并确认 VPN 常驻通知和自启动没有被清理工具关闭。Android 官方文档说明，Doze 和 App Standby 会延迟后台网络、任务和同步；恢复后台权限后，再前台手动更新一次。Android Developers：Doze 与 App Standby

iOS：不要把自动订阅更新当成精确到点的任务。Apple 官方文档说明，应用进入后台后通常会被挂起，只有符合系统支持的后台执行模式或后台任务条件时才可能恢复；重要配置应在打开客户端后前台手动更新。Apple Developer Documentation：应用后台执行流程

排查自查清单

  • 是否明确自己更新的是 Profile，还是 proxy-providers？
  • 是否分别记录了 Profile 更新时间、Provider 更新时间和节点数量？
  • 是否把 proxy-providers.interval 与 health-check.interval 分开检查？
  • 唤醒后手动更新是否成功？日志中有没有 timeout、401、403、404、DNS、TLS 或 YAML 错误？
  • 是否确认了实际 mihomo 内核版本，而不是只看图形客户端版本？
  • 是否查看了官方发布页和 Issue 状态，避免把仍处于报告阶段的问题当成已修复？
  • 是否保留最后一份可用配置，并对订阅 Token 做了脱敏？
  • 如果使用 API，是否核对了真实控制端口、secret、Provider 名称和 URL 编码？

本文是第三方使用指南，不是客户端或订阅服务的官方页面；具体菜单、后台策略和版本行为以对应项目的官方说明为准。

如果你需要进一步排查跨境办公线路，可在完成客户端和订阅更新检查后，查看边界云加速官网的服务说明。

常见问题

把 proxy-providers.interval 改短，能彻底解决休眠后不更新吗？

不能保证。MetaCubeX 文档只定义它是 Provider 更新间隔；Issue #3327 报告的是休眠后没有立即补刷。因此改短可能改变正常运行时的更新频率，但不能证明能修复唤醒后的延迟。

Profile 订阅更新和 proxy-providers 更新有什么区别？

Profile 更新通常刷新图形客户端管理的整份远程配置；proxy-providers 更新只刷新配置中的某个代理集合。前者应在订阅或配置列表操作，后者应在 Provider 或代理集合入口操作，不能只改 interval 代替另一种更新。

为什么重启 mihomo 后订阅又更新了？

重启会重新执行启动阶段的 Provider 加载流程，所以可能暂时触发一次拉取。Issue #3327 的复现记录观察到重启可以恢复，但这不等于订阅地址、后台权限或内核问题已经永久解决。

Windows 休眠后一定会出现这个问题吗？

不一定。Issue #3327 的复现环境是 Linux，Windows 还要考虑睡眠类型、客户端后台行为和任务调度。可用唤醒前后时间、手动更新结果和日志进行判断，不能把 Linux 的复现直接当成所有 Windows 设备的结论。

Provider 名称含中文时，API 刷新为什么可能返回 404？

接口路径中的 Provider 名称需要作为 URL 路径的一部分传递。中文、空格或特殊字符如果未做 URL 编码，服务端可能无法识别路径；应先用 URL 编码，再确认控制端口、Provider 名称和 secret。

Android 锁屏后订阅不更新，应该先改配置吗？

先检查电池优化、后台限制、自启动和 VPN 常驻通知。Android 官方说明 Doze 和 App Standby 会延迟后台网络与任务；如果客户端进程没有运行，修改 interval 也没有执行机会。

iOS 能保证在后台按计划更新订阅吗？

不能作这种保证。Apple 官方文档说明，应用进入后台后通常会被挂起，是否恢复执行取决于系统支持的后台模式、任务调度和客户端实现。重要订阅应在打开客户端后前台手动更新。

相关阅读

参考资料

  1. mihomo Issue #3327：订阅更新因系统休眠未在正确时间触发
  2. MetaCubeX 官方 proxy-providers 配置文档
  3. MetaCubeX 官方 API 文档
  4. MetaCubeX mihomo 官方发布页
  5. mihomo Issue #3337：URL-test 代理组自动切换问题
  6. Microsoft Q&A：使用 Power-Troubleshooter 事件触发唤醒任务
  7. systemd-suspend.service 官方文档（freedesktop.org）
  8. Android Developers：Doze 与 App Standby
  9. Apple Developer Documentation：应用后台执行流程