Composer 报“Unable to use HTTPS, fallback disabled”是因TLS连接失败且disable-tls=false（默认），拒绝降级HTTP；常见于CA证书缺失、代理劫持或OpenSSL异常，应修复TLS环境而非关闭安全机制。
composer install 时提示 “Unable to use HTTPS, fallback disabled” 是什么情况
这是 Composer 在无法建立 TLS 连接（比如系统缺少 CA 证书、代理拦截、或 OpenSSL 配置异常）时，又发现 disable-tls 被设为 false（即强制走 HTTPS），就会直接报错退出——它不尝试降级到 HTTP，而是“宁可失败也不妥协”。
注意：disable-tls 的默认值就是 false，你几乎不需要、也不应该手动设它为 false；真正需要调整的是修复 TLS 环境，而不是关安全开关。
- 这个错误常见于：Docker 容器里没装
ca-certificates、Windows 上 WSL2 的 OpenSSL 版本太旧、公司内网代理劫持了证书 -
disable-tls = false不是“启用 TLS”，而是“禁止降级到 HTTP”；它的反面disable-tls = true才是关闭 HTTPS 强制要求（但极度不推荐） - 强行设
disable-tls = true后，所有包下载都走 HTTP，中间人可篡改 zip 包，等同于放弃校验
怎么查当前的 disable-tls 设置是否被意外修改过
Composer 会按顺序读取多个配置源，优先级从高到低：命令行参数 → 当前项目 composer.json → 用户全局配置 auth.json → 系统级 config.json。问题往往出在某一层被误写。
- 运行
composer config --list --global查看全局配置，重点找disable-tls行 - 检查
~/.composer/config.json（Linux/macOS）或%APPDATA%\Composer\config.json（Windows）里有没有手写的"disable-tls": true - 项目级配置可能藏在
composer.json的config段里，搜"disable-tls"字符串 - 如果没找到，那大概率是默认行为，问题在 TLS 底层，不是配置本身
修复 TLS 失败比关 disable-tls 更靠谱的三件事
与其绕过 HTTPS，不如让 HTTPS 正常工作。90% 的场景靠这三项就能解决：
- 更新 CA 证书：Ubuntu/Debian 运行
sudo apt update && sudo apt install -y ca-certificates；macOS 用brew install ca-certificates；Windows 建议重装 OpenSSL 或用 Git for Windows 自带的证书包 - 检查环境变量：确认没设置
HTTP_PROXY或HTTPS_PROXY指向一个不支持 TLS 透传的代理（比如某些老旧 squid）；临时取消代理试试：unset HTTP_PROXY HTTPS_PROXY - 升级 Composer 自身：
composer self-update—— 新版内置更健壮的证书加载逻辑，老版本（
真要临时禁用 TLS（仅限离线调试）该怎么安全操作
仅当确认网络完全可信（如本地虚拟机、无外网的 CI 环境），且已排除所有 TLS 配置问题后，才考虑临时关闭。必须限制作用域，不能污染全局。
- 只对单次命令生效：
composer install --no-plugins --disable-tls（注意是命令行参数--disable-tls，不是配置项） - 若必须写配置，仅限当前项目：
composer config disable-tls true，它会写入项目根目录composer.json的config字段，不会影响其他项目 - 绝对不要执行
composer config --global disable-tls true—— 这会让所有后续项目裸奔 - 执行完立刻还原：
composer config --unset disable-tls（项目级）或删掉config.json里对应字段
最常被忽略的一点：即使你设了 disable-tls = true，Composer 仍会校验包的 sha256 签名（如果仓库提供），但前提是 zip 包本身没被中间人替换——而 HTTP 下这个前提就没了。
