该错误本质是 php 底层调用 getaddrinfo() 失败导致 DNS 解析失败，常见于国内网络、DNS 配置异常或 hosts 污染；需通过 nslookup/dig 验证系统 DNS，检查代理与 CA 配置，并优先修复系统级 DNS 而非依赖 hosts 临时映射。
composer install/update 报 php_network_getaddresses: getaddrinfo failed 怎么定位
这错误本质是 PHP 底层调用 getaddrinfo() 失败，也就是 DNS 解析失败。不是 Composer 本身的问题，而是它发起 http 请求前，连目标域名（比如 packagist.org）都解析不出 IP。常见于国内网络环境、DNS 配置异常或 hosts 被污染。
检查系统级 DNS 是否生效
先绕过 Composer，确认基础网络是否能解析 Packagist 域名：
- 运行
nslookup packagist.org或dig packagist.org +short，看是否有返回 IP； - 如果超时或返回空，说明系统 DNS 不可用，需改用稳定 DNS（如
8.8.8.8或114.114.114.114）； - linux/macOS 可临时测试：
nslookup packagist.org 8.8.8.8；windows 可用nslookup packagist.org 114.114.114.114； - 注意：PHP 的 curl 和 stream 扩展默认复用系统 DNS 设置，不读取
/etc/hosts以外的自定义配置。
PHP 是否被强制绑定了异常 DNS 或代理
某些 PHP 环境（尤其 WAMP/MAMP/XAMPP 或 docker 容器）会预设 curl.cainfo、openssl.cafile，或通过 http_proxy 环境变量间接影响 DNS 行为：
- 运行
php -i | grep -i "curl|proxy|dns"查看是否启用了代理或自定义 CA； - 检查 shell 环境：
env | grep -i proxy，若存在http_proxy/https_proxy，尝试临时清空：unset http_proxy https_proxy再运行composer update； - Docker 用户注意：容器内默认使用宿主机 DNS，但若用了
--dns参数或自定义/etc/resolv.conf，可能指向不可用 DNS； - PHP-FPM 场景下，
fastcgi_param也可能透传代理变量，需同步排查。
临时绕过 DNS（仅调试用）
若确认是 DNS 问题且短期无法修复，可手动把 Packagist 域名映射到已知可用 IP（不推荐长期使用）：
立即学习“PHP免费学习笔记（深入）”；
echo "151.101.2.162 packagist.org" | sudo tee -a /etc/hosts该 IP 是 packagist.org 当前 CDN 节点之一（可通过 dig packagist.org +short 获取最新值）。Windows 用户修改 C:WindowsSystem32driversetchosts，注意用管理员权限保存。
注意：这个 IP 可能随 CDN 调度变化，且 repo.packagist.org、api.github.com（依赖 github 包时）等也需一并加 hosts 条目，否则后续仍会报错。
真正稳定的解法永远是让系统 DNS 回归正常——因为 Composer 依赖的不只是 packagist.org，还有 GitHub、gitlab、私有仓库等所有源域名，逐个写 hosts 不可持续。DNS 解析失败时，任何基于 HTTP 的包管理操作都会卡在第一步。