本文目录
先确认是否匹配这次 EasyTier 失联
Mihomo v1.19.31 于 2026 年 9 月 14 日发布，正式加入了 type: easytier 出站。随后提交的 issue #3214 记录了一种特定现象。
报告中，Mihomo 和其他代理仍正常，只有 EasyTier 出站变成 alive: false，延迟历史为 0，测速持续 Error 或 Timeout，对端的 peer 列表也看不到这台 Mihomo 节点。
这是一份 Linux/amd64、with_gvisor、OpenWrt/Kwrt 与 ShellCrash 环境中的用户报告，不代表所有 v1.19.31、所有前端或所有平台都会遇到。报告者当天观察到三次，只有第一次明确发生在 EasyTier 对端重启之后，因此不能把对端重启写成唯一触发条件。
如果所有代理都不可用、Mihomo 无法启动、配置加载失败，或只有 DNS 和规则命中异常，就不属于这份报告已经描述的范围。先按首条错误处理，不要仅凭一个 alive: false 判断根因。
现象与判断
| 看到的情况 | 是否匹配 | 下一步 |
|---|---|---|
| 只有 EasyTier 出站 alive: false，其他代理正常 | 较匹配 | 继续核对延迟历史和对端 peer |
| 延迟历史为 0，测速 Error 或 Timeout | 需要结合其他信号 | 确认测试流量确实命中该出站 |
| 对端 peer 列表中预期 hostname 消失 | 匹配报告中的关键观察 | 保存状态后再做受控重启 |
| Mihomo 整体无法启动或所有出站失败 | 不匹配 | 先查配置、服务、网络和端口 |
| 只有某个域名或 DNS 请求失败 | 证据不足 | 检查规则命中、DNS 与目标服务 |
先排除按需启动和配置条件
Mihomo 官方文档说明，EasyTier 出站只有在规则、策略组或其他路由方式把流量送到它时才启动。刚加载配置、尚未有请求命中时看不到活跃实例，可能只是正常的按需行为，不是静默失联。
先固定一个可重复的测试目标和一个明确选择 EasyTier 的策略组，让请求实际走向该出站。若没有配置 listeners，文档要求至少提供一个 peers；overlay 地址只支持 IPv4，ip-version 只决定底层 peer 连接使用 IPv4 还是 IPv6，不能用它开启 overlay IPv6。
本轮只验证启动条件，不同时修改密钥、peer 地址、策略组和路由。一次改多个变量，即使恢复也无法区分是配置修正还是实例重建起了作用。
先建立可比较的测试
确认运行版本
记录 Mihomo v1.19.31、平台、架构、构建标签和由哪个前端或服务管理器托管。
让流量命中 EasyTier
临时固定一个策略选择并发起真实请求，确认请求不是被规则送到 DIRECT 或其他代理。
核对最小配置条件
没有 listeners 时确认至少存在一个 peers；overlay 地址保持 IPv4，并正确理解 ip-version 的作用。
保留其他代理作对照
用同一目标测试一条普通代理，判断是单个 EasyTier 出站异常还是整个 Mihomo 路径异常。
重启前记录出站与 peer 状态
如果测试流量已经命中 EasyTier，仍出现 alive: false、历史延迟全为 0 和连续超时，先保存现场再重启。记录出站名称、状态、测速时间、首条相关日志，以及 EasyTier 对端 peer 列表中是否还有预期 hostname。
报告者使用 easytier-cli peer 核对对端节点，并看到异常实例消失。你可以使用当前 EasyTier 部署提供的 peer 查看入口做同样的只读确认，但不要为了复现运行来源不明的脚本或修改生产 peer。
一次 curl 的 Empty reply from server 也不能证明认证和 overlay 已经正常；它最多说明 TCP 连接后没有收到有效响应。
分享证据前删除 network-secret、私钥、peer 公钥、Controller secret、公网地址和订阅信息。保留原始私有副本，公开的只使用脱敏版本。
出站从未承载流量
先完成按需启动测试，不进入重启结论。
EasyTier 异常，普通代理与 Mihomo 进程正常
保存 alive、history、测速和 peer 状态，继续做最小重启。
peer 地址的底层端口不可达
先排查防火墙、端口、地址和对端服务，不把问题归为实例静默失联。
peer 仍存在，但 overlay 目标不可达
继续检查路由、exit-node、proxy-networks 和目标 IPv4，不只看延迟。
所有出站同时失败
先恢复 Mihomo 配置、系统网络或托管服务。
先用受控重启恢复当前连接
issue #3214 的报告者在等待超过 30 分钟仍未恢复后，重启 Mihomo 让 EasyTier 出站重新可用，对端 peer 列表也重新出现该节点。这是单一环境已经观察到的临时恢复方法，不是维护者对所有平台的保证，也不能代替后续修复。
先确认路由器或远程主机仍有本地控制台、旁路管理入口或其他不会经过该 EasyTier 出站的管理路径。然后通过当前前端、ShellCrash、systemd 或设备管理界面只重启 Mihomo；不同托管方式的命令不同，不要复制一条不适合本机的服务命令。
重启后使用同一策略、同一目标和同一网络重新发起请求，再对照 alive、history、延迟和 peer 列表。若恢复，只能记录“本次重启恢复”；若仍失败，就回到端口、配置、对端服务和路由检查，不连续重启掩盖首条错误。
完成一次最小恢复
保存当前证据
记录版本、出站状态、测速结果、peer 列表和首条相关日志，并制作脱敏副本。
确认备用管理入口
远程设备必须先确认重启核心后仍能管理，避免把唯一的控制路径一起中断。
只重启 Mihomo
使用当前托管工具的正常入口重启核心，不同时重启整台路由器、修改配置或更换 peer。
重复同一组验证
确认 EasyTier 重新启动、peer 回来、延迟恢复，并完成一次真实 overlay IPv4 请求。
稳定版和 Alpha 应该怎么选
v1.19.31 正式版早于修复合并，因此不包含本次自动重建逻辑。PR #3215 已于 2026 年 9 月 15 日合入 Alpha，最终提交为 fbb6742；2026 年 9 月 16 日的滚动 Prerelease-Alpha 也明确列出“在静默 overlay 失败后重启 EasyTier 出站”的修复。
最终实现没有增加定时测速或把每次超时都当作重启信号。EasyTier 自身继续负责 peer 重连，Mihomo 消费事件流；只有事件流关闭、实例确实停止时，才重建 Host 和 Instance。这个范围比“任何超时都自动修复”窄。
Alpha 是滚动标签，之后会指向新的提交。决定试用时要同时记录 fbb6742、下载时间、资产文件名和当前构建标签，不能只写“最新版 Alpha”。无人值守路由器、没有备用管理入口或无法快速回滚的设备，更适合留在稳定版等待后续正式 Release 明确包含该修复。
版本选择
| 当前情况 | 建议 | 原因 |
|---|---|---|
| 尚未出现匹配现象 | 继续使用 v1.19.31 稳定版 | 不为单一公开报告主动切换预发布版 |
| 偶发失联，受控重启可以接受 | 暂留稳定版并记录频率 | 等待正式 Release 给出明确修复边界 |
| 频繁失联，有维护窗口和备用入口 | 评估包含 fbb6742 的 Alpha | 可以验证已合入的自愈逻辑并随时回退 |
| 远程无人值守或无法恢复旧核心 | 不要直接追滚动 Alpha | 预发布回归可能同时影响其他出站和管理路径 |
验证 Alpha 是否能自动恢复
测试 Alpha 前先保存 v1.19.31 稳定版完整二进制、准确架构与构建变体，并备份配置和托管工具中的核心选择。只使用 Mihomo 官方 Prerelease-Alpha 资产，确认运行提交包含 fbb6742；不要把新的核心文件和旧版本组件混合复制。
先让真实流量命中 EasyTier，确认 peer 已出现且 overlay IPv4 请求成功。只有在维护窗口、对端可控且有备用管理入口时，才让测试 peer 短暂停止后恢复，观察是否在不重启 Mihomo 的情况下重新出现 peer、恢复延迟和真实请求。
PR 作者在 disable-p2p: true、单一路径的本地测试中看到对端恢复后约一秒出现 peer_added，Mihomo PID 没有变化。这支持该特定测试中的自愈设计，但不能承诺所有 P2P、中继、多路径或不稳定网络都在一秒内恢复。多路径网络也可能根本没有明显断流。
Alpha 自愈验证清单
- 运行版本可以对应到包含 fbb6742 的 Alpha 提交，而不是只记录滚动标签
- 测试请求确实命中 EasyTier 出站，普通代理仍可作为对照
- 中断前 peer、alive、history、延迟和真实 overlay IPv4 请求都已记录
- 对端恢复后无需重启 Mihomo，预期 peer 能再次出现
- 延迟历史恢复，真实 TCP 请求成功；需要 UDP 时另做真实 UDP 验证
- Mihomo PID 未变化，日志没有反复重建或错误循环
- 其他出站、基础联网和设备管理入口没有回归
- 稳定版二进制、配置备份和恢复步骤仍然可用
Alpha 异常就完整回退稳定版
如果 Alpha 无法启动、CPU 或内存异常、普通代理出现回归，或 EasyTier 仍不能恢复，先停止继续改配置。关闭 Mihomo 后恢复升级前保存的 v1.19.31 完整二进制和原配置，再通过同一托管入口重新启动。
回退后先确认版本和配置加载，再验证普通代理、EasyTier 出站、overlay IPv4 与管理入口。不要只复制旧库文件、插件或单个模块到 Alpha 目录，也不要把 issue 报告者使用独立 EasyTier Core 加 SOCKS5 的替代架构写成维护者推荐。
稳定版回退会重新失去 fbb6742 的自愈逻辑。若失联仍会复发，可以保留受控重启作为临时恢复，并等待后续稳定 Release；不要通过不停改 peer、密钥和路由来掩盖可重复的版本差异。
回退完成标准
- 当前运行的是原先保存的 v1.19.31 稳定版和正确构建变体
- 原配置、策略组、EasyTier peer 与托管方式已经恢复
- 普通代理和基础网络请求正常
- EasyTier 出站能按需启动并完成真实 overlay IPv4 请求
- 设备本地与远程管理入口仍可使用
- Alpha 的提交、现象、日志与回退结果已经脱敏记录
- 没有混用不同版本的二进制或组件
以后以正式 Release 判断修复边界
截至 2026 年 9 月 16 日，当前稳定版仍是 v1.19.31，EasyTier 静默失联后的自动重建只在 Alpha 提交 fbb6742 中有明确记录。后续要以 Mihomo 正式 Release 是否包含该提交或等价修复为准，不猜测下一个版本号，也不把 issue 关闭状态当作已经发布。
正式版发布后，仍要用相同策略、相同 peer 和相同测试目标复核一次正常启动、短时中断、自愈、普通代理与回退。Release 说明、运行版本和本机结果三者一致，才能撤销临时重启或 Alpha 测试方案。
继续向项目反馈时，应提供平台、架构、构建标签、最小脱敏配置、EasyTier 与普通代理对照、alive/history、peer 变化和首条相关日志。不要公开 network-secret、私钥、Controller secret、订阅或完整公网拓扑。