答案是代理配置未生效或HTTPS证书校验被拦；必须同时设置http-proxy和https-proxy（值均以http://开头），且需验证真实请求路径，禁用镜像混用、检查PHP扩展及CA证书配置。
代理环境下 Composer 下载失败，90% 是代理配置未生效或 HTTPS 证书校验被拦，不是镜像或包本身的问题。
代理配置写了但没走代理？先确认真实请求路径
很多人执行 composer config -g http-proxy 后就以为搞定了，其实 http-proxy 和 https-proxy 必须**同时设置**，且 URL 格式必须带协议和端口（如 http://127.0.0.1:8080）。否则 Composer 默认只用 http-proxy 走 HTTP 请求，而所有镜像都是 HTTPS，直接跳过代理。
- 验证是否真正启用：运行
composer global config --list --verbose，检查输出中http-proxy和https-proxy是否都存在且值非空 - 临时绕过代理测试：加
--no-proxy参数跑一次composer install -vvv，看错误是否变成Connection refused或cURL error 7——如果是，说明代理确实是瓶颈 - 企业内网常见问题：中间人代理（如 Zscaler、Netskope）会替换 TLS 证书，导致 PHP 的 OpenSSL 扩展校验失败；此时
curl -I https://mirrors.aliyun.com/composer/packages.json也会卡在 TLS handshake
HTTPS 代理失败时怎么临时绕过证书校验？
这不是永久方案，但能快速验证是不是证书问题。注意：仅限调试，切勿保留在生产或 CI 环境中。
- 关闭安全 HTTP 强制：运行
composer config -g secure-http false - 禁用 CA 校验（慎用）：运行
composer config -g cafile /dev/null（Linux/macOS）或composer config -g cafile NUL（Windows） - 验证效果：再执行
composer diagnose，如果之前报SSL certificate problem，现在应变为连接成功或超时类错误 - 更稳妥的替代：把代理的根证书导出为 PEM 文件，然后设
composer config -g cafile /path/to/proxy-root.crt
PHP 自身不支持 HTTPS？检查 OpenSSL 和 cURL 扩展
代理配置全对，但 composer install 仍卡在 Downloading ...，大概率是 PHP CLI 层缺失关键扩展。
立即学习“PHP免费学习笔记（深入）”；
- 运行
php -m | grep -E "openssl|curl"，必须同时输出openssl和curl；缺任意一个，HTTPS 请求根本发不出去 - Windows 用户特别注意：PhpWebStudy 或 XAMPP 的
php.ini有两个——Web 版和 CLI 版。php -i | grep "Loaded Configuration File"显示的才是 CLI 实际加载的路径，确保该文件里extension=openssl和extension=curl前面没有分号 - 宝塔/CI 环境常禁用
proc_open或putenv，会导致 Composer 无法读取环境变量里的代理设置；运行composer diagnose会明确提示 “Theproc_openfunction is not available”
代理+镜像混用时最易踩的坑
国内用户常一边配阿里云镜像，一边开代理，结果反而更慢甚至失败——因为镜像站本身在国内，走代理等于绕远路，还可能触发代理层限速或拦截。
- 优先级判断：如果
ping mirrors.aliyun.com能通（time<10ms），就**不要配代理**，直接换镜像 +composer clear-cache - 如果必须用代理（如公司强制出口），就**不要换镜像**，保持默认源 + 代理 + 关闭
secure-http，避免镜像 URL 和代理策略冲突 - CI 环境（GitHub Actions / GitLab CI）里，
http-proxy配置不会继承本地设置，必须显式写进脚本：composer config -g http-proxy http://proxy.example.com:8080和composer config -g https-proxy http://proxy.example.com:8080 - 项目级
composer.json中若定义了repositories，会完全忽略全局代理配置——Composer 会尝试直连该仓库 URL，此时需在仓库 URL 里硬编码代理参数（不推荐）或改用--repository-url临时覆盖
代理环境下的 Composer 问题，核心永远是“请求到底发去了哪”。别猜，用 -vvv 看日志里真实的 Downloading from URL，再用 curl -v 模拟相同请求，两步就能定位到到底是代理没生效、证书被拦，还是 PHP 缺扩展。其他操作都是干扰项。
