必须同时配置 http-proxy 和 https-proxy，因 composer 的 packagist 请求走 https，仅配 http-proxy 无效；https-proxy 值仍用 http:// 协议，且需 url 编码特殊字符，优先检查环境变量冲突与代理是否支持 connect 隧道。
Composer 在企业内网里连不上 packagist.org，不是它慢，是根本没发出去——网关拦截了 HTTPS 请求，必须用 HTTP 代理透传，且 http-proxy 和 https-proxy 必须同时配对，缺一不可。
为什么只配 http-proxy 会静默失败
Composer 对 Packagist 的元数据请求（如 https://packagist.org/packages.json）走的是 HTTPS 协议，而 http-proxy 配置只影响 HTTP 流量；https-proxy 才真正接管这些 HTTPS 请求。漏掉它，Composer 就会直连外网，被网关丢包或超时，现象就是卡在 “Loading composer repositories”，日志里却看不到明确错误。
-
https-proxy的值仍必须写成http://127.0.0.1:8080，不是https://——填错协议头会静默忽略 - 验证是否生效：运行
composer config -g --list | grep -E "(http|https)-proxy"，必须看到两行输出 - 某些旧版文档提到的
proxy（无 s）字段已弃用，以http-proxy和https-proxy为准
curl -x 能通，但 Composer 还是卡住？检查这三处
手动用 curl -x http://127.0.0.1:8080 https://packagist.org/packages.json 成功，只说明代理进程和基础链路 OK，不代表 Composer 就能用。真正卡点常在：
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
- 代理地址里含
@、:、/等字符但未 URL 编码，例如密码pa@ss/word必须先执行php -r "echo rawurlencode('pa@ss/word');"得到pa%40ss%2Fword，再拼成http://user:pa%40ss%2Fword@127.0.0.1:8080 - 系统环境变量
HTTP_PROXY或HTTPS_PROXY与 Composer 配置冲突——Composer 优先读环境变量，若设了又没生效，先unset HTTP_PROXY HTTPS_PROXY再试 - 代理服务本身不支持 CONNECT 隧道（即无法中转 TLS 流量），此时
file_get_contents(): SSL operation failed是典型表现，换用纯 HTTP 代理地址（非 HTTPS）可绕过
遇到 407 Proxy Authentication Required 怎么办
这是 NTLM 认证代理（常见于 Windows 域控环境）返回的标准响应，Composer 原生不支持 NTLM，任何 http-proxy 配置都无效。
- 不能靠改 Composer 参数解决，必须加一层本地中转：用
cntlm或px启一个监听127.0.0.1:3128的普通 HTTP 代理，再让 Composer 连它 - 确认公司是否有免认证的 bypass 代理出口（比如
http://bypass-proxy.internal:8080），直接配这个更省事 - 临时测试可清空代理：
composer config -g http-proxy '' && composer config -g https-proxy ''，但别长期留空
镜像源和代理别混着用
如果公司已有私有镜像（如阿里云、腾讯云或 Artifactory 部署的内网镜像），就别配代理——直接切源更稳，也避免 TLS 不匹配、DNS 解析异常等衍生问题。
- 全局切换阿里镜像：
composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/ - 私有镜像示例：
composer config -g repo.packagist composer http://internal-mirror.yourcompany.com/composer（注意必须是repo.packagist，不是repo.packagist.org） - 切源后务必清理残留代理：
composer config -g --unset http-proxy && composer config -g --unset https-proxy
最麻烦的从来不是命令怎么写，而是代理链路里任意一环（本地代理进程、防火墙策略、网关 ACL、甚至 DNS 转发规则）出问题，现象都一样：没报错，只卡住。逐层用 curl -x 验证，比反复重装 Composer 有用得多。
