How to Handle a Lost EasyTier Outbound Connection in Mihomo v1.19.31

With Mihomo still running and other proxies working, record whether EasyTier shows alive: false, a latency history of 0, persistent Error or Timeout results, and no entry for this node in the remote peer list. That combination matches the symptoms in issue #3214.

This is a user report from a Linux/amd64, with_gvisor, OpenWrt/Kwrt, and ShellCrash environment. It does not mean that every v1.19.31 installation, frontend, or platform will encounter the issue. The reporter observed it three times that day, and only the first occurrence was explicitly after the remote EasyTier endpoint restarted, so that restart cannot be described as the sole trigger.

If all proxies are unavailable, Mihomo cannot start, the configuration fails to load, or only DNS and rule matching are abnormal, the situation falls outside the scope described by this report. Address the first error first; do not infer the root cause from alive: false alone.

Mihomo's official documentation states that an EasyTier outbound starts only when a rule, proxy group, or another routing method sends traffic to it. If the configuration has just loaded and no request has matched it yet, the absence of an active instance may simply be normal on-demand behavior, not a silent connection loss.

First choose a repeatable test target and a proxy group that explicitly selects EasyTier so requests actually go to that outbound. If no listeners are configured, the documentation requires at least one peers entry. The overlay addresses support only IPv4; ip-version determines only whether the underlying peer connection uses IPv4 or IPv6 and cannot enable overlay IPv6.

In this pass, verify only the startup conditions; do not change the secret, peer address, proxy group, and routing at the same time. If multiple variables change at once, even a recovery cannot show whether a configuration correction or instance recreation was responsible.

Test a regular proxy against the same target to determine whether a single EasyTier outbound is abnormal or the entire Mihomo path is affected.

If test traffic has already reached EasyTier but alive: false, a latency history consisting entirely of 0 values, and repeated timeouts remain, preserve the current state before restarting. Record the outbound name, status, latency-test time, first relevant log entry, and whether the expected hostname is still present in the remote EasyTier peer list.

The reporter used easytier-cli peer to check the remote nodes and saw that the affected instance had disappeared. You can perform the same read-only check through the peer viewing interface provided by your current EasyTier deployment, but do not run scripts from unknown sources or modify a production peer merely to reproduce the issue.

A single curl result of Empty reply from server does not prove that authentication and the overlay are working normally; at most, it shows that no valid response was received after the TCP connection was established.

Before sharing evidence, remove the network-secret, private keys, peer public keys, Controller secret, public addresses, and subscription information. Keep the original private copy and use only a redacted version publicly.

After waiting more than 30 minutes without recovery, the reporter in issue #3214 restarted Mihomo, which made the EasyTier outbound available again and restored the node to the remote peer list. This is a temporary recovery method observed in one environment, not a maintainer guarantee for every platform, and it does not replace a subsequent fix.

First confirm that the router or remote host still has a local console, an out-of-band management interface, or another management path that does not use this EasyTier outbound. Then restart only Mihomo through the current frontend, ShellCrash, systemd, or device-management interface. Commands differ by hosting method, so do not copy a service command that is unsuitable for the local system.

After the restart, make another request with the same policy, target, and network, then compare alive, history, latency, and the peer list. If it recovers, record only that this restart restored it. If it still fails, return to checking the port, configuration, remote service, and routing; do not conceal the first error with repeated restarts.

Confirm that EasyTier starts again, the peer returns, latency recovers, and one real overlay IPv4 request completes.

Mihomo v1.19.31 was released on 9/14/2026 and officially added the type: easytier outbound. The subsequently filed issue #3214 documented a specific symptom.

The v1.19.31 stable release predates the fix merge and does not include this automatic recreation logic. PR #3215 ended at commit fbb6742, which first entered the rolling Alpha; the Mihomo v1.19.32 stable-release notes also include this fix.

Mihomo receives EasyTier runtime events and rebuilds Host and Instance only when the event stream has closed and the instance has actually stopped. EasyTier still handles peer reconnection. The fix adds no scheduled latency testing and does not restart on every timeout; it does not mean all timeouts recover automatically.

You do not need to chase a rolling Alpha for this fix now. If the symptoms match, preserve the current state and a rollback path first, then choose official v1.19.32 or a newer stable release that contains the fix during a maintenance window. For an unattended device, confirm a backup management path before upgrading.

Before upgrading, save the complete old core binary, exact architecture and build variant, and back up the config and the core selection in the hosting tool. Use only official Mihomo v1.19.32 or newer stable-release assets, confirm the running version, and do not mix old and new components.

First send real traffic through EasyTier and confirm that the peer appears and an overlay IPv4 request succeeds. Only during a maintenance window, with control of the remote endpoint and backup management access, briefly stop and then restore the test peer. Observe whether the peer reappears, latency recovers, and real requests resume without restarting Mihomo.

In a local, single-path test with disable-p2p: true, the PR author saw peer_added about one second after the remote endpoint recovered, while the Mihomo PID did not change. This supports the self-recovery design in that specific test, but it does not promise that every P2P, relay, multipath, or unstable network will recover within one second. A multipath network may not experience an obvious traffic interruption at all.

If the new stable release cannot start, CPU or memory behavior is abnormal, regular proxies regress, or EasyTier still cannot recover, stop making further config changes. Shut down Mihomo, restore the complete binary and original config saved before the upgrade, then restart it through the same hosting interface.

After rolling back, first confirm the version and config load, then verify regular proxies, the EasyTier outbound, overlay IPv4, and management access. Do not copy only old library files, plugins, or individual modules into the new directory. Also, do not describe the reporter's alternative architecture of a standalone EasyTier Core plus SOCKS5 as a maintainer recommendation.

Rolling back to v1.19.31 removes the self-recovery logic from fbb6742 again. If the connection loss recurs, keep a controlled restart as a temporary recovery method and upgrade after compatibility problems are resolved. Do not conceal version differences by repeatedly changing the peer, secrets, or routing.

When providing further feedback to the project, include the platform, architecture, build tag, minimal redacted configuration, a comparison between EasyTier and a regular proxy, alive/history, peer changes, and the first relevant log entry. Do not disclose the network-secret, private keys, Controller secret, subscription, or complete public network topology.