Composer代理请求卡在Retrying是因确定性失败（如502、Connection refused），非网络抖动；--retries对此无效，须停用并用composer install -vvv定位DNS/TLS/HTTP卡点，重点检查https-proxy是否以http://开头、禁用镜像与代理混用、关闭并发下载。
代理请求卡在 Retrying 是因确定性失败，不是网络抖动
Composer 的 --retries 对代理场景完全无效——它只对可恢复错误（如 cURL error 28 超时）重试，但代理返回的 502 Bad Gateway、Connection refused、CURL_ERROR 7 都是确定性失败。反复打印 Retrying 只是掩盖真实卡点，必须停掉重试，直击底层链路。
- 立即执行
composer install -vvv --no-retry（或删掉配置中所有retries相关项） - 观察
-vvv输出里哪一步卡住：是DNS resolution、TLS handshake，还是HTTP status code？卡在哪就修哪 - 重点检查
https-proxy值是否以http://开头（不是https://），这是触发 502 的最常见拼写错误
用 curl -x 复现并验证代理链每一段
别信 Composer 日志里的 URL，它可能已 fallback 到直连。真正能定位代理问题的是手动复现请求路径：
- 先确认代理地址和端口正确：
curl -I -x http://127.0.0.1:7890 https://mirrors.aliyun.com/composer/packages.json - 如果返回
502，说明代理自身异常（比如 Clash 配置了 HTTPS 端口但监听的是 HTTP） - 如果卡在
* Connected to或* TLS handshake，说明代理未完成隧道建立，可能是证书不受信任或企业 WAF 拦截 - 若成功返回
HTTP/2 200，再跑composer install -vvv，对比两者的请求 URL 和响应头是否一致
并发下载必须关闭，否则代理压力翻倍触发限流
Composer 默认并发 12 个连接，但多数本地代理（Clash、Proxifier、cntlm）不支持高并发 CONNECT 隧道，极易被上游网关限速或直接返回 429 Too Many Requests。这不是 Composer 的错，是代理吞吐瓶颈。
- 永久关闭并发：
composer config -g repos.packagist.org.concurrent-downloads 1（注意键名是repos.packagist.org，不是http-max-concurrent-downloads） - 临时验证效果：
composer install --concurrent-downloads=1 -vvv - 若仍卡住，说明代理本身不可靠——换用系统级代理（如 macOS 的 Network Preferences 设置）或改用 socks5 代理（需确保
https-proxy仍为http://协议前缀）
镜像源与代理不能混用，必须二选一
很多人以为“配了阿里云镜像 + 代理”能双保险，实际是灾难组合：Composer 先走镜像 URL，再把请求扔给代理，而镜像服务（如阿里云）明确拒绝代理访问，直接返回 403 Forbidden 或静默断连。
- 验证是否混用：
composer config -g repo.packagist输出含https://mirrors.aliyun.com/composer/，但composer install -vvv日志里请求 URL 却是https://repo.packagist.org/...→ 说明代理配置覆盖了镜像 - 正确做法：要么彻底禁用代理（
composer config -g --unset http-proxy+--unset https-proxy），只用镜像；要么禁用镜像（composer config -g --unset repo.packagist），只走代理 - 清理残留：
composer clear-cache后再重试，避免缓存元数据误导请求路径
代理配置的坑不在参数多寡，而在协议、并发、源三者是否自洽。哪怕一个斜杠漏掉、一个键名多写个 s，都会让整个链路静默失效。排查时别跳步，从 curl -x 开始，一层层剥开，比改十次 Composer 配置都快。
