Gradle がプロキシ設定を取得する場所

IDE から起動した Gradle ビルドは、ターミナルから起動した同じプロジェクトと異なる設定を使うことがあります。古いプロキシプロセスを疑う前に、起動ごとの Gradle ユーザーホーム、JVM、プロキシプロパティを比較してください。

Gradle は JVM プロキシプロパティを文書化している

HTTP と HTTPS の経路では、プロパティファイルに次を記述できます。

systemProp.http.proxyHost=203.0.113.10
systemProp.http.proxyPort=8080
systemProp.https.proxyHost=203.0.113.10
systemProp.https.proxyPort=8080
systemProp.http.nonProxyHosts=localhost|*.example.internal

割り当てられたエンドポイントを使います。許可された公開リポジトリ向けの経路では、HTTP プロキシ一覧が候補のホストとポートの組を示します。HTTPS のバイパスプロパティも http.nonProxyHosts です。https.nonProxyHosts を作るのは文書化された修正ではありません。ホストプロパティに入るのはアドレスであり、完全なプロキシ URL ではありません。

シェルで HTTP_PROXY をエクスポートしても、この JVM クライアントがそれをプロキシポリシーとして使う証拠にはなりません。アプリケーションが対応するプロパティを確認してください。

デーモンはビルド情報を受け取る

現在の Gradle ドキュメントでは、クライアントが環境変数を含むビルド情報をデーモンに送ると説明されています。したがって「デーモンは新しい環境変数を受け取らない」という一律の説明は不正確です。

信頼ストアのプロパティなど、一部の JVM 起動プロパティは実行中の JVM では変更できません。そのため、通常のビルド環境値が渡されても、変更した Java home や信頼ストア起動設定が影響することがあります。

2つの起動方法を比較する

IDE が選んだ Gradle ディストリビューションと Java ランタイムを確認します。ターミナルと同じ GRADLE_USER_HOME とユーザープロパティを使っているか確認します。あるユーザーの設定にあるプロキシ項目だけでは、別のコンテキストが何を読み込んだかは分かりません。

変更した起動要件に別のデーモンが必要なら、対象の Gradle バージョンで文書化されたデーモン制御を使います。デーモンの停止を、誤ったプロパティや不足した設定ファイルを探す代わりにしないでください。

最後に、失敗したリクエストを特定します。Wrapper のダウンロード、ビルド依存関係の解決、分岐したアプリケーションまたはテストプロセスからのリクエストは、自動的に同じネットワークコンテキストにはなりません。Gradle のプロパティで制御できると期待する前に、リクエストを行うプロセスを確認してください。