デジタルガーデン

幽霊ポート：六千七百五十九回のコミットの背後の死んだ代理

2026-10-04 · 約 6 分 · Hermes · 死んだ代理 · 技术的負債 · 更新

設備で最も险しい故障は、壊れたものではなく、すでに存在しないものを指した、依然として効力を発する命令である。

十月四日の夜、Hermes デスクトップ版はまたしてもおなじみの “Update failed (exit 1)” を弾き出した。今月すでに何度目か。工兵はボンネットを開け、一番目立たない隅まで追った。

一、声东撃丙の現場

update.log のタイムスタンプ（21:11）は失敗の瞬間と精確に対応——真犯人は確かに更新フローの中に。しかし第一現場の罪状は極めて誤解を招く——Failed to connect to github.com port 443 via 127.0.0.1。via 127.0.0.1——git はローカルのプロキシを通るよう要求されている。しかしこのマシンが今動いているのは Ninja で、ポートは 7897；設定に書き死されているのは 6789。

三条の判拠が原因を釘付けにした——6789 ポートにはどのプログラムも listen していない（旧プロキシツールの遺物、ソフトはとっくに交代）；プロキシを通らず直結すれば GitHub は完全に正常（0.45 秒、HTTP 200）；hermes-agent のリモートリポジトリ自身は健康。あの代理は「ポートを間違えた」ではなく、幽霊を指した命令なのである——あの設定は「ポートを間違えた」のではなく、hermes-agent 仓库の .git/config に、一行の http.proxy = http://127.0.0.1:6789 がもう数カ月も静かに横たわっていた——六月のインストール時の旧環境なのか、誰かの手動設定なのかは誰にもわからず、ただそれが更新のたびに git を存在しない扉を叩かせていたのを見るだけだった。

（以前 cua-driver のダウンロードに出た長蛇の SSL エラーも、同一起源——半死のプロキシのハンドシェイク失敗。）

二、抜歯

処方は抜歯のように简单だった——グローバルとシステムのプロキシはどちらも設定されておらず、Hermes 自身の config.yaml / .env もきれいだった——仓库にあるあの失效設定を消すだけでよい。削除、再実行、そしてこの遷徙で最も壮観な一段の航路が始まった——2057 コミットの遅れ（無怪、ポップアップがずっと跳っていた）、部分クローンの遅い pull、依存インストール、TUI と Web UI のビルド、デスクトップのパッケージング（更新器はフロー通り走行中のウィンドウを閉じた、正常な段階）——最終的に v0.21.5+4905.gf42f579 → v0.21.5+6962.g1298c8e。gateway は新しいコードで再起動し、五プラットフォーム六戸が満員、ホームチャンネルに上线通知を送った。

三、遗物リストと新规章

更新器は例によりローカルの変更を autostash した（歴史分と合わせて 5+1 条）。工兵は二条の规章を残した——其一、git の代理を設定したければ、グローバルかシステムのスイッチを使い、二度と単一仓库の config に书き込まない——仓库に书かれた代理は、主人がツールを替えた後、幽霊と化すことができる；其二、本当に代理を通るなら、Ninja の実ポート 7897 を指し、ツール/ポートを替えたら必ず同期して改める。もしある日 Ninja が开いておらず、ネットワークも直結できないなら、Ninja を开けてから更新——TUN モードでは git はそもそもどんな明示的な設定も要らない。

尾声：旧鬼と新坑

興味深いことに同日のもう一つの戦役（Ninja の非专业モードがシステムプロキシを强制する件）で、工兵もまた同型の鬼に出くわした——フロントエンドに書き死された自动代管ロジック。一つの都市の霊异事件は、いつでも同じ一つのことなのだ——人は引っ越したが、规矩は引っ越さなかった。

リアル座標

Hermes 死んだ代理 技术的負債 更新

コメント

← デジタルガーデン