正确做法是使用 file:// 协议本地加载 Gradle 发行版 ZIP：下载 gradle-X.Y-bin.zip，按规范结构重打包，放入 $GRADLE_USER_HOME/wrapper/dists/ 对应哈希目录，并在 gradle-wrapper.properties 中设 distributionUrl=file:///path/to/zip。
gradle-wrapper.properties 无法访问带认证的 internal URL
Gradle Wrapper 本身不支持在 distributionUrl 中嵌入用户名密码（如 https://user:pass@internal.example.com/...），这种写法会被 JVM 的 URL 解析器拒绝，运行 ./gradlew 时直接抛出 java.net.MalformedURLException: unknown protocol: https 或空指针异常。
systemProp.http(s).proxyUser/password 不起作用
代理认证配置（systemProp.http.proxyUser 等）只影响 Gradle 构建过程中的 HTTP 客户端行为，对 Wrapper 下载 Gradle 发行版这个独立阶段完全无效——Wrapper 使用的是底层 java.net.URLConnection，绕过了 Gradle 的代理设置逻辑。
- 即使你在
~/.gradle/gradle.properties或项目级gradle.properties里写了认证代理参数，./gradlew启动时仍会失败 - Android Studio 的 Settings → HTTP Proxy 配置也仅作用于 IDE 自身和构建任务，不影响 Wrapper 下载
-
gradle -Dhttps.proxyUser=...这类命令行参数同样不生效
正确做法：用 file:// 协议 + 预置 ZIP 到 GRADLE_USER_HOME
内网环境下最可靠、零网络认证依赖的方式，是彻底跳过 HTTP 下载，让 Wrapper 直接从本地文件加载。关键不是“怎么配认证”，而是“怎么绕过认证”。
- 手动下载对应版本的
gradle-X.Y-bin.zip（注意必须是-bin.zip，-all.zip会被 Wrapper 拒绝） - 解压后确认目录结构为
gradle-X.Y/（不含外层父目录），再重新打包为 ZIP - 将 ZIP 放到
$GRADLE_USER_HOME/wrapper/dists/gradle-X.Y-bin/哈希串/下（哈希串可随便生成一串 32 位小写 hex，如abcd1234ef5678901234567890abcdef） - 修改
gradle/wrapper/gradle-wrapper.properties：distributionUrl=file:///path/to/your/gradle-X.Y-bin.zip（Linux/macOS）或file:///C:/path/to/gradle-X.Y-bin.zip（Windows，三斜杠不能少） - 首次运行
./gradlew --version时，Wrapper 会校验 ZIP 并解压，之后所有构建都复用该本地副本
如果必须走 HTTPS + Basic Auth，只能改 Wrapper 源码
官方 Wrapper 不支持认证，但你可以 fork gradle/wrapper 模块，在 org.gradle.wrapper.Download 类中硬编码插入 conn.setRequestProperty("Authorization", "Basic ...")。这属于高维护成本方案，每次升级 Gradle 都要同步 patch，且无法通过标准 gradle wrapper 命令生成。
真正容易被忽略的一点：很多团队误以为把认证信息写进 gradle.properties 就能透传给 Wrapper，其实 Wrapper 启动时根本不会读这个文件——它只认 gradle-wrapper.properties 和 JVM 启动参数，而后者又不支持认证头注入。
