1 127.0.0.53：systemd-resolved 的 stub 在做什麼
在近年的 Ubuntu、Fedora、Arch 與多數 systemd 發行版中，使用者常見 /etc/resolv.conf 內只剩一行：nameserver 127.0.0.53。這並非「程式寫錯」，而是 systemd-resolved 在環路網路上提供的 stub resolver：傳統 C 函式庫（glibc 的 getaddrinfo）與許多程式，預設只會把 明文 DNS（UDP／TCP 53） 丟到此位址。stub 自己再視設定把查詢轉發到 ISP、VPN、路由器或 DHCP 推過來的真正上游伺服器。
當您在 Mihomo／Clash Verge Rev 這類使用者端 Linux 上啟 TUN 模式時，核心通常會：a) 建立虛擬介面並改 路由，讓規則內的流量走代理鏈路；外加 b) 用 nftables／iptables 或 Mihomo 內建的 hijack 規則，嘗試攔 對外發往 53 埠 的查詢，改交到 Mihomo 內建的 DNS 處理（與規則、FakeIP／redir-host、DoH／DoT 對接）。矛盾點在於：許多程式 並沒有 把查詢送向「對外」，而是 127.0.0.53:53。hijack 規則未涵蓋此路徑時，請求照常進入 systemd-resolved，於外觀上就像「我已經開 TUN、為什麼 dig 仍顯示走 resolved」——其實兩線 並行，容易導致您以為規則沒套用，或開始懷疑節點壞掉。
與站內 Chrome／Edge 安全 DNS、Android 私人 DNS 等主題類似：重點在「解析入口要統一到哪裡」。Linux 桌面上，這個入口常綁在 127.0.0.53。iOS／Android／瀏覽器 那套並無法照搬；您需要的是與發行版的 解析堆疊 對齊。若尚未安裝核心，可先讀 Linux 安裝 Mihomo 與 systemd 入門教學 再打開 TUN，本文則視為進階排障。
2 症狀：什麼情況下該懷疑「stub 卡住」而非節點
下列任一組合都值得把stub納入檢查清單，而不是先換伺服器：（甲） TUN／代理開啟後，resolvectl query或dig顯示回應仍經過local或127.0.0.53，而同網環境換成純紅襪／環境變數代理時行為截然不同。（乙） 規則應將某國內 CDN 判為直連卻異常繞國外，追查後發現問題出在前置解析結果早被 resolved 決定。（丙） 啟用 FakeIP／enhanced-mode後，程式仍對真實 IP 發起對外問詢——與iptables優先級、環路規則有關，常伴隨對stub的並行請求。（丁） 伺服器上使用 TUN／透明代理結合 Docker：/etc/resolv.conf掛載或dhcpcd復寫錯開，造成環路問詢或逾時。
iptables -t nat -nvL或 nft 規則列舉裡看得到 DNS 劫持、但journalctl仍爆出大量對上游的環路請求時，先查 resolved 較省時間。Clash Meta 連線／DNS 日誌一文可協助把「規則沒打到」與「解析進錯門」拆開來看。3 診斷：resolvectl、resolv.conf與劫持鏈
在動任何發行版的預設前，請先備份並記下結果。第一段看 統一視角：resolvectl status（部份舊環境對應 systemd-resolve --status）。留意 環路（lo） 上的 DNS／是否仍有 127.0.0.53、全域與 個別網路介面 各自的綁定。第二段看 resolv.conf 到底是不是 符號連結、指向 /run/systemd/resolve/stub-resolv.conf 還是非 stub 的那份；不同路徑代表 Docker、netplan 與發行套件差異。readlink -f /etc/resolv.conf 可一次釐清。
resolvectl status
ls -la /etc/resolv.conf
readlink -f /etc/resolv.conf
第三段對照 Mihomo：Mihomo 日誌 是否在您開 TUN／hijack 後仍對環路 127.0.0.53 大量轉發，或對上游 ISP 發重複請求。strace -e poll -p $(pidof YOUR_APP) 對進階除錯有幫助，但多數人用 對照時間戳 與規則表即可。Verge Rev 的 TUN 教學 協助確認用戶端是否已將自動路由／堆疊模式對齊，避免把症狀全怪在發行版。
4 兩條並行不收斂時的主線策略
實務上常收斂到二選一（或可折衷）。策略 A： 讓 systemd-resolved 不再霸占 127.0.0.53 的 stub 埠，並用 Docker／GUI 相容 的 /etc/resolv.conf 對外暴露真實上游或由 DHCP／NetworkManager 管理；再配合 Mihomo dns.listen 與劫持，讓規則看得見的流量 先入核心。策略 B： 保留 stub，但在 netfilter 輸出鏈 上把對 127.0.0.53 的 UDP／TCP 53 轉發到 Mihomo DNS listener（實際寫法因 iptables／nft／核心版本而異）；使程式打到 stub 的封包仍能 被接到 Mihomo。請勿在未理解副作用時 停用整個 systemd-resolved 並硬寫 nameserver 8.8.8.8 進靜態檔——許多發行版的 dhcpcd／GUI 會在下次連線覆寫，且您會失去 DNSSEC／私網伺服器發現等附帶機制。
5 策略 A：關 DNSStubListener 與對齊 resolv.conf
Debian／Ubuntu／Fedora 系族常見作法是新增 drop-in 置入檔：
sudo mkdir -p /etc/systemd/resolved.conf.d
sudo tee /etc/systemd/resolved.conf.d/no-stub.conf <<'EOF'
[Resolve]
DNSStubListener=no
EOF
sudo ln -sf /run/systemd/resolve/resolv.conf /etc/resolv.conf
sudo systemctl restart systemd-resolved
注意：符號連結必須與發行套件文件一致；部份衍生版仍會建議在「非 Docker、非 Mihomo hijack」時保留 stub-resolv.conf。調整後請再跑上一節的 resolvectl status 確認 stub listener 已關。無 GUI 的伺服器上，請同步檢查 Docker 是否掛載了舊的 /etc/resolv.conf 快照：Compose／run 若在容器建立時固定了 nameserver，主機側改動不會自動推進已存在的容器網命名空間。
/etc/systemd/resolved.conf.d/no-stub.conf、改回適當 symlink、再執行 systemctl restart systemd-resolved 通常即可回復；保留備份可避免緊張時失手。6 策略 B：Mihomo dns 與 tun 要和宿主解析同時規劃
許多YAML會把 dns.listen 設在 127.0.0.1:1053 並搭配加密上游；問題不在埠號數字而在 hijack 是否真的覆蓋走 stub 的那一條路徑。tun.auto-route、tun.dns-hijack 等選項須與發行版的 iptables／nft backend（legacy 或 nft）、以及您是否用 cgroup／eBPF 分流對齊。建議將日誌等級暫調高，對照連線時間線，再配合站內 DNS 防洩漏 一文檢視 fallback 是否在未斷區網時就對 ISP 發出多餘明文查詢。
下列片段僅示範tun.dns-hijack語法風格，實際鍵名與預設值請對照您安裝的 Mihomo／Meta 文件：
dns:
enable: true
listen: "127.0.0.1:1053"
enhanced-mode: fake-ip
tun:
enable: true
stack: system
auto-route: true
auto-detect-interface: true
dns-hijack:
- any:53
若日誌顯示對 127.0.0.53 的流量未被 hijack 接管，就代表應回頭檢視 netfilter 規則或改採前述策略 A。
7 NetworkManager、DHCP 與復寫 resolv.conf 的連動
桌面常見：GNOME／KDE 設定與 nmcli 在您切換有線／Wi‑Fi／VPN時，會把介面綁定的 DNS 交給 systemd-resolved。dhcpcd 在部份 ARM 迷你主機會直接寫死 /etc/resolv.conf，若與您改的 symlink 競爭便出現「調好又覆寫」。實務順序：確認 /etc/NetworkManager/NetworkManager.conf 的 [main] 裡 dns=systemd-resolved 等預設是否合理；關 stub 後執行重連網路或 nmcli networking off && sudo nmcli networking on 讓 DHCP 重新送租。企業 VPN 若推送專用 DNS（GlobalProtect、OpenVPN dhcp-option 類設定），可能表現成「stub 關了但仍只解析內網」——此時應與 IT 確認 split-tunnel，並避免與 Mihomo tun exclude 介面清單自相矛盾。
8 FakeIP、IPv6 與「像環路」的症狀
enhanced-mode: fake-ip 期間，規則決策依賴 Mihomo 對查詢的假位址回應。systemd-resolved 若在背景仍對同一主機名向 ISP 問第二輪，會在測試頁上被誤判為「DNS 外洩」；其實可能只是雙解析路徑並存。收斂作法仍是上兩節將 stub 關掉或對 127.0.0.53 對齊 netfilter／Mihomo 劫持。IPv6 在部份網路會額外發 AAAA 或走 Router Advertisement 的 RDNSS；若 Mihomo 組態關閉 ipv6 但系統仍偏 IPv6-first，可能留下「偶發逾時」的假性節點故障。建議在對照實驗時先以 -4 或暫關介面 IPv6 做二分，再決定要全面關閉 IPv6 還是為 dhcp6／ra 加例外。
getaddrinfo」。9 常見問題
- 改完還是
127.0.0.53：先sudo systemctl restart systemd-resolved，再看readlink -f /etc/resolv.conf是否仍指到 stub；必要時檢查 resolvconf、docker 掛載或其他守護行程是否定期覆寫。 - hijack 似乎沒作用：
iptables -t nat -S與nft list ruleset對照 Mihomo 開 TUN 前後差異；確認沒有其他套件在更高優先級插鏈。 - WSL2 或雙系統特殊嗎：基底是虛擬網路／轉發規則的另一層；可讀站內 WSL2 與 Clash 規劃，但核心仍要釐清宿主與子系統各自誰握有
/etc/resolv.conf。 - 關 stub 後公司內網名稱失效：多半是 split-DNS 只靠 resolved 轉發；改以 VPN 或 systemd 的 網域繫結方式補回，而不是強行把全機指到單一公開 DNS。
10 總結
systemd-resolved 的 stub resolver 127.0.0.53 是現代 Linux 的預設組態，與 Mihomo TUN／DNS 劫持並存時，若沒把「誰先看到 53 埠查詢」說清楚，就會出現解析繞路、像環路或多路徑並行等困擾。請依序：resolvectl 與 resolv.conf 真實鏈結 → 選擇關 DNSStubListener 或補齊對 stub 的劫持 → 重連 NetworkManager／VPN → 用日誌對照一次。相較來回換節點，這條路線通常更快讓規則／FakeIP／防洩漏發揮設計初衷。
Clash 家族在 Linux 上可依需求選圖形使用者端或 systemd 常駐核心；相較零散論壇片段，從本站下載頁取得與教學對齊的版本，能省下大量「介面選項與核心行為對不起來」的試錯時間。若您剛完成主機端服務化，也別忘了把本文與安裝 systemd 指南一併標記書籤。
