Gradle 从哪里获取代理设置
跟踪 Gradle 的 JVM 代理属性、用户主目录设置和客户端环境，不要假定守护进程总会忽略新变量。
从 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。
在 shell 中导出 HTTP_PROXY本身不能证明这个 JVM 客户端会把它作为代理策略。检查应用支持的属性。
守护进程确实会收到构建信息
当前 Gradle 文档说明，客户端会把包括环境变量在内的构建信息发送给守护进程。因此，“守护进程永远收不到新的环境变量”是错误的笼统解释。
某些 JVM 启动属性（包括信任库属性）对正在运行的 JVM 不可变。因此，即使普通构建环境值会被传递，改变 Java home 或信任库启动配置仍可能产生影响。
比较两种启动方式
检查 IDE 选择了哪个 Gradle 发行版和 Java 运行时。检查它是否使用与终端相同的 GRADLE_USER_HOME和用户属性。一个用户配置中的代理条目不能说明另一个上下文加载了什么。
如果改变启动要求后需要另一个守护进程，请使用对应 Gradle 版本文档规定的守护进程控制。不要把停止守护进程当成查找错误属性或缺失配置文件的替代办法。
最后确定失败的是哪个请求。Wrapper 下载、构建依赖解析，以及分叉的应用或测试进程发出的请求，不会自动属于同一个网络上下文。先确认发起请求的进程，再判断 Gradle 属性是否能控制它。