必须同时配置http-proxy和https-proxy，且https-proxy值必须以http://开头；只配http-proxy会导致HTTPS请求静默直连，卡在“Loading composer repositories”。
为什么只配 http-proxy 容器里照样卡住
容器内跑 composer install 卡在 Loading composer repositories，八成不是网络不通，而是 HTTPS 请求根本没走代理。Composer 对 HTTP 和 HTTPS 用两套路由：只设 http-proxy，所有仓库（https://packagist.org、GitHub 等）都会 fallback 直连——而直连海外节点在容器里常被 DNS 或 TLS 握手拖死，且无明确报错。
必须同时配置：
- http-proxy（哪怕只是占位）
- https-proxy（值必须是 http:// 开头，哪怕代理监听的是 HTTPS 端口）
漏掉任一字段，或 https-proxy 写成 https://127.0.0.1:8443、127.0.0.1:8080，都会静默失效。
验证容器内代理是否真正生效
别信配置命令执行成功，要进容器看实际生效值：
composer config -g --list | grep -E "(http|https)-proxy" 必须输出两行，且 URL 格式合规（协议头 http://、地址可解析、端口可连）。
常见假成功场景：
- 配置写进了项目级 composer.json（没加 -g），换基础镜像就丢
- 容器启动时覆盖了环境变量，但 config 命令读的是磁盘文件，和运行时无关
- https-proxy 的值含未编码的 @ 或 /，如 http://u:p@w@rd@127.0.0.1:8080 → 实际只解析到 u:p 就截断
容器里绕过代理快速定位是不是代理问题
临时禁用代理比反复改配置更快：
进容器后执行：HTTP_PROXY= HTTPS_PROXY= composer install
如果这时能通，说明问题 100% 出在代理链路；如果仍失败，就该查 DNS（nslookup packagist.org）、TLS（openssl s_client -connect packagist.org:443 -servername packagist.org）或镜像源配置。
注意：
- 不要只清 composer clear-cache，容器每次重建都是干净环境，缓存本来就不跨次
- 如果用的是腾讯云/阿里云镜像，确认 composer config -g repo.packagist 输出的是对应域名，而不是空或默认 https://packagist.org
NTLM 代理在容器里怎么破
公司内网用 Windows 域认证？407 Proxy Authentication Required 不是 Composer 配错了，是它压根不支持 NTLM。容器里更麻烦：你没法直接装 cntlm 或 px，得把中转代理跑在宿主机或独立 sidecar 容器里。
可行路径：
- 宿主机起 cntlm 监听 0.0.0.0:3128，容器通过 --add-host=host.docker.internal:host-gateway 让 host.docker.internal 解析到宿主机
- https-proxy 改成 http://host.docker.internal:3128
- 用 curl -x http://host.docker.internal:3128 -I https://packagist.org/packages.json 先验证中转层通不通
跳过中转直接配 NTLM？没用。http-basic 是给私有仓库鉴权的，对出站代理无效；auth.json 也完全不参与代理协商。
