テクノロジー · 実用ガイド
VS Code Remote SSHでサーバーが毎回ダウンロードされる？削除前にインストールループを切り分ける
再ダウンロードは起動が受け入れられなかった証拠であり、すべての既存環境を消す理由にはなりません。完全なログを正確なVS Codeコミットに結び付け、取得、展開、起動、転送を分けて調べ、証明できた障害だけを修復します。
Remote-SSHがVS Code Serverを何度もダウンロードすると、遠隔側のインストールディレクトリを丸ごと消したくなります。しかし、それでは原因を説明するログや正常なコミットの環境まで失う可能性があります。障害はネットワーク、ツール不足、容量、所有者、展開、起動出力、SSH転送のどこでも起きます。反復は前回の起動をクライアントが受け入れなかったことしか示しません。
管理した接続試行を一度行い、監査として扱います。クライアントのコミットとRemote-SSHログの遠隔パスを記録し、証拠を保存してから起動処理を順に調べます。最後に成功した境界と最初に失敗した境界の両方が分かって初めて、修復を正当化できます。
変更前に一回の試行を固定する
Remote-SSHの出力チャネルを開き、認証プロンプトが見えない可能性があればログインターミナルを表示して、一度接続します。再試行前に完全な出力を保存し、ホスト別名、ローカルVS Codeのバージョンとコミット、拡張機能のバージョン、遠隔OSとアーキテクチャ、インストール先、取得経路、アーカイブやコミット名、最後のエラーを記録します。最後の一行だけの画像では、前に起きた重要な転換を失います。
コミットは環境の識別子です。クライアント更新後に別のサーバービルドが必要になるのは正常な場合があります。一方、同じコミットの再取得はインストールや受け入れが完了していない兆候です。Issue #11269は低速回線での負担を示し、一律削除が診断可能な障害を新たな全量転送に変える理由を説明しています。
サーバーツリーに手を加える前に読み取り専用で棚卸しします。可能ならログの正確なパスを使います。`df -h "$HOME"`、`df -i "$HOME"`、`id`、`find ~/.vscode-server -maxdepth 4 -type d -print 2>/dev/null`で、ブロック容量、inode枯渇、予想外の所有者、複数コミットの環境を変更せずに調べられます。
境界1：シェルと前提条件を確認する
同じSSH接続先で非対話テストを行います。別の起動ファイルを読む可能性がある対話ログインだけに頼らず、`ssh your-host 'printf "shell-ok\n"; command -v bash; command -v tar; command -v curl || command -v wget; uname -s; uname -m; getconf GNU_LIBC_VERSION 2>/dev/null || true'`を実行し、出力を接続ログと保存します。Bashまたはtarの欠落、curlとwgetの両方が使えない状態、または未対応ランタイムは前提条件の障害で、同じアーカイブの再取得では解決しません。
非対話の起動ファイルがブートストラップの目印より前にバナー、デバッグ文字、エラーを出していないか調べます。Stack Overflowの長年のポート解析質問では、通常のSSHが動いてもRemote-SSHが構造化された起動出力を読めない状況が報告されています。飾りの出力を対話シェルだけに限定し、一度だけ制御した接続をやり直します。
シェルとツールが通ったら、むやみに再変更せず、証明済みと記録して次へ進みます。監査は範囲を絞るためのもので、無関係な設定を積み重ねるものではありません。
境界2：取得経路を選んで検証する
遠隔側がサーバーを取得する場合、`update.code.visualstudio.com`と`vscode.download.prss.microsoft.com`へのHTTPS接続が必要です。遠隔側で使えるツールによりDNSとTLSを調べます。ただしHTTP状態の解釈には注意し、名前解決、経路、証明書交渉の確認と、サイトのトップURLがアーカイブURLであるという思い込みを区別します。
遠隔側の外向き通信が遮断され、ローカルPCなら取得できる場合は、ローカルVS Codeのユーザー設定で`"remote.SSH.localServerDownload": "always"`を選び、ローカル取得と転送を使います。拡張機能全体の設定なので他のSSH接続先にも影響し得ます。以前の値を記録して戻してください。すでにローカル転送がログに出ていれば、遠隔プロキシではなく転送行と宛先を調べます。遠隔取得が正常なら強制転送は境界を一つ増やします。
進捗率をインストール成功とみなさず、アーカイブ取得の完了、宛先ファイルの存在、展開への移行を記録します。展開の目印が出ない再取得は取得か転送の境界です。取得完了後の障害は次の境界に属します。
境界3：容量、所有者、展開を確認する
ホームディレクトリに数GB空いていてもinodeは尽きている場合があります。`df -h`と`df -i`を両方確認し、サーバーの親ディレクトリと正確なコミットのパスの所有者を調べます。アカウント全体を再帰的に所有者変更せず、誤った所有者が証明されたパスだけを扱い、その原因も先に確認します。
アーカイブがあればtarが動き、ログの展開先に書き込めることを確認します。コミットと失敗を記録するまで部分的なディレクトリを残します。Remote-SSHの配置は世代で変わるため、すべてが`bin/<commit>`だと仮定せず、現在のログが示すパスを使います。
転送成功後の展開エラーは再取得では直りません。証明された容量、inode、権限、tarの問題を修正し、同じコミットで一度再試行します。期待する移行は、アーカイブの存在から、サーバーツリーへの展開と起動コマンドの出現です。
境界4：サーバー起動と転送を分ける
展開後に起動行と構造化出力を探します。待受エンドポイントを報告する前にプロセスが終了したら、終了状態と付近の標準エラーを保存します。一時ディレクトリの権限や起動スクリプトの出力を含め、実際に渡された遠隔環境を調べます。サーバーの起動が証明されるまでは、トンネル障害と決め付けません。
待受エンドポイントが報告されてもクライアントが使えない場合はSSH転送へ進みます。公式の説明ではTCP用のAllowTcpForwardingとUnixソケット用のAllowStreamLocalForwardingが区別されます。実際のモードに対応するポリシーを管理者に確認してください。`remote.SSH.useLocalServer: false`はローカルサーバー経路が隠すエラーの診断比較であり、転送権限を与える設定ではありません。
「failed to parse remote port」は分類の手掛かりで、普遍的な根本原因ではありません。保存済みの出力と起動の目印を比べます。余分なシェル文字、起動前の終了、トンネルの遮断にはそれぞれ別の修復が必要です。
根拠のある最小限の修復を選ぶ
元に戻せる変更を優先します。必要ツールを入れる、動く取得経路を選ぶ、不要だと確認した領域を空ける、正確な所有者誤りを直す、非対話シェルの出力を調整する、必要な転送ポリシーを依頼する、といった変更です。一つ変えるごとに一度接続し、最初の失敗境界が移ったか記録します。
公式のKill VS Code Server on Hostは本当に固まった環境に役立ちますが、広い範囲の復旧操作で、診断の代用ではありません。実行前に完全な出力を保存し、正常な別コミットの環境まで除かれないか確認します。
正確なコミット環境が不完全だと証明した場合、関連する遠隔ウィンドウを閉じ、サーバープロセスや別セッションがそのインスタンスを使っていないと確認します。ログを残してから、対応が明確なディレクトリだけを隔離し、`.vscode-server`全体は削除しません。同じクライアントコミットで一度接続し直し、新規インストールを確認します。正常状態とログが確保されるまでは隔離分を残します。パスが曖昧、または別セッションが活動中なら停止します。
ループを見逃さない完了条件
一度ウィンドウが開いただけでは不十分です。切断し、同じローカルコミットで再接続します。二回目は全アーカイブ転送を繰り返さず、既存サーバーを再利用する必要があります。遠隔ターミナルを開いて無害なコマンドを動かし、遠隔拡張機能ホストの接続が維持されるか確認します。
監査行に時刻、クライアントコミット、遠隔OSとアーキテクチャ、取得経路、インストール先、空きブロックとinode、前提ツールのバージョン、最後の成功境界、修復、初回と二回目の結果、全量再取得の有無を残します。再発時に比較でき、毎回削除してやり直す必要がなくなります。
見える境界がすべて通っても同じコミットがループするなら、保存した完全なログと最小の再現可能なホスト設定を添えて報告します。秘密情報を伏せ、原因説明に不要なホスト名、ユーザー名、トークン、私的なパスを公開しないでください。
