De dónde obtiene Gradle la configuración del proxy

Una compilación de Gradle iniciada desde un IDE puede usar una configuración distinta de la del mismo proyecto iniciado desde una terminal. Antes de culpar a un proceso de proxy obsoleto, compara el directorio personal de Gradle, la JVM y las propiedades de proxy usadas en cada inicio.

Gradle documenta las propiedades de proxy de la JVM

Para rutas HTTP y HTTPS, un archivo de propiedades puede contener:

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

Usa el extremo asignado; para rutas permitidas a repositorios públicos, la lista de proxies HTTP ofrece pares candidatos de host y puerto. La propiedad de omisión de HTTPS también es http.nonProxyHosts; inventar https.nonProxyHosts no es la solución documentada. Las propiedades del host contienen una dirección, no una URL de proxy completa.

Exportar HTTP_PROXY en un shell no demuestra por sí solo que este cliente JVM lo use como política de proxy. Comprueba las propiedades que admite la aplicación.

El daemon sí recibe información de la compilación

La documentación actual de Gradle indica que el cliente envía al daemon información de compilación, incluidas las variables de entorno. Por eso, la explicación general «el daemon nunca recibe variables de entorno nuevas» es inexacta.

Algunas propiedades de inicio de la JVM, incluidas las del almacén de confianza, son inmutables para una JVM en ejecución. Un Java home o una configuración inicial del almacén de confianza distintos pueden importar aunque se transmitan los valores normales del entorno de compilación.

Compara los dos inicios

Comprueba qué distribución de Gradle y qué runtime de Java selecciona el IDE. Comprueba si usa el mismo GRADLE_USER_HOME y las propiedades de usuario que la terminal. Una entrada de proxy en la configuración de un usuario no demuestra qué cargó otro contexto.

Si un requisito de inicio modificado necesita otro daemon, usa los controles documentados del daemon para la versión de Gradle correspondiente. No trates detener daemons como sustituto de encontrar una propiedad incorrecta o un archivo de configuración ausente.

Por último, identifica la solicitud que falló. Las descargas del Wrapper, la resolución de dependencias de compilación y las solicitudes de procesos bifurcados de aplicación o pruebas no son automáticamente un mismo contexto de red. Verifica el proceso que hace la solicitud antes de esperar que una propiedad de Gradle lo controle.