“Connection refused”或“cURL error 7”说明请求未发出，根因是底层网络连通性中断，需优先排查DNS、防火墙、代理、hosts绑定等基础链路问题，而非Composer配置或缓存。
报错含“Connection refused”或“cURL error 7”说明请求根本没发出去
这类错误不是 Composer 解析失败，而是底层网络连通性中断——DNS 解析失败、代理未生效、防火墙拦截或本地 hosts 绑定错误都可能导致。别急着重装或清缓存，先验证基础链路是否通。
- 运行
ping packagist.org：如果返回unknown host，立刻检查 DNS（比如改用8.8.8.8） - 运行
curl -I https://mirrors.aliyun.com/composer/：必须看到HTTP/2 200；若卡在* Connected to或* TLS handshake，说明出口被拦（企业网/NAT/中间人代理常见） - 临时绕过证书校验验证是否为 TLS 问题：
composer config -g secure-http false和composer config -g cafile /dev/null（仅调试用，勿留生产）
为什么 composer install -vvv 比瞎猜快十倍
-vvv 输出里藏着三段关键链路日志：DNS resolution → TLS handshake → HTTP status code。卡在哪，就修哪，不靠经验，只看真实响应。
- 观察输出中第一个
Downloading行末尾的 URL，复制出来手动curl -I验证——注意 URL 末尾必须带/，否则拼出/packages.json导致 404 - 如果
curl -I返回403或502，换镜像源；返回429是阿里云限流，需降http-max-concurrent-downloads - 已停服源（如
https://packagist.phpcomposer.com）必须从全局 config 彻底删除：composer config -g --unset repo.packagist
企业网/校园网下反复出现 Connection reset by peer
这是 NAT 环境下中间设备强制断开长连接的典型表现，Composer 无法控制连接池，全靠 cURL 底层行为。Linux/macOS 下可临时禁用 keepalive 规避：
- 运行
CURL_OPTIONS="--no-keepalive" composer install -vvv - 若仍失败，说明是出口策略级拦截，需联系 IT 部门确认 HTTPS 流量是否被深度检测或重定向
- 别信
composer config -g repo.packagist的输出——它可能显示成功，但实际请求 URL 并未变更；唯一验证方式是composer install -vvv 2>&1 | grep Downloading
代理配置只设 http-proxy 必然失败
Packagist、GitHub 所有仓库均走 HTTPS，Composer 对 HTTP/HTTPS 请求分路由：前者走 http-proxy，后者必须走 https-proxy 字段发起 CONNECT 隧道。漏掉任一，HTTPS 请求就静默直连。
-
https-proxy值协议头必须是http://，例如http://127.0.0.1:7890；写成https://或无协议头会静默失效 - 验证是否生效：
composer config -g --list | grep -E "(http|https)-proxy"必须两行都存在且格式合规 - NTLM 代理（如 Windows 域环境）需引入中转工具（
cntlm或px），让 Composer 的两个 proxy 都指向中转服务的http://127.0.0.1:3128
网络问题的根因往往藏在最底层：DNS、TLS、代理、NAT、证书路径、甚至 /etc/hosts 里一行错误绑定。越早跳过“重试”和“清缓存”这类无效动作，越快定位到那个确定性失败点。
