連線疑難排解 · Clash 技術部落格

Mihomo REALITY authentication failed 怎麼辦？

Xray 26.7.11+ 升級後，若 Mihomo 顯示 REALITY authentication failed，可核對 minClientVer 與用戶端版本，評估風險後修復、驗證並復原。

閱讀正文返回部落格
  • Mihomo
  • REALITY
  • Xray
  • minClientVer
  • VLESS
本文目錄
發布日期
預計閱讀
約 10 分鐘

先確認是不是同一種 REALITY 相容性問題

本文只處理一種明確組合：伺服器端使用 Xray-core v26.7.11 或更高版本，VLESS 入站啟用 REALITY，realitySettings 未明確填寫 minClientVer；用戶端使用 Mihomo 核心，例如 Clash Verge Rev、FlClash 或其他 Mihomo 前端。

常見情況是設定可以載入、伺服器端連接埠也正在監聽，但用戶端顯示 REALITY authentication failed，或伺服器端記錄 authentication failed or validation criteria not met，實際流量始終為 0。

若錯誤是 x509、certificate、invalid short id、invalid public key、SNI 錯誤或一般節點 timeout，應先依對應欄位檢查，不屬於本文直接處理的範圍。

Mihomo issue #2967 記錄了 1.8.2 工作階段版本與預設門檻的衝突。Xray issue #6477 則記錄相同設定從 v26.6.27 升至 v26.7.11 後連線失敗，並在回退伺服器版本後恢復。

3x-ui issue #5922 也記錄了在面板中明確設定相容的 minClientVer 後恢復的情況。

近期 issue #3132 再次要求將這項已知界線寫入 Mihomo 文件，但維護者並未宣布用戶端已有正式修正。

四項條件都符合再繼續閱讀本文

檢查項目符合本文情況不符合時的處理
協議VLESS + REALITY先依實際協議、TLS 或傳輸層檢查
伺服器端Xray-core v26.7.11+不要套用本文的版本結論
伺服器端欄位minClientVer 留空或未填寫核對明確設定值與用戶端版本
用戶端使用 Mihomo 核心且發生身分驗證失敗先確認實際核心與第一筆錯誤

儲存設定並記錄兩端的實際版本

修改伺服器端前，先匯出或複製目前生效的 Xray 設定，記錄管理面板版本、Xray-core 版本、用戶端顯示的 Mihomo 版本，以及第一次失敗的時間。不要只寫「都是最新版」，版本號才能建立可重現的對照。

同時保存受影響入站的 protocol、network、security、flow、serverNames、shortIds，以及 minClientVer 是否留空。備份中可能包含 UUID、privateKey、訂閱識別資訊與伺服器位址，只能存放在受控位置；公開 issue 或螢幕截圖前必須遮蔽敏感資訊。

在伺服器端確認 Xray 版本
xray version

修改前可還原的基準

  • 目前的 Xray 設定已備份至受控位置
  • 已記錄伺服器端 Xray-core 與用戶端 Mihomo 版本
  • 已保存用戶端與伺服器端的第一筆錯誤
  • UUID、public key、private key、short-id 與 SNI 均未變更
  • 已有一筆相同網路環境下的失敗測試結果

瞭解 Xray 為什麼會拒絕 Mihomo

Xray REALITY 官方文件將 minClientVer 定義為伺服器允許的最低用戶端版本，並說明目前預設值是 26.3.27。結合 Xray issue #6477 在相同設定下的重現結果，v26.7.11 起伺服器在此欄位留空時也會套用這個預設門檻，而不再將空值解讀為不限制。

Mihomo issue #2967 提供的目前實作證據顯示，其 REALITY ClientHello 工作階段版本為 1.8.2。伺服器端將 1.8.2 與預設最低版本 26.3.27 比較時會拒絕這次握手，因此同一個節點在 Xray 用戶端可用，在 Mihomo 用戶端卻會失敗。

這不是一般的憑證驗證，也不是用戶端 YAML 少了一個可以分享的欄位。minClientVer 屬於 Xray REALITY 伺服器端入站設定，不會隨 Clash 或 Mihomo 訂閱下發給一般使用者。沒有伺服器端控制權時，應將版本與錯誤交給服務供應商處理，不能在用戶端憑空加入這個欄位。

Xray 用戶端可用，Mihomo 顯示 REALITY authentication failed

優先核對伺服器端 minClientVer 與兩端版本。

所有用戶端都失敗

檢查入站監聽、UUID、short-id、SNI、金鑰與防火牆，不要只看版本。

只有一個節點失敗，且伺服器端未升級

先核對該節點完整的 REALITY 參數與服務狀態。

用戶端只有 x509 或 certificate 錯誤

改查憑證、時間與 SNI，不要降低 minClientVer。

只變更版本或門檻進行一次對照

最有價值的對照，是維持同一條入站、同一個節點與同一個網路，只比較用戶端核心或伺服器端版本。若 Xray 用戶端可透過該入站完成實際 HTTPS 請求，而 Mihomo 用戶端持續失敗，表示連接埠、金鑰與目標網站並未同時失效。

若你在升級前保留了官方 Xray v26.6.27，且相同設定降回該版本後立即恢復，也能支持版本相容性判斷。降版只用於短時間確認；沒有備份與官方二進位檔來源時，不要替換正式環境的伺服器端。

如何解讀對照結果

對照結果下一步
Xray 用戶端成功、Mihomo 失敗檢查 minClientVer 與 Mihomo 工作階段版本
兩類用戶端都失敗回頭檢查連接埠、入站與 REALITY 參數
v26.6.27 成功、v26.7.11+ 失敗確認版本界線後，再評估明確設定的相容門檻
更換網路後才恢復檢查網路路徑或封鎖，不要將結果歸因於 minClientVer

先決定是否接受降低最低版本

Xray 官方文件明確提醒：降低 minClientVer 會允許舊版用戶端連線，但舊版用戶端的 TLS 指紋與真實瀏覽器差異更明顯，可能更容易被 DPI 辨識。這是相容性與被辨識風險之間的取捨，不是沒有代價的修正。

若能升級至符合伺服器端門檻，且已在同一節點驗證過的相容用戶端，應優先保留 Xray 預設值。確實必須繼續使用目前的 Mihomo 用戶端時，可將最低值明確設為與其回報的 1.8.2 一致；不要為了省事直接填入 0、0.0.0 或關閉所有限制。

如果這是多人共用的伺服器端，先確認哪些用戶端仍需要舊門檻，並記錄修改原因、時間與還原條件。只需處理受影響的入站，不應批次放寬所有 REALITY 入站。

在伺服器端進行最小幅度的相容性調整

在 3x-ui 等面板中，編輯受影響的 VLESS 入站，開啟 Security 或 REALITY 設定，將 Min Client Ver 從空值改為 1.8.2。

使用原生 JSON 設定時，只在該入站的 realitySettings 中加入 minClientVer，不修改 UUID、privateKey、serverNames 或 shortIds。

儲存後，先使用目前的 Xray 二進位檔測試實際設定檔。官方命令文件說明，run 子命令的 -test 只驗證設定，不會啟動服務。設定路徑、二進位檔名稱與服務重新啟動入口以你的安裝方式為準；由面板管理的服務應優先使用面板本身的測試與重新啟動流程。

只顯示需要新增的伺服器端欄位
"streamSettings": {
  "security": "reality",
  "realitySettings": {
    "minClientVer": "1.8.2"
  }
}
使用實際路徑測試設定，不啟動服務
xray run -test -config /path/to/config.json

最小變更順序

  1. 備份目前生效的設定

    保留原始空值狀態與還原檔案，不要公開 privateKey、UUID 或伺服器位址。

  2. 只修改一個入站

    將 minClientVer 明確設為 1.8.2，其他 REALITY 參數保持不變。

  3. 執行設定測試

    測試失敗就立即還原備份，不要讓有語法錯誤的設定進入重新啟動流程。

  4. 透過原本的管理方式重新啟動

    使用面板或現有服務管理入口，不要同時啟動第二份 Xray。

使用同一節點驗證握手與實際流量

服務重新啟動後不要只看延遲數字。保持原本的 Mihomo 節點、SNI、short-id、public key 與用戶端指紋不變，先重試一次原本必定失敗的 HTTPS 請求，再查看用戶端連線記錄與伺服器端日誌。

修正生效時，REALITY authentication failed 不再出現，伺服器端可看到入站進入 VLESS 處理，用戶端會產生實際上傳與下載流量，並能連續完成至少兩次 HTTPS 請求。通常不需要重新匯入訂閱，因為變更的是伺服器端的接受門檻。

驗證清單

  • Xray 設定測試成功，且只執行一份服務
  • 同一個 Mihomo 節點不再顯示 REALITY authentication failed
  • 伺服器端日誌不再將該連線送入身分驗證失敗分支
  • 實際 HTTPS 請求能回傳內容，不只是顯示延遲
  • 連續再次測試兩次，切換網路後結果仍能合理解釋
  • 未修改 UUID、金鑰、SNI、short-id 或 skip-cert-verify

不接受風險時還原預設值並降回舊版

如果無法接受降低最低版本所帶來的指紋風險，請還原修改前的 realitySettings，重新執行設定測試，再透過原本的管理入口重新啟動。此時舊版 Mihomo 用戶端再次失敗屬於預期，應改用符合門檻且已完成驗證的用戶端。

短期業務必須恢復、又沒有可用的相容用戶端時，可在備份完整且來源可核對的前提下，考慮暫時回退到升級前已驗證的官方 Xray v26.6.27。這是相容性回退，不代表舊版更安全，也不應取代後續修復；請保留目前版本的安裝檔與復原計畫。

若明確設為 1.8.2 後仍然失敗，立即還原備份，停止繼續降低數值。接著核對伺服器端實際載入的設定、入站連接埠、UUID、short-id、SNI、金鑰與用戶端第一筆錯誤。

這些操作無法解決版本門檻問題

不要開啟 skip-cert-verify，不要盲目更換 SNI 或 client-fingerprint，不要重新產生 UUID、REALITY 金鑰與 short-id，也不要反覆轉換訂閱。這些操作都沒有改變伺服器端用來比較的用戶端版本。

同樣不要把所有節點切換到 Global、關閉規則或刪除本機設定。身分驗證是在規則分流之後建立；REALITY 伺服器端已拒絕握手時，用戶端代理模式無法讓它通過。

常見錯誤操作

操作為什麼無效或有風險
開啟 skip-cert-verifyminClientVer 不是一般的憑證驗證
重建 UUID 與 REALITY 金鑰會破壞原本的對照，仍不會改變版本門檻
將 minClientVer 設為 0會擴大相容範圍與指紋風險，並非最小幅度的修正
只看延遲是否恢復延遲正常不代表實際 HTTPS 流量已經通過

目前的證據範圍與後續維護

截至 2026-09-02，Xray REALITY 官方文件仍將 26.3.27 列為 minClientVer 預設值，並明確記錄降低該值的指紋風險。Mihomo issue #2967 被標記為 wontfix，後續文件請求 #3132 也已關閉，因此不能將等待某個 Mihomo 正式版本寫成已確定的修正路徑。

現有證據足以支持本文限定的版本相容性判斷，但不能將所有 REALITY authentication failed 都歸因於 minClientVer。無效的 short-id、public key、SNI、時間、流量控制、連接埠，或伺服器端未載入新設定，都可能產生相近情況。

後續只有 Xray 或 Mihomo 的正式 Release、官方文件或合併程式碼明確改變這個界線，且同一節點完成實際請求的再次測試後，才應撤除本文的暫時相容設定。維護記錄應保留伺服器端版本、明確設定的門檻、需要相容的用戶端，以及最後一次驗證日期。

參考資料