真正有效的方案是让镜像与代理协同：国内包走镜像，国外Git仓库走代理；因Packagist镜像不代理git clone操作，需单独配置Git的HTTP/SSH代理，且避免全局http_proxy干扰镜像。
Composer 安装慢，本质是网络链路问题，不是配置错——换镜像或开代理单独用，效果常打折扣；真正有效的方案是让两者协同工作：国内包走镜像，国外包（如私有 Git 仓库、GitHub 原始源）走代理。
为什么只换镜像仍卡在 github.com 或 gitlab.com
Composer 的 packagist.org 镜像（如阿里云、腾讯云）只加速 PHP 包元数据和 ZIP 下载，但不代理 Git 克隆操作。一旦依赖中含 "repo": "git@github.com:xxx/yyy" 或 "vcs" 类型仓库，Composer 会直接走 git clone，触发 SSH/HTTPS 连接 GitHub —— 此时镜像完全不生效。
- 现象：
Installing xxx/yyy (dev-main): Cloning xxxxx from github.com卡住几十秒甚至超时 - 原因：Git 协议未被镜像覆盖，且系统级 Git 未配置代理
- 验证方式：手动执行
git clone https://github.com/composer/composer看是否同样缓慢
如何让 Composer 同时用镜像 + 代理
关键在分层控制：Composer 自身请求走镜像，Git 操作走代理。需两处配置：
- 全局设置 Packagist 镜像：
composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/ - 为 Git 单独配置 HTTPS/SSH 代理（推荐 HTTPS）：
git config --global http.https://github.com.proxy http://127.0.0.1:7890（假设代理端口是 7890） - 若用 SSH 方式克隆，需改写 URL 并配置
~/.ssh/config，例如：Host github.com<br> ProxyCommand nc -x 127.0.0.1:7890 %h %p
- 注意：不要对
http://或本地地址设代理，否则镜像请求也被转发，反而绕过镜像
代理端口选 HTTP 还是 SOCKS5
HTTP 代理更稳妥。Composer 内部调用 curl 或 PHP Stream，对 HTTP 代理原生支持；SOCKS5 需额外启用 curl 的 CURLOPT_PROXYTYPE，PHP 层未必透传，容易失效。
- Clash / Qv2ray 默认开启 HTTP 代理（通常 7890），直接用即可
- 如果代理只开 SOCKS5（如 1080），可用
privoxy转发：配置forward-socks5 / 127.0.0.1:1080 .，再让 Git 指向 privoxy 的 HTTP 端口 - 避免在
php.ini中设http_proxy全局环境变量——这会让所有 PHP HTTP 请求（包括镜像）都走代理，失去镜像意义
验证是否真正混合生效
运行 composer install -vvv，观察日志中的 URL 前缀：
- 元数据请求应为：
GET https://mirrors.aliyun.com/composer/p2/monolog/monolog.json - Git 克隆应为：
Executing command (/tmp/xxx): git clone --no-checkout 'https://github.com/monolog/monolog' '/tmp/xxx' --depth 1 --reference '/home/user/.composer/cache/vcs/https---github.com-monolog-monolog/'，且该命令实际能快速完成 - 若仍见
https://packagist.org或卡在git clone git@，说明镜像未生效或 SSH 代理未命中
最易忽略的一点：某些公司网络会拦截或重定向 git clone https://，此时必须用 SSH + SOCKS5 配置，且确保 ~/.ssh/config 的 Host 规则与实际 Git URL 完全匹配（比如 github.com 和 www.github.com 是不同 Host）。
