结论是DNS解析失败导致镜像无法访问，而非镜像地址错误；需先用nslookup或dig验证mirrors.aliyun.com是否能解析出IP（如223.5.5.5），再通过curl --resolve直连测试服务可用性，确认为纯DNS问题后可改hosts硬绑定IP或切换公共DNS。
直接说结论：不是镜像地址写错了，而是 mirrors.aliyun.com 这个域名在你本地根本解析不出 IP——DNS 污染或失效导致请求卡死在第一步，换源命令执行成功也白搭。
先确认是不是 DNS 真的解析失败
别跳过这步。所有后续操作都依赖系统能返回真实 IP。
-
nslookup mirrors.aliyun.com返回*** Can't find mirrors.aliyun.com: Non-existent domain或超时 → 解析失败 -
ping mirrors.aliyun.com报unknown host→ 同样是 DNS 问题，不是网络不通 -
nslookup mirrors.aliyun.com 1.1.1.1或nslookup mirrors.aliyun.com 8.8.8.8能返回 IPv4 地址（如223.5.5.5）→ 证实本地 DNS 被污染
用 curl --resolve 绕过 DNS 验证镜像服务是否真可用
这是最快验证“是不是纯 DNS 问题”的方式，不改任何配置，5 秒内出结果。
CurlShip Directory Submission
下载
向CurlShip提交产品，这是一个对机器人友好的SaaS目录。只需一条curl命令即可发布产品，支持OG标签抓取、带徽章的dofollow链接及层级升级。
- 先查真实 IP：
dig mirrors.aliyun.com @223.5.5.5 +short | head -n1（推荐用阿里自己的 DNS 查） - 拿到 IP 后直连测试：
curl -I --resolve "mirrors.aliyun.com:443:223.5.5.5" https://mirrors.aliyun.com/composer/packages.json - 返回
HTTP/2 200和Content-Type: application/json→ 镜像服务正常，问题纯属 DNS - 若仍超时或报 SSL 错误，再排查代理、防火墙或证书信任链
改 hosts 是最稳的落地方案
当 DNS 污染反复出现，或你在 CI/CD、Docker 容器里需要确定性行为时，硬绑定 IP 最可靠。
- 获取最新 IP（别用过期缓存）：
dig mirrors.aliyun.com @8.8.8.8 +short | head -n1 - 编辑 hosts 文件：
/etc/hosts（Linux/macOS）或C:\Windows\System32\drivers\etc\hosts（Windows） - 追加一行（注意空格分隔）：
223.5.5.5 mirrors.aliyun.com - 刷新 DNS 缓存：
sudo dscacheutil -flushcache（macOS）、ipconfig /flushdns（Windows） - 此时
composer install发起的请求已完全跳过 DNS 解析链路
换源后仍失败？三处残留必须清干净
很多人配了镜像还报错，是因为旧配置在后台静默干扰。
- 删全局仓库配置：
composer config --global --unset repos.packagist.org（注意 key 是repos.packagist.org，不是repositories） - 检查项目级
composer.json的repositories字段，删掉所有含packagist.org或空type: "composer"的条目 - 清 hosts 里所有含
mirrors.aliyun.com、repo.packagist.org的行（避免新旧 IP 冲突） - 禁用 fallback：
COMPOSER_DISABLE_FALLBACK=1 composer install，否则 Composer 2.2+ 会在主源响应慢时自动切回官方源
关键点在于：镜像源配置生效的前提，是你本机能解析出镜像域名本身。哪怕你写了 https://mirrors.aliyun.com/composer/，只要 mirrors.aliyun.com 解析不出来，Composer 就卡在 DNS 层动不了——这时候调 http-timeout、清 Composer 缓存、重装 PHP 扩展，全都没用。
