必须同时配置http-proxy和https-proxy，且https-proxy协议头必须为http://；因composer对http/https请求分路由，所有仓库全量走https，缺一将导致https请求静默直连，卡在loading composer repositories或报curl error 28。
必须同时配置 http-proxy 和 https-proxy，且后者协议头必须是 http:// —— 配错一个，Composer 就会静默 fallback 到直连，卡在 Loading composer repositories 或报 cURL error 28。
为什么只配 http-proxy 一定失败
Composer 把 HTTP 和 HTTPS 请求走完全不同的代理路径：前者走 http-proxy，后者强制走 https-proxy 字段发起 CONNECT 隧道。而 Packagist、GitHub、GitLab 所有仓库全量走 HTTPS，漏掉 https-proxy 就等于让 HTTPS 请求直连。结果不是报错，而是卡住或超时，终端无明确提示。
-
composer config -g --list只显示http-proxy，没看到https-proxy→ 配置不完整 - 填了
https://127.0.0.1:7890或127.0.0.1:7890→ 协议头错误，静默失效 - 代理服务监听 HTTPS 端口（如 443），仍要写成
http://127.0.0.1:443→ 这是 Composer 的硬性路由规则，不是代理本身的要求
https-proxy 的正确写法和验证方式
无论你的代理是 Clash、Proxyman 还是 Squid，https-proxy 的值协议头必须是 http://：
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- 本地 Clash：
http://127.0.0.1:7890 - 带认证的代理：
http://user:pa%40ss%2Fword@127.0.0.1:8080（密码含@或/必须 URL 编码） - 验证是否生效：
composer config -g --list | grep -E "(http|https)-proxy"，必须两行都存在且格式合规 - 临时绕过测试：
HTTP_PROXY= HTTPS_PROXY= composer install，若此时成功，基本锁定是代理配置问题
NTLM 代理（如公司 Windows 域环境）怎么办
Composer 原生不支持 NTLM 认证，设了 http-proxy 也会直接返回 407 Proxy Authentication Required。不能靠改 Composer 配置解决，必须引入中转代理工具：
- Windows 推荐
cntlm或px，让它们监听127.0.0.1:3128并处理 NTLM，再把 Composer 的http-proxy和https-proxy都指向http://127.0.0.1:3128 - 验证中转层是否生效：
curl -x http://127.0.0.1:3128 -I https://packagist.org/packages.json，如果也报407，说明中转没配好 - 别指望
https-proxy支持ntlm://—— 没这回事，Composer 不解析这个协议
代理配对了还是超时？别只盯着 proxy 字段
代理只是链路一环，超时还可能卡在其他环节：
-
http.timeout默认仅 300 秒（5 分钟），弱网下极易触发；需同步运行composer config -g http.timeout 600 - PHP 的
default_socket_timeout若低于你设的http.timeout（常见值是 60），会提前掐断连接；查它：php -i | grep default_socket_timeout - CI 容器重启后配置丢失、SSH 地址未持久化、
COMPOSER_HOME被覆盖 —— 这些比代理本身更容易被忽略
最常被跳过的一步：换源后没执行 composer clear-cache，旧缓存仍会复用失败地址，导致你以为代理生效了，其实还在走老路。
