答案是DNS解析失败或网络链路中断导致，需先用ping、nslookup验证DNS，再用curl -I和--resolve测试TCP连通性及CDN回源IP冲突，确认镜像配置键名repo.packagist、type值composer、URL末尾带/并清缓存。
报错卡在“Could not resolve host”或“Connection refused”时先验证DNS和连通性
这类错误不是 Composer 本身问题，而是系统级网络链路中断。关键看两件事：DNS 能否解析、TCP 是否能建连。ping packagist.org 返回 unknown host 就是 DNS 失效；curl -I https://mirrors.aliyun.com/composer/ 卡在 * Connected to 阶段，说明路由丢包或中间设备拦截。
推荐快速验证组合：
- 运行
nslookup mirrors.aliyun.com，记下返回的 IP 列表 - 对每个 IP 执行
curl -s -o /dev/null -w "%{http_code}\n" --connect-timeout 3 -m 5 https://$ip/composer/ -k（加-k是因为直连 IP 会跳过 SNI，证书校验必然失败） - 如果多数 IP 返回
000或超时，但其中某个（如223.5.5.5）返回200，说明其他 IP 是无效回源地址
确认是否本地网段与 CDN 回源 IP 冲突
阿里云、腾讯云等镜像后端常用 100.64.0.0/10、172.16.0.0/12 等私有网段做内部回源。如果你的路由器或防火墙把这类地址当成本地内网处理，就会静默丢包——DNS 能解析，但 curl 卡在 Trying 100.64.x.x... 就是典型表现。
查当前解析出的 IP 是否落在这些网段：
-
dig mirrors.aliyun.com +short查所有 A 记录 - 用在线 CIDR 工具或手动比对：比如
172.20.1.100属于172.16.0.0/12（即 172.16.0.0–172.31.255.255），大概率不可达 - 若你本地局域网恰好也用了
172.20.0.0/16，那冲突就坐实了
临时绕过路由冲突的实操方法
不改网络设备配置的前提下，最直接的方式是强制绑定已知可用的公网 IP。这不是换源，而是绕过 DNS 返回的“假公网 IP”。
开箱即用的技能链路由引擎。13 条预定义链覆盖搜索、开发、审查、MLOps、法律、创意等场景，三层路由架构（触发词→SAD反馈→DAG编排），recall@10=96.97%。配置驱动（chains.yaml），零代码扩展。pip install skill-weave-chains 一键安装。
例如：
curl --resolve mirrors.aliyun.com:443:223.5.5.5 -I https://mirrors.aliyun.com/composer/- 把这个逻辑透传给 Composer：
COMPOSER_HOME=~/.composer composer install --no-plugins --no-scripts不行时，可临时改写 hosts：echo "223.5.5.5 mirrors.aliyun.com" | sudo tee -a /etc/hosts - 注意：hosts 绑定后要清缓存：
composer clear-cache，否则 Composer 仍可能读旧记录
为什么换镜像源命令容易静默失效
很多人执行了 composer config -g repos.packagist composer https://mirrors.aliyun.com/composer/ 却没效果，是因为键名、type 值或 URL 格式错了，Composer 不报错也不提示。
必须满足三要素：
- 键名是
repo.packagist（不是repos.packagist，也不是packagist.org） - type 值必须是
composer（漏掉就 fallback 到官方源） - URL 必须以
/结尾：https://mirrors.aliyun.com/composer/✅，https://mirrors.aliyun.com/composer❌（少斜杠会导致拼成/composerpackages.json报 404）
验证是否生效：composer config -g repo.packagist 应该原样输出镜像 URL，而不是 https://packagist.org。
