“Could not resolve host”错误本质是系统DNS解析失败，非Composer故障；应先执行ping packagist.org和curl -I https://packagist.org定位DNS或防火墙问题，再优化/etc/resolv.conf、/etc/hosts及禁用systemd-resolved，最后清缓存并验证镜像源配置。
“Could not resolve host”先别动 Composer 配置
这根本不是 Composer 的错，而是系统卡在 DNS 解析层。报这个错时，composer install 甚至还没开始发 HTTP 请求——它连 packagist.org 的 IP 都没查出来。
直接执行这两行命令比翻日志快得多：
-
ping packagist.org返回unknown host→ DNS 失败，换 DNS 服务器（如8.8.8.8或223.5.5.5）立竿见影 -
curl -I https://packagist.org卡住或报Failed to connect→ 防火墙、代理或 HTTPS 策略拦截，切手机热点一试便知
公司/学校网络常统一屏蔽 https://packagist.org 和 https://github.com，这不是你配错了，是策略本身不放行。
/etc/resolv.conf 和 /etc/hosts 是 DNS 优化的真正开关
改 Composer 镜像源解决不了 DNS 失效，但硬编码可信 DNS + 预置关键域名 IP 能跳过整条解析链路。
编辑虚拟机或容器内 /etc/resolv.conf，只保留：
nameserver 114.114.114.114 nameserver 223.5.5.5
再往 /etc/hosts 加这几行（用 curl -I https://mirrors.aliyun.com/composer/ 确认当前可用 IP）：
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
223.6.6.6 mirrors.aliyun.com 223.6.6.6 packagist.org 223.6.6.6 github.com 223.6.6.6 githubusercontent.com
如果启用了 systemd-resolved，务必禁用它：sudo systemctl disable --now systemd-resolved，否则它会偷偷覆盖 resolv.conf。
镜像源配完没生效？清缓存 + 查优先级
换了阿里云或清华源还报错，大概率不是镜像不行，而是旧缓存或配置覆盖在捣鬼：
- 必须执行
composer clear-cache，否则仍可能从本地缓存读取已失效地址 - 检查项目根目录
composer.json是否硬写了repositories→ 它的优先级高于全局镜像，会直接忽略config -g设的地址 - 清华镜像 URL 必须带末尾斜杠：
https://mirrors.tuna.tsinghua.edu.cn/composer/，少一个/就 404 - 验证是否真生效：
composer config -g repos.packagist（看全局），composer config repos.packagist（不加-g，看当前项目）
IPv6 fallback 是最隐蔽的“卡住但不报错”元凶
不是网络慢，而是 Composer 默认先尝试 IPv6 地址，超时（通常 1–3 秒）再 fallback 到 IPv4。上百个包叠加，就是几分钟无响应。
验证方法：curl -v https://packagist.org 2>&1 | grep "Connected to"，看到类似 Connected to packagist.org (2a03:2880:...) 且后续卡住，基本就是它。
临时绕过：启动容器时加 --dns 8.8.8.8；虚拟机里可禁用 IPv6：sudo sysctl -w net.ipv6.conf.all.disable_ipv6=1；Docker 全局配置则改 /etc/docker/daemon.json 加 "dns": ["8.8.8.8"]。
