Debian 12 DNS 查詢失敗：修正 systemd-resolved

如果 Debian 12 顯示“名稱解析暫時失敗”，請依序檢查解析器服務、/etc/resolv.conf連結以及 `--servers` 列出的 DNS 伺服器resolvectl。重啟服務僅在服務停止時有效；連結損壞或上游伺服器無法存取需要其他修復方法。

這些說明適用於配置為使用 Debian 12 (Bookworm) 的系統systemd-resolved。 Debian 已將該解析器拆分為單獨的軟體包，並且沒有將其設定為預設解析器，正如Debian 12 發行說明中所述。如果您的系統使用其他 DNS 管理器，請保持該管理器的控制權，而不是強制其套用這些設定。

1. 確定名稱解析失敗的原因

首先配置網路路由並尋找主機名稱。在本機或終端機中執行命令，確保終端機在網路變更時保持開啟：

ip -br address
ip route
ping -c 2 1.1.1.1
resolvectl status
resolvectl query debian.org
getent ahosts debian.org

預設路由和有效的數位 IP 連線表示機器無需 DNS 即可存取網路。僅 ping 失敗並不能證明路由故障：網路可能會阻止 ICMP 回顯應答。如果介面缺少位址或路由，請先修復網路連線。

resolvectl status顯示全域或指派給各個介面的 DNS 伺服器和網域名稱。resolvectl query測試 systemd 解析器；getent ahosts測試 Linux 應用程式常用的主機名稱查找路徑。這種差異有助於隔離故障。

觀察	下一步檢查
沒有地址或預設路由	在設定 DNS 之前，請先修復介面、網關或 DHCP 設定。
`resolvectl`無法連線到其服務	檢查是否已`systemd-resolved`安裝並正在運作。
`resolvectl query`有效，`getent`失敗	檢查`/etc/resolv.conf`NSS 主機配置。
兩次查找都失敗，但路由卻可以正常運作。	檢查上游 DNS 位址、DNS 路由和防火牆存取權限。

Debian 終端，使用 ip route、resolvectl status 和 getent hosts 指令檢查 DNS 連線性。 — 終端視圖將預設網路路由、DNS 伺服器指派和應用程式級主機名稱查找分組在一起，用於初步診斷。

2. 確保 systemd-resolved 已安裝並處於活動狀態

在 Debian 12 系統中，systemd 的存在並不能保證已安裝單獨的解析器軟體包。在修改任何 DNS 檔案之前，請檢查軟體包和單元：

dpkg-query -W -f='${Status}\n' systemd-resolved
systemctl status systemd-resolved --no-pager

如果軟體包已安裝但服務處於非活動狀態，請啟動服務並使其在下次啟動時生效：

sudo systemctl enable --now systemd-resolved
systemctl is-active systemd-resolved

最後一條命令應該會報告結果active。如果設備運作失敗，請檢查其實際的錯誤訊息，而不是重複重新啟動它：

journalctl -u systemd-resolved -b --no-pager -n 60

如果缺少該軟體包，請sudo apt install systemd-resolved在擁有可用的軟體包倉庫存取權限後再進行安裝。安裝此軟體包會變更控制權限/etc/resolv.conf，因此請先檢查任何 NetworkManager、VPN 或靜態 DNS 設定。 Debian 在其Bookworm 升級說明中記錄了此軟體包變更。

Debian 終端機顯示 systemctl status systemd-resolved，活動狀態為：active（正在運作）。 — 服務狀態顯示會說明在哪裡可以找到已載入的單元、活動狀態和啟動訊息。

3. 僅當解析器連結錯誤時才修復它

標準systemd-resolved存根監聽於127.0.0.53。其推薦的兼容性文件為/run/systemd/resolve/stub-resolv.conf，可從連結/etc/resolv.conf。請先檢查您目前的模式：

ls -l /etc/resolv.conf
readlink -f /etc/resolv.conf
cat /etc/resolv.conf
resolvectl status

連結到來源/run/systemd/resolve/resolv.conf也是支援的模式，但使用此模式的程式會直接聯絡上游 DNS 伺服器，而不是本機存根 DNS 伺服器。不要因為連結方式不同就斷定它已失效。 Debian systemd-resolved 服務手冊解釋了支援的模式。

如果您有意使用本機存根，且服務正在運行，存根監聽器已啟用，但現有連結/etc/resolv.conf缺失、懸空或指向過時的解析器，請恢復建議連結。首先備份現有文件或連結；如果文件不存在，則跳過複製步驟：

sudo cp -a /etc/resolv.conf /etc/resolv.conf.dns-backup
sudo ln -sfn /run/systemd/resolve/stub-resolv.conf /etc/resolv.conf
cat /etc/resolv.conf

請勿在其他服務有意管理 DNS 的主機上執行此替換操作/etc/resolv.conf。本機nameserver 127.0.0.53條目還需要一個正常運作的存根監聽器；僅寫入該位址並不能建立 DNS 服務。在遠端電腦上，在編輯解析器設定之前，請保留第二種存取方式。

Debian 終端機顯示 /etc/resolv.conf 符號連結指向 systemd-resolved stub-resolv.conf 檔案。 — 當 Debian 被刻意配置為使用本機 systemd 解析的存根時，符號連結檢查會顯示預期的目標。

4. 修復缺少或無法存取的上游 DNS 伺服器

當resolvectl status顯示沒有適當的上游 DNS 伺服器，或已設定的伺服器無法存取時，請修復該指派的來源。動態 DNS 設定可能來自 DHCP、NetworkManager、systemd-networkd 或 VPN。請驗證哪個介面承載預設路由，以及哪個 DNS 伺服器屬於該介面。

對於允許公共 DNS 的網絡，要進行簡短的診斷測試，請將已知的公共解析器指派給該介面。請將 `<interface>` 替換ens33為實際介面ip -br address：

sudo resolvectl dns ens33 1.1.1.1 1.0.0.1
resolvectl query debian.org

Cloudflare已將這兩個位址記錄為其公用 DNS 解析器位址。此resolvectl dns變更屬於執行時間配置；網路管理員可能會在連結重新連接後將其替換。如果現在尋找有效，請修復持久性 DNS 來源，而不是依賴此臨時命令。

使用 NetworkManager，您可以檢查目前連線nmcli connection show --active並調整其 DNS 設定或 DHCP 行為。使用 systemd-networkd，您可以將所需的DNS=設定寫入相應的設定.network文件，並在安全的時間重新載入或重新配置網路。請參閱Debian systemd.network 手冊和Debian NetworkManager 設定手冊。重新連接受管介面可能會中斷 SSH 會話。

對於內部名稱，建議優先使用組織或 VPN 的 DNS 伺服器。不能假定公共解析器能夠解析私人區域；強制所有查詢都使用公共解析器可能會破壞分離式 DNS 或洩漏內部主機名稱。全域 DNSDNS=配置resolved.conf可以與連結級 DNS 並行運行，而不是自動取代它；請參閱Bookworm resolved.conf 手冊。

5. 清除快取並確認兩條查找路徑均正常運作

更正服務、解析器連結或上游配置後，清除快取的答案並重新測試：

sudo resolvectl flush-caches
resolvectl query debian.org
getent ahosts debian.org
resolvectl status

如果網路重新連線後，resolvectl query返回位址、回傳位址記錄和目標 DNS 伺服器仍然可見，則修復有效。這兩個命令測試的是不同的接口，因此不要將其中一個成功視為所有應用程式都已修復的證明。 Debian resolvectl 手冊中記錄了查詢、狀態和快取刷新的相關內容。getent ahosts

Debian 終端機顯示 resolvectl 查詢 debian.org 和 getent ahosts debian.org 回傳位址記錄，然後執行 flush-caches。 — 最終的終端視圖顯示了兩個檢查，這兩個檢查在 DNS 配置修復後都應該返回地址記錄。

如果resolvectl query成功但getent仍失敗，請檢查grep "^hosts:" /etc/nsswitch.conf並確認查找路徑中是否dns已安裝合適的resolveNSS 模組。如果兩種方法都仍然失敗，請檢查解析器日誌和防火牆對 DNS 流量的任何限制，然後使用實際的企業、路由器或提供者的 DNS 位址進行測試。一次單獨的成功查找是不夠的：請在重新連接和重新啟動後重複檢查，以驗證修復是否持久有效。