死んでいない死：cloudflared の CLOSE_WAIT 検死、出所不明の親プロセス、そして十分ごとの脈拍確認

公開の門には「530 Service Unavailable」の札が掛かっていたのに、門番は間違いなく番所に座っていた。「生きているのに働いていない」についての検死が、午後四時十六分に始まった。

一、検死：プロセスは生き、トンネルは死んでいる

第一層の検査は、最も直感的な仮説を覆した。cloudflared プロセスは稼働中（PID 15668）だが、Cloudflare エッジ 7844 番への二本の接続はすべて CLOSE_WAIT の死骸で readyConnections=0——トンネル本体はすでに癱瘓し、公開の 530 はこれと完全に一致した。さらに一層深い発見は、接続の対端のアドレスだった。198.18.x——fake-IP の帯である。トンネルの接続は本地の Clash TUN に乗っており、プロキシ側に切られたあと、トンネルは自己回復しない。転送の標的は全程潔白だった。Hermes dashboard は 127.0.0.1:9119 で正常に待ち受け、本地の探測は HTTP 302——問題は純粋にトンネル側にあった。

二、実りのない自起動探索と、出所の不明

第二層の調査は自起動の鎖だった。Windows サービス、否。予定タスク、否。レジストリの Run キー、否。起動フォルダ、否——cloudflared には自起動の項目が一切なかった。時系列はこう示した。本日 15:43（起動 15:42:42 の分後）に、すでに退場した親プロセスによって起こされた。起動フォルダの 30 秒遅延の astrbot_autostart.vbs とは時刻が符合するが、あの bat の中に cloudflared はなく、Hermes の app.asar にも起こしの論理は見つからない——出所は証明できない。結論は冷たく、かつ実用的である。再起動のあと、それが起こされる保証を持つ者はいない。今日、誰が順手に連れて行ったとしても。

三、修復の二層：蘇生と守衛

手術は二刀だった。第一刀は救急。偽死の実例を殺し、tunnel run hermes をやり直す——本地の ready は 200 と二本の活動接続を返し、公開側は 530 から 302 へ回復した。第二刀は制度。自起動はあえて SYSTEM サービスにしない——起動の時点ではバックエンド（9119）もプロキシもまだ生きておらず、サービス方式はただ死んだ扉に向かって立つ門番を起こすだけである。代わりにログイン級の守衛を、既存の astrbot 自起動と同じ方式で設けた。tunnel-watch.ps1 はログイン後に 45 秒待ち（Clash TUN を落ち着かせるため）、不健康なときだけ起動または再起動し、のち十分ごとに健康確認——本日この型の「プロセス在り、トンネル死」の偽死再発を専門に治す。ログは watchdog.log と 10MB ローテーションの tunnel.log に落ち、予定タスク cloudflared-tunnel-watchdog はログイントリガー＋五秒遅延で登録され、手動発火による端から端までの検証を通過し、すでに健康な実例に対しては正しく nothing to do と判定した。

四、「生きている」の二つの定義

この事件の啓示は一句に圧縮される。プロセスの存在は、サービスの可用と同じではない。CLOSE_WAIT はプロセスの退出よりも隠れた死に方である——接続の死骸が半空に吊られ、プロセスの心拍はまだ打っており、業務はとっくに断流している。守衛の価値もまたここにある。それは「プロセスが在るか」を確認するのではなく、「扉が押して開くか」を確認する。偽死と欠勤は、あの十分ごとの脈拍確認からは逃れられない。