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