CLIとSDK
プログラムがシステムプロキシを読み取るのか、HTTPまたはSOCKSプロキシを明示的に設定する必要があるのか、まず確認してください。実行環境によってはHTTP_PROXY、HTTPS_PROXY、ALL_PROXYを参照しますが、環境変数への対応、優先順位、DNSの解決場所はツールによって異なります。すべてのSDKが同じルールに従うとは限りません。プロキシには、クライアントが実際に提示するローカルアドレスとポートを指定し、説明記事から推測しないでください。
NO_PROXYの設定によって、接続先サービスが意図せずプロキシの対象外になっていないか確認します。環境変数を変更したあとは、ターミナルまたは関連プロセスを再起動してください。起動済みのプロセスには新しい値が反映されない場合があります。TLS証明書エラーが出た場合は、システム時刻、証明書チェーン、企業ネットワークのポリシーを確認し、証明書検証を無効にして問題を隠さないでください。
IDE・プラグイン・リモート開発
Cursor、GitHub Copilotなどのエディタープラグインでは、アプリのメインプロセス、拡張機能ホスト、統合ターミナルがそれぞれリクエストを送信する場合があります。ブラウザーで認証できてもエディターでエラーが続くときは、認証結果がアプリに戻っているかを確認し、エディターと拡張機能それぞれのプロキシ設定を調べましょう。統合ターミナルから接続できても、すべてのプラグインが同じ経路を使うとは限りません。
リモート開発、コンテナ、サブシステムでは、localhostは現在の環境を指し、デスクトップクライアントが動作する端末を指すとは限りません。まずネットワークの境界と、正規に利用できるプロキシの接続先を確認し、ツールのドキュメントに従って設定してください。リモート接続のためにローカルプロキシをインターネットへ公開すると、追加のリスクが生じます。標準的な方法としては推奨できません。
CIと自動化タスク
CIの接続元はランナーの実行環境によって決まり、ローカルの回線設定がリポジトリにアップロードされるわけではありません。ランナー上でDNSと接続先APIへの接続を確認し、実際にタスクを実行するプロセスにプロキシ設定を渡してください。企業のセルフホストランナーでは組織のネットワークルールも確認が必要です。共有ランナーでは接続元が変わり、地域判定に影響する場合があります。
APIキーはCIのシークレット変数に保存し、リポジトリ、ビルド成果物、デバッグログには記載しないでください。調査用ログには必要なエラーの種類、発生した処理、マスキング済みのリクエスト識別子だけを残し、認証ヘッダー、完全なキー、サブスクリプションURLは出力しないようにします。長時間のタスクでは、初回の接続だけでなく、認証情報の更新、リクエストのキャンセル、サーバー側のレート制限への対応も考慮してください。