必须用curl -I测试镜像根路径状态码，因Composer不输出HTTP状态码；重点验证是否返回HTTP/2 200、Content-Type为application/json、无Location重定向；若为403/502/301则后续必败。
curl -I 直接看镜像根路径状态码
Composer 不会把 HTTP 状态码打出来，报错里写“Connection reset”或“file could not be downloaded”，你根本不知道它实际收到了 403、502 还是 301。必须跳过 Composer，用 curl -I 测真实响应：
curl -I https://mirrors.aliyun.com/composer/重点看三件事：返回是否
HTTP/2 200、Content-Type 是否为 application/json、有没有 Location 重定向头。如果返回 HTTP/1.1 301 或 403 Forbidden，那 Composer 后续所有请求都注定失败——它不会告诉你，只会卡在 Loading composer repositories。
--repository 覆盖源地址，绕过全局配置污染
改了 composer config -g repo.packagist 却还是失败？大概率是旧配置残留或权限污染。临时调试别碰全局，直接用 --repository 强制指定源：
composer install -vvv --repository=https://mirrors.huaweicloud.com/repository/php/这个参数只对当次命令生效，
-vvv 会打出完整请求链路（DNS、TLS、HTTP 状态码），一眼定位卡在哪一层。注意 URL 必须带完整路径后缀，https://mirrors.huaweicloud.com 少了 /repository/php/ 就会拼出 /composerpackages.json 导致 404。
CURL_OPTIONS="--no-keepalive" 破解 NAT/防火墙 RST 干扰
在企业网、CI 或某些云主机上反复出现 “Connection reset by peer”，不是镜像挂了，而是 cURL 复用连接时被中间设备发 RST 包击穿。Composer 底层全靠 cURL，但它默认启用 Connection: keep-alive 却不探测连接存活。解决方案是禁用复用：
CURL_OPTIONS="--no-keepalive" composer installLinux/macOS 直接运行；Windows PowerShell 写：
$env:CURL_OPTIONS="--no-keepalive"; composer install这会让每次请求新建 TCP 连接，握手开销略增，但在高干扰环境下失败率可从 80% 降到接近 0%。
删 repo/ 缓存目录，别信 composer clear-cache
composer clear-cache 只清 files/ 下的 ZIP 包，对已缓存的非法 packages.json 或 p2/*.json 完全无效——它们存在 ~/.composer/cache/repo/ 下，且默认 15 分钟不刷新。一旦镜像返回过 HTML 或空 JSON，这个损坏快照就会一直被读。真正有效的清理是：
rm -rf $(composer config --global cache-dir)/repo/https---mirrors.aliyun.com-composer或者更干脆：
rm -rf $(composer config --global cache-dir)/repo/然后再跑命令。别等镜像修复，先让本地元数据回归干净起点。 很多问题卡在“以为自己在调 Composer，其实是在调一个坏掉的 JSON 响应”。状态码、缓存路径、连接复用——这三个点不手动验证，光 retry 或换 PHP 版本，基本白忙。
