Composer代理配置提速秘籍与实战-composer-PHP中文网

composer 2.2+ 支持 socks5:// 代理，旧版仅识别 http://；配错协议或未同步配置 ssl-proxy 会导致 https 请求直连超时，必须同时设置 proxy 和 ssl-proxy 才生效。

composer代理配置提速秘籍与实战

配代理不等于一定快，配错反而更慢——关键在协议匹配、证书信任和命令覆盖范围。

composer config -g repo.packagist.org.proxy 配什么协议才生效

Composer 2.2+ 才支持 socks5://，旧版只认 http://。国内常用代理（Clash、Surge）默认开 HTTP 代理端口（如 7890），直接填 http://127.0.0.1:7890 最稳妥：

composer config -g repo.packagist.org.proxy http://127.0.0.1:7890
composer config -g repo.packagist.org.ssl-proxy http://127.0.0.1:7890

如果用 socks5://127.0.0.1:7891 却没反应，先运行 composer --version 确认 ≥ 2.2；再检查代理是否开启 TUN 模式或允许 TCP 转发。

配了代理但 composer install 还是卡住？先看这三类错误

Composer 不会直接报“代理连不上”，而是抛出底层网络异常：

Discussion Composer

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

下载

file_get_contents(): SSL operation failed → 代理未正确透传 TLS 流量，或本地 CA 证书不被信任；临时改用 http:// 代理可绕过
Connection refused 或 No route to host → 代理进程未运行、端口填错、防火墙拦截；用 curl -x http://127.0.0.1:7890 https://packagist.org/packages.json 手动验证通路
composer create-project 慢但 install 快 → 漏配 ssl-proxy，该命令首步访问 https://repo.packagist.org/packages.json，必须走 ssl-proxy

企业内网/CI 环境下，代理反而该关掉

阿里云、腾讯云等镜像站已全量同步 Packagist，且走内网直连。此时配代理不仅多余，还可能因 DNS 解析或 TLS 中间人导致失败：

确认是否已配置镜像：composer config -g repo.packagist 输出应为完整 JSON，如 {"type": "composer", "url": "https://mirrors.aliyun.com/composer/"}
若输出是字符串或仍是 https://packagist.org，说明镜像未生效，优先修复镜像配置而非加代理
CI 中建议显式禁用代理：composer config -g --unset repo.packagist.org.proxy 和 --unset repo.packagist.org.ssl-proxy

代理只是加速链的一环，别漏掉其他关键参数

代理只解决下载源访问问题，真正影响最终耗时的还有包格式、依赖范围和自动加载策略：

composer install --prefer-dist --no-dev --optimize-autoloader：三项组合能压到 12 秒内（实测 PHP 8.2 + 4GB RAM）
--prefer-dist 强制走压缩包，避免 Git 克隆；即使某包没 dist，Composer 也会自动 fallback，不用怕
COMPOSER_CACHE_DIR 必须指向 SSD 路径，如 /tmp/composer-cache；挂载到 NFS 或慢盘，缓存等于白设

代理配得再准，如果 cache-dir 在机械盘上，或者忘了 --no-dev，提速效果就打对折——性能优化从来不是单点动作。