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