本文重點

適用於 v2rayN、v2rayNG 與 v2flyNG 的一般 TLS 節點排錯：先查看日誌，判斷連線停在哪個階段，再依序檢查系統時間、伺服器位址、SNI 與憑證鏈。本文整理客戶端檢查步驟與常見錯誤的對應關係，協助區分本機設定問題和伺服器憑證問題，並說明為何不應將 allowInsecure 當成長期解決方案。

一、TLS 握手失敗：先確認連線卡在哪個階段

圖形化客戶端負責儲存節點並產生設定，實際建立連線的是 Xray 或 V2Fly 等核心。v2rayNG 使用 Xray 核心，v2flyNG 使用 V2Fly 核心；v2rayN 實際使用的核心則依目前設定與日誌判斷。不同核心和版本的日誌前綴可能不同，排查時應查看錯誤鏈末端，不要只看最外層的「連線失敗」。

以啟用 TLS 的 VLESS、VMess 或 Trojan 節點為例，通常會先解析伺服器位址，再連線至遠端 TCP 連接埠，接著進行 TLS 握手；握手成功後才會進入後續的代理協定交握。協定名稱本身無法證明節點啟用了一般 TLS，仍須檢查安全層設定。REALITY 使用自己的參數與驗證機制，不應直接套用本文的憑證處理方式。

日誌線索大致階段優先檢查項目
no such host位址解析伺服器位址拼寫、DNS 回應
connection refusedTCP 連線遠端監聽連接埠、防火牆、服務狀態
x509:憑證驗證裝置時間、憑證網域、信任鏈
tls: handshake failureTLS 協商SNI、TLS 服務設定、伺服器日誌
EOF 或 i/o timeout需搭配上下文判斷錯誤是在握手前還是握手後發生

例如遠端連接埠設定為 443，但握手開始前就出現 connection refused，此時修改憑證選項並無助益。443 只是常見連接埠，不能取代服務提供者指定的實際連接埠；本機代理連接埠也不是此處要填寫的遠端連接埠。

二、系統時間與憑證有效期：先校正本機時鐘

憑證包含生效時間與到期時間。客戶端會依裝置目前時間判斷憑證是否在有效期內：日期被重設到過去，可能顯示「尚未生效」；日期跳到未來，則可能顯示「已過期」。時間應以實際準確時刻為準，單純變更時區通常無法修正錯誤的系統時鐘。

  1. 記錄錯誤

    在客戶端日誌中找到這次連線的錯誤，記下目前時間及憑證有效期提示。先停止連續測試，以免新舊日誌混在一起。

  2. 同步時間

    在 Windows 11 開啟「設定」→「時間與語言」→「日期與時間」，啟用「自動設定時間」，再按「立即同步」。請先確認裝置已連上可用網路。

  3. 檢查 Android 裝置

    Android 原生介面通常可在「設定」→「系統」→「日期與時間」中啟用「自動設定時間」。各廠牌名稱可能不同，可在設定中搜尋「日期與時間」，確認自動校時是否生效。

  4. 重新連線

    返回客戶端重新連線一次，並查看新日誌。若本機時間正確，但憑證確實已過期，應由伺服器端更新並重新載入憑證，不要繼續調整客戶端日期。

憑證有效期是明確界線，並沒有「容許誤差五分鐘」這類固定寬限。例如憑證在 UTC 00:00 生效，若本機時鐘實際慢到前一天 23:50，就可能無法通過驗證。日誌與憑證工具顯示的時區可能不同，比對前應先統一為 UTC 或同一個當地時區。

三、伺服器位址、SNI 與憑證網域分別如何填寫

伺服器位址決定連線目的地；SNI 則是在 TLS 握手時告知伺服器的目標主機名稱，伺服器可能據此選擇網站與憑證。常見核心設定中的 serverName 也用來指定預期驗證的伺服器名稱，因此不能把它當成可任意填寫的備註。

假設服務提供者明確提供連線位址 edge.example.com、遠端連接埠 443，以及 TLS 名稱 tls.example.com，客戶端就應分別填入這些欄位。兩者不同不一定是錯誤，但必須符合伺服器端設定；不可從搜尋結果隨意挑選網域當作 SNI。

萬用字元憑證也有適用範圍：*.example.com 通常可涵蓋 node.example.com，但不代表也涵蓋 example.com 或 a.node.example.com。如果將伺服器位址改為 IP，卻未明確設定預期名稱，核心可能會嘗試驗證該 IP；只有網域 SAN 的憑證無法通過這種驗證。

結論：依伺服器端參數核對名稱，不要根據位址猜測 SNI

若連線位址是 IP、憑證卻簽發給網域，尤其要確認服務提供者指定的 serverName。保留正確的連線位址，並設定憑證涵蓋的預期名稱，比啟用略過憑證驗證更可靠。

四、常見憑證錯誤：依錯誤原文判斷

以下列出日誌中常見的錯誤核心文字。外層可能還包含出站名稱、連線編號或位址；不要只把整行日誌末尾的通用提示當成唯一原因。憑證類錯誤應優先保留 x509 後的完整說明；回報給服務提供者前，再遮蔽訂閱權杖、使用者識別資訊與個人位址。

錯誤：x509: certificate has expired or is not yet valid

原因：本機時間不正確，或伺服器憑證確實已不在有效期內。處理方式：先同步裝置時間，再對照日誌中的有效期；若本機時間正確，請服務端更新憑證或修正憑證部署。

錯誤：x509: certificate signed by unknown authority

原因：憑證鏈無法連結至客戶端信任的根憑證，可能是中繼憑證未完整提供、使用自簽憑證，或本機信任環境異常。處理方式：請服務提供者檢查完整憑證鏈，並更新系統信任庫；不要安裝來源不明的根憑證。

錯誤：x509: certificate is valid for

原因：錯誤訊息後面通常會列出憑證涵蓋的名稱與不符的目標名稱。處理方式：檢查節點的 serverName 是否符合憑證 SAN；若伺服器因 SNI 錯誤而回傳預設網站的憑證，也須修正虛擬主機設定。

錯誤：tls: first record does not look like a TLS handshake

原因：目前連接埠回傳的內容不像 TLS，常見情況是連到未加密的服務。處理方式：檢查遠端連接埠、安全層與反向代理入口；不要把修改憑證驗證選項當成修正連接埠的方法。

錯誤：remote error: tls: handshake failure

原因：對端拒絕 TLS 協商，可能與 SNI、通訊協定版本或伺服器政策有關，單憑這句訊息無法判定是憑證過期。處理方式：還原服務提供者指定的 TLS 參數，並比對同一時間的伺服器日誌繼續排查。

如果只看到 EOF，還不能判定「憑證不受信任」。對端提前關閉連線、入口設定不符或網路設備中斷連線，都可能造成此結果。先檢查是否有更早出現的 TLS 詳細錯誤，再判斷是否需要服務提供者協助。

五、allowInsecure 的用途與風險

在常見的一般 TLS 設定中，allowInsecure 用來控制是否略過伺服器憑證驗證。它不是通用的「提升相容性」開關：略過驗證後，即使連線被導向錯誤的服務，或遭到中間人干預，客戶端也可能不再透過一般憑證驗證拒絕連線。連線經過加密，不代表對端身分已獲得可靠確認。

以下僅示意核心出站設定 streamSettings 中的 TLS 欄位，並非可直接匯入的完整節點設定。tls.example.com 是示意網域，實際值必須使用服務提供者明確指定的 TLS 名稱。圖形化客戶端通常會產生這些欄位，建議優先透過節點編輯介面修改。

{
  "security": "tls",
  "tlsSettings": {
    "serverName": "tls.example.com",
    "allowInsecure": false
  }
}

六、v2rayN 與 v2rayNG 的檢查順序

介面文字可能隨版本變動，排查前先記下客戶端版本與實際核心版本。以下以常見的節點編輯方式說明：在 v2rayN 的伺服器清單中，雙擊目標節點；在 v2rayNG 中，點選目標設定右側的編輯圖示。進入編輯畫面後，核對同一節點的位址、連接埠、安全層、SNI 與憑證驗證狀態，不要混淆全域設定與單一節點設定。

  1. 鎖定目標

    只選擇一個要排查的節點，記下它的備註與來源群組。確認日誌對應的是該節點，而非其他自動切換的出站連線。

  2. 檢查連線入口

    在節點編輯頁逐項比對服務提供者的參數：伺服器位址、遠端連接埠、傳輸方式，以及安全層是否設定為 TLS。範例中的 443 不能取代實際設定值。

  3. 檢查名稱

    檢查「SNI」或「serverName」欄位，確認內容沒有通訊協定前綴、連接埠或前後空格。若另有 Host 欄位，請依服務提供者要求分別填寫，不要互相替代。

  4. 保留驗證

    關閉「略過憑證驗證」或同義選項後儲存。返回主畫面重新啟動連線；必要時使用客戶端提供的重新啟動核心功能，讓變更生效。

  5. 比對日誌

    實際發出一次請求，比較修改前後的錯誤。若 TLS 錯誤消失，但出現驗證或傳輸錯誤，請改查使用者識別資訊、路徑與伺服器端協定參數。

訂閱節點也要留意更新覆寫：直接修改由訂閱產生的項目，下次更新時可能會被取代。排錯時若客戶端支援，可複製為獨立項目並註明用途；長期修正則應請服務提供者更正訂閱參數。不要將完整節點匯出檔、原始 JSON 或訂閱網址公開貼到求助頁面。

七、常見問題：瀏覽器正常，為何客戶端仍然連線失敗？

瀏覽器能正常開啟同一個網域，節點卻仍出現憑證錯誤？

先比較瀏覽器使用的網域與節點的 serverName 是否一致，再檢查連接埠。瀏覽器與核心所使用的信任來源、建立憑證鏈的方式也可能不同；網頁能正常開啟，仍不能排除伺服器缺少中繼憑證。請服務提供者檢查實際 TLS 入口。

改用伺服器 IP 後，出現憑證名稱不符？

保留服務提供者允許使用的連線 IP，並確認是否需要另外填寫 TLS 的 serverName。網域憑證通常無法用來驗證任意 IP；不要只因連線位址改成 IP，就連 SNI 也一併改成 IP。

時間已同步，為何仍提示憑證過期？

查看同步後的新日誌，核對憑證到期時間。若憑證確實已過期，伺服器端須更新憑證、重新載入服務，並確認連線入口實際回傳的是新憑證；管理面板顯示更新成功，不代表執行中的服務已使用新憑證。

啟用略過驗證後就能連線，可以一直開著嗎？

不建議作為日常設定。記錄狀況後恢復驗證，再分別排查時間錯誤、名稱不符與信任鏈異常。若問題出在伺服器部署，請將準確時間、核心版本及已遮蔽敏感資訊的 x509 錯誤提供給服務提供者處理。

節點使用 REALITY，也要找憑證網域嗎？

不要套用一般 TLS 憑證排錯流程。先確認安全層確實設定為 REALITY，再依伺服器參數檢查 serverName、公鑰、shortId 等欄位，並確認客戶端與核心支援情況；不要自行切換為 TLS。

結論：一次只修改一項，並保留驗證

依照「時間 → 入口 → 名稱 → 憑證鏈」的順序處理；每修改一項，就重新連線並保存新日誌。TLS 驗證通過後，再檢查代理協定與路由，避免混淆不同階段的問題。