Composer不读取HTTP_PROXY环境变量（v2.2+才默认支持，旧版完全忽略），必须显式配置http-proxy和https-proxy字段，否则请求直连导致超时或卡在TLS握手。
为什么设了 HTTP_PROXY 还超时
Composer 不直接读取 HTTP_PROXY 或 HTTPS_PROXY 环境变量（v2.2+ 才默认支持，旧版完全忽略），所以即使你 export 了代理，它仍可能走直连并卡在 TLS 握手或 DNS 阶段。更麻烦的是：某些杀毒软件、Fiddler/Charles 会静默劫持 HTTPS 流量，导致 Composer 实际发出的请求被中间人拦截，但错误不报 SSL 问题，只显示 cURL error 28 或直接卡死。
确认代理是否真正生效
先验证当前全局代理配置是否写进 Composer 配置：
Discussion Composer
下载
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- 运行
composer config -g http.proxy—— 如果输出为空，说明没生效； - 正确设置方式是：
composer config -g http.proxy http://127.0.0.1:8888（HTTP 代理）或composer config -g http.proxy https://127.0.0.1:8888（HTTPS 代理，注意协议）； - 若代理需认证，格式为：
http://user:pass@127.0.0.1:8888； - 检查是否被项目级
composer.json中的config.http-proxy覆盖（优先级更高）。
代理环境下必配的证书与连接参数
公司代理或抓包工具（如 Fiddler）通常用自签名 CA 签发证书，Composer 默认不信任，会卡在 TLS 阶段而非超时本身：
- 下载代理根证书（如
fiddler-root.cer），转成 PEM 格式后，执行：composer config -g cafile /path/to/fiddler-root.pem； - 同步调高底层连接容忍度：
composer config -g http.connect_timeout 60和composer config -g http.timeout 600； - 禁用不必要的协议降级：
composer config -g github-protocols ["https"]，避免 Git SSH 触发代理不兼容问题； - 临时排除干扰：加
-n参数跳过所有插件，再试composer install -n -vvv，看日志里是否出现Proxy CONNECT字样。
CI/CD 或 Docker 中代理失效的典型场景
容器环境常因网络命名空间隔离、DNS 策略或证书路径不可达，导致代理配置“写了等于没写”：
- GitHub Actions 中，
HTTP_PROXY环境变量对 Composer 无效，必须显式composer config -g http.proxy； - Docker 构建时，
cafile路径需映射进容器，且确保该路径在容器内可读（比如挂载到/etc/ssl/certs/custom.pem）； - GitLab CI 若用 shared runner，代理可能被系统级策略屏蔽，建议改用 private runner 并预装证书；
- Windows 上 WSL2 容器若时间不同步，TLS 握手会失败——运行
sudo hwclock -s同步主机时间。
http.timeout 才报错。调参前，先用 curl -x http://127.0.0.1:8888 -v https://mirrors.aliyun.com/composer/packages.json 直测代理通路，比盲调更省时间。 
