HTTP和HTTPS代理必须同时配置，因为Composer代理逻辑协议隔离：HTTP流量走http-proxy，HTTPS流量只认https-proxy，二者互不接管；仅配http-proxy时，HTTPS仓库请求会直连卡死。
为什么http-proxy和https-proxy必须同时设
只配http-proxy，https://packagist.org这类 HTTPS 仓库请求会 fallback 到直连，结果卡在Loading composer repositories不动，也不报错。Composer 的代理逻辑是“协议隔离”的：HTTP 流量走http-proxy，HTTPS 流量只认https-proxy，两者互不接管对方协议。
常见错误写法：https-proxy: https://127.0.0.1:8080（协议头错）、https-proxy: 127.0.0.1:8080（漏协议头）——这两种都会导致静默失效。正确格式必须是http://开头，哪怕代理服务本身监听 HTTPS 端口。
- 执行
composer config -g --unset repo.packagist清空镜像，否则代理字段被完全忽略 - 用
composer config -g http-proxy http://your-proxy:port和composer config -g https-proxy http://your-proxy:port成对设置 - 用户名或密码含
@、/、:时，必须 URL 编码，例如pa@ss/word→pa%40ss%2Fword
cafile配置不当导致TLS握手失败的典型表现
代理环境下最常遇到的不是连不上，而是cURL error 28、SSL certificate problem或无日志超时。根本原因不是证书过期，而是 Composer 默认信任系统 ca-bundle.crt，而企业代理通常用自签名根证书，系统证书链里没有它。
- 运行
composer config -g cafile /path/to/your-company-root.pem，指向公司内网签发的根证书文件 - 不要复用
curl-ca-bundle.crt或 PHP 自带的ca-bundle.crt，它们不含企业私有 CA - Windows + WSL2 用户若时间差超过 5 分钟，也会触发 TLS 握手失败，需同步时间：
sudo hwclock -s - 验证是否真走代理：加
-n -vvv运行composer install，看到Proxy CONNECT字样才算生效
镜像和代理混配为什么必出问题
镜像源改的是元数据地址（比如把https://packagist.org换成https://mirrors.aliyun.com/composer/），代理改的是流量出口路径。Composer 内部逻辑是“二选一”：一旦repo.packagist被设为镜像地址，http-proxy和https-proxy字段就彻底不读取——不是优先级低，是直接跳过。
国内用户 90% 的“卡死”都源于此：既配了阿里云镜像，又填了公司代理，结果 Composer 拿着镜像地址直连，但公司网络策略强制所有 HTTPS 流量过代理，于是连接被拦截或超时，日志里却只显示Loading composer repositories，没有任何错误提示。
- 企业内网首选镜像；只有需要 mTLS 私有源（如内部 GitLab 包仓库）时才必须用代理
- 用
composer config -g -l检查当前生效配置，确认repo.packagist为空且http-proxy/https-proxy都存在 - 临时切换可加
--no-plugins避免插件干扰，排除第三方扩展干扰
代理配置后仍失败的三个冷门排查点
很多问题不在配置本身，而在环境链路的隐性环节。比如 Composer 启动时加载的 PHP 配置、DNS 解析顺序、甚至 Windows 主机文件缓存。
- PHP 的
openssl.cafile或curl.cainfoini 设置会覆盖 Composer 的cafile，需统一指向同一证书文件 - 某些代理要求 Host 头必须为
Host: packagist.org，但 Composer 默认发Host: mirrors.aliyun.com（如果误留镜像配置），此时需彻底清空并重试 - Windows 下 DNS 缓存可能污染测试结果，执行
ipconfig /flushdns后再试，避免旧解析干扰
代理配置真正生效的关键，从来不是字段填得全，而是整个链路里没有一个环节在“假装工作”。尤其要注意cafile路径是否真实可读、https-proxy协议头是否严格为http://、以及镜像配置是否被-g全局设置残留。
