镜像配了却走https重定向失败，根本原因是用了http://开头的url，composer强制https导致服务器301跳转后在老旧环境（如alpine、wamp、企业代理）卡住；必须用https://且末尾带/，并验证-vvv日志中实际请求域名与协议是否匹配。
为什么镜像源配了却还走 HTTPS 重定向失败
根本不是镜像地址写错了，而是你用了 http:// 协议开头的镜像 URL。Composer 默认强制走 HTTPS，当它向 http://mirrors.aliyun.com/composer/ 发起请求时，服务器返回 301/302 跳转到 HTTPS 地址——但某些环境（如老旧 Docker 镜像、Windows WAMP、企业透明代理）会卡在重定向环节，最终报 Failed to download 或 cURL error 22: The requested URL returned error: 301。
- 必须用
https://开头，且末尾带/：例如https://mirrors.tuna.tsinghua.edu.cn/composer/✅，https://mirrors.tuna.tsinghua.edu.cn/composer❌（少斜杠会导致路径拼接错误） - 阿里云镜像已明确要求 HTTPS，
http://mirrors.aliyun.com/composer/自 2025 年底起不再响应非加密请求 - 腾讯云和清华源虽仍接受 HTTP 请求，但会立即 301 跳转；一旦本地 curl 不支持自动跟随重定向（如 Alpine Linux 的 busybox wget），就会中断
如何验证镜像是否真在走 HTTPS 直连
别信 composer config -g repo.packagist 的输出，要看实际发出的请求域名和协议。最可靠的方式是加 -vvv 跟踪：
- 运行
composer require monolog/monolog -vvv，第一行日志里出现的Downloading https://...域名必须是你配的镜像地址，且协议是https - 如果看到
Downloading https://packagist.org/...或Downloading http://...，说明配置未生效或被项目级repositories覆盖 - 手动测试镜像可用性：
curl -I https://mirrors.cloud.tencent.com/composer/packages.json，应秒回HTTP/2 200；若返回301或超时，问题出在网络层，不是 Composer 配置
镜像源配置写法必须严格匹配 Composer 2.2+ 规范
旧写法 repo.packagist 在部分新版环境中已不兼容，且容易因字段缺失被忽略。真正生效的配置必须满足三个硬条件：
- 键名必须是
repositories.packagist.org（不是repos.packagist，也不是repo.packagist） - 值必须是 JSON 对象，显式声明
"type": "composer"，不能只写字符串 URL - 命令要带
-g且用单引号包裹 JSON：composer config -g repositories.packagist.org '{"type": "composer", "url": "https://mirrors.tuna.tsinghua.edu.cn/composer/"}'
企业网络下 HTTPS 重定向失败的绕过方式
有些公司防火墙或代理会拦截并改写 HTTPS 重定向响应，导致 Composer 收到畸形 header。此时不能靠换源解决，得调整底层行为：
- 临时禁用 TLS 验证仅用于排障：
composer config -g disable-tls true（生产环境严禁保留） - 强制指定 CA 证书路径（尤其 macOS/Homebrew PHP 或 Alpine）：
composer config -g cafile /etc/ssl/certs/ca-certificates.crt - 若使用代理，必须同时设
HTTPS_PROXY环境变量，HTTP_PROXY对 HTTPS 请求无效 - CI/CD 中建议加
--prefer-dist，避免触发 GitHub API（其域名不受镜像控制，也常因重定向失败）
重定向失败的本质是协议协商断在中间层，不是 Composer 本身的问题。配置对了，还要确认 curl、PHP OpenSSL、系统 CA、代理策略四者协同正常——漏掉任何一环，https:// 开头的镜像也会静默退回到 packagist.org。
