Composer报500错误90%非代码问题，而是网络层故障：需先检查Packagist源是否已下线（如phpcomposer.com自2022年起失效）、cURL SSL证书过期或代理/防火墙拦截，并用-vvv日志定位真实原因。
Composer install/update 报 HTTP 500 错误，90% 不是代码问题，而是网络通信层被拒绝或中断——必须先定位是源失效、证书校验失败，还是代理/防火墙拦截。
确认当前 Packagist 源是否已下线
国内用户常被旧镜像坑：比如 https://packagist.phpcomposer.com 自 2022 年起就返回 404/500，但 Composer 不会明确提示“源已废弃”，只报错。运行以下命令检查：
composer config -g repo.packagist
若输出包含已停用域名，立刻切换：
- 切回官方源（需境外网络）：
composer config -g repo.packagist composer https://packagist.org - 用推荐的稳定国内镜像：
composer config -g repo.packagist composer https://packagist.proxy.fly.dev - 清华源（注意末尾斜杠）：
composer config -g repo.packagist composer https://mirrors.tuna.tsinghua.edu.cn/composer/
别用带 .phpcomposer.com 的地址——它已不可用，不是配置问题，是服务端直接 500。
排查 cURL SSL 证书校验失败
PHP 的 cURL 扩展在 TLS 握手失败时，常把空响应误判为 500。典型现象：加 -vvv 后看到 cURL error 60: SSL certificate problem 或请求卡在 GET https://packagist.org/packages.json 不动。
验证 CA 证书状态：
php -r "print_r(openssl_get_cert_locations());"
检查 default_cert_file 对应路径是否存在、是否为空或修改时间早于 2022 年。常见修复方式：
- 临时验证（仅调试）：
composer config -g secure-http false，再试一次；若成功，就是证书问题 - 生产环境必须更新：下载最新 PEM 文件（如 curl.se 官方 CA 包），写入
php.ini的curl.cainfo和openssl.cafile - Docker 用户（如
php:8.2-cli-alpine）需确保安装了ca-certificates，且/etc/ssl/certs/ca-certificates.crt可读
检查自定义 repositories 配置是否引发重定向或认证失败
如果你在 composer.json 中声明了私有源（如 GitLab、GitHub Packages），500 往往来自这些源的响应异常，而非 Packagist 本身。
常见错误点：
- 用
git@SSH 地址但没配 SSH key，cURL 无法处理，直接失败 - HTTPS 地址漏写
.git后缀（如写成https://gitlab.example.com/group/repo），触发 302 重定向，而 Composer 默认不跟随重定向 - 私有源启用了 Basic Auth，但
auth.json里 token 过期或权限不足 - 源服务器本身返回 500（例如 GitLab 实例负载高、API 限流），Composer 会原样透传
快速验证：手动用 curl -I 请求该源的 packages.json 路径，看真实状态码和响应头。
忽略 verbose 日志就等于蒙眼排错
Composer 默认日志太简略，500 错误的真实原因藏在底层请求细节里。每次出问题，第一反应不是换源，而是加 -vvv：
composer update -vvv 2>&1 | grep -A5 -B5 "GET\|HTTP\|error"
重点关注三类输出：
- 最终发起的 URL（确认是不是访问了已下线地址）
- 实际收到的 HTTP 状态码（有时显示
000，说明连接根本没建立） - cURL 错误编号（如
CURLE_COULDNT_RESOLVE_HOST或CURLE_SSL_CONNECT_ERROR）
没有 -vvv 日志就动手改配置，大概率在无效操作上浪费半小时。
