科技 · 實用指南
sudo 顯示「unable to resolve host」？先沿 NSS 追查本機主機名稱
先證明 runtime hostname 與真正 NSS 查詢路徑，找出設定擁有者，再只修一層並重驗 sudo。
這個警告表示機器無法透過已設定的 hosts database 解析自己目前的 hostname，不等同網際網路 DNS 故障。先保留準確名稱，再沿應用程式實際路徑檢查。
凍結精確本機身分
記錄 sudo 警告中的字面名稱、hostname 輸出、可用時的 hostnamectl 狀態，以及環境是主機、container 或 CI runner。先不要補 domain、改大小寫或猜哪個檔案錯。
測試真正 hosts database
用目前 hostname 執行 getent hosts，需要地址族時再用 getent ahosts。它們遵循 NSS 路徑。host 或 dig 可能繞過 local files 與 NSS module，因此結果不同不代表矛盾。
讀取有效來源順序
檢查 /etc/nsswitch.conf 的 hosts 行，記錄 files、myhostname、resolve、dns 與控制條件的順序。只檢查應回答本機名稱的來源；files 缺項、module 缺失與 DNS-only 失敗是不同分支。
找出持久設定擁有者
靜態 Debian 類主機比較 runtime hostname、persistent hostname 與已驗證 local mapping。cloud image、DHCP、NetworkManager、cloud-init、systemd-hostnamed、container 或 orchestration 要找出誰會重建名稱或檔案。
只修一個已證實層級
修正一個確認的不一致或 module 設定。保留 localhost 與有效 alias，不要為了消除警告隨意附加 address 或全域改名。ephemeral container 和 CI 應修 image、entrypoint 或 runtime mapping。
分開驗證並結束
重跑 hostname 與 getent，再做無副作用 sudo 驗證及原命令。只有 owner 要求時才 reboot 或 recreate，並在之後重測。外部 DNS 另行驗證，不讓本機自解析與網路可達性互相遮蔽。
