根本原因是composer元数据拉取不走代理，必须配置镜像源；正确做法是执行composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/、clear-cache、删vendor与lock后重装，并用-vvv验证日志是否命中镜像地址。
composer install 时走代理但卡在 Loading repositories
根本原因不是代理没配，而是 Composer 默认仍尝试直连 packagist.org 的元数据接口，而该域名即使走代理也常因 TLS 指纹或 CDN 路由被拦截。单纯设 HTTP_PROXY 环境变量对元数据拉取无效——它只影响 dist 包下载（zip/tar），不控制 repository discovery。
必须配合镜像源使用，否则代理只是“绕远路连失败”。国内用户尤其要先执行：
composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/composer clear-cache- 删掉项目下的
composer.lock和vendor/
再跑 composer install -vvv，日志里出现 Downloading https://mirrors.aliyun.com/... 才算真正生效。
require 指定包时代理失效的常见写法错误
很多人以为 composer require vendor/pkg 会自动继承系统代理，其实它内部仍分两步：先查包信息（走 repository），再下代码（走 dist）。如果第一步就失败，第二步根本不会触发。
正确做法是确保以下三点同时满足：
- 全局镜像已配置且验证通过：
composer config -g repo.packagist输出必须是完整 JSON，含"type": "composer"和带尾斜杠的 HTTPS URL - 代理环境变量在 shell 中导出且未被子进程清除：
export HTTP_PROXY=http://127.0.0.1:7890; export HTTPS_PROXY=$HTTP_PROXY - 避免在 CI 或 Docker 中用
sudo启动 composer —— 它会丢掉用户级环境变量，导致 proxy 失效
若仍报 Connection refused 或超时，加 -vvv 看第一行请求地址：如果是 https://api.github.com/...，说明镜像没生效；如果是 https://mirrors.aliyun.com/... 但失败，则问题在代理本身（比如代理不支持 HTTPS CONNECT 隧道）。
装含二进制依赖的包（如 pestphp/pest）时代理不转发
这类包在 post-install-cmd 或 scripts 里会调用 curl / wget 直接下载预编译二进制，完全绕过 Composer 的代理设置。它们只认系统级或自身脚本里的环境变量。
解决方案不是改 Composer 配置，而是提前注入：
- Linux/macOS 下运行前设：
export PEST_BINARY_MIRROR=https://npmmirror.com/mirrors/pest/（以 pest 为例，其他包查其文档找对应 env 变量） - 或临时替换下载命令：
alias curl='curl -x http://127.0.0.1:7890'，确保所有子进程继承 - Windows PowerShell 用户注意：
$env:HTTP_PROXY="http://127.0.0.1:7890"必须在启动终端后第一时间设置，否则 Composer 启动的 PHP 进程可能读不到
这类行为由包自身控制，Composer 无法干预——所以别指望 --proxy 参数能解决所有下载问题。
公司内网用 NTLM 代理时 composer require 失败
标准 HTTP_PROXY 不支持 NTLM 认证，直接设会导致 407 Proxy Authentication Required 错误，且 Composer 不提示具体原因。
可行路径只有两条：
- 换用支持 NTLM 的本地代理中转，例如
cntlm或px，把认证卸载到本地，再让 Composer 连http://127.0.0.1:3128 - 放弃代理，改用离线方式：先在能上网的机器上
composer install --no-dev --prefer-dist打包整个vendor/，再拷进内网；后续require新包时，用composer archive导出单个包的 zip，手工放至内网私有 repo
试图用 curl -U user:pass 强行封装 Composer 命令，大概率失败——因为 Composer 启动多个 PHP 子进程，每个都得单独传参，不可维护。
