科技 · 實用指南
npm 顯示「getaddrinfo EAI_AGAIN」？改 DNS 前先證明解析環境
固定正確的 registry 主機名與失敗的 shell、CI、WSL 或容器，在同一環境驗證解析，再分開檢查 npm proxy、TLS 與 registry。
「getaddrinfo EAI_AGAIN」表示名稱解析步驟發生暫時失敗，不能證明 npm 停機，也不能把瀏覽器成功當成失敗程序的證據。
安全流程要在原失敗的 shell、CI、WSL 或容器內完成：記錄有效 registry 與 proxy，驗證同一環境的解析，主機名成功後才進入連線、TLS 與 HTTP 分支。
固定正確呼叫者與主機名
保存完整錯誤、命令、時間與環境，明確是 shell、IDE、服務、CI、WSL 或容器；不要用另一環境的瀏覽器結果代替。
輸出有效 registry 與 proxy，但不暴露憑證。記錄參數、環境變數及各層 npmrc；私有 registry 或失效 proxy 也可能先失敗。
在失敗環境驗證名稱解析
以同一使用者、命名空間與網路解析精確主機名，重複測試以區分短暫波動與持續政策問題。容器與 CI 必須在內部測試。
記錄 resolver、搜尋網域、VPN 或 split DNS 與 nameserver 可達性。不要先用公共 DNS 取代企業 DNS。
分開 DNS、proxy 與 registry 傳輸
對有效 registry 執行 npm ping。若仍為 EAI_AGAIN，留在解析分支；若已解析但出現 timeout、憑證或 HTTP 狀態，移到對應層。
先記錄 proxy 與 https-proxy 的來源；proxy 主機名也要在失敗環境解析。只有證明設定錯誤才清除。
分支處理容器、WSL 與 CI
Docker 要比較容器網路和 DNS，並在真正失敗的 build 或 runtime 階段測試；重啟只能證明暫時恢復。
WSL 與 CI 要記錄生成的 resolver 檔、VPN 時序和 job 映像。單一 runner 失敗時不要全域修改。
不靠繞過完成驗證
在同一呼叫者重做解析、npm ping 與原命令，確認仍使用設定主機名，沒有 hosts 或公共 DNS 臨時覆寫。
間歇性問題要跨建置視窗重複成功並保留時間戳；前後帳本應顯示真正改變的邊界。
