要約
- VSCode(WSL上)で
>Dev Container: Add Dev Container Configuration Files...などしてマニフェストファイルを取得しようとすると、タイムアウトする - マニフェストファイルの取得処理自体はVSCodeの ホスト側 で行われる。なのでWindows上で動いているVSCodeの環境変数にもHTTPS_PROXYの設定が必要（settings.jsonではダメだった）
多分なんか設定を見落としてるか手順を間違えてるか何かな気はするが…
でもなんで治ったかわかってない
ただ、よくわからないのは、なぜかリダイレクトした先で失敗する。
やっていることは以下だ。.devcontainer/devcontainer.jsonを作るまでに以下の通信をしているっぽい。（>Dev Container: log とかすれば確認できる）
- ghcr.ioからトークンを得る
- トークンを使いghcr.ioからマニフェストファイル一式(blob.tar)を取得する → pkg-containers.githubusercontent.comへリダイレクト
- pkg-containers.githubusercontent.comから取得する → タイムアウト（
Error getting blob: Error: connect ETIMEDOUT 2606:50c0:8001::154:443）
このIPv6がなんなのかすぐにわからなかったが、pkg-containers.githubusercontent.comを名前解決すると複数あるやつの1つということがわかった。
単純に環境変数のHTTPS_PROXY設定の問題なのであれば、(1)か(2)の時点で失敗するはず…なんだけど、ここはなぜか、なぜか、通過した。
悩みながらログを見ていて思ったのが、このdevcontainers拡張機能自体はWSLではなくホスト機の方で動いているので、もしかしてホスト機のProxyの環境変数が必要なのでは？と思い、ホスト機からcmdで以下のようにして起動しなおす。（環境変数を設定して起動するだけ）
set HTTPS_PROXY=https://id:pass@proxy.example.local:8080 code
これだけでうまくいった。なので解決して「よかったですね」で終わるのだけど。
解せない
解せないのはそこまで到達できているのはなんなんだ、ということ。
プロキシを通らないとインターネットに出れない環境なので、その前のghcr.ioの通信はどうやって解決しているのか。そもそも(1)のトークンの時点でキャッシュできない内容なのでインターネットに出るのは間違いないし、(3)のURLを得るには(2)の通信が必要で、どうやって通信したのか？
スタックトレースを頼りに軽く処理を見た感じ、該当のコードはここっぽい。リダイレクトの実装はfollow-redirectsパッケージを使っていそう。Proxy対応にはproxy-agentを使っている模様。（なおNodeJS自体にはHTTPS_PROXY環境変数を解釈する機能はない！）うーん、でもそれなら動くんじゃないんか…
ということでよくわからず。
悩んだが気になったのはghcr.ioの時はIPv4で、pkg-containers.githubusercontent.comのときはIPv6で通信しようとしているので、これがリダイレクト周りで何か変な動きになるのだろうか。いやでもそれならHTTPS_PROXYの指定が無かった時にも動かないはずじゃろうて・・・リダイレクト時のプロキシの通信がおかしいのか？わけわからん。難しい。
