Composer不读HTTP_PROXY环境变量，只认自身配置的http-proxy和https-proxy；必须用composer config -g设置，且https-proxy字段必须以http://开头，密码需URL编码，镜像源与代理不可共存。
Composer根本不读HTTP_PROXY环境变量
它只认自己配置项里的http-proxy和https-proxy，哪怕你export了HTTP_PROXY和HTTPS_PROXY，composer install照样当没看见。这不是bug，是设计如此——Composer明确跳过系统级代理变量，避免意外透传或协议混淆。
常见错误现象：Loading composer repositories卡住、cURL error 35、静默超时，90%是因为只设了环境变量，没动Composer自己的配置。
- 验证是否真生效：运行
composer config -g --list | grep -E "(http|https)-proxy"，必须看到两行输出 - 临时绕过检查：加
-n -vvv运行composer install，日志里出现Proxy CONNECT才说明走通了 - Windows用户注意：
set http_proxy=...这类命令对Composer无效，别浪费时间试
https-proxy必须写成http://开头
哪怕你的代理服务监听在https://127.0.0.1:8443，https-proxy字段也得填http://127.0.0.1:8443。这是Composer的硬性约定：它用这个值发起HTTP CONNECT请求，建立TLS隧道，而不是自己做HTTPS握手。
填错的典型表现：无报错、无日志、所有HTTPS请求fallback直连，最终超时或返回502 Bad Gateway。
- 正确写法永远是
http://user:pass@127.0.0.1:8080（注意协议头） - 密码含
@、/、:必须URL编码，例如pa@ss/word→pa%40ss%2Fword - 用
php -r "echo rawurlencode('pa@ss/word');"快速生成编码结果
镜像源和代理不能共存
二者作用层面不同：repo.packagist改的是元数据地址，http-proxy/https-proxy改的是流量转发路径。一旦配了镜像，Composer就彻底忽略代理字段；反之，开了代理，镜像配置形同虚设。
国内用户卡在Loading composer repositories，绝大多数是因为同时执行了这两条命令：
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/composer config -g https-proxy http://127.0.0.1:8080
结果是：镜像地址生效，但代理不启动，而公司网络策略又强制所有HTTPS流量过代理——于是连接被拦截，且无明确错误提示。
真要用代理，第一步永远是清掉镜像：composer config -g --unset repo.packagist（注意不是repos.packagist或packagist.org）。
NTLM代理必须用中转工具
Windows域环境下常见的407 Proxy Authentication Required错误，根源是Composer原生不支持NTLM认证。你填再正确的http://user:pass@proxy也没用，因为NTLM不是简单Base64或Basic Auth。
必须引入中转层，比如cntlm或px，让它们监听127.0.0.1:3128并处理NTLM握手，再让Composer连这个本地地址。
- 验证中转是否正常：
curl -x http://127.0.0.1:3128 -I https://packagist.org/packages.json - 如果curl也报407，说明中转没配好，别急着调Composer
- 别指望
COMPOSER_DISABLE_NETWORK=1能绕过——它只是跳过网络请求，不解决认证问题
证书、时间、协议头、配置层级……这些点单独看都小，但混在一起就极难定位。最稳妥的做法是：先确认网络策略要求走代理还是镜像，再清空所有冲突配置，从零开始配一对可验证的http-proxy和https-proxy。
