“could not resolve host”是系统dns解析失败，需先用ping、dig、curl验证域名是否可解析，再排查dns污染、hosts绑定、镜像配置残留及网络策略干扰。
“Could not resolve host”不是 Composer 配置错了，是系统根本没解析出镜像域名的 IP——DNS 污染或失效导致所有后续操作全部卡死在第一步。
怎么确认是不是 DNS 污染或解析失败
别看 Composer 报错就去改 composer.json。先用系统命令直击 DNS 层：
-
ping mirrors.aliyun.com：返回unknown host→ 确认 DNS 解析失败 -
dig mirrors.aliyun.com @114.114.114.114和dig mirrors.aliyun.com @8.8.8.8对比：若一个超时、一个有 ANSWER SECTION → 本地 DNS 被污染或不可靠 -
curl -I https://mirrors.aliyun.com/composer/packages.json：返回Could not resolve host或卡住 → 不是 HTTPS 问题，是 DNS 根本没通 -
composer diagnose中https connectivity to packagist.org失败 ≠ 你不能用镜像，只说明它仍试图连官方源（可能因配置未生效）
如何临时绕过污染 DNS 快速验证
不改系统设置也能快速测试镜像是否真可用，关键是让请求走干净 DNS：
- Linux/macOS：临时加环境变量，强制 cURL 走指定 DNS（需 cURL 7.85+）：
export CURL_CA_BUNDLE="" && curl --resolve mirrors.aliyun.com:443:223.5.5.5 -I https://mirrors.aliyun.com/composer/packages.json（223.5.5.5是阿里公共 DNS） - Windows（CMD）：
set HTTP_PROXY=http://127.0.0.1:8080 && curl -I https://mirrors.aliyun.com/composer/packages.json，再配一个本地代理（如 Proxifier + Cloudflare 1.1.1.1）转发 DNS - 最简方式：手机热点直连，再跑一遍
composer install—— 如果成功，100% 是原网络 DNS 或策略问题
彻底清除镜像残留与 DNS 绑定污染
换镜像后还报错，往往不是镜像地址不对，而是旧配置、缓存、hosts 或 fallback 在暗中作祟：
- 删干净三层配置：
composer config --global --unset repos.packagist.org（注意 key 是repos.packagist.org，不是repositories.packagist.org）；再检查项目级composer.json的repositories字段是否残留 - 清空 hosts 文件：
/etc/hosts（Linux/macOS）或C:\Windows\System32\drivers\etc\hosts（Windows）里删掉所有含packagist.org、mirrors.aliyun.com的行 - 强制禁用 fallback 行为：
COMPOSER_DISABLE_FALLBACK=1 composer install—— 否则即使你删了镜像，Composer 2.2+ 仍可能在主源慢时自动切过去 - 删缓存前先确认路径：
composer clear-cache默认清的是~/.composer/cache，但若设过COMPOSER_HOME，得手动进对应目录rm -rf cache/repo/ cache/files/
为什么改了 DNS 还是解析失败
常见被忽略的底层干扰点：
- WSL 用户：宿主机和 WSL 的 DNS 完全独立，
nslookup mirrors.aliyun.com必须在 WSL 里执行，且/etc/resolv.conf可能被 systemd-resolved 动态覆盖，建议加options timeout:1并重启systemd-resolved - 企业网络：某些防火墙会 DNS 劫持，返回假 IP（比如把
mirrors.tuna.tsinghua.edu.cn解成内网 10.x.x.x），此时curl -v会卡在* Connected to ...后无响应，而非报错 - PHP CLI 自身限制：运行
php -i | grep default_socket_timeout，若值为 60，http.timeout再大也无效，得用php -d default_socket_timeout=600 $(which composer) install
真正卡住的时候，往往不是 Composer 不够快，而是它连目标服务器的门牌号都还没查到。DNS 层的异常最难感知，却最先阻断一切——盯住 dig 和 curl --resolve 的输出，比反复重试 composer update 有效十倍。
