Port Drift: The Identity of 7897 and a Mistyped Path

The most dangerous accident in deep space was never an engine explosion; it was navigation silently entering a wrong coordinate while the whole ship believed the course correct.

On the afternoon of October 2, bad news surfaced: the backend service process had received a termination signal and exited. The engineers immediately boarded to investigate whether TA was lost or had been taken over by a new instance. The command did not reach TA — the shell itself malfunctioned. An investigation that would exhume two skeletons began from here.

I. The first skeleton: the eaten path

First look at the autostart VBS script — the answer was nearly written on the forehead: the script-writing hit a low-level escaping mistake, the \a in the path was eaten by Python into a bell character, what was actually written into the file was F:strbot\... — a path that never existed from day one. This autostart was dead from the second it was written; today’s boot error was merely its first honest run and also its first expose of the problem.

II. The second skeleton: the port that moved

Just as the engineers rewrote the script, the second skeleton was dragged out: the start script hardcoded the old proxy port 6789, while the proxy on this machine had long moved house. A sweep of all listening ports settled the truth — Clash Ninja was running, the new mixed port was 7897 (Clash Verge default), and 6789 had gone unanswered for ages. Had the script not been changed, she could not even pass the TG gate.

The final network geography:

Channel	Status	Use
Clash 7897 (new mixed port)	✅ tested reachable	TG goes through it explicitly (written in the bat)
TUN global takeover	✅ also on	fallback double insurance
Local gateway :3000	✅ normal	LLM calls via localhost, unaffected by proxy changes
Local Ollama :11434	✅ running	embeddings + local models, also bypass proxy

III. Prescription: triple hardening

The fix has three layers: first, path fix — the autostart VBS now points to F:\astrbot\autostart.bat (pure ASCII filename, and content identical to the manual 启动AstrBot.bat, carrying new port 7897); no Chinese characters appear in the VBS anymore, encoding issues vanish for good; second, 30-second delay — wait for Clash Ninja to connect to nodes after boot before starting her, avoiding her grabbing the line to TG first and hitting ConnectError; third, silent drill — actually tested the script parsing and execution chain headlessly, all normal.

Alongside, the admin panel’s address was delivered: http://127.0.0.1:6185 (account astrbot, password the one the user later set). The only future standing rule converges to one line: when Clash changes port/software, sync the 7897 in 启动AstrBot.bat; after the change, close the window and restart once.

Coda

The absurdity of this incident: every day she was “alive,” she stood on a miscopied live wire and an obsolete port chart. And the trigger to discover it was merely one process exit. Latent deaths never announce themselves — only by pulling every live wire into the light can you prove she is still alive.

Real coordinates

• Trigger: backend AstrBot service process received termination signal and exited; investigate after machine restart
• Skeleton one: autostart VBS path \a escaped by Python into a bell char, actually written F:strbot\... — autostart dead since written
• Skeleton two: start script hardcoded old proxy port 6789, actual Clash Ninja new mixed port is 7897 (Clash Verge default; 6789 dead)
• Prescription: VBS points to pure-ASCII autostart.bat (content = manual bat, writes 7897); 30-second wait for proxy readiness; headless drill passed
• Network map: Clash 7897 (TG) / TUN fallback / gateway :3000 and Ollama :11434 bypass proxy
• Address: admin panel http://127.0.0.1:6185 (account astrbot); standing rule: sync bat on port change