因为composer对http和https请求分通道代理，仅配http-proxy无法处理强制https的仓库通信，必须同时配置https-proxy建立connect隧道，否则会静默直连触发防火墙拦截。
为什么只配 http-proxy 还是被防火墙拦截
Composer 对 HTTP 和 HTTPS 请求走完全不同的代理通道：http-proxy 只处理纯 HTTP 流量，而所有仓库通信（包括 packagist.org、GitHub 包元数据）都强制走 HTTPS，必须靠 https-proxy 字段建立 CONNECT 隧道。漏掉它，Composer 就会静默 fallback 到直连——这正是防火墙最擅长识别和阻断的流量模式。
常见错误现象：composer install 卡在 “Loading composer repositories”，-vvv 日志里既无报错也无域名请求，最终超时。这不是慢，是请求根本没进代理。
-
https-proxy的值必须是http://开头（哪怕代理监听的是 TLS 端口），例如http://127.0.0.1:7890；填成https://或漏协议头会直接失效 - 两个字段必须同时配全：
composer config -g http-proxy http://127.0.0.1:7890和composer config -g https-proxy http://127.0.0.1:7890 - Windows 用户若用 NTLM 代理（如域环境），Composer 原生不支持，得用
cntlm或px在本地起中转服务，再让 Composer 连127.0.0.1:3128
repo.packagist.org.proxy 和 https-proxy 有什么区别
这是最容易混淆的一组配置。前者是旧版 Composer（https-proxy 是唯一有效字段；repo.packagist.org.proxy 在新版本中会被忽略，还可能干扰诊断。
验证方式：运行 composer config -g --list | grep -E "(http|https)-proxy"，只应看到两行：http-proxy 和 https-proxy，且值格式正确。如果出现 repo.packagist.org.proxy，说明你混用了旧命令，建议先用 --unset 清掉再重配。
- 别信“系统环境变量自动生效”——
HTTP_PROXY和HTTPS_PROXY对 Composer 完全无效 - 代理地址必须带端口，
http://127.0.0.1不合法，会报Invalid URI - 密码含特殊字符（如
@、/）必须 URL 编码，可用php -r "echo rawurlencode('pa@ss/word');"生成
代理配好了，但 composer install 仍报 Connection refused
这不是代理没连上，而是代理本身被防火墙策略拦截了。典型表现是：curl -x http://127.0.0.1:7890 -I https://packagist.org/packages.json 同样失败，或返回 502 Bad Gateway。此时问题已不在 Composer 配置层，而在网络链路本身。
快速定位三步法：
- DNS 层：执行
nslookup packagist.org，返回unknown host就换 DNS（如114.114.114.114） - TCP 层：执行
telnet packagist.org 443，通不过说明 443 被拦，需确认代理进程是否运行、端口是否填错 - TLS 层：执行
curl -v https://mirrors.aliyun.com/composer/，卡在TLS handshake表明企业中间人代理在篡改证书，必须配cafile
注意：换源后务必执行 composer clear-cache，否则失败缓存还在，重试照样走原路径。
企业内网下绕过 TLS 审查的唯一安全做法
浏览器能打开镜像站但 Composer 报 SSL certificate problem，基本可断定是企业防火墙做了 TLS 解密。此时关校验（secure-http false 或 cafile /dev/null）等于主动放弃供应链安全，绝不能用于生产环境。
正确做法是导出公司根证书（从 Chrome/Edge 的“证书管理器→受信任的根证书颁发机构”导出 PEM 格式），然后：
- Linux/macOS：
composer config -g cafile /path/to/company-ca.crt - Windows：
composer config -g cafile C:\certs\company-ca.crt（双反斜杠） - 验证是否生效：
composer diagnose输出里不应再有cURL error 60或证书警告
最关键但最常被跳过的一步：镜像 URL 必须带 type=composer 且以 / 结尾，否则 Composer 会拼错路径（如 /composerpackages.json），导致 404 后自动 fallback 到 packagist.org——前功尽弃。
