“连接被重置”是网络层问题而非 Composer 故障，常见于企业内网、云主机等环境，需先通过 composer diagnose、curl、ping 和 git clone 排查是否系统级网络或 DNS 异常，再针对性调整 IPv4、SSL 验证、镜像源、超时、代理或 Git 配置。
连接被重置（Connection reset by peer）不是 Composer “坏了”，而是它在下载包时，TCP 连接被中间网络设备（如防火墙、代理、NAT 网关）或远端服务器主动中断。常见于企业内网、云主机、CentOS 默认配置环境，和 SSL 证书、DNS、超时、IPv6 路由都可能有关。
检查是否真是网络层问题
别急着改 Composer 配置——先确认是不是系统连不上外网：
- 运行
composer diagnose，重点关注标为 ERROR 的项，尤其是HTTPS connectivity和GitHub API connectivity - 手动测试：用
curl -I https://packagist.org或ping github.com；如果这些也失败，问题不在 Composer，在系统网络或 DNS - 若
git clone https://github.com/composer/composer.git也卡住或报fatal: unable to access 'https://...': Failed to connect to github.com port 443: Connection reset by peer，基本可锁定是网络策略拦截
强制走 IPv4 + 关闭 SSL 验证（临时排障）
某些老旧内网环境对 IPv6 支持差，或证书链不全，会导致 TLS 握手阶段就被重置。这不是 Composer 的 bug，但可以绕过：
- 临时只用 IPv4：
CURL_IPRESOLVE=4 composer install（Linux/macOS）；Windows 可设环境变量再运行命令 - 临时关闭 HTTPS 校验（仅调试！）：
composer config -g secure-http false，之后记得恢复：composer config -g secure-http true - 如果仍报错，加
-vvv看具体卡在哪一步：composer install -vvv，输出里会显示正在请求哪个 URL，方便定位是 packagist 还是某个私有源
换镜像源 + 清缓存 + 调超时
国内直连 packagist.org 极易触发连接重置（尤其高峰时段），阿里云、腾讯云镜像更稳定，且自带 CDN 缓存，减少直连失败概率：
- 切阿里云镜像：
composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/ - 清掉可能损坏的缓存：
composer clear-cache（注意不是cache-clear） - 延长超时（尤其大项目或低带宽环境）：
composer config -g process-timeout 1800和composer config -g http-timeout 600 - 若公司有代理，必须显式配置：
composer config -g http-proxy http://proxy.example.com:8080；不用时及时清除：composer config -g --unset http-proxy
排查 Git 克隆失败引发的“重置”假象
Composer 安装某些包（如 dev 分支、未打包的 source）时会调用 git clone。如果 Git 自身连不上 GitHub，错误常被误读为“Composer 连接重置”：
- 确认
git --version可用；若无，CentOS 上跑sudo yum install -y git - 测试 Git HTTPS 访问：
git ls-remote https://github.com/composer/composer.git HEAD - 若失败，可能是 Git 代理没配：
git config --global http.proxy http://proxy.example.com:8080；或 DNS 解析异常，可临时改/etc/resolv.conf加nameserver 8.8.8.8 - 避免混用 SSH/HTTPS：如果项目用了
git@github.com:xxx地址，但没配 SSH key，Git 会 fallback 到 HTTPS，再因认证失败触发重置
真正难搞的是那种“偶尔成功、偶尔重置”的情况——它往往不是单一配置问题，而是网络路径中某段设备（比如出口防火墙）做了连接数限制或 TLS 检测。这时候最有效的动作不是反复试命令，而是先用 curl -v https://packagist.org 抓握手过程，看 reset 发生在 TCP SYN-ACK 后，还是 TLS Client Hello 之后。细节藏在那一行 * Recv failure: Connection reset by peer 前面。
