Windows 時間不準怎麼辦|W32Time 同步與時區排錯

文章屬性:疑難排除
適用系統:Windows 11(Windows 10 的設定路徑與指令相同)
難易度 / 耗時:⭐⭐⭐(方法四涉及登錄檔) / 約 20 分鐘
核心結論:沒加入網域的 Windows 原廠是 604800 秒(7 天)才校時一次,服務又屬觸發啟動、對完就停;差距超過 54,000 秒(15 小時)更會被原廠上限擋住而不修正。
適用對象:時鐘每天慢幾十秒、按「立即同步」跳錯誤、或雙系統差 8 小時的人

📌 快速答案

一句話答案:Windows 時間不準最常見的原因是時區設錯或自動同步關閉,其次是非網域電腦原廠七天才向 NTP 校時一次;先修時區,再用 w32tm /resync 強制同步,仍漂移就縮短輪詢間隔。

🧰 開始前的準備

系統需求:Windows 11 或 Windows 10 任一版本(本文不涉及特定 build 的新功能)
權限需求:設定 App 的時區開關需要系統管理員;w32tm 官方明載需要本機 Administrators 群組成員才能執行
需要工具:設定 App、以系統管理員身分執行的命令提示字元、事件檢視器;方法四另需登錄檔編輯程式
網路需求:對外 UDP 123 要通。W32Time 遵循 NTP 規範,所有校時都走 UDP 123,而且內建 NTP 用戶端只能用 UDP 123 當來源埠——公司防火牆或某些路由器擋掉這個埠,按幾次「立即同步」都不會有反應
預計耗時:約 20 分鐘(方法一到方法三約 10 分鐘)

🔍 症狀描述與錯誤訊息

「Windows 時間不準」在實務上其實是好幾種完全不同的故障穿同一件衣服,先分清楚你是哪一種,後面的方法才不會亂試一通。

最常見的是慢性漂移:時鐘每天慢個幾十秒到一兩分鐘,不至於誤事,但拖幾週就會差到讓 LINE 訊息順序錯亂、網銀 OTP 對不上。第二種是跳大差:關機或休眠幾天後開機,時間直接差好幾分鐘甚至好幾小時。第三種是時區型:時間的「分」是對的,但整整差 8 小時或差 1 小時——這通常不是時鐘壞掉,是時區或日光節約時間設定跑掉。第四種是同步失敗:你在設定裡按了「立即同步」,畫面卻回一句錯誤。

按「立即同步」失敗時,常見的字樣像這樣:

上次成功的時間同步:(空白或很久以前的日期)
Windows 在與 time.windows.com 同步時發生錯誤。

在命令提示字元跑 w32tm /resync 時,則可能看到:

電腦沒有重新同步,因為沒有可用的時間資料。
這台電腦目前不是可靠的時間來源。

如果時間差距非常大,你甚至會先撞到憑證錯誤:瀏覽器把每個 HTTPS 網站都判成「您的連線不是私人連線」,因為憑證的有效期間是用系統時間比對的。同理,在公司網域環境裡時間差超過 5 分鐘就會直接登入失敗——Kerberos 的「電腦時鐘同步處理的最大容錯」原則預設值就是 5 分鐘。

🔎 問題根因

先講結論:絕大多數家用機的時間問題,根因不是硬體,是「校時頻率」與「校時上限」這兩個你從來沒看過的原廠預設值。

Windows 的時間有三個獨立的來源在互相拉扯,任何一個歪掉,你看到的時鐘就會不準:

時區與日光節約時間設錯——系統內部存的是 UTC,你螢幕上看到的是「UTC + 時區位移」。時區錯了,內部時間再準,顯示出來也是錯的。這就是「差整整 8 小時」的典型成因。
自動同步的頻率遠比你想的低——Windows Time(W32Time)在未加入網域的電腦上,登錄檔 SpecialPollInterval 的原廠預設值是 604800 秒,也就是七天一次。微軟官方支援文件(KB 3205089)自己也承認:這個值太大時,NTP 用戶端不會照你期待的間隔同步,官方建議的變通做法就是把它改成 3600 秒(1 小時)。
服務根本沒在跑——W32Time 在工作群組電腦上被設計成「觸發啟動(Trigger-Start)」服務,微軟官方說明得很白:即使你把啟動類型從「手動」改成「自動」,它在時間同步工作成功之後仍然會自動停止。所以中間那幾天的漂移,沒有任何人在管。
差太多反而修不動——這是最反直覺的一條。MaxPosPhaseCorrection 與 MaxNegPhaseCorrection 規定服務願意做的最大正/負時間修正量,獨立用戶端與伺服器的預設值是 54,000 秒(15 小時);超過這個量,服務會只寫一筆事件記錄、不修正時間。相對地,網域成員的預設值是 0xFFFFFFFF(永遠修正)。也就是說,一台放了半年沒開、CMOS 電池又快沒電的家用機,時間差到超過 15 小時,它會愈同步愈不動。
硬體時鐘(RTC)老化或沒電——主機板上的即時時鐘靠 CMOS 電池維持,電池電壓不足時,關機期間的計時會嚴重失準,開機後你看到的就是「每次開機時間都重置或大幅落後」。

🔬 底層機制:這個時間到底是誰在報?

一句話:你看到的時鐘,是「硬體時鐘 → 系統時鐘 → NTP 校正 → 時區換算」四段接力的最後一棒,每一段都有自己的失效模式。

開機時,Windows 從主機板的 RTC 讀進一個起始時間,之後就交給系統時鐘用計時中斷自己累加。這顆軟體時鐘一定會漂,所以才需要 W32Time 定期用 NTP 向外部時間伺服器對答案。對完之後,系統內部維持的是 UTC,再套上你選的時區與日光節約規則,才變成工作列右下角那串數字。

W32Time 修正的方式也不是「直接跳」。官方文件寫得很清楚:服務會先比較目前偏移量與 MaxAllowedPhaseOffset——偏移量小於等於它,就靠調整時鐘速率慢慢把時間拉回來;大於它,才直接把時鐘設過去。而這個門檻在網域成員是 300 秒、在獨立用戶端只有 1 秒。這解釋了一個常見現象:你手動把時間調對之後,過一陣子它又「自己慢慢飄回去」——那其實是速率修正在作用。

下面這張表是同一份官方文件裡,獨立電腦與網域成員的預設值對照,差異之大值得記下來:

設定值	獨立(工作群組)電腦	網域成員
SpecialPollInterval	登錄檔原廠 604,800 秒(7 天)	同左(此值不因網域而異;套用「設定 Windows NTP 用戶端」原則時預設顯示 1,024 秒)
MaxPos/MaxNegPhaseCorrection	54,000 秒(15 小時)	0xFFFFFFFF(永遠修正)
MaxAllowedPhaseOffset	1 秒	300 秒
時間來源類型(Type)	NTP	NT5DS(走網域階層)

三點重點摘要:

家用機(工作群組)拿到的是一組為「偶爾對一次就好」設計的保守值,不是為了精準。
官方群組原則「設定 Windows NTP 用戶端」啟用後的 SpecialPollInterval 預設顯示為 1024,和登錄檔原廠的 604800 不是同一個數字;這個差異來自「原則有沒有被套用」,不是「有沒有加入網域」——這是很多人照網路教學開了 GPO 之後行為突然改變、卻搞不清楚為什麼的原因。
預設的時間伺服器是 time.windows.com,0x9,旗標 0x9 代表使用 SpecialPollInterval;若改成 0x8,就會改用 MinPollInterval 到 MaxPollInterval 之間的自動輪詢(工作群組預設分別是 1024 秒與 32768 秒)。

🛠️ 解決方案

⚠️ 執行前警語:方法一到方法三只動設定 App 與服務,可逆且低風險。方法四要改登錄檔,請先照該節指示匯出備份;登錄檔改錯值可能導致系統無法復原的錯誤,微軟官方在 W32Time 登錄檔參考頁面也明確警告「不要更改這些值」。改之前建議先建立系統還原點。
停止條件(符合任一,請先停手,不要往下做):①你不確定這台是不是加入公司網域或 Microsoft Entra 管理的裝置;②尚未匯出登錄檔備份、也沒有還原點;③這是公司/學校管控的設備而你沒有 IT 授權(網域電腦的時間由網域階層統一管,自行改設定會造成登入問題);④指令輸出與本文描述明顯不同。

方法一:先把設定 App 的三個開關校正(先做這個)

大部分「差 8 小時」「差 1 小時」的案例,在這一步就結束了。

開啟 設定 → 時間與語言 → 日期和時間(可在執行視窗輸入 ms-settings:dateandtime 直接跳過去)。
確認 自動設定時間 為「開啟」。
確認 自動設定時區 為「開啟」;若要手動指定,先把它關掉,再從下拉選單選 (UTC+08:00) 台北。
自動設定時區開啟時,日光節約時間會自動處理;關閉時,才會出現「自動調整日光節約時間」這個獨立開關。台灣目前不實施日光節約時間,這個開關開著也不影響。
按一下「立即同步」。

「自動設定時區」是灰色的、按不動怎麼辦? 這幾乎都是兩個原因:一是定位服務被關掉——自動時區靠 Microsoft 定位服務推算你在哪個時區,定位關了它就沒依據;二是你不是系統管理員——微軟官方文件明載這是設計如此,「自動設定時區」是套用到整台機器所有使用者的系統層級設定,非系統管理員看不到或呈現灰色。

系統管理員可用的官方作法有三條:以系統管理員身分執行登錄檔編輯程式,把 HKLM\SYSTEM\CurrentControlSet\Services\tzautoupdate 底下的 Start 設為 3(啟用)或 4(停用);同時把 HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\CapabilityAccessManager\ConsentStore\location 的 Value 設為 Allow。若定位是被群組原則關掉的,手動改登錄檔會被原則蓋回去,要先到 電腦設定 → 系統管理範本 → Windows 元件 → 位置和感應器 → Windows 位置提供者 → 關閉 Windows 位置提供者,把它設為「未設定」。動登錄檔前,建議先看過Windows 11 登錄檔備份與還原完整教學把還原路徑準備好。

方法二:用 w32tm 診斷,不要憑感覺

開啟以系統管理員身分執行的命令提示字元,依序跑:

w32tm /query /status /verbose

重點看三行:Source(目前時間來源是誰)、Last Successful Sync Time(上次成功同步是什麼時候)、Poll Interval(輪詢間隔,括號內是秒數)。如果上次成功同步是好幾天前,你已經抓到兇手了。

w32tm /query /configuration

這會列出實際生效的設定值與它們的來源(Local、Policy 或 Default),是判斷「到底是登錄檔還是群組原則在作主」最快的方法。順帶一提,官方特別提醒:在網域成員上若用群組原則的「設定 Windows NTP 用戶端」設了 NtpServer,W32Time 不會去用登錄檔那個值。

w32tm /resync /rediscover

/rediscover 會重新偵測網路設定、重新探索時間來源後再同步,比單純 /resync 有用。

想看自己到底差多少、還是網路延遲造成的假象,用 stripchart 直接量:

w32tm /stripchart /computer:time.stdtime.gov.tw /samples:5 /dataonly

這裡用的是國家時間與頻率標準實驗室(經濟部標準檢驗局)提供的免費 NTP 服務。time.stdtime.gov.tw 是 Stratum 1 等級、直接同步自台灣國家標準時間,對台灣使用者而言比預設的 time.windows.com 少繞一大圈。要把它設成慣用來源:

w32tm /config /manualpeerlist:"time.stdtime.gov.tw,0x8" /syncfromflags:manual

w32tm /config /update

別只填兩台。 自 Windows Server 2016 起同步演算法向 RFC 規範對齊,官方建議要指定多個對等點時準備三台以上;只有兩台時,必須用 UseAsFallbackOnly(0x2)旗標把其中一台降權,否則演算法會判不出誰對。實務上可以用 time.stdtime.gov.tw、tock.stdtime.gov.tw、watch.stdtime.gov.tw 這三台湊齊。

方法三:讓 W32Time 真的活著

這是最多人漏掉的一步。前面提過,工作群組電腦的 W32Time 是觸發啟動服務,同步成功就會自己停。微軟官方針對這個症狀給了兩條路:

路線 A(建議,改動最小)——用觸發事件把服務綁在網路上線/離線:

sc triggerinfo w32time start/networkon stop/networkoff

路線 B——改成常駐,但兩件事必須一起做:①到「服務」把 Windows Time 的啟動類型改成 自動(延遲啟動);②同時到「工作排程器程式庫 → Microsoft → Windows → Time Synchronization」把 SynchronizeTime 工作停用。官方在延遲啟動那一項底下明載必須一併停用該排程工作——只做第一件事,服務仍會在同步工作完成後被帶著停掉,你會以為修好了其實沒有。

改完之後重啟服務:

net stop w32time

net start w32time

方法四:縮短輪詢間隔 SpecialPollInterval(⭐⭐⭐ 登錄檔)

只有在方法一到三都做完、時間仍然會慢慢漂的機器才需要做這一步。

先備份。用系統管理員身分的命令提示字元匯出整個 W32Time 機碼:

reg export "HKLM\SYSTEM\CurrentControlSet\Services\W32Time" C:\w32time.reg

確認 C:\w32time.reg 檔案存在且大小不是 0,再往下做。

執行 regedit,展開到:

HKLM\SYSTEM\CurrentControlSet\Services\W32Time\TimeProviders\NtpClient

找到 SpecialPollInterval(DWORD),原廠值 604800。
官方 KB 3205089 給的建議是:把它改成一個落在 MinPollInterval(0xA,即 1024 秒)與 MaxPollInterval(0xF,即 32768 秒)之間的值,範例值為 3600 秒(1 小時)。以十進位輸入 3600。
套用設定(不需重開機):

w32tm /config /update

官方同一篇文件還提供第二條路:不動 SpecialPollInterval,改到 HKLM\SYSTEM\CurrentControlSet\Services\W32Time\Parameters,把 NtpServer 的旗標從 time.windows.com,0x9 改成 time.windows.com,0x8,讓服務改用內建的自動輪詢調整——時間走得準時它會自己拉長間隔,走不準就縮短。要少動一個數字的人建議走這條。

方法五:硬體與雙系統

如果做完前四步,每次關機再開機時間就大幅落後,那問題在硬體層:主機板的 CMOS 電池(多半是 CR2032)電壓不足,關機期間 RTC 就走不準,常伴隨 BIOS 設定跑掉、開機日期回到出廠日。想確認的話,進 BIOS 看它自己顯示的時間對不對——不熟入口的話可以參考BIOS / UEFI 是什麼?如何進入設定畫面。

雙系統(Windows + Linux)差 8 小時是另一個經典:Linux 預設把硬體時鐘當 UTC,Windows 預設當本地時間,兩邊互相蓋來蓋去。網路上流傳的解法是在 HKLM\SYSTEM\CurrentControlSet\Control\TimeZoneInformation 新增 RealTimeIsUniversal(DWORD=1)讓 Windows 也把 CMOS 當 UTC。站長不建議走這條:微軟官方支援文件記載過啟用該機碼後「無法手動變更系統時間、系統時間會被 CMOS 設定蓋回」的問題,微軟 AskDS 團隊的技術文章更直接把它列為未受支援的登錄機碼,並描述了它在日光節約時間切換時造成伺服器無回應的案例。比較安全的方向是反過來——讓 Linux 那邊改用本地時間,而不是叫 Windows 去用一個官方不支援的機碼。

至於虛擬機,時間偏移通常來自主機端的時間同步服務(w32tm /query /status 的 Source 會顯示成主機的整合服務),要調整請從虛擬化平台的設定下手,不是在客體 OS 裡硬改。

✅ 驗證修復結果

不要只看工作列上的數字對不對,那只能證明「這一秒對了」。依序確認:

重跑 w32tm /query /status,Last Successful Sync Time 應該是剛才,Source 應該是你設定的伺服器。
確認 Poll Interval 括號內的秒數已經變成你設定的值(例如 3600s)。
開啟事件檢視器 → Windows 記錄 → 系統,篩選來源 Time-Service。W32Time 預設會在切換時間來源時記錄事件(EventLogFlags 預設值 2 = 來源變更)。看到來源變更事件、沒有反覆的錯誤事件,代表狀態穩定。
隔天再看一次。慢性漂移的驗證本來就需要時間;隔 24 小時後 Last Successful Sync Time 若有更新,才算真的修好。

🔙 萬一翻車:回退步驟

情境一:改完之後時間反而更亂,或服務起不來。

用系統管理員身分的命令提示字元把備份匯回去,再重啟服務:

reg import C:\w32time.reg

net stop w32time

net start w32time

⚠️ 回退一律以你自己那份備份檔的原值為準,不要照抄任何文章(包含本文)寫出來的數字。 原廠預設值會因為 Windows 版本、是否加入網域、是否被群組原則接管而不同——同一個 SpecialPollInterval,獨立機是 604800、群組原則啟用時顯示 1024,你抄錯一個就不是「還原」,而是「改成另一種設定」。這就是為什麼第 4 節第一件事是叫你先 reg export。

情境二:登錄檔備份也還原不回來。

用系統還原點回到修改前的狀態(這也是前面要你先建還原點的原因)。

情境三:W32Time 服務整個壞掉、w32tm 指令回錯誤。

最後手段是把服務登錄資訊重建。/unregister 會移除 W32Time 的所有設定資訊,所以確定備份還在再做:

w32tm /unregister

w32tm /register

net start w32time

重建後所有自訂設定都會回到原廠值,需要重做方法二與方法四。若連這步都失敗,通常代表系統元件本身有損壞,可考慮走就地升級 In-place Repair Upgrade這類不清資料的修復路線。

💡 總結:預防再次發生

站長我在處理這類案子的時候,習慣先問一句「這台多久沒關機了?」——因為家用機的時間問題有很強的規律:天天開機、天天上網的機器很少出事,反而是那種放在櫃子裡一個月開一次的備用機、或整天休眠的筆電最容易歪。 原因就在前面那組預設值:七天輪詢一次,而你這台一週開機不到七天,它可能連一次校時機會都沒有。

三個預防動作,做完基本上就不用再管它:

把輪詢間隔調到 1 小時(方法四),讓漂移沒有累積空間。
時間伺服器指到台灣的 Stratum 1 來源,並準備三台以上,避免單點失效時整個同步鏈停擺。
把 CMOS 電池當耗材看待。桌機大約每 3 到 5 年會出現電池電壓不足的徵兆,一顆幾十塊錢,發現「每次開機時間都重置」就換掉,不要等到 BIOS 設定也跟著跑掉。

還有一個常被忽略的連動:時間不準會讓依賴時間戳的驗證機制連鎖出錯——HTTPS 憑證、TOTP 動態密碼、網域登入都算在內。如果你的機器同時出現時間異常和登入問題,先修時間再修登入,順序反過來會白忙一場。相關的登入類故障可參考Windows 顯示「PIN 無法使用」的排查。

❓ 常見問題

Q:我按了「立即同步」顯示成功,但過幾天又慢了,是不是主機板壞了?

不一定。先確認 w32tm /query /status 的 Poll Interval。工作群組電腦的 SpecialPollInterval 原廠是 604800 秒(7 天),同步成功只代表「這一次對了」,中間七天的漂移沒人管。先照方法四把間隔縮短再觀察;若連 CMOS 電池都換過還是每天差幾分鐘,才輪到懷疑硬體。

Q:時間差很多的時候,為什麼 w32tm /resync 反而沒反應?

因為有上限。獨立用戶端與伺服器的 MaxPosPhaseCorrection / MaxNegPhaseCorrection 預設值是 54,000 秒(15 小時),服務判斷需要的修正量超過這個值時,會只記錄一筆事件、不修正時間。先在設定 App 裡手動把時間拉到大致正確(差距縮小到幾分鐘內),再跑 w32tm /resync。

Q:公司電腦的時間不準,我可以照這篇改嗎?

不要。加入網域的電腦時間由網域階層統一供應(用戶端類型是 NT5DS),自行指定外部 NTP 伺服器會造成與網域控制站不一致;Kerberos 預設只容忍 5 分鐘誤差,弄歪了會直接登入失敗。請回報 IT。

Q:一定要用 time.windows.com 嗎?

不用。預設值是 time.windows.com,0x9,你可以換成任何可達的 NTP 伺服器。台灣使用者建議用國家時間與頻率標準實驗室的 time.stdtime.gov.tw 等主機,並依官方建議準備三台以上。

Q:修完之後又復發怎麼辦?

先跑 w32tm /query /configuration 看設定值的來源欄位。如果顯示 Policy,代表有群組原則在覆蓋你的登錄檔設定——官方明載群組原則定義的值會蓋掉 W32Time 登錄檔既有的值,這時候要去改原則而不是改登錄檔。公司管控的機器出現這種狀況,就是 IT 那邊的設定,自己改沒有用。

📎 參考資料來源

📖 第一級|廠商官方:

Windows Time service tools and settings — Microsoft Learn — 2026-07-26 查證
W32time settings fail when starting Windows Time Service(KB 3205089)— Microsoft Learn — 2026-07-26 查證
W32Time doesn’t start on a workgroup computer — Microsoft Learn — 2026-07-26 查證
Set time, date, and time zone settings in Windows — Microsoft Support — 2026-07-26 查證
Can’t set time zone automatically — Microsoft Learn — 2026-07-26 查證
Maximum tolerance for computer clock synchronization — Microsoft Learn — 2026-07-26 查證
You cannot change system time if RealTimeIsUniversal registry entry is enabled — Microsoft Support — 2026-07-26 查證
Unresponsive Servers due to DST and an unsupported registry key — Microsoft Learn(AskDS 封存) — 2026-07-26 查證
網路校時服務(NTP)— 國家時間與頻率標準實驗室 — 2026-07-26 查證
標準時間與 NTP 伺服器說明 — 國家時間與頻率標準實驗室 — 2026-07-26 查證

⚠️ 本文核心事實以第一級為準,全篇未使用第二級來源。文中「實務上」「站長我」段落為經驗性描述,官方文件未載明。

📅 本文查證戳記:2026-07-26 依據 Microsoft 官方文件與國家時間與頻率標準實驗室資料撰寫,未包含站長第一手實測數據。
微軟若調整 W32Time 的預設值或設定 App 的路徑,本文會同步更新;你若在自己的機器上量到不同的 Poll Interval,歡迎在留言區補上版本號一起對照。