curl -i 能通但 composer install 报 connection refused，说明代理未被 composer 实际使用，主因是 https 代理未单独配置、docker 内 127.0.0.1 指向错误、环境变量冲突或项目级 repositories 强制直连，需检查 https-proxy 配置、cafile 路径及容器网络视角。
curl -I 能通但 composer install 报 connection refused
说明代理本身是通的，但 Composer 没走你配的代理——它压根没用上。常见原因有三个：
• composer config -g http-proxy 配的是 http-proxy，但目标地址是 HTTPS（比如镜像源是 https://mirrors.aliyun.com/composer/），得额外配 https-proxy；
• 代理地址写成 http://127.0.0.1:8080，而你在 Docker 容器里跑 Composer，容器里的 127.0.0.1 指向自己，不是宿主机；
• 环境变量 HTTP_PROXY 和 HTTPS_PROXY 同时存在，且值不一致，Composer 会优先读环境变量，覆盖 config 配置。
composer config -g http-proxy 显示已配置，但 -vvv 日志里没出现代理地址
这说明配置被绕过了。重点查两点：
• 当前项目 composer.json 里有没有硬写 "repositories"？它会强制走直连，完全无视全局代理；
• 是否用了 COMPOSER_DISABLE_TLS=1 或 secure-http false？这类设置会让 Composer 改用 HTTP 协议拉元数据，而你的代理可能只监听 HTTPS 流量，或服务端直接拒绝非 TLS 请求；
• 运行 composer install -vvv 2>&1 | grep -E "(proxy|Proxy|HTTP_)"，看日志里是否真出现代理相关关键词。没出现，基本等于没生效。
公司网络下 HTTPS 代理导致 TLS 握手失败，curl 能过但 Composer 卡死
企业中间人代理（如 Zscaler、Netskope）会替换证书，Composer 默认校验严格，直接拒连。现象是 curl -I https://mirrors.aliyun.com/composer/ 成功，但 composer install 卡在 TLS handshake 或报 cURL error 60。
• 临时验证：加 COMPOSER_CAFILE=/dev/null 再试，能过就确认是证书问题；
• 正确做法：导出企业根证书（如 company-ca.crt），然后执行 composer config -g cafile /path/to/company-ca.crt；
• 注意：cafile 路径必须是绝对路径，且文件权限不能是 777（OpenSSL 会拒绝加载）。
Docker 容器里 proxy 配置始终连不上宿主机代理服务
根本问题是网络视角错位。容器内 127.0.0.1 不等于宿主机，得换真实地址：
• Linux/macOS 下，宿主机在 Docker 网络中的 IP 通常是 host.docker.internal（Docker Desktop 默认支持）或 172.17.0.1（Linux docker0 网桥地址）；
• 代理服务必须绑定到 0.0.0.0:端口，不能只绑 127.0.0.1，否则容器请求会被拒绝；
• 在 docker-compose.yml 的服务 environment 下显式传入：HTTP_PROXY: http://host.docker.internal:7890，别依赖全局 config。
