composer config -g --list 仅显示手动设置的全局配置项，不显示默认值或未设置项；例如有 http-proxy 而无 https-proxy，说明后者未配置，这是代理失效的最常见原因。

composer config -g --list 能看到什么

这条命令输出全局配置，但只显示你手动写入的字段。如果看到 http-proxy 却没看到 https-proxy，说明 HTTPS 代理根本没设——这是最常见失效原因。输出里若出现 HTTP proxy: [none] 或 HTTPS proxy: [none]，代表对应字段为空或未加载。

为什么 composer diagnose 不够用

composer diagnose 只校验配置语法和本地状态，不发真实 HTTPS 请求。它可能显示 OK，但实际 composer install 仍卡在 Loading composer repositories。真正验证代理是否“通”，得触发 Packagist 的元数据请求：

Academic Composer Upload

辅助学术写作，包括查找资料、生成大纲、引用扩写及润色风格，同时确保引用规范。

下载

• composer global status：返回 OK 表示 HTTPS 代理可转发
• composer show --platform：直接 GET https://packagist.org/packages.json，超时或 Connection refused 就说明代理服务没运行或端口不通

curl -x 是唯一能快速定位问题的命令

绕过 Composer 层，用底层 cURL 模拟等效请求，结果最可信：

• 执行 curl -x "http://user:pass@127.0.0.1:7890" -I https://packagist.org/packages.json
• 返回 HTTP/1.1 200 OK → 隧道通
• 返回 407 Proxy Authentication Required → 密码错或 NTLM 未中转
• 返回 502 Bad Gateway → 代理自身异常（如 Clash 规则没放行 packagist.org）
• 超时或 TLS 报错 → 代理协议不支持 CONNECT 或证书被拦

环境变量和配置文件谁优先级高

Linux/macOS 下 HTTP_PROXY 和 HTTPS_PROXY 环境变量优先级高于 config.json，但大小写敏感；Windows 不区分大小写。容易踩的坑：

• 终端里设了 export HTTPS_PROXY=http://...，但值用了 https:// 开头 → 静默失效
• 代理地址末尾带斜杠，如 http://127.0.0.1:7890/ → 解析失败
• 密码含 @ 或 / 没 URL 编码 → 认证失败且无明确提示

代理配置本身不难，难的是它和 PHP 的 OpenSSL、cURL 扩展、系统 DNS、中间人证书、镜像源开关全部耦合在一起。调不通时，别只盯着 config -g 输出，先用 curl -x 看隧道通不通，再看 php -m 有没有 openssl 和 curl。