改DNS比换镜像源更关键，因为90%的“Loading composer repositories”卡顿或“Could not resolve host”错误源于DNS解析失败；镜像再快，域名无法解析就根本连不到服务器，需手动锁定114.114.114.114等可信DNS并禁写保护。
为什么改DNS比换镜像源还关键
Composer 卡在 Loading composer repositories 或报 Could not resolve host，90% 不是源站慢，而是 DNS 解析失败或超时。镜像源 URL 再快，域名都解析不出来，根本连不到服务器。国内网络环境下，packagist.org、github.com 等域名常被劫持、污染或返回错误 IPv6 地址，导致默认 fallback 机制拖慢整条链路。
直接改 /etc/resolv.conf 最有效
别依赖宿主机继承或 systemd-resolved 自动管理——它经常偷偷覆盖配置、引入超时重试逻辑，甚至强制走 IPv6。最稳的方式是手动锁定可信 DNS：
- 编辑
/etc/resolv.conf，只保留两行：nameserver 114.114.114.114和nameserver 223.5.5.5 - 加
options timeout:1 attempts:2到文件末尾，避免单次查询卡死 - 运行
sudo chattr +i /etc/resolv.conf防止被其他服务重写（如 NetworkManager、systemd-resolved） - 验证：执行
nslookup packagist.org，确认返回的是 IPv4 地址且耗时
hosts 预绑定关键域名防 fallback
DNS 解析慢的另一个隐性原因是 Composer 默认先查 IPv6 AAAA 记录，超时（通常 2–3 秒）再退到 IPv4 A 记录。上百个包叠加就是几分钟无响应。预绑定可彻底跳过这一步：
- 用
curl -I https://mirrors.aliyun.com/composer/确认当前可用 IP（比如223.6.6.6） - 往
/etc/hosts加入：223.6.6.6 mirrors.aliyun.com、223.6.6.6 packagist.org、223.6.6.6 github.com、223.6.6.6 githubusercontent.com - 注意：不要加
www.前缀，Composer 不会带 www 请求这些域名 - 改完立刻生效，无需重启服务
容器内 DNS 必须显式指定
Docker 默认用宿主机 /etc/resolv.conf，但在 macOS/Windows 上经虚拟化层转发后，DNS 查询常延迟或失败。不能靠 --network host（它忽略 dns 字段），也不能只改 daemon.json：
- 启动容器时加
--dns 114.114.114.114 --dns 8.8.8.8 - Compose 文件中，在 service 下写明：
dns: ["114.114.114.114", "8.8.8.8"]和dns_search: ["svc.cluster.local"] - 避免使用
network_mode: host同时配dns——该组合下dns字段完全被忽略 - 验证容器内 DNS 是否生效：
docker exec -it myapp cat /etc/resolv.conf，确保内容与预期一致
真正卡住 Composer 的，从来不是下载速度，而是第一次握手前的那几毫秒不确定性。DNS 配置一旦松动，所有后续优化（镜像源、并发数、超时设置）都会打折扣。动手前先跑一遍 nslookup packagist.org 和 curl -v https://packagist.org 2>&1 | grep "Connected to"，看到 IPv6 地址就说明还没绕过去。
