科技 · 实用指南
npm 提示“getaddrinfo EAI_AGAIN”？改 DNS 前先证明解析上下文
固定准确的 registry 主机名与失败的 shell、CI、WSL 或容器，在同一环境验证解析，再分开排查 npm 代理、TLS 与 registry；不要硬编码 IP。
“getaddrinfo EAI_AGAIN”表示名称解析步骤出现临时失败。它不能证明 npm 服务宕机，也不能证明浏览器与失败进程使用同一解析路径。
安全做法是在原失败的 shell、CI、WSL 或容器内固定证据：先记录有效 registry 与代理，再在该上下文验证解析，只有主机名成功解析后才进入连接、TLS 与 HTTP 分支。
固定准确调用者和主机名
保存完整 npm 错误，包括 code、syscall、hostname、命令、时间与执行环境，明确是交互 shell、IDE、服务、CI、WSL 还是容器。不要拿另一环境的浏览器结果代替证据。
输出有效 registry 与代理配置，但不要泄露凭据。记录命令覆盖、环境变量以及项目、用户和全局 npmrc。私有 registry 或失效代理也可能在公共 registry 之前失败。
在失败上下文验证名称解析
用同一用户、命名空间和网络环境解析准确主机名，并重复测试以区分暂时波动与持续策略错误。容器或 CI 必须在内部探测；宿主机成功不等价。
记录解析器配置、搜索域、VPN 或 split DNS 状态以及 nameserver 可达性。不要先把企业 DNS 换成公共 DNS，内部 registry 与安全策略可能依赖原路径。
把 DNS 与代理、registry 传输分开
对有效 registry 运行 npm ping。若仍是 EAI_AGAIN，留在解析分支；若已解析但出现超时、拒绝连接、证书或 HTTP 状态，则进入对应层并保留原 DNS 证据。
先记录 proxy 与 https-proxy 的来源，再判断是否修改。代理主机名也必须在失败环境可解析；只有证明配置失效或不适用时才清除。
单独处理容器、WSL 与 CI
Docker 中要比较容器网络和 DNS 与宿主机的差异，并在真正失败的 build 或 runtime 阶段测试。重建镜像或重启 daemon 可能暂时掩盖问题，却不能证明根因。
WSL 与托管 CI 要记录生成的 resolver 文件、VPN 时序和 job 镜像。若仅一台 runner 失败，先保留该 runner 证据，不要全局改 registry 或 TLS。
在无绕过条件下验证
在同一调用者中重复解析、npm ping 和原 npm install 或 npm ci，确认仍使用配置的主机名，代理与证书策略明确，且没有遗留 hosts 或公共 DNS 临时覆盖。
间歇性失败需要跨相关构建窗口重复成功并保留时间戳。一次重试成功只证明当时恢复，前后账本应指出究竟哪个边界改变。
