開啟 3 天免費試用
註冊即可免費體驗全部高級功能。
*只限新用戶；每位用戶只可獲得一次試用。
時鐘偏差何時導致 REALITY 認證失敗？時間窗口與同步證據檢查
Ryan Foster
2026年9月12日· 更新於 2026年9月13日· 8 分鐘讀完
伺服器啟用非零 maxTimeDiff 後，如果 REALITY 加密的客戶端時間戳落在允許窗口之外，時鐘偏差便會令身份驗證失敗，伺服器不會把交換接受為已授權 REALITY 握手。這個答案有明確條件：maxTimeDiff 為 0 時，現行實作停用時間差檢查，因此時鐘偏差不會在這項關卡造成失敗。
完整 VPN 指南說明隧道跨越的層次。本文只分離 REALITY 的一個授權條件：客戶端時間、伺服器時間與設定窗口，不把所有證書或握手錯誤歸因於時鐘。
關鍵要點
- REALITY 客戶端攜帶經加密、可由授權伺服器評估的時間戳。
- 非零
maxTimeDiff規定兩端時間可接受的最大絕對差值。maxTimeDiff: 0會停用現行實作的時間比較，而非建立零毫秒窗口。- NTP 狀態、畫面顯示時間與程式實際使用的時間並非同一證據。
- 校準時鐘不能修復錯誤公鑰、short ID、伺服器名稱、目標或版本不兼容。
時間在 REALITY 身份驗證的哪個位置？
REALITY 改造面向 TLS 的交換，讓授權客戶端證明掌握設定參數，並對未授權流量採取不同處理；REALITY 官方 README概述了這項設計。［3］ 客戶端建立的認證材料包含時間，伺服器驗證交換後恢復客戶端時間戳。Project X 把 maxTimeDiff 定義為可選的最大時間差，單位是毫秒。［1］
實作條件很清楚：MaxTimeDiff == 0，或伺服器目前時間與 ClientTime 的絕對差不超過 MaxTimeDiff 時，授權才可繼續。［2］ 時間只是多個條件之一，並非完整身份驗證。
| 設定與觀察 | 時間關卡結果 | 不能證明甚麼 |
|---|---|---|
maxTimeDiff: 0 | 跳過時間差檢查 | 其他憑證正確 |
| 非零且差值在窗口內 | 時間條件通過 | 完整握手成功 |
| 非零且差值在窗口外 | 此條件拒絕 REALITY 授權 | 網絡故意封鎖 |
| 校時後仍失敗 | 時間可能不再是原因 | 目標、密鑰或版本有效 |
接受窗口如何運作？
可把伺服器時間視為對稱窗口中心。伺服器時間是 12:00:00、最大差值為 30 秒時，客戶端時間戳在前後足夠接近即可通過；較遠則不能。程式比較絕對時長，因此客戶端時鐘快或慢都會有影響。
圖例：1 是客戶端時間戳；2 是伺服器目前時間；3 是已設定的非零 maxTimeDiff 窗口；4 是時間在窗口內的認證分支；5 是窗口外轉入非 REALITY 或回落處理。maxTimeDiff: 0 不會令第 3 項變成零闊度窗口，而是完全不執行檢查。
單位很重要。設定文件描述的是毫秒。若按「秒」的理解複製數值，得到的窗口可能與營運者的原意相差一千倍。因此，應在實際運行的伺服器版本中核對設定序列化和時長解析方式，而不是按控制台上的標籤推斷。
比較亦發生在處理過程中的某個具體時刻。相對於設定得較寬鬆的窗口，普通網絡延遲通常微不足道；但極窄的值會令延遲、排程或過載變得相關。最穩妥的營運取值應來自有文件記錄的威脅模型和實測的整體時鐘健康狀況，而不是憑猜測。
為何 maxTimeDiff: 0 是關鍵例外？
不少設定用零表示「一點也不允許」，REALITY 在此把零當成「不執行檢查」的標記。現行源碼先判斷 MaxTimeDiff == 0。［2］ 因此零值不會只因兩端時間相差很大而拒絕客戶端。
若服務實際載入零，校時仍有系統價值，但不能解釋這個已停用條件的狀態變化；應繼續檢查公鑰、short ID、名稱、版本、路由及目標行為。
這亦會改變保安方面的措辭。不要聲稱 REALITY 總是要求時鐘同步。準確的說法是：當營運者啟用非零的 maxTimeDiff 時，這項授權檢查需要同步的時鐘。將來的實作可能改變，因此結論要綁定到正在運行的版本及其官方源碼。
應否把值設為零來恢復服務？
不應把停用安全相關的新鮮度條件當作盲目排障。先確認兩端時間、實際載入設定及故障階段。任何臨時更改都須獲授權、有還原條件，並證明服務已載入新值。
過窄與無限制並非僅有選擇。營運者可選擇覆蓋預期同步誤差及處理延遲的有界值，在受管理伺服器間保持一致，並記錄為認證政策。
實際環境為何會有時鐘偏差？
裝置可能沒有可靠硬件時鐘、長時間休眠後恢復、無法使用時間服務，或已關閉同步。虛擬機及容器一般繼承主機時間，但主機休眠、虛擬化故障或受限時間來源仍會影響程式所見時間。
時區常被誤判為原因。時區只改變同一時刻的顯示方式，正確設定下不改變 Unix time。裝置顯示的本地小時錯了，可能只是時區問題；而如果時鐘和時區都被手動調整過，裝置即使顯示正確的本地小時，其底層時刻仍可能是錯的。
較大的校正可能是一次跳變，亦可能是逐步調整。同步服務可能在仍在收斂時已顯示「運作中」。流動裝置可能暫時依賴網絡提供的時間，隔離的伺服器可能使用私人的時間層級。請記錄兩端實際的偏移量，而不只是同步服務程序的名稱。
網絡延遲本身可超出窗口嗎？
它可能有影響，尤其在窗口窄得不切實際時，但普通的來回延遲並不等於時鐘偏差。伺服器以它此刻的時間，評估客戶端較早產生的時間戳。排隊、重傳、暫停和程序停頓都會增加這個時間戳的「年齡」。
一個在手提電腦休眠前已產生、恢復後才傳送的封包，看來可能比即時網絡延遲舊得多。除了路由，亦要診斷裝置的生命週期。在兩端系統都穩定後反覆進行全新握手，比重播一次過時的嘗試更能提供證據。
時間檢查失敗會有甚麼表現？
客戶端可能已連到遠端地址，卻未能通過 REALITY 專有授權。視設定與實作而定，它可以看到普通目標行為、一般 TLS 錯誤或連線終止，不應預期伺服器披露「你的時鐘錯誤」。
錯誤公鑰、不支援的 short ID、serverName 不一致、指紋不兼容、版本差異與目標故障都可有相同外觀。REALITY 連線排查提供完整階段樹；本文只處理時間分支。
授權部署的伺服器日誌可能顯示失敗條件，但等級與字眼會改變。不要記錄可重用憑證或完整客戶端識別；保留版本、設定身份、UTC 時間、量度偏移及首個失敗階段。
如何排查 REALITY 時鐘偏差？
第一步是讀取服務實際生效設定，確認 maxTimeDiff 是否非零。只看已編輯檔案不足夠：服務可能未重新載入、選用了另一設定，或容器掛載不同。保留不含密鑰的設定身份。
第二步以 UTC 量度客戶端、伺服器相對可信時間來源的偏移，並讓仍在校時的裝置穩定。之後建立全新握手，不要重用休眠前或快取材料。
第三步固定設定、端點、地址族、網絡及軟件版本，在時間進入窗口後重試。由失敗轉成功支持時鐘假設，但不能排除其他同時改變的間歇條件。
第四步是在失敗持續時停止擴大時鐘理論，轉查公鑰、short ID、serverName、伺服器到目標的可達性，以及兩端兼容性。裝置時間通用指南涵蓋證書、權杖與作業系統等非 REALITY 情況。
哪些證據足以支持結論？
有用的證據包括：實際載入的非敏感 maxTimeDiff 值、兩端的 UTC 時刻、實測偏移、軟件版本、要求時間，以及伺服器作出決定的階段。一次受控的前後對照測試，比一張時鐘截圖更有說服力。
不要公開完整設定、私鑰、short ID 或帳戶資料。要證明偏移超出窗口，並不需要這些值。對記錄作範圍盡量小的遮蓋，同時保留時間戳和失敗分類。
這與 VPN 可靠性有何關係？
證書、簽署更新、身份權杖、日誌及事故關聯都依賴健康時間；REALITY 可選窗口只是具體例子，不是把所有 VPN 故障歸因於 NTP 的理由。
託管客戶端可以檢查明顯的時鐘異常並提供診斷提示，但不應承諾代你校正系統時間，也不應悄悄削弱伺服器政策。
系統時間校正之後，託管連線可以提供有用的第二個數據點：安裝 AethoVPN，連接推薦位置，看看它在 REALITY 客戶端失敗的同一裝置、同一網絡上能否成功。如果兩者都失敗，先查裝置時鐘和網絡；如果只有 REALITY 工作階段失敗，再回到 maxTimeDiff 和伺服器的時間來源。AethoVPN 沒有公開其協議，也無法控制第三方伺服器的時間窗口，所以它的結果並不反映那部伺服器的設定。可開始 3 日免費 Pro 試用來做這項對照；無論哪一方，都不要為了通過而削弱伺服器的時間檢查。
在營運上，應在時間偏移接近最小的已啟用驗證窗口之前便發出警報。要監察主機的時鐘來源，而不只是應用程式錯誤。設定審查應把由非零改為零視為一次政策變更，而不是無害的可用性微調。
總結
- REALITY 可在授權時比較加密客戶端時間戳與伺服器時間。
- 非零
maxTimeDiff以毫秒定義可接受的絕對差值。 - 現行實作中，
maxTimeDiff: 0會停用時間條件。 - 時間通過不代表密鑰、ID、名稱、目標或版本正確。
- 應以生效設定、UTC 偏移與全新受控重試診斷。
- 不應為未知故障而隨意削弱時間政策。
常見問題
REALITY 總是要求時鐘同步嗎？
不是。這項時間差要求只在伺服器啟用非零 maxTimeDiff 時適用；裝置其他系統仍可能依賴正確時間。
maxTimeDiff: 0 是否表示不允許任何偏差？
不是。現行實作把零解作停用時間差比較，而非零毫秒窗口。
maxTimeDiff 單位是秒嗎？
官方設定文件指單位為毫秒。應確認部署版本的解析方式，不依賴無單位介面。
錯誤時區會令 REALITY 身份驗證失敗嗎？
只有底層時刻因而錯誤才會。單純顯示時區不同不會改變 Unix time。
NTP 顯示運作能證明時間準確嗎？
不能。服務可能仍在收斂或使用欠佳時間來源，必須量度實際偏移。
校準時鐘能修復所有 REALITY 握手嗎？
不能。它無法修復錯誤密鑰、short ID、伺服器名稱、目標、路徑或版本。
用戶應自行增大伺服器 maxTimeDiff 嗎？
不應。只有獲授權營運者可改變伺服器認證政策；用戶應報告偏移與失敗證據，而非索取或披露機密。
免責聲明：本文僅供一般資訊參考，不構成法律、技術或其他專業建議。我們不保證內容的準確性、完整性或時效性。
來源：
- Project X, "REALITY configuration": https://xtls.github.io/en/config/transports/reality.html
- XTLS, "REALITY implementation time-window check": https://github.com/XTLS/REALITY/blob/main/tls.go
- XTLS, "REALITY README": https://github.com/XTLS/REALITY/blob/main/README.en.md
Sources checked 2026 年 9 月 12 日。
延伸閱讀：
