若要使用公用 NTP 伺服器列表，請依提供者篩選主機名稱、檢視每個提供者的閏秒處理方式、複製可見的 ntpd 風格設定行，並在依賴它們之前先從目標系統驗證連線可達性。一份整理良好的公用 NTP 伺服器列表會包含大多數讀者實際所需的那 11 個官方主機名稱：來自 NTP Pool Project 的輪替式 0、1、2 和 3.pool.ntp.org 名稱、來自 Google Public NTP 的 time.google.com 系列、來自 Cloudflare 的 time.cloudflare.com，以及來自 NIST 的 time.nist.gov 輪詢位址。每一列通常會記錄提供者、範疇、閏秒處理方式，以及一段簡短的運作註記，讓您能一目了然地比較各種策略。該列表會提供可立即複製的伺服器行，例如 server time.google.com iburst，但無法測試這些主機名稱是否真的從您的網路回應，因為一般網頁無法對連接埠 123 發送 UDP 封包。請將該列表視為一份起始設定，再依您的時間用戶端進行調整——無論是 ntpd、chrony、systemd-timesyncd、Windows Time，或是路由器上的設定頁面。
大多數讀者會接觸到公用 NTP 伺服器列表，是因為他們需要設定單一機器、小型辦公室網路或實驗室裝置，卻不想記住每一個區域性集區名稱。公用 NTP 伺服器列表正是為了該工作流程而存在：它將官方主機名稱集中於一處、讓您能依提供者或功能進行搜尋，並產生可貼入真實設定檔的乾淨設定片段。
公用 NTP 伺服器列表實際上包含哪些內容
該列表是一份以官方主機名稱（而非 IP 位址）為鍵的 11 列靜態參考資料。每一列僅記錄提供者已公開的資訊：範疇（全球或區域）、閏秒處理行為（無、smear 或可追溯至 UTC(NIST)），以及一段簡短的運作註記，例如「輪詢式主機名稱」或「請勿與非 smearing 伺服器混用」。由於條目是主機名稱而非 IP，底層位址可以輪替，而無須您端進行設定修改。
所列出的四家提供者涵蓋了絕大多數的公用 NTP 使用情境：
- NTP Pool Project — 由志工營運，提供 0.pool.ntp.org 至 3.pool.ntp.org 的輪替名稱，不採用 leap smear，建議以主機名稱而非固定 IP 來使用。
- Google Public NTP — time.google.com 加上四個編號子網域，啟用 leap smear，範疇為全球。
- Cloudflare Time Service — 透過 Cloudflare 的 anycast 網路提供 time.cloudflare.com，使用 leap indicator 而不進行 smearing。
- NIST Internet Time Service — time.nist.gov 輪詢位址，散佈 UTC(NIST)。
篩選不區分大小寫：輸入「google」會將列縮窄至 Google 條目；輸入「smear」則會列出所有記載 smearing 行為的提供者。複製動作會針對每個可見的主機名稱產生一行 ntpd 風格的伺服器行，並已附加 iburst 關鍵字，以便在守護程序啟動後能快速完成首次同步。
提供者策略與閏秒處理
閏秒是公用 NTP 伺服器列表無法當作「隨便挑四個伺服器就能用」的最大原因。閏秒是插入 UTC 中的一個額外秒數，用以讓民用時間與地球自轉保持對齊，而不同提供者對它的反應並不相同。下表摘要說明每個提供者的做法，方便您挑選一個一致的策略。
| 提供者 | 主機名稱樣式 | 閏秒處理 | 運作註記 |
|---|---|---|---|
| NTP Pool Project | 0/1/2/3.pool.ntp.org | 使用 leap indicator（不 smear） | 請使用主機名稱；志工會變更底層 IP |
| Google Public NTP | time.google.com 與 time1–4.google.com | Leap smear | 請勿與非 smearing 伺服器混用 |
| Cloudflare Time Service | time.cloudflare.com | 使用 leap indicator（不 smear） | Anycast，全球 |
| NIST Internet Time Service | time.nist.gov | 散佈 UTC(NIST) | 請使用輪詢式主機名稱，而非固定 IP |
正如 Google 公開的 NTP 說明文件 所反覆強調的實務原則：您絕對不能在同集區中混用 smeared 與非 smeared 伺服器。如果您的設定同時指向 time.google.com 與 pool.ntp.org，在閏秒事件發生期間，您的用戶端可能會短暫與自己產生分歧，導致行為無法預測。請挑選一個一致的來源策略，並遵循該提供者所公布的使用條款。
挑選主機名稱並複製設定行
使用公用 NTP 伺服器列表最快速的流程是：將列縮窄至單一提供者、複製可見的條目，再將它們轉換為您的時間用戶端所預期的格式。下列步驟假設您已知道自己要的是 smearing 來源或 leap-indicator 來源。
- 開啟公用 NTP 伺服器列表，並在搜尋欄位中輸入提供者名稱（例如「google」或「nist」），以縮窄表格範圍。您也可以輸入「smear」之類的功能，或特定的主機名稱片段。
- 閱讀每個剩餘列的簡短運作註記。確認閏秒處理欄位與您設定中的其他來源所採用的方式一致。
- 若您打算混用來源，請切換回未篩選的檢視，檢視全部 11 列的閏秒處理欄位，以免不小心混用了 smeared 與非 smeared 伺服器。
- 點擊工具中的複製動作。複製出來的文字會是每個可見主機名稱一行 ntpd 風格的伺服器行，並已附加 iburst 關鍵字，以加快首次同步的速度。
- 將這些行貼到暫存緩衝區，再轉換為您的時間用戶端所適用的語法（請參閱下一節）。請勿將 ntpd 格式的行原封不動地貼到 chrony 或 Windows 設定中。
- 在目標系統本機上執行真正的連線測試，例如 ntptime、chronyc tracking，或廠商的診斷指令，因為該列表無法從您的瀏覽器執行此測試。
將設定行調整為 ntpd、chrony 與 systemd-timesyncd 可用格式
複製出來的行採用 ntpd 的語法，其中每個伺服器以獨立一行宣告，並可搭配 iburst、prefer 或 noselect 等選用關鍵字。然而，大多數讀者執行的並非 ntpd。chrony 雖然也使用 server 行，但它期望 iburst 關鍵字出現在行尾，並寫入 /etc/chrony.conf 或 /etc/chrony/chrony.conf。systemd-timesyncd 會讀取 /etc/systemd/timesyncd.conf，並接受一行以空格分隔主機名稱的 NTP= 行；它不支援逐行的關鍵字（例如 iburst）。
Windows 10 與 11 用戶端內建的 Windows Time 是透過「設定 > 時間與語言 > 日期與時間 > 其他時鐘 > 網際網路時間 > 變更設定」進行設定，且一次只能接受一個伺服器主機名稱。網路設備與防火牆通常在管理介面中只提供單一「主要 NTP 伺服器」欄位，因此您可能必須挑選最重要的主機名稱，而不是列出四個。這些目標都無法在未經編輯的情況下直接接受列表所產生的原始 ntpd 行；該工具的輸出僅作為起點，並非萬用設定。
從目標系統驗證連線可達性
在某個網路中可以解析並回應的主機名稱，在另一個網路中可能被封鎖、限流或變慢。防火牆、強制式入口網頁、DNS 政策，以及提供者的維護作業，都會影響服務品質。您用來閱讀此列表的瀏覽器無法執行真正的 NTP 檢查，因為一般網頁無法對連接埠 123（NTP 使用的連接埠）發送 UDP 封包。請在您打算同步的實際機器上執行連線測試。
在執行 ntpd 的 Linux 主機上，ntpq -p 會列出設定的伺服器，並顯示一個 reachability 欄位，該欄位在幾輪成功後會上升到 377。在 chrony 上，chronyc sources -v 會回報類似的欄位。在 Windows 上，w32tm /query /status 會顯示來源名稱與最近一次成功同步的時間。若某個伺服器始終未出現或一直停在零，請檢查防火牆上對外的 UDP 123，並確認 DNS 能將該主機名稱解析為合理的位址。若您需要一條用於該對外路徑的防禦性規則，關於將通用連接埠列表用於防火牆允許清單的相關指南會說明這種作法的實際限制。
何時應跳過公用列表、改用廠商時間來源
對於錯誤時間可能影響驗證、記錄、財務、安全或事件回應的基礎架構，請勿依賴單一公用主機名稱。請使用作業系統或設備廠商所支援的設定、多重受監控的來源，以及經驗證或本地端的時間架構，例如由 GPS 校時的 stratum-1 伺服器。Active Directory 網域預期成員電腦遵循網域階層；Kubernetes 叢集通常預期 chrony 指向本地 NTP Pod；同時充當 VPN 端點的路由器，則常需要專屬的硬體時間來源以供憑證驗證。
公用 NTP 伺服器列表適用於長尾場景——例如開發者的筆電、家庭網路上的 Raspberry Pi、印表機、需要基本時戳記錄的交換器，或只需要接近真實時間的實驗室裝置。針對這類用途，請從公用 NTP 伺服器列表複製列、依您的用戶端調整格式，並驗證一次連線可達性。能通過那次驗證的設定，就是您該保留下來的設定。