Ubuntu DNS 解析問題：確認鏈路、設定來源及臨時測試結果

Ubuntu DNS 無法解析時，先確認網絡連結和 IP 路徑仍然正常：只有路徑正常、主機名稱卻解析失敗或傳回錯誤結果時，才屬於 Ubuntu DNS 解析問題。接着用 resolvectl status 和 resolvectl query 查看使用中的連結實際採用哪部 DNS 伺服器和哪個路由域名，並在測試任何一項臨時改動之前記下現時的設定擁有者和各項數值。清除臨時改動後，讓設定擁有者重新套用設定，再把結果與已保存的狀態比較。

關鍵要點

• Wi-Fi 或以太網連結、IP 路由、互聯網連通和 DNS 解析是不同層面。
• Ubuntu 可以按連結選擇 DNS；全域列出的伺服器未必負責處理某項查詢。［1］
• /etc/resolv.conf 可能由 systemd-resolved 或其他網絡元件管理。不要盲目覆寫或刪除這個連結。［2］
• 公共解析器只能作臨時對照，並不是通用的永久修復方法。

如果多個層面都可能出錯，先參考一般的裝置故障排查指南。現有的DNS 伺服器無回應概覽較廣泛地解釋 DNS；本文集中處理 Ubuntu 現時的解析器（resolver）狀態。

Ubuntu DNS 解析問題應如何逐步排查？

步驟 1：記錄故障狀態

更改任何設定之前，先保存失敗的主機名稱、完整錯誤、時間、使用中的介面，以及現時的 resolvectl status 輸出。

步驟 2：證明連結和路由正常

確認預期的 Wi-Fi 或以太網連結已啟用，而失敗的路徑有路由。如果連結或路由不存在，就留在該分支排查，不要更改 DNS。

步驟 3：比較 IP 與名稱的行為

把一項獲准進行的 IP 層檢查與一次系統主機名稱查詢比較。只有 IP 路徑正常，而名稱解析失敗或傳回錯誤結果時，才把 DNS 視為首要假設。

步驟 4：找出獲選用的解析路徑

對確切的名稱執行 resolvectl status 和 resolvectl query。確認獲選用的連結、伺服器、路由域名，以及故障屬全域性抑或只限於某個域名。

步驟 5：找出設定擁有者

檢查 /etc/resolv.conf 和使用中的網絡堆疊。記下該數值由 NetworkManager、Netplan、DHCP、VPN、systemd-resolved 還是政策提供。

步驟 6：測試一個臨時的每連結數值

如果設定擁有者和環境許可，臨時更改一個每連結（per-link）DNS 數值，重複同一查詢，然後對該連結執行 resolvectl revert。

步驟 7：讓擁有者重新套用設定

讓設定擁有者重新套用其設定，並把新狀態與已保存的輸出比較。不要把 revert 描述為還原已保存的快照。

步驟 8：在所屬層面修復並驗證

只在所屬的設定層面作持久修復，並預備還原途徑；之後重複最初的查詢，確認內部名稱和公共名稱都按預期運作。

每一步的結果決定下一個分支。如果 IP 檢查和名稱檢查都失敗，用公共解析器作對照也無法證明是單純的 DNS 故障。如果只有一個分流 DNS（split DNS）名稱失敗，更換所有解析器可能會破壞仍然正常的路由。如果臨時伺服器測試成功，你得到的是一次有用的對照，而不是准許你留下一個無人管理的覆寫設定。

如何證明故障確實在 DNS？

寫下失敗的主機名稱、完整錯誤、時間、網絡介面，以及同一請求在另一部裝置或另一個網絡上是否正常。檢查連結和路由，不要以為「已連接」圖示就證明能上網：

ip -brief link
ip route

然後，把一個你獲准測試的 IP 層目標，與同一服務使用的主機名稱比較。IP 路徑成功而名稱查詢失敗，才支持 DNS 假設。如果兩者都失敗，應改為調查路由器、登入頁面（captive portal）、本地路由、防火牆或上游連線。全網故障可參考路由器已連接但無法上網的排查樹。

不要只用瀏覽器內一個有快取的分頁來測試。瀏覽器可能使用自己的加密 DNS 設定、快取、代理或安全網絡功能，所以亦要比較一次系統解析器查詢。

resolvectl status 會顯示甚麼？

執行：

resolvectl status
resolvectl query example.com

在本機可安全披露的情況下，把 example.com 換成實際失敗的主機名稱。status 會顯示全域及每條連結的 DNS 伺服器、搜尋域名或僅路由域名、協議和使用中介面的狀態。query 會報告傳回的位址，通常亦會顯示涉及的連結和協議。resolvectl 說明文件亦提供統計和重設快取的操作，但重設快取應以證據為依據，不能取代診斷。

重點查看：

• 預期的 Wi-Fi、以太網、VPN 或隧道連結是否正在使用；
• 哪條連結擁有預設 DNS 路由，或最相符的路由域名；
• DNS 伺服器來自 DHCP、受管理網絡、VPN 還是手動設定；
• 是否只有一個域名失敗，特別是內部的分流 DNS 名稱；
• 重新連接同一條連結後，結果有否改變。

按連結路由代表輸出中的兩部伺服器不一定可以互換。公司域名可能刻意經 VPN 連結處理，而公共名稱則經家居連線處理。

誰在管理 DNS 設定？

檢查解析器檔案，而不是直接編輯它：

ls -l /etc/resolv.conf
cat /etc/resolv.conf
systemctl is-active systemd-resolved

systemd-resolved 說明文件描述了 /etc/resolv.conf 的幾種受支援模式，包括指向本機 stub 或所產生解析器清單的符號連結，以及與由其他元件管理的檔案配合運作。當 DHCP、NetworkManager、Netplan、VPN 或管理政策更新連結時，所產生的檔案可能隨之改變。

找出這部電腦上的實際擁有者。NetworkManager 設定檔、Netplan 設定、伺服器網絡工具和機構政策各有不同的持久設定路徑。不要照搬另一個 Ubuntu 版本的檔案路徑，當作通用做法。如果裝置受管理，更改 DNS 或 VPN 設定檔前先詢問管理員。

如何進行可還原的 Ubuntu DNS 測試？

先保存相關的 resolvectl status 輸出，並確認介面名稱。如果使用中的每連結狀態由 systemd-resolved 管理，管理員可以在該連結上臨時設定一部測試伺服器：

sudo resolvectl dns interface-name resolver-address
resolvectl query example.com
sudo resolvectl revert interface-name

請使用適合你網絡的實際數值。revert 指令會移除臨時覆寫，並把該連結的所有 DNS 設定重設為預設；它不會重播已保存的原設定。還原後，讓實際的設定擁有者重新套用其設定（只有重新連接是擁有者支援的方式時才重新連接），再把 resolvectl status 與測試前保存的輸出比較。在改動之前、期間和之後執行同一查詢。測試期間成功，表示原本的伺服器或其路由需要調查；但不能證明測試伺服器就是正確的永久選擇。

不要同時更改 DNS 並停用 VPN、代理、防火牆和 IPv6。多項改動會破壞對照。在需要內部名稱、過濾、家長控制或機構政策的網絡上，不要永久硬編碼公共 DNS 解析器。

如何進行持久修復？

在擁有該數值的層面修復：

• DNS 由 DHCP 提供、而所有客戶端都收到錯誤數值時，修正路由器或 DHCP 伺服器；
• 由 NetworkManager 管理的連線，使用該設定檔支援的設定，並有意識地重新連接；
• 由 Netplan 管理的伺服器，使用該 Ubuntu 版本支援的格式（schema），驗證改動，並保留主控台存取；
• VPN 或受管理裝置，修正 VPN 設定檔或聯絡其管理員；
• 只有某個權威域名失敗時，聯絡該域名或服務的擁有者，而不是更換每部客戶端的解析器。

套用持久改動前，記下原有設定並預備還原途徑。之後只透過所屬工具重新連接或套用，再重複 resolvectl status 和最初的查詢。

如果只在 apt update 時出現 DNS 錯誤呢？

保留確切的軟件庫主機名稱和錯誤。如果 resolvectl query 對該主機名稱失敗，就繼續留在 DNS 分支。如果能夠解析，但 APT 報告簽署、Release 檔案、TLS、軟件庫或相依套件錯誤，DNS 就不是主要診斷方向，請繼續參考APT 錯誤與相依套件修復指南。

總結

把故障定為 DNS 之前，先證明連結和 IP 連通。用 resolvectl 讀取全域及每連結狀態，找出由哪個元件管理這些數值，並且每次只改一個變數。清除臨時覆寫，讓擁有者重新套用設定；任何持久修復都應在 NetworkManager、Netplan、DHCP、VPN 或政策中進行，而不是盲目取代 /etc/resolv.conf。

常見問題

為甚麼 IP 位址可以連接，主機名稱卻失敗？

這種情況可能表示名稱解析失敗，因為 IP 路由毋須把名稱轉換成位址也能運作。用 resolvectl query 確認，並排除應用程式本身的代理或快取。

為甚麼會顯示多部 DNS 伺服器？

Ubuntu 可能從多條連結取得伺服器。路由域名和預設 DNS 路由決定由哪條連結處理查詢，在 VPN 分流 DNS 情況下尤其如此。

應該直接編輯 /etc/resolv.conf 嗎？

在弄清其擁有者之前，通常不應該。它可能是受管理的符號連結或所產生的檔案，直接編輯可能被覆寫，或破壞受支援的解析器模式。

重新啟動 systemd-resolved 一定能解決問題嗎？

不一定。重新啟動或可清除臨時狀態，但無法糾正錯誤的 DHCP 數值、失效的上游伺服器、錯誤的路由域名或受管理的 VPN 政策。

應該刪除 /etc/resolv.conf 符號連結嗎？

不應該。先確認它有文件記載的模式和設定擁有者。刪除它可能令應用程式與本機 stub 或所產生的伺服器清單斷開。

可以永久使用公共 DNS 伺服器嗎？

只有在考慮過內部域名、私隱、過濾、政策和可靠性之後才可以。一次短暫的對照不足以支持永久改動。

Ubuntu Server 的 DNS 無法運作，應如何處理？

在 Ubuntu Server 上，持久的 DNS 設定通常由 Netplan 管理，寫在介面 nameservers 鍵下的 addresses 和可選的 search 中。請修改所屬的 Netplan 檔案，或產生該檔案的 cloud-init 設定，而不是 /etc/resolv.conf；然後用 sudo netplan try 套用改動：如果你沒有在逾時前確認，它會自動還原，預設逾時為 120 秒。保留主控台存取，確認被拒絕的改動確實已還原，再重複 resolvectl status 和最初的查詢。

如何撤銷臨時的 resolvectl dns 測試？

對同一條連結執行 sudo resolvectl revert interface-name。它會清除臨時覆寫，並把該連結的 DNS 設定重設為預設；它不會還原已保存的設定。讓設定擁有者重新套用設定，再把 resolvectl status 與測試前保存的輸出比較。

VPN 連線有沒有改變 Ubuntu 的 DNS 選擇？

如果某個名稱只在連接 VPN 後才失敗，就在連接前後就同一名稱比較獲選用的連結、DNS 伺服器和路由域名。VPN 設定檔可能提供每連結 DNS 或僅路由域名，所以只影響內部名稱的故障，可能反映的是分流 DNS 路由，而不是公共解析器壞了。比較時保持實體網絡不變，並遵從網絡擁有人的政策。［1］［2］

如果被測連線涉及 AethoVPN，應把連線狀態連同 resolvectl status 及原有查詢結果記錄下來。必須按實際觀察判斷這套設定有沒有影響 DNS，不能單憑品牌名稱認定設定擁有者。錯誤 DHCP 值或持久的 NetworkManager/Netplan 設定仍須在來源處修復；清除臨時覆寫後，亦要確認內部名稱仍可解析。

---

免責聲明：resolver 擁有者和持久網絡設定會隨 Ubuntu 版本、安裝方式、VPN 與組織政策改變。修改前請保存原值與 console 存取。

來源：

1. Ubuntu Manpage Repository — resolvectl(1) — https://manpages.ubuntu.com/manpages/noble/man1/resolvectl.1.html
2. Ubuntu Manpage Repository — systemd-resolved(8) — https://manpages.ubuntu.com/manpages/noble/man8/systemd-resolved.8.html

Sources checked 2026 年 10 月 4 日。

---

延伸閱讀：

• 裝置故障排查指南
• 如何修復 DNS 伺服器無回應
• 路由器已連接但無法上網
• APT 更新失敗的修復步驟