应手动执行curl -i测试镜像源根路径（如https://mirrors.aliyun.com/composer/），返回http/2 200或http/1.1 200 ok才表示镜像http层可达；少斜杠、测packagist.org或忽略curl_options="--no-keepalive"均会导致误判。
curl -I 测试镜像源根路径是否返回 200
Composer 不报具体 HTTP 状态码，只笼统提示连接失败。必须手动验证镜像源本身是否可达——重点不是 packagist.org，而是你配置的镜像地址。
常见错误是测错 URL：比如用 curl -I https://mirrors.aliyun.com/composer（少末尾斜杠），结果返回 404；正确写法必须带 /：
curl -I https://mirrors.aliyun.com/composer/
只要返回 HTTP/2 200 或 HTTP/1.1 200 OK，说明镜像源 HTTP 层通；若卡住、返回 403/502/503，问题在镜像服务端或中间拦截。
- 别测
https://packagist.org：国内直连基本不可用，测了也白测 - Windows 用户可用
curl.exe，但需确保 PATH 中有 Git for Windows 或 cURL 安装目录 - macOS/Linux 用户注意系统 curl 可能走代理，而 Composer 不认系统代理，所以这个测试只是初步筛查
composer config -g --list 验证代理字段是否完整生效
很多人只配了 http-proxy，漏掉 https-proxy，导致所有 HTTPS 请求静默 fallback 到直连——现象是没报错，但卡在 Loading composer repositories。
运行以下命令确认两个字段都存在且格式正确：
composer config -g --list | grep -E "(http|https)-proxy"
输出应类似：
http-proxy http://127.0.0.1:8080 https-proxy http://127.0.0.1:8080
-
https-proxy的值必须是http://协议开头，哪怕代理本身监听 TLS 端口，这是 Composer 硬性要求 - 漏掉
-g参数会导致只写入当前项目，换目录就失效 - 填成
https://127.0.0.1:8080或无协议头（如127.0.0.1:8080）会静默失败，无任何提示
nc -zv 或 telnet 测试 TCP 层是否被阻断
curl 成功 ≠ Composer 能通。curl 可能走系统代理，而 Composer 只认自己配置的 https-proxy，且对 TLS 更敏感。要定位是 TCP 还是 TLS 层问题，得绕过应用层直接测端口：
- Linux/macOS：
nc -zv mirrors.aliyun.com 443，返回succeeded表示 TCP 层通 - Windows：
telnet mirrors.aliyun.com 443，黑窗不闪退、光标闪烁即为通（若未启用 telnet，先用OptionalFeatures.exe启用） - 若不通，说明本地防火墙、企业策略或 DNS 污染已拦截 443 端口，此时配代理也没用
如果 nc 通但 curl -v https://mirrors.aliyun.com/composer/ 卡在 TLS handshake，问题大概率出在证书链或 OpenSSL 配置，不是网络连通性问题。
CURL_OPTIONS="--no-keepalive" 强制新建连接防 RST
Connection reset by peer 的主因不是网络断了，而是 cURL 复用了已被 NAT 或防火墙 RST 的空闲连接——它没探测，复用时直接撞上重置。
加这个环境变量可禁用 keep-alive，每次请求都建新 TCP 连接，实测大幅降低失败率：
- Linux/macOS：
CURL_OPTIONS="--no-keepalive" composer install - Windows cmd：
set CURL_OPTIONS=--no-keepalive && composer install - PowerShell：
$env:CURL_OPTIONS="--no-keepalive"; composer install
这个参数不解决 DNS、代理缺失或证书错误，只针对“连接被中间设备悄悄断开”这一类高干扰网络场景。很多用户调了半天代理和镜像，最后加这一行就通了——但它容易被忽略，因为错误日志里根本不会提它。
