本文目錄
伺服器升級前可用的節點，升級後設定仍能載入卻連不上，容易讓人反覆改訂閱或憑證。這裡需要核對的是兩端版本及伺服器的最低用戶端要求。一般訂閱使用者應把證據交給提供方；有管理權限的人，也要先評估放寬要求後流量更容易被辨識的風險，不能把相容設定視為沒有代價的修復。
Xray 升級後，Mihomo 為什麼認證失敗
分別查看用戶端與伺服器日誌：設定能載入、連接埠也在監聽時，仍要確認是否出現 REALITY authentication failed 或 authentication failed or validation criteria not met，以及實際流量是否始終為 0。
minClientVer 限定伺服器接受的最低用戶端版本。Xray-core v26.7.11 起，未填寫也會預設採用 26.3.27。本篇核對的 Mihomo 在 REALITY 認證會話中回報 1.8.2；這是認證時提交的版本值，不是應用程式顯示的核心安裝版本，因此仍可能被伺服器拒絕。
這不是一般的憑證驗證，也不是用戶端 YAML 少了一個可以分享的欄位。minClientVer 屬於 Xray REALITY 伺服器端入站設定，不會隨 Clash 或 Mihomo 訂閱下發給一般使用者。沒有伺服器端控制權時，應將版本與錯誤交給服務供應商處理，不能在用戶端憑空加入這個欄位。
儲存設定並記錄兩端的實際版本
對應的安裝組合是：伺服器端使用 Xray-core v26.7.11 或更高版本，VLESS 入站啟用 REALITY，realitySettings 沒有顯式填寫 minClientVer；用戶端使用 Mihomo 核心，例如 Clash Verge Rev、FlClash 或其他 Mihomo 前端。
若發生錯誤是 x509、certificate、invalid short id、invalid public key、SNI 錯誤或普通節點 timeout，應先按對應欄位檢查，不適用這裡的相容調整。
修改伺服器端前，先匯出或複製目前生效的 Xray 設定，記錄管理面板版本、Xray-core 版本、用戶端顯示的 Mihomo 版本，以及第一次失敗的時間。不要只寫「都是最新版」，版本號才能建立可重現的對照。
同時保存受影響入站的 protocol、network、security、flow、serverNames、shortIds，以及 minClientVer 是否留空。備份中可能包含 UUID、privateKey、訂閱識別資訊與伺服器位址，只能存放在受控位置；公開 issue 或螢幕截圖前必須遮蔽敏感資訊。
xray version協議、伺服器端與用戶端的對應條件
| 檢查項目 | 對應表現 | 不符合時 |
|---|---|---|
| 協議 | VLESS + REALITY | 先依實際協議、TLS 或傳輸層檢查 |
| 伺服器端 | Xray-core v26.7.11+ | 不要套用本文的版本結論 |
| 伺服器端欄位 | minClientVer 留空或未填寫 | 核對明確設定值與用戶端版本 |
| 用戶端 | 使用 Mihomo 核心且發生身分驗證失敗 | 先確認實際核心與第一筆錯誤 |
固定節點，只改變用戶端或伺服器端版本做對照
最有價值的對照，是維持同一條入站、同一個節點與同一個網路，只比較用戶端核心或伺服器端版本。若 Xray 用戶端可透過該入站完成實際 HTTPS 請求，而 Mihomo 用戶端持續失敗，表示連接埠、金鑰與目標網站並未同時失效。
若你在升級前保留了官方 Xray v26.6.27，且相同設定降回該版本後立即恢復，也能支持版本相容性判斷。降版只用於短時間確認；沒有備份與官方二進位檔來源時，不要替換正式環境的伺服器端。
如何解讀對照結果
| 對照結果 | 下一步 |
|---|---|
| Xray 用戶端成功、Mihomo 失敗 | 檢查 minClientVer 與 Mihomo 工作階段版本 |
| 兩類用戶端都失敗 | 回頭檢查連接埠、入站與 REALITY 參數 |
| 只有一個節點失敗，且伺服器端未升級 | 先核對該節點完整的 REALITY 參數與服務狀態。 |
| v26.6.27 成功、v26.7.11+ 失敗 | 確認差異與版本有關後，再評估是否明確設定最低用戶端版本 |
| 更換網路後才恢復 | 檢查網路路徑或封鎖，不要將結果歸因於 minClientVer |
| 用戶端只有 x509 或 certificate 錯誤 | 改查憑證、時間與 SNI，不要降低 minClientVer。 |
降低 minClientVer 為什麼可能讓流量更容易被識別？
Xray 維護者在官方討論中提醒：舊版或經過改動的 TLS 指紋（握手時呈現的特徵）可能偏離真實瀏覽器，更容易被 DPI 這類網路流量檢測辨識。降低 minClientVer 只放寬可連線的用戶端範圍，不會修正用戶端已送出的指紋；能恢復相容性，也需要接受相應風險。
若能升級至符合伺服器端門檻，且已在同一節點驗證過的相容用戶端，應優先保留 Xray 預設值。確實必須繼續使用目前的 Mihomo 用戶端時，可將最低值明確設為與其回報的 1.8.2 一致；不要為了省事直接填入 0、0.0.0 或關閉所有限制。
如果這是多人共用的伺服器端，先確認哪些用戶端仍需要舊門檻，並記錄修改原因、時間與還原條件。只需處理受影響的入站，不應批次放寬所有 REALITY 入站。
接受風險後，只修改受影響入站的 minClientVer
在 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最小變更順序
備份目前生效的設定
保留原始空值狀態與還原檔案，不要公開 privateKey、UUID 或伺服器位址。
只修改一個入站
將 minClientVer 明確設為 1.8.2，其他 REALITY 參數保持不變。
執行設定測試
測試失敗就立即還原備份，不要讓有語法錯誤的設定進入重新啟動流程。
透過原本的管理方式重新啟動
使用面板或現有服務管理入口，不要同時啟動第二份 Xray。
不要開啟 skip-cert-verify，不要盲目更換 SNI 或 client-fingerprint，不要重新產生 UUID、REALITY 金鑰與 short-id，也不要反覆轉換訂閱。這些操作都沒有改變伺服器端用來比較的用戶端版本。
同樣不要把所有節點切換到 Global、關閉規則或刪除本機設定。身分驗證是在規則分流之後建立；REALITY 伺服器端已拒絕握手時，用戶端代理模式無法讓它通過。
使用同一節點驗證握手與實際流量
服務重新啟動後不要只看延遲數字。保持原本的 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、金鑰與用戶端第一筆錯誤。
官方記錄與後續相容設定的維護
Mihomo issue #2967 與 Xray issue #6477 支援同一設定在不同用戶端或伺服器端版本下表現不同；3x-ui issue #5922 記錄了在面板顯式設定 minClientVer 後恢復的情境。
截至 2026-09-02，Xray 的固定提交與維護者討論仍明確提醒，調整最低用戶端版本須自行承擔指紋風險。Mihomo issue #2967 被標為 wontfix，後續文件請求 #3132 也已關閉；維護者沒有宣布用戶端側正式修正，不能把等待某個 Mihomo 正式版當成確定的處理方法。
現有證據支援上述安裝組合的版本相容判斷，但不能把所有 REALITY authentication failed 都歸因於 minClientVer。無效 short-id、public key、SNI、時間、流控、連接埠或伺服器端未載入新設定，都可能產生相近表現。
只有 Xray 或 Mihomo 的正式 Release、官方文件或合併程式碼明確改變相容要求，同一節點也完成實際請求重新測試，才撤銷顯式最低版本並恢復預設。維護記錄保留伺服器端版本、設定值、需相容的用戶端和最後驗證日期。