答案：需用curl -i验证镜像根路径是否返回http/2 200，末尾必须带斜杠；若卡住、超时或返回403/502/404，则源失效，非网络问题。
curl -I 验证镜像源是否真通
Composer 报 Connection reset by peer，90% 不是网络断了，而是你配的镜像源本身已失效或返回了 403/502。它不输出 HTTP 状态码，必须手动验证。
执行：curl -I https://mirrors.aliyun.com/composer/（注意末尾斜杠）——只有返回 HTTP/2 200 才算真正可用；卡住、超时、403 或 404 都说明该源不可靠。
- 别测
https://packagist.org：国内直连基本不通，测了也白测 - 已停服源如
https://packagist.phpcomposer.com必须从配置里删掉 - URL 少斜杠会拼出错误路径，比如
https://mirrors.aliyun.com/composer→ 请求/composerpackages.json→ 404
CURL_OPTIONS="--no-keepalive" 强制新建连接
cURL 默认复用 TCP 连接，但企业防火墙、校园网 NAT 会在空闲几十秒后发 RST 清理连接，cURL 不探测，复用时直接撞上重置。这不是 Composer 的 bug，是底层连接管理问题。
Linux/macOS 下运行：CURL_OPTIONS="--no-keepalive" composer install
Windows PowerShell：$env:CURL_OPTIONS="--no-keepalive"; composer install
- 该参数禁用
Connection: keep-alive，每次请求都建新连接 - 实测在高干扰网络下失败率可从 80% 降至 0%
- 代价是略增 TLS 握手开销，但在城域网/CI 场景下稳比快重要
--repository 临时覆盖源，绕过所有配置污染
全局改 composer config -g repo.packagist 风险极高：一旦源失效，所有项目（含 CI）批量失败。调试阶段应强制指定源，不碰任何配置文件。
命令示例：composer install -vvv --repository=https://mirrors.huaweicloud.com/repository/php/
-
-vvv输出完整链路：DNS、TLS 握手、HTTP 状态码，一眼定位卡在哪步 - URL 必须带完整路径后缀，
https://mirrors.huaweicloud.com会 404，正确是https://mirrors.huaweicloud.com/repository/php/ -
--repository只对当次命令生效，不影响composer.json或全局 config
清缓存 + 检查 curl.cainfo 是否真实生效
缓存损坏或 SSL 证书路径错配，会导致 Composer 反复重试同一失败路径，看起来像“一直重置”。尤其在企业内网或自建 CA 环境下，curl.cainfo 错位是静默故障主因。
执行：composer clear-cache，再确认 PHP 加载的 php.ini 路径：php --ini，打开对应文件检查 curl.cainfo 指向的 PEM 文件是否存在且可读。
- 若用自建 CA，确保该 PEM 包含全部中间证书，顺序不能错
- Docker 容器中常漏挂证书卷，或 Alpine 镜像未装 ca-certificates
- WSL2 中若项目放在
/mnt/c/，curl.cainfo路径需用 Windows 风格且避开 metadata=false 限制
CURL_OPTIONS 没用 → 又去翻代理设置 → 最后才发现是源本身拼错了。先验证源是否真通，是最省时间的起点。
