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

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.

In the report, Mihomo and the other proxies continued working normally, while only the EasyTier outbound changed to alive: false, its latency history showed 0, latency tests kept returning Error or Timeout, and the Mihomo node was no longer visible in the remote peer list.

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.

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.

The v1.19.31 stable release predates the fix merge and therefore does not include this automatic recreation logic. PR #3215 was merged into Alpha on 9/15/2026, with fbb6742 as the final commit. The rolling Prerelease-Alpha on 9/16/2026 also explicitly lists a fix to restart the EasyTier outbound after a silent overlay failure.

The final implementation does not add periodic latency tests or treat every timeout as a restart signal. EasyTier remains responsible for peer reconnection, while Mihomo consumes the event stream. The Host and Instance are recreated only when the event stream closes and the instance has actually stopped. This scope is narrower than automatically fixing every timeout.

Alpha is a rolling tag and will later point to newer commits. When deciding to test it, record fbb6742, the download time, asset filename, and current build tag; do not record only the latest Alpha. Unattended routers and devices without backup management access or a quick rollback path are better kept on the stable release until a later formal Release explicitly includes the fix.

Before testing the Alpha, save the complete v1.19.31 stable binary, the exact architecture and build variant, and back up the configuration and the core selection in the hosting tool. Use only official Mihomo Prerelease-Alpha assets and confirm that the running commit includes fbb6742. Do not mix new core files with components from an older version.

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 Alpha cannot start, CPU or memory behavior is abnormal, regular proxies regress, or EasyTier still cannot recover, stop making further configuration changes. Shut down Mihomo, restore the complete v1.19.31 binary and original configuration saved before the upgrade, then restart it through the same hosting interface.

After rolling back, first confirm the version and configuration 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 Alpha directory. Also, do not describe the issue reporter's alternative architecture of a standalone EasyTier Core plus SOCKS5 as a maintainer recommendation.

Rolling back to the stable release removes the self-recovery logic from fbb6742 again. If the connection loss continues to recur, keep a controlled restart as a temporary recovery method and wait for a later stable Release. Do not conceal a reproducible version difference by repeatedly changing the peer, secrets, and routing.

As of 9/16/2026, the current stable release remains v1.19.31, and automatic recreation after a silent EasyTier connection loss is explicitly documented only in Alpha commit fbb6742. Going forward, rely on whether a formal Mihomo Release includes this commit or an equivalent fix. Do not guess the next version number or treat closure of the issue as proof that a release has occurred.

After a formal release, use the same policy, peer, and test target to recheck normal startup, a brief interruption, self-recovery, regular proxies, and rollback. Retire the temporary restart or Alpha test plan only when the Release notes, running version, and local results all agree.

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.