composer diagnose 不够用，因它仅检测 packagist.org 的 TLS 握手与证书，不扫描 composer.json 中配置的私有 HTTPS 仓库（如 Artifactory、Nexus），故诊断通过仍可能在 install 时因证书信任、SNI 或认证问题失败。
直接用 composer diagnose 就能测，但它只测 packagist.org，不测你配的私有 HTTPS 仓库；真要验证，得手动触发请求或用 curl -Iv 看 TLS 握手细节。
为什么 composer diagnose 不够用
它默认只对 packagist.org 发起真实 HTTPS 请求，检查 TLS 握手、证书有效性及系统信任链。你 composer.json 里写的其他 HTTPS 仓库（比如 Artifactory、Nexus、自建 Satis）完全不会被扫描到。常见现象是：diagnose 显示 OK，但 composer install 一碰到私有源就卡在 Loading composer repositories 或报 SSL certificate problem。
-
diagnose不遍历repositories列表，只认默认源 - 企业自签名 CA、中间人代理、SNI 配置异常等，都会让私有 HTTPS 源失败，但
diagnose不报 - 某些 Artifactory 启用
Enable Token Authentication后，旧版 Composer 客户端会在 SSL 层提前断连，diagnose也无感知
怎么手动验证私有 HTTPS 仓库
最可靠的方式是模拟 Composer 的实际请求行为，用 curl -Iv 直接打仓库的元数据接口：
- 目标 URL 通常是
https://your-repo.com/artifactory/api/composer/packagist.org/packages.json（Artifactory）或https://nexus.example.com/repository/composer/packages.json（Nexus） - 执行
curl -Iv https://your-repo.com/.../packages.json，重点看三处：* SSL connection using TLS_...（是否完成握手）、* Server certificate:（CN 是否匹配域名）、HTTP/2 200（状态码） - 若返回
SSL_ERROR_SYSCALL或unable to get local issuer certificate，说明证书未被系统信任，需补cafile或更新系统 CA - 若返回
401 Unauthorized或403 Forbidden，可能是认证头缺失或 Token 过期，不是 SSL 问题
怎么让 composer install 暴露真实 HTTPS 错误
加 -vvv 并指定单个仓库测试，避免被缓存或镜像干扰：
- 临时新建目录，写最小
composer.json，只保留你要测的 HTTPS 仓库和一个轻量依赖（如"php": "^8.0"） - 运行
COMPOSER_HOME=/tmp/test-composer composer install --no-plugins --no-scripts --dry-run -vvv 2>&1 - 日志中搜
Could not fetch或SSL certificate problem—— 这比diagnose更贴近真实场景 - 注意：如果用了
github-oauth，SSL 失败可能被掩盖成Could not fetch，此时必须先排除网络层问题
容易忽略的证书细节
很多问题不是“连不上”，而是证书校验逻辑被绕过或误配：
-
cafile路径必须绝对，且文件需含完整证书链（根 + 中间），不能只放终端证书 - 公司自建 CA 若未注入系统信任库（如
/etc/ssl/certs/ca-certificates.crt），仅设cafile也不够，openssl s_client -connect会失败 -
secure-http设为false或COMPOSER_DISABLE_TLS=1会跳过所有校验，导致composer audit静默失效，漏检漏洞 - 某些 HTTPS 代理（如 Squid）会重写证书 Subject CN，造成域名不匹配 —— 这类问题
curl -Iv一眼可见，但diagnose完全不提示
真正卡住的往往不是“能不能通”，而是“通了但证书不被信”或“通了但域名和证书不匹配”。别急着关 TLS，先用 curl -Iv 把握手过程拉出来看清楚。
