composer根本不支持https双向认证（mtls），所谓“双向认证配置”是概念误用；它仅进行服务端证书单向验证，不发送客户端证书，也不读取cert/key等配置，镜像源本身也不要求mtls。
Composer根本不支持HTTPS双向认证（mTLS），所谓“双向认证配置”是概念误用，强行启用只会让请求失败。
为什么 composer config -g repo.packagist 不能启用双向认证
Composer只做服务端证书的单向验证：检查CA签名、域名匹配、有效期。它不发送客户端证书，也不读取任何 client-cert、tls-key 或 ca-bundle 类配置项。镜像源（如阿里云、腾讯云）本身也不要求客户端证书——它们是公开缓存代理，不是私有mTLS网关。
常见错误操作包括：
- 在 Nginx 反向代理层开启
ssl_verify_client on，结果 Composer 直接报cURL error 35或连接被重置 - 试图通过
composer config -g设置cert/key字段，但这些字段被完全忽略 - 把企业内网的 mTLS 网关策略套用到 Composer 上，导致所有 HTTPS 请求静默失败
真正起作用的是 signature 字段校验，不是 TLS 双向性
Composer 2.2+ 的安全核心是 packagist.org 响应头中携带的 signature 字段，它由官方私钥签名，用于校验 packages.json 和 provider 文件的完整性。这个字段只存在于 HTTPS 响应中，且国内镜像必须同步它才有效。
要确保校验生效，必须同时满足：
-
secure-http为true（默认，不可禁用） - 镜像 URL 以
https://开头且末尾带/（如https://mirrors.aliyun.com/composer/） - 全局启用签名验证：
composer config -g security.signature true - 运行
composer diagnose后输出中同时出现secure-http: OK和signature verification: OK
代理配置必须成对设置 http-proxy 和 https-proxy
Composer 不读取 HTTP_PROXY 或 HTTPS_PROXY 环境变量，必须显式配置两个字段，否则 HTTPS 请求（如访问 https://packagist.org）会 fallback 到直连，表现为卡在 Loading composer repositories 或 cURL error 35。
正确写法（注意协议必须是 http://，即使代理监听 HTTPS 端口）：
composer config -g http-proxy http://127.0.0.1:8080 composer config -g https-proxy http://127.0.0.1:8080
验证是否生效：
composer config -g --list | grep -E "(http|https)-proxy"
如果只看到一行，或 https-proxy 值是 https://...、无协议头、含未编码的特殊字符（如 @、/），就一定会失败。
内网环境该怎么做：镜像 > 代理 > 私有仓库
在腾讯云 VPC、公司内网等受限环境，优先级应该是：
- 换国内镜像源（如
https://mirrors.cloud.tencent.com/composer/），这是最简单可靠的方案 - 仅当镜像不可用时，才配代理，且必须确认代理支持 CONNECT 隧道（Clash、Squid 4.0+）
- 若完全断网，则需搭建 Satis 或接入 Nexus/Artifactory，而非折腾 TLS 层
最容易被忽略的一点：镜像源是否同步了 signature 字段。旧版 Laravel China 镜像就不同步，导致 composer install 自动降级为无校验模式——此时即便 HTTPS 正常，安全机制也已失效。
