“Could not resolve host”错误90%是系统DNS解析失败，非Composer问题；应先用ping和curl -I定位：ping返回unknown host即DNS故障，换8.8.8.8等公共DNS；curl卡住则为防火墙或代理拦截，切手机热点验证；nslookup/dig可确认DNS污染，hosts绑定需IP最新、格式严格并刷新缓存。
看到“Could not resolve host”先别改Composer配置
这错误90%不是Composer的问题，而是系统卡在DNS解析层——它连域名都还没转成IP，根本轮不到Composer发HTTP请求。直接改http.timeout或process-timeout毫无意义。
快速验证只需两行命令：
-
ping packagist.org返回unknown host→ DNS解析失败，换DNS服务器（如8.8.8.8或223.5.5.5）立竿见影 -
curl -I https://packagist.org卡住或报Failed to connect→ 防火墙、代理或HTTPS策略拦截，切手机热点一试便知
nslookup和dig才是真·诊断工具
靠ping只能看通不通，nslookup和dig才能确认是不是DNS污染。比如国内部分云厂商镜像源（如mirrors.aliyun.com）常被区域性污染，本地DNS查不到真实IP。
执行这两条命令对比结果：
-
nslookup mirrors.aliyun.com 1.1.1.1→ 若返回IPv4地址（如223.5.5.5），说明干净DNS能解析 -
nslookup mirrors.aliyun.com（不指定DNS）→ 若超时或报*** Can't find ...: Non-existent domain，就是污染实锤
只要第一条通、第二条不通，问题纯属DNS，不用查代理、不用清缓存、不用重装Composer。
hosts绑定比换DNS更稳，但三处必须同时对
CI/CD或内网多机部署时，临时换DNS或--resolve不可靠，手动绑定/etc/hosts（Linux/macOS）或C:\Windows\System32\drivers\etc\hosts（Windows）才是生产首选，但以下三点缺一不可：
- IP必须最新：每次用
dig mirrors.aliyun.com @8.8.8.8 +short | head -n1拿当前有效IP，别抄网上过期地址 - 格式必须严格：写成
223.5.5.5 mirrors.aliyun.com，IP和域名之间只能是空格，不能是Tab或中文符号 - 缓存必须刷新：macOS执行
sudo dscacheutil -flushcache，Windows执行ipconfig /flushdns，Linux systemd系统执行sudo systemd-resolve --flush-caches
杀毒软件（如火绒、360）常锁死hosts文件，保存失败时务必右键编辑器选“以管理员身份运行”。
IPv6 fallback导致“卡住但不报错”最隐蔽
不是网络慢，而是Composer默认先尝试IPv6地址，超时（通常1–3秒）再fallback到IPv4。上百个包叠加，就是几分钟无响应，日志里却看不到错误。
验证方法：curl -v https://packagist.org 2>&1 | grep "Connected to"，如果看到类似Connected to packagist.org (2a03:2880:...)且后续卡住，基本就是它。
临时绕过：启动容器时加--sysctl net.ipv6.conf.all.disable_ipv6=1；长期解决建议在系统DNS配置中禁用IPv6解析，或强制使用IPv4 DNS（如8.8.8.8）。
真正容易被忽略的是：这个问题不会触发任何错误提示，只会让composer install长时间静默，直到超时——你得主动去看curl -v的连接细节，而不是等报错。
