Release 1.5.1 — the exit chain, and the routes the app was describing wrong

[DarkPoesidon]

Everything since 1.5.0. Each of these was the app trusting or describing a route that was not the one carrying traffic.

The tunnel would not connect

A failed attempt left the system proxy pointing at a bridge whose tunnel had already gone. Nothing restored it until the supervisor gave up or the user disconnected — so for the whole backoff and the whole next attempt, every application was aimed at a listener that answered nothing. In Whole machine mode that does not read as "one attempt did not come up"; it reads as the app having taken the network down. Ordinary retries now restore it. The kill switch, whose purpose is to hold it, still does.

The chain's node list was never decoded

mihomo's control API is Go's net/http, which sets Content-Length only for a reply small enough to buffer and frames anything larger in chunks. The client read neither. /version is 35 bytes so it arrived whole and the readiness check passed — the chain reported itself up and carried traffic — while the node list, the one reply that is always large, reached the JSON parser as 8a0c\r\n{"proxies":.... That is exactly the expected value at line 1 column 1 on screen, and it read like a crash rather than a reply we had not finished reading.

The app named the wrong address

The exit card read the tunnel even with a hop running, so it reported Cloudflare's address while everything left through the node. "This app only" named the tunnel's port for the same reason, sending anything pointed at it straight past the hop — and that address was a literal, so it was also wrong for anyone who had changed the SOCKS port. The hop's own port was ephemeral (62704, then 36701, then 7677), so the one address a person types into a browser moved every launch; it is now the tunnel's port plus one.

A degraded gateway stayed pinned for good

The engine caches the gateway that last worked and asks only whether it still answers — never whether it is still worth having — and every successful connect writes it back. Measured on one machine, one minute apart:

edge	time to first byte
freshly scanned 162.159.198.128	0.11 s, steady
cached 162.159.198.130	3.2 → 5.6 → 7.0 → 9.7 s → timeout

Nothing noticed, because the latency probe timed a SOCKS5 CONNECT — which stays fast on a tunnel whose data plane is congested. The chart read 33 ms while no page would load. The probe now waits for a byte to come back, and a watcher re-scans after three checks in a row over two seconds. It leaves the transport alone: alternating H2/H3 answers a transport that cannot get through, and here the transport was fine.

Nobody could see any of it

The core's output lived only in a 1000-line ring buffer inside the running process, so every diagnosis was inference — and inference kept landing on the engine, which was never at fault. Each line was also its own IPC message, emitted from the thread that is the sole drainer of the core's stdout pipe. mihomo's output was piped and never read at all, which blocks it on its own logging once the pipe fills, and threw away the only account of what the chain was doing.

Lines are now buffered and one pump delivers them: in batches to the window, and to a rotating core.log that survives a crash. mihomo's output joins it.

And one found by accident

Launching the app while it was already running started a second process that knew nothing about the first — it showed "Not connected" over a live tunnel, and its startup proxy recovery reverted the system proxy the running copy had applied. A second launch now focuses the window already open.

Verified

route	address	location	warp
tunnel only	104.28.214.151	Singapore	on
through the chain	64.110.98.173	Japan (KIX)	off

Nodes list with their delays, latency reads a true 79 ms, This app only names 127.0.0.1:1820, the chain log captures traffic through the selected node, and nothing is left running after disconnect. Built, installed and exercised on Windows 11.

cargo test 55 · pnpm check clean · pnpm test 33