“强制走代理”更危险，因GitHub无官方镜像，硬代理api.github.com会触发TLS指纹检测或403；代理仅适用packagist.org，GitHub API须直连+Token认证，且http-proxy/https-proxy必须成对严格配置。
为什么“强制走代理”反而更危险
Composer 本身不支持“强制走代理访问 GitHub 镜像”这种操作——GitHub 没有官方镜像，所谓“GitHub 镜像”是用户误称；你真正想连的是 packagist.org（元数据源）和 api.github.com（包信息源），它们协议不同、认证逻辑独立。硬把 api.github.com 塞进 https-proxy 会触发 GitHub 的 TLS 指纹检测或 403，尤其在企业网络下更易被拦截。代理只该用于 packagist.org 流量，GitHub API 必须走直连 + Token 认证。
http-proxy 和 https-proxy 必须成对配置且格式严格
漏配 https-proxy 是国内用户卡在 “Loading composer repositories” 的最常见原因。Composer 对协议分流极严格：http-proxy 只处理 HTTP 请求，https-proxy 才建立 CONNECT 隧道转发 HTTPS 流量。而 packagist.org 全站 HTTPS，没配 https-proxy 就等于没配代理。
-
https-proxy的值必须以http://开头（不是https://），哪怕你的代理服务监听 TLS 端口——这是 Composer 硬编码约定，填错就静默失效 - 带认证时，密码含
@或:必须先rawurlencode()，例如pa@ss:word→pa%40ss%3Aword；否则 URI 解析截断，连接直接拒绝 - 验证命令：
composer config -g --list | grep -E "(http|https)-proxy"，两行都得有且 URL 格式合法（无空格、无中文、末尾无换行）
别混用代理和镜像源，二者互斥
一旦你执行了 composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/，Composer 就不再发请求到 packagist.org，自然绕过所有 http-proxy/https-proxy 设置——镜像和代理是两条完全不同的链路，强行共存会导致部分请求走镜像、部分被代理劫持，最终 404 或 fallback 到官方源。
- 想走代理 + 连国际源：只配
http-proxy/https-proxy，绝对不要动repo.packagist - 想连国内镜像：清掉代理配置，只设
repo.packagist，并执行composer clear-cache - CI/CD 中常见陷阱：sudo 写入的全局配置在普通用户进程里读不到，务必确认
COMPOSER_HOME路径和属主一致
GitHub API 必须单独配 Token，不能靠代理解决限流
即使代理通畅，composer update 仍报 403，大概率是 api.github.com 的 rate limit 超限。未认证请求每小时仅 60 次，而 Composer 拉取每个包的 composer.json 和版本列表都要调 GitHub API。代理无法绕过这个限制，只有 Token 能升到 5000+/小时。
- Token 权限至少勾选
repo（读私有库）和read:packages（读 GitHub Packages） - 配置命令：
composer config --global github-oauth.github.com YOUR_TOKEN - 验证方式：
curl -I https://api.github.com/rate_limit，看响应头中X-RateLimit-Remaining是否 > 0 - 国内用户注意：镜像源加速下载 ZIP 包，但 GitHub API 限流仍存在，Token 和镜像必须同时配，缺一不可
https-proxy 配错导致超时，你却去查镜像 URL 是否少斜杠。 
