Composer本身不处理DNS解析，改系统DNS（如8.8.8.8）可解决“Could not resolve host”问题，因其依赖系统resolver；需清DNS缓存并验证curl -I https://packagist.org是否通。
Composer 本身不处理 DNS 解析，换 DNS 是系统/网络层的事——它只是用 PHP 的 file_get_contents 或 curl 发请求，底层全靠系统 resolver。
为什么改系统 DNS 能让 Composer 连得上 packagist.org
Composer 报 Could not resolve host: packagist.org 或卡在 Downloading packages.json，90% 是系统 DNS 返回了错误结果或超时。国内某些 ISP 的 DNS 会污染、缓存过期、甚至直接屏蔽境外域名。换成稳定公共 DNS 后，ping packagist.org 和 curl -I https://packagist.org 就能通，Composer 自然跟着恢复。
- Google DNS：
8.8.8.8和8.8.4.4（全球覆盖好，但偶尔受干扰） - Cloudflare：
1.1.1.1（隐私强、延迟低，国内多数地区直连快） - 阿里云：
223.5.5.5（国内 CDN 配合好，适合镜像源未生效时兜底） - 114 DNS：
114.114.114.114（响应快，但偶有劫持，建议仅作备选）
改完 DNS 必须清系统缓存，否则无效
系统不会自动刷新 DNS 缓存，旧记录可能持续数分钟甚至几小时。不清理，Composer 仍会查错的 IP。
- Windows：
ipconfig /flushdns - macOS：
sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder - Linux（systemd-resolved）：
sudo systemd-resolve --flush-caches或sudo resolvectl flush-caches - Docker 容器内：若用自定义网络，需在
docker-compose.yml中显式设dns字段，宿主机改 DNS 对容器无效
别只信 ping，用 curl -v 看真实连接路径
ping 只验证 ICMP 和 DNS 解析，但 Composer 走 HTTPS，真正卡点常在 TLS 握手或 IPv6 fallback。用 curl -v https://packagist.org 2>&1 | grep "Connected to" 才能看出是否连到了正确 IP，以及是否因 IPv6 卡住再降级到 IPv4。
- 看到
Connected to packagist.org (2a03:2880:...)且后续无响应 → 极大概率是 IPv6 不通，可临时禁用 IPv6 或配curl默认走 IPv4：curl -4 -I https://packagist.org - 看到
Connected to packagist.org (137.74.169.73)且返回 HTTP 200 → DNS 和链路正常，问题在 Composer 配置或镜像源 - 返回
Failed to connect但 DNS 已确认正确 → 防火墙、代理或 TLS 策略拦截，不是 DNS 问题
最易被忽略的一点：DNS 改了，但 Composer 还在用旧的镜像配置（比如 repo.packagist 键名写错、URL 少 /、没加 -g），或者项目级 composer.json 里硬写了 repositories，会直接覆盖全局设置。验证前先跑 composer config -g repo.packagist 和 composer config repo.packagist 对比输出。
