必须同时配置http-proxy和https-proxy且均以http://开头，缺一不可；仅显示http-proxy说明https-proxy缺失，导致HTTPS请求静默直连而卡在Loading composer repositories或报cURL error 28。
composer config -g --list 能看到代理但不生效？先确认两字段都存在
只看到 http-proxy 没有 https-proxy，基本等于没配——Packagist 全量走 HTTPS，https-proxy 缺失会导致所有元数据请求静默 fallback 到直连，卡在 Loading composer repositories 或报 cURL error 28。
必须同时设置两个字段，且值格式严格：
-
http-proxy和https-proxy都必须以http://开头（哪怕代理监听的是 HTTPS 端口） - 地址末尾不能带斜杠，
http://127.0.0.1:7890/会解析失败，得写成http://127.0.0.1:7890 - 含特殊字符（
@、/、:）的密码必须 URL 编码，例如pa@ss/word→pa%40ss%2Fword
为什么 composer diagnose 显示 proxy 却仍连不上？它不发真实请求
composer diagnose 只校验配置语法和本地文件状态，不触发任何网络请求。它告诉你“配置写对了”，但不保证“代理能通”。真正验证是否生效，得让它实际走一次 HTTPS 流量：
Workflow Decomposer
下载
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
- 运行
composer global status：它会尝试访问https://packagist.org/packages.json，返回OK才算代理转发成功 - 或执行
composer show --platform：同样触发 HTTPS GET，若超时或报Connection refused，说明代理进程没运行、端口不通，或中间被拦截 - 如果命令卡住无响应，大概率是
https-proxy没配，或代理服务本身未启动
curl -x 能通，但 Composer 还是失败？检查 NTLM 和镜像冲突
用 curl -x http://127.0.0.1:7890 -I https://packagist.org/packages.json 能拿到 200，不代表 Composer 就能用——常见干扰项有两个：
-
NTLM 代理：公司 Windows 域环境常用。Composer 原生不支持 NTLM 认证，设了
http-proxy也会直接返回407 Proxy Authentication Required。必须用cntlm或px做中转，再让 Composer 连http://127.0.0.1:3128 -
镜像与代理混用：一旦设置了
repos.packagist（如阿里云镜像），http-proxy和https-proxy字段会被完全忽略。国内用户卡住，90% 是这个原因。验证方法：composer config -g --list | grep -E "(http|https)-proxy"有输出，但composer install -n -vvv日志里没出现Proxy CONNECT，就说明代理根本没启动
代理地址没错，还是 502 或超时？重点看 TLS 和超时链路
502 Bad Gateway 不是 Composer 的错，而是代理服务自身返回了非法响应，常见于：
- 代理填了
https://127.0.0.1:7890（协议头错误），导致隧道建立失败，上游网关吐出 502 - 代理启用了 TLS 终止但证书不受信任，cURL 拒绝继续，Composer 静默 fallback 直连，结果卡住而非报错
-
http.timeout默认仅 300 秒，弱网下极易超时；同时要检查 PHP 的default_socket_timeout（php -i | grep default_socket_timeout），若它比 Composer 设的 timeout 还小，就会提前掐断连接
代理配置只是链路一环，真正出问题的地方往往藏在 TLS 握手、DNS 解析、或系统级 socket 超时里——别只盯着 config -g 输出看。
