改DNS能缓解“Could not resolve host”错误，因该错本质是DNS解析失败而非网络不通；换用8.8.8.8等公共DNS可提升packagist.org等域名解析成功率，避免运营商劫持DNS导致超时或错误IP。
为什么改DNS能直接缓解“Could not resolve host”
Composer报这个错，不是没连上网络，而是根本没查出packagist.org或mirrors.aliyun.com的IP。系统默认用宿主机DNS（比如运营商劫持的114.114.114.114），但这类DNS在虚拟机/Docker里常返回超时或错误IP。换成8.8.8.8、1.1.1.1或223.5.5.5后，解析成功率从约60%升到99%以上。
- 别依赖
/etc/resolv.conf被自动覆盖——用sudo systemctl disable --now systemd-resolved先干掉它 - Docker容器要显式传
--dns 8.8.8.8，否则默认走宿主机/etc/resolv.conf，而该文件在容器内可能为空 - macOS上用Parallels/VirtualBox，宿主机DNS常被强制改写，必须在虚拟机内单独配
/etc/hosts硬编码关键域名IP最稳
DNS再快也有RTT延迟，而/etc/hosts是本地查表，毫秒级响应。尤其对github.com、githubusercontent.com这类Composer下载ZIP包必经的域名，硬编码能跳过全部DNS链路。
- 先用
curl -I https://mirrors.aliyun.com/composer/确认当前可用IP（阿里云镜像IP会轮换，别抄旧教程里的固定值） - 往
/etc/hosts加这四行（IP统一用最新查到的，不要混用）：223.6.6.6 mirrors.aliyun.com<br>223.6.6.6 packagist.org<br>223.6.6.6 github.com<br>223.6.6.6 githubusercontent.com
- 注意：如果公司用了私有GitLab，也得把对应域名+内网IP加进去，否则
composer install仍卡在Cloning
镜像源配置不生效？先看DNS是否已通
很多人执行了composer config -g repo.packagist https://mirrors.aliyun.com/composer/，但composer install -vvv日志里还是出现packagist.org——这是因为DNS根本没解析通mirrors.aliyun.com，Composer自动fallback回默认源。
- 验证DNS是否OK：
nslookup mirrors.aliyun.com 8.8.8.8，返回非空IP才算通过 - 验证镜像是否真生效：
composer install -vvv 2>&1 | grep "Downloading\|Resolving"，看到的域名必须是mirrors.aliyun.com而非packagist.org - 旧版Composer（1.x）必须用
repos.packagist字段，命令是composer config -g repos.packagist '{"type":"composer","url":"https://mirrors.aliyun.com/composer/"}'
Docker里DNS配置最容易漏的三个点
Docker默认复用宿主机DNS，但在CI环境、内网机器或某些Linux发行版上，这个行为极不可靠。不手动指定，composer install失败率直线上升。
-
docker run启动单容器时，必须带--dns 8.8.8.8 --dns 1.1.1.1，两个备用防止单点失效 -
docker-compose.yml里要写dns: ["8.8.8.8", "1.1.1.1"]，不能只靠networks配置 - 如果用BuildKit构建，
Dockerfile中RUN composer install阶段的DNS由docker build命令决定，需加--dns参数，而非Dockerfile内写echo改resolv.conf
DNS优化本身不解决TLS握手慢或PHP内存不足的问题，但它是一切网络操作的前提——没IP，后面所有加速手段都无从谈起。实际排查时，永远先跑nslookup和curl -I，再动Composer配置。
