Composer代理配置突破网络封锁实录-composer-PHP中文网

只配http-proxy仍卡在“loading composer repositories”是因为packagist全量走https，而http-proxy仅处理http请求；https必须依赖https-proxy字段（值须为http://协议）建立connect隧道，缺一则fallback直连导致拦截或超时。

composer代理配置突破网络封锁实录

为什么只配 `http-proxy` 依然卡在 “Loading composer repositories”

因为 Packagist 全量走 HTTPS，而 http-proxy 只处理 HTTP 请求；HTTPS 必须靠 https-proxy 建立 CONNECT 隧道。漏掉后者，Composer 就会 fallback 直连，触发防火墙拦截或静默超时。

实操要点：

https-proxy 的值必须以 http:// 开头（哪怕代理监听的是 TLS 端口），填 https:// 或漏协议头会导致完全失效
必须同时设置 http-proxy 和 https-proxy，缺一不可；命令要加 -g 写入全局配置
用户名或密码含 @、/、: 时，必须 URL 编码，例如 pa@ss/word → pa%40ss%2Fword
验证是否生效：运行 composer config -g --list | grep -E "(http|https)-proxy"，两行都得存在且格式正确

镜像和代理能不能一起用？

不能。二者作用层面不同：镜像改的是元数据源地址（repo.packagist），代理改的是流量转发路径（http-proxy/https-proxy）。混配后 Composer 优先走镜像直连，代理字段被忽略，反而导致 TLS 握手失败、静默卡死或 cURL error 28。

常见错误现象：

配了阿里云镜像又设了代理，日志里仍出现 Loading composer repositories 卡住，但无报错
镜像 URL 少了结尾 / 或漏了 type=composer，Composer 自动 fallback 到 packagist.org，触发企业审查
没关 "packagist.org": false，即使镜像成功，失败后仍重试官方源，被防火墙精准识别并阻断

真要用代理，第一步永远是清空镜像：composer config -g --unset repo.packagist。

代理连上了但 TLS 握手失败怎么办

典型表现是 SSL certificate problem、file_get_contents(): SSL operation failed，或 curl 测试返回 certificate verify failed——这不是网络不通，而是公司中间人代理篡改了证书，本地 OpenSSL 不信任其根 CA。

Discussion Composer

围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par

下载

修复方式：

导出公司浏览器里的“本地 CA”证书，保存为 PEM 格式（无 BOM、纯文本）
执行 composer config -g cafile /path/to/company-ca.crt（Windows 路径用双反斜杠，如 C:\certs\company-ca.crt）
别用 secure-http false 或 cafile /dev/null，这是主动关闭校验，供应链风险极高
Windows + WSL2 用户常因系统时间不同步导致握手失败，运行 sudo hwclock -s 同步主机时间

临时验证是否真走代理：加 -n -vvv 运行 composer install，日志里出现 Proxy CONNECT 才算成功。

NTLM 代理或 SOCKS5 怎么办

Composer 原生不支持 NTLM 认证，设了 http-proxy 也会直接返回 407 Proxy Authentication Required。SOCKS5 则要求 Composer ≥ 2.2，旧版不识别 socks5:// 协议。

解决方案：

NTLM 场景必须引入中转代理工具，如 cntlm 或 px，让它们监听 127.0.0.1:3128 并处理认证，再让 Composer 连这个本地地址
SOCKS5 用户先确认版本：composer --version，再配 composer config -g https-proxy socks5://127.0.0.1:7891
验证中转层是否正常：用 curl -x http://127.0.0.1:3128 -I https://packagist.org/packages.json 测试，若也报 407，说明中转没配好

最易被忽略的一点：所有代理配置都依赖 https-proxy 字段的协议头和格式，哪怕代理本身是 HTTPS 服务，这里也必须写 http:// ——这是 Composer 的硬性约定，不是 bug。