Composer使用脚本设置代理失败怎么纠错-composer-PHP中文网

composer提示connection refused或curl error 7，90%是代理未生效或配置错误：composer不读取系统代理，必须用config -g显式设置http-proxy/https-proxy，且需带协议头、格式严格，设完需用composer config -g验证是否输出正确地址。

composer使用脚本设置代理失败怎么纠错

Composer install 时提示 Connection refused 或 cURL error 7 是代理没生效

Composer 本身不读取系统全局代理（比如 http_proxy 环境变量），也不自动继承 Git 或 npm 的代理配置。它只认自己配置的 proxy 和 https-proxy 设置，且对协议头、端口、认证格式极其敏感。

常见错误现象包括：Connection refused、cURL error 7: Failed to connect、Could not resolve host: repo.packagist.org —— 这些基本都能定位到代理配置未被 Composer 正确加载或格式错误。

检查是否用了 http:// 前缀：Composer 要求代理地址必须带协议，127.0.0.1:10809 无效，得写成 http://127.0.0.1:10809
HTTPS 流量必须用 https-proxy 单独设，proxy 只管 HTTP 请求；两者要同时配全，否则部分包源（如 Packagist）会失败
含用户名密码的代理需 URL 编码：比如密码含 @ 或 /，得用 urlencode() 处理，否则解析中断
Windows 用户注意反斜杠路径或 PowerShell 特殊字符（如 $）可能意外展开变量，建议用 CMD 或加单引号包裹值

用 config 命令设代理比改 config.json 更可靠

直接编辑 composer.json 或全局 config.json 容易因格式错误（多逗号、引号不匹配）导致后续所有命令报错 JSON decode error。用命令行设是原子操作，自动校验格式。

实操建议：

全局设置（推荐）：

composer config -g http-proxy http://127.0.0.1:10809
composer config -g https-proxy http://127.0.0.1:10809

项目级设置（仅当前目录生效）：

composer config http-proxy http://127.0.0.1:10809

取消代理：

composer config -g --unset http-proxy
composer config -g --unset https-proxy

设完可立刻验证：composer config -g http-proxy 应输出你刚设的地址；若为空，说明没生效或被其他配置覆盖。

代理生效但 still timeout？检查是否绕过了 Packagist 镜像

即使代理通了，Composer 默认仍走 repo.packagist.org，而国内直连该域名极大概率超时。代理只是通道，不等于自动换源。很多用户误以为“设了代理就万事大吉”，结果卡在 DNS 解析或 TLS 握手阶段。

Academic Composer Upload

辅助学术写作，包括查找资料、生成大纲、引用扩写及润色风格，同时确保引用规范。

下载

必须显式启用镜像（推荐阿里云或腾讯云）：

临时切换：

composer config -g repos.packagist composer https://mirrors.aliyun.com/composer/

或者用国内一键脚本：

composer config -g repo.packagist composer https://packagist.phpcomposer.com

（注意该源已停更，不推荐）

确认是否生效：composer config -g repos.packagist 输出应为镜像地址，不是 https://repo.packagist.org

如果用了代理又启用了镜像，Composer 会先走镜像地址，再经代理发出请求 —— 顺序不能颠倒。

debug 模式下看到 proxy header 被 strip 掉？那是 cURL 版本太老

某些旧版 cURL（如 CentOS 7 自带的 7.29）不支持 HTTP_PROXY 环境变量透传，Composer 内部调用时会静默丢弃代理头，但不报错。现象是：composer diagnose 显示 “OK”，composer config -g 显示代理已设，但 install 依然直连。

验证方式：

composer diagnose -v

查看详细日志里有没有 Using proxy 行；没有就基本确定被底层拦截了。

升级 cURL：Ubuntu/Debian 用 apt install curl；macOS 用 brew install curl 后，确保 Composer 调用的是新版（which curl 和 curl --version）
绕过 cURL：强制 Composer 用 PHP stream：
```
composer config -g use-include-path false
export COMPOSER_NO_INTERACTION=1
```
并确保 allow_url_fopen = On 在 php.ini 中启用

这个点最容易被忽略——代理配置全对、镜像也开了，就因为系统 cURL 太旧，全程静默失败。