ターミナルのダウンロードは成功するのに VS Code 拡張機能は VPN で失敗する

コンテナのターミナルで成功するダウンロードは、そのターミナルの環境についての確かな証拠です。エディタのプロセス、拡張機能のインストーラ、拡張機能が後から取得するバイナリについては何も語りません。その三者間でプロキシ変数をコピーすることは、一度の失敗したリクエストを、無関係な編集に費やす半日へと変えてしまいます。

二つの環境は通常、ちょうど一つの点で異なります。その点を見つけるほうが、プロキシの文書を二度読むより速いのです。

失敗したリクエストを出したのはどのプロセスか

一度のインストールで三つのリクエストが失敗し得て、それぞれに独自のネットワーク上の身元があります。エディタは Marketplace にメタデータとパッケージの URL を問い合わせ、その後パッケージをダウンロードします。その後に初めて、拡張機能ホストが言語サーバーや独自のバイナリを取得し得るコードを実行します。どの段階が壊れたかで、どのプロセスにプロキシが必要かが決まり、エラーの表示面がその段階を名指すことはほとんどありません。

動くターミナルが証明するのはコンテナがインターネットに到達できることであり、エディタが到達できることではありません。拡張機能のログで、最後に試した URL を読んでください。そこに示されたホストが、そのプロセスと適用されるポリシーを特定します。

ローカルエディタとリモートコンテナは二つの環境である

リモートワークスペースでは、拡張機能はその種類が宣言する側で実行されます。UI 拡張機能はローカルエディタにとどまり、ワークスペース拡張機能はコンテナ内で実行されます。一方に設定したプロキシは他方には見えず、リビルドはコンテナ環境を設定ファイルから作り直すのであって、シェルで export したものから作り直すのではありません。この分離が、同じ拡張機能がノート PC ではインストールでき、同じプロジェクトで SSH 経由だと失敗する理由を説明します。

何かを編集する前にインストール先を読んでください。ログがリモートへのインストールを報告しているなら、重要なのはコンテナの環境です。

プロキシはリクエストが始まる場所に置く

本当に HTTP プロキシが必要な Dev Container なら、変数はコンテナ設定に置くべきで、そうすればリビルドでも再現されます。以下の断片はその環境向けに設定します。プレースホルダのアドレスは自分のゲートウェイの代わりであり、除外項目は省略可能な詰め物ではありません。

"containerEnv": {
  "HTTP_PROXY": "http://proxy.corp.example:8080",
  "HTTPS_PROXY": "http://proxy.corp.example:8080",
  "NO_PROXY": "localhost,127.0.0.1,.internal.example"
}

変数名は宛先プロトコルを表すので、HTTPS_PROXY の値が http で始まっても正当であり、変更はサポートされたリビルド手順で適用し、除外項目は残してください。内部ホストを横取りするプロキシは、コンテナが必要とするサービスを壊します。

信頼の失敗と到達性を切り分ける

接続したうえで証明書検証エラーを返すプロキシは、接続を拒否するプロキシより後の段階に達しています。前者の失敗には、リクエストを実行する環境に組織の承認済み信頼素材が入っていることが必要です。後者には到達可能なアドレスとポートが必要です。両者を一つの問題として扱うと、どちらにも効かない修正になります。

検証を無効にすることや、エディタを昇格した権限で動かすことは、プロキシの欠落や信頼チェーンの欠落の修理ではありません。どちらも見えるエラーを静かなエラーに交換するだけです。その後で同じ拡張機能を再試行し、次に失敗する URL を記録してください。

env | grep -iE '^(http|https|no)_proxy='
code --install-extension ms-python.python --force

ワークスペースのどちら側がその URL を生んだのかを記録してください。段階、ホスト、側を記した短いメモは、次の人が再現できるまさにそのメモだから、誰かが変えた設定の一覧より価値があります。