github代理加速需绕开codeload.github.com下载瓶颈，因http_proxy对tls直连无效，必须显式重写dist.url、部署内网缓存或强制刷新composer.lock。
直接说结论：GitHub 代理加速不是配 Composer 的“代理”，而是绕开 codeload.github.com 这个下载瓶颈——它不走 Packagist 元数据源，也不听 http_proxy 环境变量，必须显式重写 dist URL 或部署反向代理。
为什么 http_proxy 对 codeload.github.com 基本无效
Composer 下载 ZIP 包时默认直连 https://codeload.github.com/xxx/zip/refs/tags/vx.y.z，这个域名走的是 TLS 直连，多数企业代理不支持 HTTPS 透传，或会拦截证书导致连接重置；更关键的是，composer config -g http-proxy 根本不控制这一环节——它只影响 API 请求（如 packagist.org），对 lock 文件里已写死的 dist.url 完全没用。
- 用
curl -x http://your-proxy:8080 https://codeload.github.com测试，90% 情况返回 SSL 错误或超时 -
https_proxy环境变量即使设了，也常因代理不支持 CONNECT 方法而失效 - 就算代理通了，
codeload.github.com在国内 DNS 解析慢、TLS 握手卡顿，代理无法优化底层网络路径
真正有效的三种加速路径
核心思路只有一个：不让 Composer 去连 codeload.github.com。
批量替换指定目录下所有 Git 仓库的远程地址（remote URL）。 当用户需要将 Git 仓库从一个服务器迁移到另一个服务器时使用。 触发词：git remote 替换、git url 批量修改、git 仓库迁移、更换 git 地址、批量修改 remote url。
-
个人开发首选：用
ghproxy.com类反向代理 + 显式重写dist.url在composer.json的包定义里手动改"dist": {"url": "https://ghproxy.com/https://codeload.github.com/..."}。注意：必须改每个包，且每次composer update后要重新 patch，适合小项目或临时调试 -
团队/企业推荐：部署
satis或toran proxy把 GitHub ZIP 包缓存到内网服务器，再让 Composer 的composer.lock中所有dist.url指向内网地址。需配合composer config --global repos.packagist切换元数据源，且首次生成 lock 时就得用新源 -
CI/自动化场景：删
composer.lock+ 强制走镜像源 很多 CI 脚本缓存了旧 lock，里面仍是codeload.github.com地址。应在脚本开头加rm composer.lock，再跑composer install --repository=https://mirrors.aliyun.com/composer/，否则配置全是白搭
--repository 参数为什么总失效
这是最常被误解的一点：--repository 只控制 composer install 和 composer update 时拉取元数据（即 packages.json）的地址，它完全不修改已存在于 composer.lock 中的 dist.url。
- 现象：换了
--repository，还是从codeload.github.com下载 → 因为 lock 文件没动 - 正确做法：先
rm composer.lock vendor，再composer install --repository=https://mirrors.aliyun.com/composer/ -
composer require不支持--repository，它只读当前全局配置，所以得提前用composer config -g repos.packagist设好
真正卡住的从来不是 GitHub API（那个配 Token 就能解），而是 codeload.github.com 这个 ZIP 下载入口。它不走 Composer 配置体系，得靠重写 URL、自建缓存或彻底替换域名来解决——别在 http_proxy 上浪费时间了。
