Composer 默认会尝试 IPv6，但国内很多网络环境对 IPv6 支持不稳或被干扰，导致 composer install 卡在 DNS 解析或连接阶段——这不是 Composer 本身慢，是它在等 IPv6 超时。
为什么 Composer 会卡在 repo.packagist.org 或 packagist.org
Composer 底层用 PHP 的 curl 或 stream 发起 HTTP 请求，而系统解析域名时若返回 IPv6 地址（如 2a02:fc00::1），且本地网络无法通达该地址，就会触发长达数秒的超时，反复重试后才降级到 IPv4。你看到的“慢”，其实是隐性等待。
- 典型现象：
Updating dependencies阶段长时间无响应，strace可见大量connect系统调用失败 - 验证方式：运行
ping -c 3 repo.packagist.org，如果看到 IPv6 地址且不通，基本就是它 - 注意：不是所有机器都如此，但阿里云/腾讯云部分 ECS、校园网、某些家用宽带极易触发
强制 Composer 使用 IPv4 的三种实操方法
优先级从高到低，按需选用：
Evez Github Manager
下载
在 OpenClaw 中管理 GitHub 仓库、Pull Request、Issue 与工作流。适用于审查 PR、管理 Issue、自动化 GitHub Actions、同步仓库等场景。
-
全局设置（推荐）：执行
composer config -g github-protocols https（虽名含 GitHub，但实际影响所有 HTTPS 源），再配合系统级 IPv4 强制——更直接的是改 Composer 自身行为 -
临时生效（调试用）：在命令前加环境变量
export COMPOSER_HOME=/dev/null; export HTTP_PROXY=""; composer install --no-cache不解决根本问题；真正有效的是让底层 curl 只走 IPv4：curl_setopt($ch, CURLOPT_IPRESOLVE, CURL_IPRESOLVE_V4)——但 Composer 不暴露该参数，所以得绕道 -
最可靠方案：修改系统 hosts 并禁用 IPv6 解析：
运行nslookup repo.packagist.org 8.8.8.8 | grep "Address:" | head -1 | awk '{print $2}'获取当前 IPv4 地址（例如185.199.108.153），然后写入：echo "185.199.108.153 repo.packagist.org" | sudo tee -a /etc/hosts
PHP cURL 层面的硬性限制（进阶排查）
如果你自己写脚本调用 Composer API，或使用 composer require 时仍异常，检查 PHP 的 cURL 是否编译支持 IPv6：
- 运行
php -r "var_dump(curl_version()['features'] & CURL_VERSION_IPV6);"，输出int(1)表示支持，但支持 ≠ 可用 - 关键参数是
CURLOPT_IPRESOLVE，Composer 未开放配置，因此不能靠php.ini或curl_setopt_array注入 - 替代做法：在
composer.json中换镜像源，例如："repositories": [{"type": "composer", "url": "https://packagist.phpcomposer.com"}]——但该镜像已停用，现可用https://mirrors.aliyun.com/composer/，它默认只响应 IPv4 请求
真正起效的永远是「让域名解析不出 IPv6 地址」，而不是教 Composer 学会选路。hosts 绑定 + 镜像源双管齐下，99% 的“Composer 卡住”问题当场消失。别在 composer config 里找 IPv4 开关——它压根没这个开关。
