CLI:プロセスが設定を読み込んでいるか確認
システムプロキシの設定が、コマンドラインのプログラムに自動で適用されるとは限りません。使用するSDKやツールのプロキシ対応方法を確認してから、アプリの設定、環境変数、クライアントのネットワークモードのいずれを使うか決めましょう。HTTPS_PROXY、HTTP_PROXY、NO_PROXYが有効かどうかは、ランタイムや起動環境によって異なります。変数が設定されているだけでリクエストがプロキシ経由だと判断しないでください。
プロキシのアドレスとポートは、自分の端末にあるクライアント設定から確認し、ほかの人の設定をそのまま使わないでください。環境変数を変更しても、起動済みのターミナルやプログラムには古い値が残っている場合があります。対象のプロセスを再起動しましょう。トラブル確認には、個人情報を除いた接続エラーを参照できますが、リクエストヘッダー全体、認証情報、サブスクリプションの内容は出力しないでください。
IDEプラグイン:画面と実行場所を切り分ける
エディター本体、拡張機能のホスト、内蔵ターミナルでは、プロキシ設定の扱いが異なる場合があります。CursorやCopilotのログイン画面が使えても、プラグインのリクエストが同じ接続先を通るとは限りません。アプリの設定、拡張機能の説明、エラーログを確認し、認証、モデルの応答、リソースのダウンロードのどこで失敗しているか特定してから、該当する設定を調整してください。
リモート開発、コンテナ、ワークスペース接続を利用すると、コードの実行場所が別のホストに移っている場合があります。ローカルのクライアントで選んだ回線が、リモートのプロセスにも自動で適用されるわけではありません。実際にリクエストを実行する環境でネットワークを確認し、組織のネットワーク管理ルールにも従ってください。組織が一括管理するセキュリティ設定を変更しないようにしましょう。
CI:ランナー側のネットワークを確認
CIのリクエストはランナーから送信されるため、ローカルのブラウザーで接続できても、CIでの接続を証明することにはなりません。ランナーのネットワーク出口、プラットフォームの対応地域、認証情報の権限、実行時のプロキシ設定を確認してください。コンテナには独自のネットワーク境界もあります。コンテナ内のローカルアドレスは、ホストのアドレスと同じではありません。
シークレットはCIの保護された変数として設定し、読み取り可能なジョブを制限してください。失敗ログには原因の分類に必要な情報を残しつつ、認証情報、非公開のプロンプト、業務データは伏せましょう。自動再試行の前に、一時的なネットワーク障害、プラットフォームのレート制限、権限エラーを見分けてください。失敗したジョブを繰り返し送信し続けないようにしましょう。