ClashBar 断网重连后无法联网怎么办？
简答：如果 ClashBar 断网重连后图标正常、内核在运行但所有节点超时，先关闭系统代理或 TUN，确认 macOS 直连网络是否真的恢复；再彻底退出并重新打开 ClashBar。若问题反复，检查日志和版本：公开 Issue #127 显示 v0.3.6 仍可能把 NWPath.satisfied 当成网络已恢复，建议备份配置后升级到发布页当前版本，并保留旧版本回滚方案。
定义：ClashBar 断网重连 Bug，是指 macOS 恢复 Wi-Fi 或热点后客户端判断网络已恢复并重新启动内核，但实际链路、DNS、TUN 句柄或上游连接仍不可用，最终表现为内核运行而节点全部超时。
先试这三步：判断是 macOS 断网还是 ClashBar 假恢复
本站是第三方使用指南站，不是 ClashBar 官方。遇到断网重连后无法联网，先不要反复切换节点，也不要立即删除配置。按下面顺序一次只改一个变量，通常能先判断故障层级。
| 步骤 | 怎么做 | 预期结果 | 失败后下一步 |
|---|---|---|---|
| 1. 暂停接管 | 在 ClashBar 中先关闭系统代理；如果启用了 TUN，也先关闭 TUN。 | 关闭后 macOS 其他应用可以直连上网，说明问题更可能在客户端接管、内核或配置层。 | 仍不能上网，先检查 Wi-Fi、热点、网关和 DNS，不要把故障归因于节点。 |
| 2. 测试直连 | 在终端运行 ping -c 2 1.1.1.1、dig baidu.com，再用浏览器访问一个平时可访问的网站。 | 至少有一项直连测试恢复，说明基础链路可能已恢复；浏览器仍失败时继续检查 DNS、系统代理和路由。 | 全部超时，先重新连接 Wi-Fi 或热点，确认网关可达后再启动 ClashBar。 |
| 3. 重启应用而非只重启节点 | 退出 ClashBar，确认菜单栏进程消失后重新打开，再启动内核并测试一个节点。 | 节点恢复且日志不再持续出现 504 或 timeout，说明可能是旧内核状态、TUN 句柄或恢复流程残留。 | 仍然全超时，记录版本、macOS、网络类型和日志，进入后文的分层排查。 |
公开 Issue #127 描述的典型现象正是“图标正常、内核在跑、TUN 已开启，但所有节点一直超时”。该 Issue 于 2026 年 10 月 27 日提交，报告环境为 ClashBar v0.3.6、macOS 27.0.1 和 arm64；它属于公开问题反馈，不等于所有设备都会复现。查看 Issue #127
为什么会出现“内核启动了，但网络仍不通”
根据 Issue #127 的描述，ClashBar 使用 NWPathMonitor 的 satisfied 状态判断网络恢复，但该状态并不能单独证明目标站点、DNS 或代理节点已经可以访问。报告中的日志显示，客户端在判定网络恢复后启动内核和 TUN，随后出现 API request failed (504)、规则提供者请求超时以及节点延迟全部超时。这里应理解为一个待修复或待确认的实现问题，而不是已经由项目维护者确认的普遍故障。Issue #127 的现象与日志
同时，ClashBar 的更新记录还涉及另一类相关但不同的问题：v0.2.5 修复了 macOS 休眠断网后 TUN 或 UDP Socket 旧句柄失效、产生 socket operation on non-socket 的问题；v0.2.4 则修复了断网期间 WebSocket 轮询未及时取消造成的重连风暴。遇到这两类日志时，应优先确认版本，而不是只更换节点。查看 ClashBar 更新记录
因此，断网重连排查要区分三个层级：第一是 macOS 是否真的恢复了外网；第二是 TUN、系统代理和内核是否处于一致状态；第三是节点、规则提供者或远程主机本身是否可用。只有直连正常后，才有必要继续判断节点问题。
macOS 终端怎么确认故障在哪一层
1. 先查基础链路和 DNS
在关闭 ClashBar 系统代理与 TUN 后执行以下检查。命令只用于当前设备的排查，示例目标不是测速或可用性排名。
ping -c 2 1.1.1.1dig baidu.comcurl -I --max-time 8 https://www.baidu.com
如果 IP 测试、DNS 查询和 HTTPS 请求都失败，优先检查 Wi-Fi、手机热点、网关或运营商链路。需要注意，IP 连通测试只能帮助隔离基础链路，不能证明 HTTPS 网页一定能访问；HTTPS 还涉及 DNS、SNI、证书和目标站点响应。
2. 再看 ClashBar 是否仍接管流量
重新打开 ClashBar 前，确认没有其他 mihomo 或 Clash 类客户端同时接管系统代理。项目 README 明确提示，同一时间只应让一个客户端接管系统代理；系统代理依赖放在 /Applications 中的 App，首次启用还可能需要管理员授权。查看项目 README 的安装与系统代理说明
如果退出 ClashBar 后仍无法直连，不要继续切换节点。先在 macOS 系统设置中确认当前 Wi-Fi 服务仍然连接，必要时断开后重新连接网络，再重复上面的直连测试。
3. 最后查看日志中的关键词
get delay: all proxies timeout：表示当前延迟探测没有得到可用代理响应，但还需要结合直连测试判断是节点问题还是本地链路问题。socket operation on non-socket：更接近休眠唤醒、TUN 或 UDP Socket 旧句柄失效方向，先确认是否低于 v0.2.5 或是否长期未升级。相关修复记录- 大量 Provider timeout：说明规则提供者刷新失败；如果直连本身不通，先恢复基础网络，不要把连续报错直接判断为规则文件损坏。
- 内核在运行但所有节点超时：与 Issue #127 的现象相似，优先执行“关闭接管—直连测试—退出重开”的顺序。
升级 ClashBar 前后的检查与回滚
截至 2026 年 10 月 28 日，项目 Releases 页面展示的较新版本为 v0.3.6；但公开 Issue #127 的报告环境同样是 v0.3.6，因此不能把“升级到 v0.3.1 或更高版本”写成已经彻底解决当前断网重连问题。v0.3.1 的更新记录确实提到重构网络恢复流程、断网时暂停内核与轮询、网络恢复后继续运行，但后续公开反馈显示仍需按具体环境验证。查看 Releases 页面 查看 v0.3.1 更新记录
- 备份：先保留 ClashBar 配置和日志目录。项目 README 给出的运行时数据目录是
~/Library/Application Support/clashbar，不要在未备份前使用清除数据的卸载方式。查看运行时目录说明 - 核对芯片：在“关于本机”确认 Apple 芯片或 Intel，再从 Releases 页面选择对应的 DMG。发布页同时提供带内置 Mihomo 内核和无内核版本，普通用户应先核对自己原来使用的类型，避免升级后把“应用问题”与“内核缺失”混在一起。查看版本与安装包说明
- 替换应用：退出旧版 ClashBar，把新版 App 放入
/Applications，重新启动后先不打开系统代理，先启动内核、选择节点并测试。 - 验证：验证顺序应为：macOS 直连正常、ClashBar 内核启动、节点延迟能返回、浏览器访问正常、最后再打开系统代理或 TUN。
- 回滚：如果升级后更差，退出新版，恢复此前保存的 App 和配置，再重复直连测试。不要同时运行两个版本或两个代理客户端。
如果你使用 Homebrew，项目 README 只明确给出了安装方式 brew tap Sitoi/tap 和 brew install --cask clashbar；具体更新行为应以当前发布说明和本机 Homebrew 输出为准，不建议照抄来源不明的第三方更新命令。项目 README 安装说明
哪些情况暂时不要归因于 ClashBar Bug
- 关闭 ClashBar 后 macOS 仍不能访问互联网：先查 Wi-Fi、热点、网关、DNS 或系统网络服务。
- 只有某一个节点超时，其他节点可用：优先检查该节点或对应上游，不足以证明客户端恢复逻辑异常。
- 只有某个规则提供者更新失败，但已缓存规则仍能使用：应先记录 Provider 地址和错误时间，不要立即删除全部配置。
- 升级后菜单或代理权限异常：确认 App 位于
/Applications，并检查首次开启系统代理时是否完成管理员授权。 - 日志中出现与本文不同的内核启动错误：本文不覆盖所有 Mihomo、TUN、证书和订阅问题，需按具体日志字段另行定位。
目前没有足够证据证明某个节点服务商、订阅来源或 GitHub 下载入口一定异常；遇到这类情况应保留错误时间、网络类型、客户端版本和最小日志片段，不要公开完整订阅链接、Token 或私钥。
结论：怎样判断已经恢复
ClashBar 断网重连后恢复正常，至少应同时满足四项：关闭客户端后 macOS 能直连；重新启动后内核和 TUN 状态一致；至少一个节点的延迟探测不再全部超时；开启系统代理后浏览器和目标应用均能访问。只有看到菜单栏图标正常，不能作为恢复标准。
如果每次 Wi-Fi 切换、热点重连或休眠唤醒后都复现，即使升级到当前发布版本仍存在，也应把它记录为可复现环境问题：写明 macOS 版本、ClashBar 版本、芯片架构、是否 TUN、网络类型，以及日志中的首个错误时间点，再关注项目 Issue 和更新记录。
常见问题
ClashBar 断网重连后必须重启电脑吗？
不一定。先关闭系统代理和 TUN，确认 macOS 直连恢复，再彻底退出并重新打开 ClashBar。只有在系统网络服务本身异常、应用无法退出或多次重连后仍无法恢复时，才把重启 macOS 作为最后一步。
为什么 ClashBar 显示网络恢复，但节点全部超时？
公开 Issue #127 报告了类似现象：客户端依据 NWPath.satisfied 判断网络恢复，但实际链路仍不可用，内核和 TUN 虽然启动，节点延迟却全部超时。这个 Issue 是公开个案，不能直接推断所有版本都会复现；应先做直连测试，再检查日志和版本。
升级到 ClashBar v0.3.1 以上就能解决断网重连吗？
不能作绝对保证。v0.3.1 的更新记录提到重构网络恢复流程，后续发布页显示已有更新版本，但 2026 年 10 月 27 日的公开 Issue #127 仍以 v0.3.6 报告类似问题。升级值得尝试，但应备份配置并保留回滚方案。
看到 socket operation on non-socket 应该怎么处理？
先确认是否发生在 macOS 休眠唤醒或断网停服之后。ClashBar v0.2.5 的更新记录明确涉及 TUN 和 UDP Socket 旧句柄失效问题；如果版本较旧，优先备份后升级。若已是新版本仍复现，应记录完整环境和首个错误时间点。
可以直接删除 ClashBar 配置重新导入吗？
不建议作为第一步。先保存配置、日志和运行时目录，再用关闭接管、直连测试、退出重开的顺序排查。删除配置可能让原本的网络状态问题与订阅、规则或节点问题混在一起，也会增加回滚难度。