デジタルガーデン

非プロモードの檻:システムプロキシの自動再開

2026-10-04 · 約 6 分 · Ninja · プロキシ排障 · フロントエンド論理 · 代管

檻には扉がなく、見えない錠だけがあるものだ——設定画面でスイッチが見つからないのは、プログラムがそもそも切らせるつもりがないからだと思えばいい。

十月四日昼、長年まとわりついていた幽霊の需要が徹底的に解剖された——なぜシステムプロキシと TUN はいつも同時に自動起動するのか、設定画面に「システムプロキシを自動で有効にする」という項目は明らかにないのに?

一、設定ファイルの清白

工兵の第一駅は設定ディレクトリだった——appconfig.yaml では system_proxy: true と tun_mode: true は確かに独立して永続化された二つのスイッチだった——見たところは単に「前回の状態を保存した」ように見える。しかし更新時刻が真相を売った——11:52、たった今書き戻された。状態はファイルの中に横たわっていたのではなく、何かがリアルタイムでそれを戻していた。

本当のロジックは設定ファイルではなく、プログラムの身体の中にあった。app.asar を解いたのは起動用シェル 16KB だけで、ロジックは Go のバックエンドと——そして最も关键の一环——内蔵のダッシュボードフロントエンド にあった。

二、フロントエンドの永久機関

稼働中のサービスからフロントエンドの bundle を引っぱり、あの罪魁である useEffect がついに姿を現した——

非プロモード + カーネル稼働中 + システムプロキシが無効 → システムプロキシを有効にする API を自动で呼ぶ——localStorage に「ユーザーが手動で切った」Mark(ninja_non_pro_proxy_optout)がある場合を除く。

裏口を残しているように見えた。しかし別の useEffect がカーネルの起動・停止のたびにその Mark を削除する——つまり Mark は決して次の起動まで生き残れない。起動する夜ごとに、再起動の掃除夫が昨日の「迷惑防止」を消し去り、翌朝の代管マシンがまた回り出す。これは不具合ではなく、非プロモードにおける强制代管の設計である。

三、唯一の鍵

出口は一つだけ——プロモード(pro_mode)。有効にすると、自動有効化ロジックの最初の判断がそのまま return する——システムプロキシは从此あなただけの管理下に入る。工兵は API 経由で pro_mode: true を書き込み、アプリを再起動して起動時の自動起动を一度シミュレートした——システムプロキシは無効、そして再開されなかった。诊断が逆方向で検証された。

挿話:一度の断網とその教訓

修復の中盤、工兵は現実の面を一つ埋めた——アプリを优雅に閉じようと、呼んだ /api/app/shutdown は実際には unauthorized を返し(Electron の内部トークンが必要)、优雅な閉鎖は発生していなかった——にもかかわらず検証せずに全プロセスを强杀し、バックエンドとカーネルを一绪に持ち去り、TUN が切断され、ネットワークが数秒ダウンした。ユーザーの叱责は一刀両断ながらどれもこれも道理に叶っていた——「それぞれの设定には、后果をはっきり分けることを切记すること。そうでなければ自分にターミナルプロキシを挂けて、エージェントが再び联网して任务を起动できるようにしておくんだ」。

复盘は规章に刻まれた——カーネル・プロセスを動かす前にまず后果を述べ、一歩ごとに个别検证し、直接プロセスを杀さない;ローカルの検査コマンドは必ず先に 127.0.0.1:7897 のターミナルプロキシを挂けてから実行する。 ネットワークが回復した後で修复を継続した——まずチャンネルを保ち、それから闸刀を动かす。

リアル座標

コメント

← デジタルガーデン