修正 Debian 12 中 systemd-resolved 導致的「DNS 解析暫時失敗」問題

此錯誤Temporary failure in name resolution表示應用程式無法將主機名稱（例如 `example.com`）轉換deb.debian.org為 IP 位址。在 Debian 12 (Bookworm) 上，這並不表示 DNS 伺服器systemd-resolved本身有問題。 Debian 12 預設不安裝systemd-resolvedDNS 解析器，DNS 可能由 NetworkManager、ifupdown、DHCP 工具或其他解析器直接管理。如果您已啟用 DNS 解析器systemd-resolved，最快的解決方法是在變更設定之前確定哪一層發生故障。

本實用參考資料重點在於使用或計劃使用 systemd-resolved 的系統systemd-resolved。 Debian 的 Bookworm 軟體包文件指出，安裝systemd-resolvedsystemd-resolved會切換/etc/resolv.conf到 systemd-resolved 管理模式。該服務本身在本地提供 DNS 存根127.0.0.53，並接受來自全域配置、鏈路級網路配置、DHCPresolvectl和網路管理服務的上游 DNS 資訊。請參閱Debian systemd-resolved 軟體包頁面和Debian systemd-resolved 手冊。

快速診斷清單

1. 確認問題出在 DNS 上，而不是網路連線。

首先測試主機名，然後測試 IP 位址：

getent ahosts debian.org
ping -c 3 debian.org
ping -c 3 1.1.1.1

如果主機名稱查找失敗而直接 IP 測試成功，則 DNS 網域很可能是故障域。如果兩者都失敗，請先檢查介面、路由、網關、VLAN、Wi-Fi 關聯、防火牆或上游網路。 DNS 變更無法修復缺少的預設路由。

為了進行更精確的路由檢查，也可以運行：

ip address
ip route

通常情況下，您應該在預期的介面上配置位址並設定預設路由。介面的具體名稱可能是 `<interface_name>`、`<interface_name>` enp1s0、ens160` eth0<interface_name>` 或其他名稱。

2. 檢查 systemd-resolved 是否正在使用中

不要因為機器使用 systemd 就想當然地認為它存在。請同時檢查軟體包和服務：

dpkg -s systemd-resolved 2>/dev/null | grep '^Status'
systemctl status systemd-resolved --no-pager
resolvectl status

如果缺少該軟體包，且您的電腦已有其他可用的 DNS 管理方案，安裝該軟體包systemd-resolved並不能自動解決問題。如果系統應該使用該方案，並且該服務已安裝但已停止，請啟用並啟動它：

sudo systemctl enable --now systemd-resolved

如果該命令失敗，請在重複重新啟動服務之前檢查日誌：

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

3. 替換之前請檢查 /etc/resolv.conf 檔案。

最常見的設定錯誤是將 視為/etc/resolv.conf一個獨立的檔案。實際上systemd-resolved， 可以以多種支援的模式運作。上游建議的存根模式連結/etc/resolv.conf到/run/systemd/resolve/stub-resolv.conf，該模式將傳統的 DNS 用戶端指向127.0.0.53。另一種有效的模式連結到/run/systemd/resolve/resolv.conf，該模式直接暴露已知的上游伺服器，但會遺失 systemd-resolved 為直接讀取該檔案的應用程式提供的逐鏈路 DNS 路由。

ls -l /etc/resolv.conf
cat /etc/resolv.conf

普通文件並非一定錯誤。 NetworkManager 或其他解析器管理員可能有意持有該檔案。但是，如果此主機設計為使用 systemd-resolved 存根模式，則過期的普通檔案、懸空的符號連結或指向無法存取的名稱伺服器的檔案都可能導致查找失敗。

當需要使用存根模式時，請恢復建議的存根連結。

sudo ln -sf /run/systemd/resolve/stub-resolv.conf /etc/resolv.conf
sudo systemctl restart systemd-resolved
ls -l /etc/resolv.conf
cat /etc/resolv.conf

nameserver 127.0.0.53在存根文件中看到相關資訊是預期行為。這是本機監聽器，而非上游 DNS 伺服器。使用此方法resolvectl status可以查看 systemd-resolved 實際會聯繫哪些上游伺服器。此差異在systemd-resolved Bookworm 手冊中有詳細說明。

4. 檢查 systemd-resolved 是否有可用的上游 DNS 伺服器

跑步：

resolvectl status

重點關注承載預設路由的連結。正常的設定通常會顯示該連結的一個或多個 DNS 伺服器，或適當的全域 DNS 伺服器。如果沒有可用的 DNS 伺服器，僅僅修復符號連結是無濟於事的：本地存根沒有可以發送查詢的有效目標。

您可以直接測試解析器：

resolvectl query debian.org

Debian resolvectl 手冊文件記錄status了用於檢查和故障排除的每個連結的 DNS 命令query。flush-caches

5. 如果 NetworkManager 擁有該接口，請在連線設定檔中修復 DNS 設定。

在桌上型系統和許多通用 Debian 系統中，NetworkManager 可能會向 systemd-resolved 提供每個連結的 DNS 資訊。首先，確定目前活動的設定檔和 DNS 值：

nmcli connection show --active
nmcli device show

如果 DHCP 提供的 DNS 伺服器有問題，請變更 NetworkManager 設定文件，而不是/etc/resolv.conf每次重新啟動後都進行編輯。例如，如果您的網路策略允許使用公共解析器：

sudo nmcli connection modify "Wired connection 1"   ipv4.ignore-auto-dns yes   ipv4.dns "1.1.1.1 9.9.9.9"
sudo nmcli connection up "Wired connection 1"

請將設定檔名稱和 DNS 伺服器替換為適合您網路的值。企業網路、VPN、Active Directory 環境和分離式 DNS 設定通常需要內部解析器；公用 DNS 可能會破壞私人主機名稱。 NetworkManager 的官方配置參考文件介紹了其與 . 的整合systemd-resolved。

6. 如果 systemd-networkd 擁有該接口，則為每個連結配置 DNS

對於使用 DHCP 的伺服器systemd-networkd，請將 DNS 設定放在. 目錄.network下的對應檔案中/etc/systemd/network/。一個簡單的基於 DHCP 的範例是：

[Match]
Name=ens160

[Network]
DHCP=yes
DNS=1.1.1.1
DNS=9.9.9.9
Domains=~.

[DHCPv4]
UseDNS=no

UseDNS=no當您需要專門忽略 DHCP 提供的 DNS 伺服器時，此設定至關重要。否則，系統預設使用 DHCP DNS。Domains=~.此設定僅用於 DNS 根的路由，因此適用於不符合更特定路由網域的查詢。請勿在有意使用分離式 DNS 的多宿主或 VPN 系統中盲目新增此設定。

sudo systemctl restart systemd-networkd
resolvectl status ens160

Debian Bookworm systemd.network 手冊中記錄了DNS=、Domains=和 DHCP的行為。UseDNS=

7. 僅當您確實需要係統範圍的 DNS 時才使用全域 resolved.conf 檔案。

/etc/systemd/resolved.conf或者，也可以透過新增一個設定項/etc/systemd/resolved.conf.d/來定義系統 DNS 伺服器。這對於主機範圍的策略很有用，但對於使用 VPN、多個介面或私人 DNS 區域的機器來說，其精確度不如逐鏈路配置。

本地替換通常比編輯廠商風格的主文件更簡潔：

sudo mkdir -p /etc/systemd/resolved.conf.d
sudoedit /etc/systemd/resolved.conf.d/10-dns.conf

例子：

[Resolve]
DNS=1.1.1.1 9.9.9.9

然後應用它：

sudo systemctl restart systemd-resolved
resolvectl status

Debian resolved.conf 手冊解釋說，DNS=它提供了系統 DNS 伺服器，並且管理員的 drop-in 配置/etc/systemd/resolved.conf.d/優先於優先順序較低的配置。

8. 僅在修復底層配置後才清除緩存

快取過期可能會使故障排除更加複雜，但清除快取並不能取代修復無法存取的上游伺服器或損壞的連結配置。在進行實際配置變更後，您可以運行：

sudo resolvectl flush-caches
resolvectl query debian.org

Systemd 本身的文件指出，當網路配置發生變更時，快取通常會自動刷新，因此反覆手動刷新不應該是你的主要解決方法。

9. 如果故障持續存在，請閱讀解析器日誌。

如果resolvectl status看起來合理但查詢仍然逾時，請檢查啟動本機解析器日誌：

journalctl -u systemd-resolved -b --no-pager
journalctl -u systemd-resolved -b --no-pager | tail -n 50

請留意是否有重複出現的伺服器逾時、備用伺服器變更、DNSSEC 驗證失敗或指示協定功能降低的訊息。解析器可能正常運行，但其配置的上游伺服器可能由於防火牆、VPN、路由策略或網路存取控制清單 (ACL) 而無法存取。

10. 驗證完整的查找路徑

不要在一次resolvectl查詢成功後就停止。也要驗證正常應用程式使用的路徑：

getent ahosts debian.org
resolvectl query debian.org
sudo apt update

getent這樣做很有用，因為 glibc 主機名稱查找會遵循 `.`hosts:中的行/etc/nsswitch.conf。如果resolvectl query查找成功但getent失敗，請檢查 NSS 設定。 Debian 的nss-resolve 手冊描述了這個可選libnss-resolve模組以及建議的配置順序，該順序可以將 glibc 主機名稱查找路由到 systemd-resolved，同時保留回退機制。

常見症狀及最可能需要檢查的部位

建議維修順序

1. 確認基本網路連線和預設路由存在。
2. 確認它是否systemd-resolved確實用於管理此主機上的 DNS。
3. 檢查systemd-resolved服務狀態和resolvectl status。
4. /etc/resolv.conf在更改之前，請檢查所有權和符號連結模式。
5. 如果目標是存根模式，請恢復stub-resolv.conf連結。
6. 修復上游 DNS 的實際擁有者：NetworkManager、systemd-networkd、DHCP、VPN 或全域解析配置。
7. 只有在配置更正後才能清除快取。
8. 與resolvectl、getent和最初失敗的應用程式進行核實。

關鍵原則在於所有權：/etc/resolv.confsystemd-resolved 和網路管理器同屬一個解析器鏈。持久性修復方案會在擁有該解析器的層級上變更 DNS，而不是重複取代最終產生的檔案。