答案是“Connection refused”或“cURL error 7”表明请求根本没发出去，需先用ping和curl验证DNS与TCP/TLS连通性，再严格按repo.packagist单数键、type值composer、URL末尾带/三要素配置镜像，清缓存、删vendor和composer.lock，并排查项目级repositories覆盖及权限错位。
Composer安装失败，90%不是网络差，而是镜像没生效、缓存没清、或根本没连上——先别改composer.json，直接看真实请求路径和系统连通性。
报“Connection refused”或“cURL error 7”说明请求根本没发出去
这类错误和 PHP 版本、扩展、composer.json 内容完全无关，是系统级网络断层。
- 运行
ping packagist.org：返回unknown host→ DNS 解析失败，立刻换 DNS（如8.8.8.8） - 能 ping 通但
curl -v https://mirrors.aliyun.com/composer/卡在* Connected to→ TCP 建连被防火墙或代理拦截 - 卡在
* TLS handshake→ 企业 HTTPS 解密代理、OpenSSL 版本过旧或 CA 证书失效
镜像配置写对了但还是走官方源
Composer 会静默 fallback 到 https://packagist.org，不报错也不提醒，必须同时满足三个硬条件：
- 键名必须是
repo.packagist（repos.packagist或repositories.packagist都无效） - 命令中必须显式传
composer作为 type：composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/ - URL 必须以
https://开头且末尾带/（https://mirrors.aliyun.com/composer会拼出 404 路径） - 配完立刻验证：
composer config -g repo.packagist输出必须是完整 JSON，如{"type": "composer", "url": "https://mirrors.aliyun.com/composer/"}
换源后还是慢，最常漏掉的一步是清缓存
缓存里存着旧的 packages.json 和元数据，Composer 优先读缓存，哪怕配置已改，它仍试图从旧地址拉校验信息。
- 必须执行
composer clear-cache（Windows 还要手动删%LOCALAPPDATA%\Composer\cache） - 项目级
repositories字段会覆盖全局镜像，用composer config --unset repositories临时清掉再试 - CI/CD 或宝塔环境常见权限错位：root 配的全局配置，www 用户执行时读不到，应切用户执行：
sudo -u www composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/
“Resolving dependencies”卡住跟镜像完全无关
这个阶段不走网络，纯本地穷举版本组合。尤其当你写了 "*"、"^1.0 || ^2.0" 或 "minimum-stability": "dev" 时，求解器可能指数级爆炸。
- 删掉
composer.lock后跑composer update --dry-run观察是否卡在这里 - 临时加
--ignore-platform-reqs和--no-scripts缩短等待时间 - 避免
--prefer-source：它强制 Git 克隆，比--prefer-dist更容易因 SSH/Git 超时卡死
真正难排查的点在于：错误日志看起来像网络问题，实际可能是属主权限错位、CA 证书过期、或项目级 repositories 暗中覆盖了全局配置——这些都不会报明确提示，得靠 composer install -vvv 2>&1 | head -n 10 | grep Downloading 抓第一行真实 URL 才能确认到底连的是谁。
