mirror of
https://hubproxy.babadafafafafa.cn/https://github.com/mihomo-party-org/clash-party.git
synced 2026-09-20 08:03:39 +08:00
0e3116abe1
* fix: recover core, TUN and system proxy after the machine wakes up
Neither side handled suspend/resume: the app had no powerMonitor listener at
all, and the core's own component/power package (which registers
PowerRegisterSuspendResumeNotification on Windows) has no callers anywhere in
the core tree, so nothing reacted to a wake-up. After a long sleep users were
left with a running core that no longer routed traffic, and had to re-run a
latency test, refresh a subscription or restart the app to get back online.
On 'resume', once the network stack is back:
- if the core process is gone or its API no longer answers, restart it;
- if TUN is enabled but its adapter has disappeared from the OS interface
list, toggle tun.enable off and on. The core skips ReCreateTun whenever the
TUN config compares equal to LastTunConf, so an off/on cycle is the only
way to force the adapter to be rebuilt - this is exactly the "switch TUN
off and on again" workaround users already report;
- re-apply the system proxy when it is enabled (idempotent, and
triggerSysProxy already retries on its own while the machine is offline).
The TUN branch only fires when the adapter is provably missing, so machines
whose TUN survives the sleep see no interruption.
Closes #1933
Closes #727
(cherry picked from commit 5978a7f280a593421cf3b2d9ba3ec552d11dc40f)
* fix: reload the core config after the system resumes from sleep
Suspending the machine tears down the routes and the DNS-hijack rules that
the TUN device installs, but it does not kill the core process. After
resume the mixed-port proxy still answers while the TUN DNS listener no
longer does - #1231 reproduced exactly that with dig against the hijack
port - so name resolution falls back to the real upstream and the user
sees "no network after it has been running for a while" (#159, where
restarting the core is the reported workaround).
The app never listened for powerMonitor 'resume', so nothing rebuilt that
state. The manual workaround users found - open DNS settings and save -
goes through mihomoHotReloadConfig, and on the kernel side that is
executor.ApplyConfig, which re-runs updateDNS, updateTun, updateIPTables
and resolver.ResetConnection. Do the same automatically on resume.
Scoped to the case that is actually reported: only when TUN is enabled and
a core process is running. The reload is delayed 5s because the physical
interface is usually still down at resume and auto-detect-interface would
latch the wrong one; the pending timer is cancelled during shutdown.
Refs #1231, #159
(cherry picked from commit 831597dcf025bcece51ce98af89194514adb5da6)
* feat: re-apply the system proxy after the machine resumes (#240)
Waking from sleep or hibernation can leave the OS proxy settings cleared
while the app still believes the system proxy is on, so the user keeps
browsing unproxied without any indication. Nothing in the app listened for
powerMonitor 'resume'.
Re-issue the system proxy on resume when it is enabled in the config.
triggerSysProxy() already disables before enabling, so it is idempotent, and
it retries by itself when the network is not up yet.
Another Mihomo GUI
本项目认证稳定机场推荐：“狗狗加速”
狗狗加速 —— 技术流机场 Doggygo VPN
- 高性能海外机场，稳定首选，海外团队，无跑路风险
- Clash Party专属8折优惠码：party，仅有500份
- Party专属链接注册送 3 天，每天 1G 流量 免费试用
- 优惠套餐每月仅需 15.8 元，160G 流量，年付 8 折
- 全球首家支持Hysteria1/2 协议，集群负载均衡设计，高速专线，基于最新UDP quic技术，极低延迟，无视晚高峰，4K 秒开，配合Clash Party食用更省心！
- 解锁流媒体及 ChatGPT
- 官网：https://狗狗加速.com
特性
- 一键 Smart Core 规则覆写，基于 AI 模型自动选择最优节点 详细介绍请看 这里
- 开箱即用，无需服务模式的 Tun
- 多种配色主题可选，UI 焕然一新
- 支持大部分 Mihomo(Clash Meta) 常用配置修改
- 内置 Smart内核 与 Mihomo(Clash Meta) 内核
- 通过 WebDAV 一键备份和恢复配置
- 强大的覆写功能，任意修订配置文件
- 深度集成 Sub-Store，轻松管理订阅