TLS 憑證錯誤排除

一、從記錄辨別憑證錯誤與連線失敗

「TLS 交握失敗」只是結果，並非具體原因。先查看 v2rayN 主視窗底部的記錄區，找出剛才那次連線的完整錯誤；如果記錄區已收合，請先展開對應面板。不同版本的介面位置可能不同，請以包含 x509、tls 或 certificate 的核心原始訊息為準，不要只看瀏覽器顯示的「連線已重設」。

選定一個節點，記下連線時間，只發出一次請求。下方英文片段是常見錯誤格式，實際記錄也可能包含核心模組名稱、連線位址及巢狀錯誤原因。分享記錄前，請移除訂閱網址、使用者識別資訊和瀏覽目標中的敏感內容。

二、同步系統時間，再確認憑證是否過期

TLS 會比較目前時間與憑證的 notBefore、notAfter。電腦斷電後時鐘重設、虛擬機還原舊快照，或手動修改日期，都可能讓仍有效的憑證被判定為「尚未生效」或「已過期」。請先確認年月日與分鐘，不要只看工作列顯示的小時。

1. 確認日期與時間

   在 Windows 11 開啟「設定」→「時間與語言」→「日期與時間」，確認日期、時間及目前時區，並與另一台時間同步正常的裝置比較。

2. 立即同步

   開啟「自動設定時間」，再於「其他設定」中點選「立即同步」。如果同步失敗，請先恢復一般網路連線，再重新嘗試使用系統時間服務。

3. 重新連線

   回到用戶端，重新啟用目前節點並發出新請求。請以新的記錄為準，不要繼續根據同步前留下的舊錯誤判斷。

4. 檢查有效期限

   時間正確但仍顯示憑證過期時，請查看伺服器實際傳回的憑證有效期限。如果目前時間確實晚於 notAfter，須由維護方更新憑證，並讓 TLS 服務重新載入。

在 Android 的系統「設定」中搜尋「日期和時間」，並開啟自動設定時間；實際選單會因裝置系統而異。時區會影響時間的顯示方式，只要底層絕對時間正確，單純選擇其他時區通常不會造成憑證錯誤。反之，手動把時鐘調回過去，即使暫時恢復連線，也會影響其他服務，不能當作修復方式。

時間同步與節點連線是兩條不同的網路路徑。節點使用 443 連接埠，不代表時間同步也使用該連接埠；排查同步服務的網路規則時，請確認實際使用的時間來源與通訊協定，不要因此任意開放本機的輸入連接埠。

三、確認 SNI、伺服器位址與 Host

節點的「位址」、TLS 的「伺服器名稱」和 WebSocket 的「Host」並不相同。伺服器位址決定連線目的地；SNI 位於 TLS 交握過程中，可協助伺服器選擇網站及憑證；HTTP Host 或 HTTP/2 的 authority 則屬於應用層請求。修改 Host 不會自動變更憑證驗證所使用的名稱。

在 v2rayN 主視窗中按兩下節點，開啟伺服器編輯視窗，確認傳輸安全性設為 TLS，再檢查「SNI」或對應的伺服器名稱欄位；不同版本的欄位標籤可能不同，請依 serverName 的意義確認。v2rayNG 可從節點卡片的編輯入口檢查 TLS 設定中的 SNI。請勿在主機名稱欄位中填入 https://、:443 或 URL 路徑。

• 使用 IP 作為連線位址時，仍可能需要明確填寫網域名稱 SNI；否則用戶端可能會以 IP 進行驗證，但憑證只包含網域名稱。
• *.example.com 通常可匹配 a.example.com，但不能因此認定也涵蓋 example.com 或 a.b.example.com。
• 「偽裝網域」是容易混淆的介面用語。請先確認它實際指的是 SNI 還是 Host，再逐項比對維護方提供的參數。
• 更新訂閱後問題再次出現時，請確認訂閱中的 SNI 是否仍是舊值。只修改本機副本，可能會在下次更新時被覆寫。

四、檢查憑證鏈與伺服器實際傳回的內容

「unknown authority」不等於「憑證過期」。網站即使使用有效的網域憑證，若漏送中繼憑證，用戶端仍可能無法建立完整的信任鏈。瀏覽器可以正常連線，也不能完全排除此問題：瀏覽器與代理核心使用的信任存放區、快取或取得中繼憑證的方式可能不同。

如果系統已安裝 OpenSSL，可以使用以下命令檢查伺服器。此處的 example.com 是保留的範例網域，並非本站節點；執行前請將命令中的網域與連接埠改成實際值。連線位址與 SNI 不同時，-connect 請填入實際連線目標，-servername 和 -verify_hostname 則填入預期的 TLS 主機名稱。

openssl s_client -connect example.com:443 -servername example.com -showcerts -verify_hostname example.com -verify_return_error

• 確認傳回的葉憑證是否屬於預期網站。如果收到其他網站的憑證，請檢查 SNI 和伺服器虛擬主機設定。
• 確認 Certificate chain 是否包含所需的中繼憑證。伺服器通常應傳送葉憑證及中繼憑證，不必附上根憑證。
• 查看最終驗證結果。Verify return code: 0 (ok) 表示本次測試在目前工具的信任環境中通過，不代表所有裝置都一定能通過。
• 若 OpenSSL 未正確設定 CA 信任路徑，也可能回報簽發者錯誤。請先確認測試工具使用的信任環境，以免誤判伺服器。

維護方應在實際終止 TLS 的服務上設定完整憑證鏈。例如前方有反向代理時，應更新反向代理載入的憑證，而非只修改後端核心目錄中的檔案。更新憑證後，還要重新載入相關服務，再從外部重新進行交握，確認傳回的是新憑證。

五、修復後以相同條件重新測試

排查時若同時更換節點、修改 SNI、切換 DNS 並啟用 Tun，測試結果就無法比較。請保留相同節點與測試目標，每次只調整一個變因。依照以下順序操作，可分辨問題是否因設定修正而解決，或只是剛好換到可用路線。

1. 記錄基準：記下目前節點位址、連接埠、TLS 類型和 SNI，並保留錯誤發生時間；請勿公開節點憑證資料。
2. 同步後重測：保持節點參數不變，只同步系統時間。若有效期限錯誤消失，再確認是否仍有名稱或信任鏈錯誤。
3. 修正名稱後重測：依維護方提供的值修正 SNI，重新連線，並檢查新記錄中的驗證名稱是否符合預期。
4. 切換網路比對：使用同一裝置和同一節點，在另一個網路上測試。只有特定網路傳回不同憑證時，再檢查網路攔截、DNS 解析及中間設備。
5. 確認修正持續有效：更新訂閱並重新開啟用戶端後再測一次，確認修正值是否被訂閱覆寫，或伺服器是否仍傳回舊憑證。

若時間與 SNI 都正確，仍顯示憑證過期或憑證鏈不完整，用戶端能處理的範圍就有限。提供錯誤原文、測試時間、用戶端與核心版本、連線連接埠及預期 SNI 給維護方，通常比只傳「節點不能用」的截圖更容易找出問題。其他網路與核心問題請參閱排查手冊。

六、常見問題：略過驗證與交握中斷