Composer 必须同时配置 http-proxy 和 https-proxy，且 https-proxy 值必须以 http:// 开头（非 https:// 或无协议），否则 HTTPS 请求静默直连导致仓库加载失败。
只配 http-proxy 一定失败，必须显式设 https-proxy
Composer 对 HTTP 和 HTTPS 请求走两套完全独立的代理路由：HTTP 请求走 http-proxy，HTTPS 请求必须靠 https-proxy 建立 CONNECT 隧道。而 Packagist、GitHub、GitLab 所有仓库全量走 HTTPS，漏掉 https-proxy 就等于让全部元数据请求 fallback 直连——现象是卡在 Loading composer repositories，或反复报 cURL error 28，却无明确错误提示。
关键点：https-proxy 的值必须以 http:// 开头（不是 https://），哪怕你的代理服务监听的是 TLS 端口。这是 Composer 的硬性协议约定，填错就静默失效。
composer config -g http-proxy http://127.0.0.1:8080-
composer config -g https-proxy http://127.0.0.1:8080✅（注意是http://） -
composer config -g https-proxy https://127.0.0.1:8080❌（会被忽略） -
composer config -g https-proxy 127.0.0.1:8080❌（缺协议头，同样静默失败）
https-proxy 密码含特殊字符必须 URL 编码
如果代理账号密码里有 @、/、: 等字符，不编码会导致解析失败，Composer 会把 @ 误认为 URL 用户名/密码分隔符，后续部分被截断。典型表现是配置看似写入成功，但实际请求仍直连。
例如密码为 pa@ss/word:123，需编码为 pa%40ss%2Fword%3A123，完整命令为：
composer config -g https-proxy http://user:pa%40ss%2Fword%3A123@127.0.0.1:8080
验证是否生效：
composer config -g --list | grep -E "(http|https)-proxy"
应输出两行，且 URL 格式可读、无截断。
全局配置必须加 -g，否则换目录就失效
不加 -g（或 --global）时，composer config http-proxy ... 只写入当前项目根目录下的 composer.json，对其他项目完全无效。CI 环境、宝塔后台、甚至你新开一个终端窗口，都可能因用户权限或路径切换导致配置不可见。
务必统一使用：
composer config -g http-proxy http://...composer config -g https-proxy http://...
配置实际写入位置是 ~/.composer/config.json（Linux/macOS）或 %APPDATA%\Composer\config.json（Windows），所有命令行调用 Composer 时都会读这里。
代理和镜像共存时，https-proxy 仍决定出口路径
镜像源（如 repo.packagist）改的是请求目标（GET https://mirrors.aliyun.com/composer/packages.json），而 https-proxy 决定这个 HTTPS 请求从哪条链路出去。两者不冲突，但顺序有影响：如果代理本身不稳定，即使镜像 URL 正确，也会因隧道建立失败而超时。
建议组合策略：
- 先确保
https-proxy能通（可用curl -x http://127.0.0.1:8080 -I https://mirrors.aliyun.com验证） - 再配镜像：
composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/ - 最后清缓存：
composer clear-cache，避免旧包信息干扰
真正容易被忽略的是：代理配置错误时，Composer 很少报错，它只是默默 fallback 直连——你得主动查 composer config -g --list 和真实请求日志（composer install -vvv 2>&1 | grep "packages.json"），才能确认流量到底走了哪条路。
