详解Composer环境变量中的安全代理设置-composer-PHP中文网

composer 不读 http_proxy 环境变量，仅认 config 中的 http-proxy 和 https-proxy 字段；必须用 composer config -g 命令配置，且 https-proxy 也须以 http:// 开头；配错将导致 tls 握手失败或静默超时；推荐优先使用阿里云镜像源替代代理。

详解composer环境变量中的安全代理设置

Composer 不读 HTTP_PROXY 环境变量，别白设

Composer 明确忽略 HTTP_PROXY 和 HTTPS_PROXY 环境变量，无论你在 shell 里 export 还是 Windows 里 set，它都当没看见。这不是 bug，是设计如此——它只认自己配置文件里的 http-proxy 和 https-proxy 字段。

常见错误现象：composer install 卡在 Loading composer repositories，无报错、无超时提示，curl 测试代理却能通。原因就是只配了环境变量，没走 Composer 的代理字段。

必须用 composer config -g http-proxy http://127.0.0.1:8080 和 composer config -g https-proxy http://127.0.0.1:8080 两条命令同时设置
https-proxy 的值必须是 http:// 开头，哪怕代理监听的是 HTTPS 端口——这是 Composer 的硬性协议约定
漏掉 https-proxy，所有 HTTPS 请求（包括访问 packagist.org、GitHub Releases）都会 fallback 到直连，极易触发 TLS 握手失败或静默超时

https-proxy 填错会导致 TLS 握手失败，不是证书问题

填成 https://127.0.0.1:8080 或漏写协议头（如 127.0.0.1:8080），Composer 会静默忽略该配置，转而尝试直连。此时你看到的错误往往是 cURL error 35、SSL routines:ssl3_read_bytes:sslv3 alert handshake failure，或者 Failed to enable crypto——这些都不是证书过期或域名不匹配，而是代理未介入、TLS 流量被系统级代理劫持后降级或 SNI 丢失所致。

真实场景中，Clash/Proxifier 等工具若未开启 HTTPS CONNECT 隧道支持，或企业 NTLM 代理未经 cntlm 中转，都会让 Composer 的直连请求卡在 TLS 握手阶段。

验证方式：运行 composer config -g --list | grep -E "(http|https)-proxy"，确认两行都存在且格式为 http://user:pass@host:port
密码含 @、/、: 必须 URL 编码，例如 pa@ss/word → pa%40ss%2Fword，可用 php -r "echo rawurlencode('pa@ss/word');" 生成
Windows 下若报 Could not write to file，检查 %APPDATA%\Composer\config.json 是否存在且当前用户有写权限

代理 ≠ 安全，私有仓库仍需三重防护

即使你用了可信代理拉取私有仓库，也不代表依赖安全。Composer 默认不校验包签名、不强制元数据 HTTPS、不阻止目录遍历——攻击者只要控制了你的代理链路或内网仓库服务端，就能注入恶意包。

Discussion Composer

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

下载

典型风险点：composer.json 里写死 "type": "vcs", "url": "https://github.com/your-org/private-repo"，但 GitHub 仓库未设私有权限；Nginx 配置开了 autoindex on，导致 /packages/ 目录裸奔；CI 脚本把 COMPOSER_AUTH 拼成多行 JSON 导致认证失效。

服务端必须关闭目录浏览，Nginx 中加 location / { try_files $uri =404; }
客户端启用元数据验证：composer config -g repo.packagist.org.allow_ssl_downgrade false
CI 中注入 COMPOSER_AUTH 必须是单行合法 JSON：{"http-basic":{"packages.your-company.com":{"username":"ci","password":"xxx"}}}，建议用 jq 生成而非字符串拼接

代理不稳定时，镜像源才是第一选择

国内用户遇到 composer install 超时、卡住、cURL error 7，90% 以上不是代理没配好，而是代理本身不支持 HTTPS CONNECT 隧道，或对 TLS 1.3/SNI 处理不兼容。强行调代理浪费时间，切镜像源一步到位。

阿里云镜像已全量同步 packagist.org，且走国内 CDN，无需代理即可秒级响应。它和代理是两套逻辑：镜像解决“路径远”，代理解决“不可达”。对绝大多数开发场景，前者覆盖后者。

全局生效：composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/
验证是否生效：composer config -g repo.packagist 输出应为完整 JSON 对象，含 "url": "https://mirrors.aliyun.com/composer/"
若之前设过其他镜像，先清理：composer config -g --unset repos.packagist

真正需要代理的场景极少：比如公司内网完全屏蔽外网，且已有合规的 HTTPS 透传代理（如 Squid + TLS passthrough）。其他情况，优先跑通镜像配置再考虑代理。