雅寶社區 · 頂客論壇 (AHPAL.COM)

📊 軟體評測

DuckDNS 與 Cloudflare DDNS，動態 DNS 的更新延遲實測

發表時間：2026 年 11 月 14 日 | 更新日期：2026 年 11 月 14 日 | 編輯：雅寶社區編輯團隊

把這三段加起來，就是使用者真正感受到的「更新延遲」。接下來我們的實測，會盡量分別量測這幾個階段，而不是只給一個笼統的「幾分鐘」。

受測服務與測試環境說明

在進入數據之前，先說明這次受測的兩個服務，以及測試的環境與方法，讓後續的數字有意義、也能被重現或質疑。

DuckDNS 與 Cloudflare DDNS 的功能對比

DuckDNS 是一個專門為動態 DNS 設計的免費服務，提供 yourname.duckdns.org 這種子網域。它的更新方式非常簡單：只要對一個特定的 URL 送出 HTTP 請求，帶上你的 token 與 IP，就能更新記錄，不需要額外安裝軟體。它的定位很清楚，就是「給自架者用的 DDNS」，沒有多餘功能，但也因此在延遲與 TTL 的設計上相對單純。DuckDNS 的 TTL 通常固定得很短（約 60 秒），這對「快速生效」其實是加分的。

Cloudflare DDNS 嚴格來說不是一個「DDNS 服務」，而是「用 Cloudflare 的 DNS API 來實作 DDNS」。你自己在 Cloudflare 代管一個網域，然後用 API Token 去更新某筆 A 記錄。它的好處是你可以自由控制 TTL、可以用 Cloudflare 的 Proxy（橙色雲）隱藏真實 IP、可以搭配 CDN 與防火牆規則；缺點是設定門檻較高，而且要自己準備更新腳本或工具。Cloudflare 免費方案的 TTL 可以設到 Auto（自動，通常 300 秒）或手動指定（最低 60 秒，部分記錄類型有不同限制）。

下表整理兩者在 DDNS 相關面向的差異：

項目

DuckDNS

Cloudflare DDNS

網域形式

固定子網域 *.duckdns.org

自有網域，可自訂子網域

費用

免費

DNS 免費，需自備網域（年費）

更新方式

簡易 HTTP 請求

REST API（需 Token）

TTL 控制

固定偏短（約 60 秒）

可自訂（Auto 或 60 秒以上）

Proxy／CDN

可啟用橙色雲

適合對象

入門自架、快速上手

已有網域、需要進階控制

實測環境、工具與測量方法

這次測試的環境是一條家用光纖線路，搭配一台可刷 OpenWrt 的路由器，以及一台常駐的 Linux 小主機（Raspberry Pi 4）負責執行更新腳本與記錄時間戳。為了模擬 IP 變動，我們不使用「真的等 ISP 換 IP」這種不可控的方式，而是準備了兩種情境：

情境 A：手動觸發更新。直接呼叫 DuckDNS 與 Cloudflare 的更新 API，把記錄指向一組新的測試 IP，並在呼叫前後記錄時間。這種情境主要量測「推送延遲」與「權威 DNS 生效時間」。

情境 B：模擬更新器偵測。用腳本每 60 秒查詢一次外部 IP，當偵測到變動才觸發更新，藉此觀察「偵測間隔」對整體延遲的影響。我們也測試了 5 分鐘與 15 分鐘間隔，觀察平均延遲的變化。

至於「生效延遲」，我們用多個不同網段的遞迴解析器（包括 ISP 提供的 DNS、Google Public DNS、Cloudflare 1.1.1.1，以及一台本機快取 DNS）分別查詢，記錄每次查詢回傳的 IP 與時間，直到所有解析器都回傳新 IP 為止。這樣可以觀察到 TTL 對快取過期的實際影響。

需要先說明的是，這類測試會受到網路環境、ISP DNS 快取策略、服務商當下負載等因素影響，數字不會每次都一樣。因此以下數據是「多次測試的中位數與範圍」，用來呈現趨勢與量級，而不是絕對保證值。

實測結果：DuckDNS 的更新延遲表現

先看 DuckDNS。作為一個專為 DDNS 設計的服務，它的表現其實相當符合預期：簡單、直接、延遲主要來自偵測間隔與 DNS 快取，而不是服務商本身。

正常情況下的推送與生效時間

在手動觸發更新的情境下，從送出 HTTP 請求到 DuckDNS 回應成功，多數測試的中位數大約落在 0.3 到 0.8 秒之間，少數幾次因為網路抖動拉到 1.5 秒左右。也就是說，推送延遲本身幾乎可以忽略。真正花時間的是「生效」。

DuckDNS 的記錄 TTL 大約是 60 秒。我們在更新後立刻用不同解析器查詢，發現：

權威 DNS 幾乎立即回傳新 IP（幾秒內）。

沒有快取的解析器（第一次查詢）也馬上拿到新 IP。

已經快取舊記錄的解析器，則要等 TTL 到期，最長約 60 秒後才會更新。

換句話說，在最壞情況下，DuckDNS 從 API 更新成功到「全網都拿到新 IP」，大約是 60 秒上下。這個數字對多數自架應用來說已經相當夠用。若更新器是每 60 秒偵測一次 IP，那平均總延遲大約是 30 秒（偵測）＋ 1 秒（推送）＋ 30 秒（平均快取剩餘時間）≒ 1 分鐘左右；最壞情況則接近 2 分鐘。這樣的量級，對於遠端連線來說通常是可以接受的。

限流與異常情況下的延遲

DuckDNS 免費服務當然也有它的限制。測試中我們刻意在短時間內連續觸發多次更新，觀察它的反應。結果發現，短時間內過於頻繁的請求，有可能被暫時拒絕或回應較慢；在我們的做法裡，大約連續 10 次以上的密集更新後，開始出現回應時間拉長到數秒，甚至偶爾回傳錯誤。不過正常使用情境（IP 一天變動幾次）幾乎不會碰到這個問題。

另一個值得注意的是 DuckDNS 的可用性。作為免費服務，它偶爾會有維護或短暫中斷的情況。測試期間我們遇到過一次 API 回應變慢（約 10 秒以上），但沒有到完全無法更新的程度。若你的應用極度要求穩定，建議在更新腳本裡加入重試機制與失敗通知，例如更新失敗時透過 Telegram 或 Email 告警，避免 IP 變了卻沒更新成功而渾然不知。

整體來說，DuckDNS 的延遲組成很單純：偵測間隔 ＋ 約 1 秒推送 ＋ 最多 60 秒生效。它的 TTL 短，反而讓「生效」這一段不會拖太久，這是它作為 DDNS 專用服務的優勢。

實測結果：Cloudflare DDNS 的更新延遲表現

Cloudflare 這邊的變數就多了。它的 API 本身很快，但 TTL 可以自己設，還可以開 Proxy，這些都會影響實際感受到的延遲。

API 更新與 TTL 設定的影響

在手動觸發 Cloudflare API 更新的測試中，從送出 PATCH 請求到收到成功回應，中位數大約 0.2 到 0.6 秒，跟 DuckDNS 差不多，甚至略快一些。Cloudflare 的 API 反應相當穩定，測試期間沒有遇到明顯的限流問題（當然，這是在合理使用頻率下）。

真正拉開差距的是 TTL。當我們把 TTL 設為 Auto（實務上常見是 300 秒）時，已經快取舊記錄的解析器最長要等 5 分鐘才會更新。這段時間對「IP 剛變、急著連線」的使用者來說，體感上就差很多。若把 TTL 手動設為 60 秒，生效延遲就會縮短到跟 DuckDNS 接近的水準。

以下是我們在不同 TTL 設定下觀察到的「最壞生效延遲」：

TTL 設定

最壞生效延遲（已快取解析器）

備註

Auto（約 300 秒）

約 5 分鐘

預設值，對延遲敏感者不建議

120 秒

約 2 分鐘

折衷選擇

60 秒

約 1 分鐘

與 DuckDNS 相當

所以，如果你用 Cloudflare DDNS，卻沒有把 TTL 調短，那你的「更新延遲」很可能比 DuckDNS 還長，而且長很多。這一點是很多教學文章沒有特別強調的。Cloudflare 的彈性很強，但彈性也意味著預設值不一定適合 DDNS 情境，需要自己調整。

代理模式（橙色雲）對延遲的影響

Cloudflare 另一個容易讓人誤解的地方是 Proxy 模式。當你開啟橙色雲（Proxied），對外顯示的其實是 Cloudflare 的 IP，而不是你家的真實 IP。这时候「更新延遲」的意義會稍微不同：

因為外部使用者連到的是 Cloudflare 的邊緣節點，所以即使你家的 IP 變了、DNS 記錄還沒完全生效，使用者的連線其實是先打到 Cloudflare，再由 Cloudflare 回源到你家的新 IP。理論上，只要 Cloudflare 內部的記錄更新了，對外服務的中斷時間會比純 DNS 模式更短。但反過來說，如果你的服務是 SSH、遊戲伺服器、或非 HTTP 協定的應用，Proxy 模式可能根本不適用（Cloudflare 免費方案主要代理 HTTP/HTTPS 流量），这时候你還是得用 DNS only（灰色雲），那就回到前面 TTL 的討論。

我們的測試中，開啟 Proxy 後，HTTP 服務的「可連線時間」確實比 DNS only 模式更連續，因為邊緣節點會幫你吸收掉一部分 DNS 快取的延遲。但這只適用於網頁類服務，而且要注意 Cloudflare 的免費方案對非標準埠的支援有限。若你的用途是遠端桌面或 Minecraft 伺服器，還是建議用 DNS only，並把 TTL 調短。

延遲數據總整理與情境分析

把前面的觀察整理起來，我們可以用一個簡單的模型來估算整體更新延遲：

總延遲 ≒ 偵測間隔 ÷ 2（平均）＋ 推送時間 ＋ TTL（最壞）

以兩種常見設定為例：

設定情境

偵測間隔

推送

TTL

平均總延遲

最壞總延遲

DuckDNS ＋ 60 秒偵測

60 秒

約 1 秒

60 秒

約 1 分鐘

約 2 分鐘

Cloudflare ＋ 60 秒偵測 ＋ TTL 60 秒

60 秒

約 1 秒

60 秒

約 1 分鐘

約 2 分鐘

Cloudflare ＋ 5 分鐘偵測 ＋ TTL Auto

300 秒

約 1 秒

300 秒

約 5 分鐘

約 10 分鐘

從表中可以看出，真正決定延遲量級的往往不是服務商，而是你的偵測間隔與 TTL 設定。DuckDNS 因為 TTL 短、設定簡單，預設表現就不錯；Cloudflare 則需要你主動把 TTL 調短，否則預設的 Auto 會讓延遲明顯拉長。

不同情境下的選型建議

那麼，到底該選哪一個？這取決於你的使用情境：

如果你是入門自架、不想搞太多設定：DuckDNS 是比較省心的選擇。它免費、設定簡單、TTL 短，對多數家用情境已經足夠。你只要在路由器或 NAS 裡填入 token 與網域，設定好更新間隔（建議 1 到 5 分鐘），就能有不錯的體驗。缺點是網域是 duckdns.org 子網域，比較不好看，而且服務本身是免費的，長期穩定性無法保證。

如果你已經有網域、需要進階控制：Cloudflare DDNS 更適合。你可以用自己的網域、自由設定 TTL、搭配 Proxy 與防火牆規則，甚至用 Cloudflare Tunnel 完全免開埠。但請務必把 TTL 調到 60 秒（或至少 120 秒），並且確定更新腳本有正確處理 API Token 與錯誤重試。

如果你對延遲極度敏感（例如遠端桌面、即時通訊、遊戲伺服器）：兩者其實都可以，但關鍵在於「縮短偵測間隔」與「壓低 TTL」。更好的做法是讓更新器在網路介面重新連線時「主動觸發」更新，而不是被動輪詢。例如 OpenWrt 的 ddns-scripts 可以設定在 WAN 介面 up 時就執行更新，這樣偵測延遲可以接近零。再搭配 60 秒 TTL，整體延遲有機會壓到 1 分鐘以內。

成本、穩定性與可維護性

除了延遲，還有幾個現實面要考慮：

成本：DuckDNS 完全免費；Cloudflare DNS 免費，但你需要負擔網域年費（視後綴而定，大約幾百到一千多元台幣）。如果你的用途很單純，DuckDNS 的零成本很有吸引力；如果你本來就有網域，那 Cloudflare 幾乎沒有額外成本。

穩定性：Cloudflare 作為大型 CDN 與 DNS 提供商，基礎設施的穩定性與冗餘通常優於免費的 DuckDNS。如果你需要長期穩定運行，Cloudflare 會是比較安心的選擇。但 DuckDNS 也不是不堪用，對個人專案來說通常夠了。

可維護性：DuckDNS 的更新方式極簡，幾乎不會壞；Cloudflare 需要管理 API Token、注意權限設定，設定錯誤的風險較高。若你不想花時間 debug，DuckDNS 的簡單反而是優點。

結論與實務建議：如何把 DDNS 延遲壓到最低

總結這次實測，DuckDNS 與 Cloudflare DDNS 在「推送」這一段的表現都很不錯，真正的差異在於 TTL 與設定彈性。DuckDNS 靠著短 TTL 與簡單設定，預設就能有不錯的更新延遲；Cloudflare 則需要你主動調降 TTL，才能達到相近的水準，但換來的是更高的可控性與穩定性。

如果你問我「哪一個比較好」，我的答案會是：看你的需求，而不是看哪個品牌比較大。入門、預算零、不想設定，選 DuckDNS；已有網域、需要 Proxy 或進階控制，選 Cloudflare，但記得把 TTL 調短。

最後，無論你選哪一套，以下幾個實務建議都能幫你把更新延遲壓到最低：

一、把偵測間隔設短。如果路由器或 NAS 支援，設成 1 分鐘甚至更短；但要注意不要短到被服務商限流。若可以，優先使用「介面重新連線時觸發」的方式，取代固定輪詢。

二、TTL 設 60 秒。這是 DDNS 情境的甜蜜點，既能讓快取快速過期，又不會對 DNS 伺服器造成太大負擔。Cloudflare 使用者尤其要注意，別讓它停在 Auto。

三、加入失敗重試與告警。更新失敗是很常見的（網路瞬斷、API 暫時錯誤），腳本要有重試機制，並在連續失敗時通知你，避免「以為更新了、其實沒有」的悲劇。

四、考慮雙備援。如果你的服務真的很重要，可以同時設定 DuckDNS 與 Cloudflare 兩組記錄，讓應用程式 or 使用者有備用入口。這雖然不能降低單一服務的延遲，但能提高整體可用性。

動態 DNS 的更新延遲不是一個固定的數字，而是由「偵測、推送、生效」三段共同決定。與其糾結哪個服務「比較快」，不如先檢視自己的設定：偵測間隔多長？TTL 設多少？有沒有失敗告警？把這幾件事調好，多數情況下你都能把中斷時間壓在一到兩分鐘以內，對絕大多數自架應用來說，這已經是很夠用的水準了。

🏠 返回首頁