必须同时配置http-proxy和https-proxy，且https-proxy值必须以http://开头；因packagist等全量走https，仅配http-proxy会导致https请求静默直连，卡在loading composer repositories或报curl error 28、502。
只配 http-proxy 肯定失败，必须同时设 https-proxy
Composer 对 HTTP 和 HTTPS 请求走两套完全独立的代理路径：HTTP 流量走 http-proxy，HTTPS 流量必须由 https-proxy 字段触发 CONNECT 隧道。Packagist、GitHub、GitLab 所有仓库全量走 HTTPS，漏掉 https-proxy 就等于让所有元数据请求（如 packages.json）静默直连——结果就是卡在 Loading composer repositories，或报 cURL error 28、502 Bad Gateway，却无明确提示。
常见错误写法包括：
-
https://127.0.0.1:7890（协议头错，必须是http://） -
127.0.0.1:7890（漏协议头，静默失效） - 只运行
composer config -g http-proxy http://127.0.0.1:7890，没配https-proxy
https-proxy 的值必须以 http:// 开头
这是 Composer 的硬性路由规则，不是可选项。哪怕你的代理服务监听的是 TLS 端口（比如 Clash 的 HTTPS 模式），https-proxy 的值也必须写成 http://127.0.0.1:7890。它只负责发起 CONNECT 请求，不参与后续 TLS 握手。
带认证时注意 URL 编码：
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
- 密码含
@或/必须编码，例如pa@ss/word→pa%40ss%2Fword - 可用
php -r "echo rawurlencode('pa@ss/word');"快速生成 - 完整示例：
http://user:pa%40ss%2Fword@127.0.0.1:8080
验证代理是否真正生效，别只看配置有没有
运行 composer config -g --list | grep -E "(http|https)-proxy" 只能确认字段存在，不能证明代理已启用。关键要看实际请求日志：
- 加
-vvv参数运行：composer install -n -vvv 2>&1 | grep -i proxy，正常应出现Proxy CONNECT日志 - 若没看到，说明代理根本没启动——大概率是镜像和代理混用了（见下一条）
- 临时绕过测试：
HTTP_PROXY= HTTPS_PROXY= composer install -n，如果此时成功，基本锁定是代理链问题
镜像和代理不能共存，国内用户最容易踩这个坑
镜像（如阿里云、腾讯云源）改的是请求地址（https://mirrors.aliyun.com/composer/），代理改的是流量转发路径。二者作用层面不同，且 Composer 会优先使用镜像配置，一旦设置了 repo.packagist，http-proxy 和 https-proxy 字段会被完全忽略。
解决办法很简单：
- 先清空镜像：
composer config -g --unset repos.packagist - 再重新设置两个代理：
composer config -g http-proxy http://127.0.0.1:7890和composer config -g https-proxy http://127.0.0.1:7890 - NTLM 企业代理需额外加中转层（如
cntlm或px），让它们监听127.0.0.1:3128，再把 Composer 的两个 proxy 都指向这个地址
最常被忽略的一点：PHP 自身的 default_socket_timeout（默认常为 60 秒）可能比 Composer 的 http.timeout（默认 300 秒）还短，导致连接在 Composer 层面还没超时，就被 PHP 底层掐断了。查它：php -i | grep default_socket_timeout，必要时同步调高。
