VLESS Reality 在一個網絡可用，另一個不可用

VLESS Reality 在一個網絡可用，另一個不可用，並不自動代表設定已損壞。盡量固定客戶端、伺服器、設定、裝置和測試時間，再逐層比較 TCP 與連接埠、IPv4/IPv6、DNS、MTU、SNI、本機政策及路徑過濾。找出第一個可重現差異，比隨機切換選項更有價值。

完整 VPN 指南說明整條連線路徑。本文假設同一設定已在網絡 A 成功，只作網絡 A/B 比較，不與一般「VPN 無法連線」問題混在一起。

關鍵要點

• 更改設定前，先在可用網絡 A 保存乾淨基準。
• 分辨 TCP 可達、REALITY 認證及其後的代理流量。
• 把 IP 協議族、DNS、連接埠、MTU、SNI、政策和過濾視為獨立假設。
• 不關閉證書檢查、不弱化識別資料，也不繞過網絡擁有者政策。
• 保存時間戳及遮蔽的證據，讓各方查看同一事件。

VLESS Reality 在一個網絡可用，另一個不可用怎麼辦？

使用同一裝置、客戶端版本、設定、伺服器地址和連接埠、serverName、公鑰、short ID、底層傳輸及測試目標。兩次測試盡量接近，避免服務更新、DNS 輪換或證書改變成為隱藏變數。

無需匯出設定。只記錄非敏感欄位和版本，移除用戶 ID、私鑰、訂閱網址、權杖及伺服器資訊，勿公開 URI。

證據	可用網絡 A	故障網絡 B
日期、時間、時區	精確記錄	精確記錄
接入類型與擁有者	Wi-Fi/流動數據/Ethernet	Wi-Fi/流動數據/Ethernet
普通 HTTPS	成功或失敗	成功或失敗
伺服器主機及連接埠	相同、已遮蔽	相同、已遮蔽
DNS A/AAAA	已記錄	已記錄
TCP 階段	成功/逾時/拒絕	成功/逾時/拒絕
REALITY 階段	結果、錯誤及時間	結果、錯誤及時間
連線後小型請求	結果	結果

兩個網絡都能連到 VLESS Reality 伺服器嗎？

步驟 1：先證明普通網絡可用

在網絡 B 中斷設定，開啟一個你獲授權存取的普通 HTTPS 頁面。透過合法頁面完成登入式網絡的驗證。不要接受證書警告；攔截 TLS 的登入頁不能作為有效基準。

記錄裝置的 DNS、預設路由和訊號是否正常穩定。如果普通存取已經出問題，先修復或上報該接入網絡的問題。在底層連線不可用時，VLESS Reality 的錯誤無法指出隧道本身的原因。

在網絡 A 上重複同一個小型普通要求。目的不是比速度，而是證明兩個網絡在比較時都能承載正常流量。

步驟 2：找出最早失敗階段

客戶端一句「連線失敗」會把好幾個階段混在一起。請使用受支援的記錄或診斷檢視，找出最早出現差異的一點：

1. DNS 解析設定的伺服器主機名稱。
2. 裝置選擇 IPv4 或 IPv6 位址。
3. TCP 到達設定的連接埠。
4. REALITY 檢查伺服器名稱、公鑰、short ID 和握手。
5. VLESS 完成驗證並建立代理連線。
6. 所選應用程式的流量被導入該連線。
7. 遠端出口到達測試目的地。

Project X 把 VLESS 描述為無狀態的輕量傳輸協議，並列出客戶端一方的伺服器與身份欄位。［1］REALITY 有各自獨立的目標、serverNames、密鑰和 short ID 約定。［2］把這些階段分開，可避免把 TCP 被封鎖誤標為 VLESS 驗證問題。

步驟 3：比較連接埠與 TCP

如果 B 無法完成 TCP 而 A 可以，核對完全相同的地址及連接埠。訪客 Wi-Fi、機構網絡和流動電訊商可能容許常見網站，卻限制未知端點或連接埠。本機防火牆亦會造成類似現象。

只對自己的伺服器作少量可達性測試，不掃描網絡或第三方連接埠。逾時表示客戶端沒有收到可用回應，立即拒絕通常表示某處主動拒絕；兩者都不能單獨確定責任方。

若營運者提供另一個獲准端點，可在之後作單變數比較。不要把服務偽裝至被禁止的連接埠，也不要規避明確網絡政策。

比較位址、握手、傳輸與政策行為

步驟 4：比較 IPv4 與 IPv6

同一個主機名稱可能同時傳回 A 和 AAAA 記錄。網絡 A 可能到達 IPv4 位址，而網絡 B 優先使用 IPv6；純 IPv6 接入網絡可能依賴 DNS64/NAT64，而這對字面 IPv4 位址並不適用。IPv6-only 排障指南詳細解釋了這條界線。

記錄客戶端實際選擇的位址家族，而不只是裝置是否顯示 IPv6 位址。比較兩個網絡上伺服器的 DNS 答案，並確認設定的是主機名稱還是字面位址。字面 IPv4 端點無法被 DNS64 合成，因為根本不會進行 DNS 查詢。

不要把在系統層面停用 IPv6 當作「修正」。那會改變網絡本身，而不是證明相容性，亦可能破壞普通存取。應借助客戶端或營運方的診斷，核實伺服器確實發佈並監聽服務聲稱支援的位址家族。

步驟 5：獨立比較 DNS

若設定使用主機名稱，在兩個網絡分別記錄 A/AAAA 及時間。答案不同可能來自地理調度、split DNS、快取或解析政策，並不一定是惡意干擾。

分辨連線前的伺服器名稱解析與連線後的目標名稱解析。如果伺服器主機名稱沒有解析，握手尚未開始；若 REALITY 已成功但網站失敗，應檢查後一條路徑。

不要盲目更換 DNS。在你管理的網絡，可把獲准解析器比較作為一個變數，然後還原原有設定。ISP 封鎖概覽介紹 DNS 方法，但不能把每次失敗都判定為封鎖。

步驟 6：檢查 SNI 與 REALITY

REALITY 從 serverNames 接受 SNI，名稱應符合目標證書行為。［2］ 項目說明亦把目標協議支援及路由位置列為相容條件。［3］ 網絡裝置可能區別處理某個 SNI，但拼寫錯誤、舊設定或目標改變亦會產生類似結果。

比較兩個網絡的精確非敏感 serverName 及客戶端版本。若 TCP 在 B 成功、握手卻失敗，保存錯誤和時間。不要換成隨機熱門域名；目標及獲准名稱是伺服器綁定契約。

若 B 連普通 HTTPS 目標都限制，可記錄為路徑政策線索，但不能證明 REALITY 流量受到完全相同處理。

步驟 7：辨識 MTU 症狀

MTU 問題通常在連線看似已開始之後才出現：極小的要求能成功，較大的頁面卻停頓；上載先於下載失敗；或當證書、回應變大時隧道反覆重設。這與 TCP 連線根本無法開啟是兩回事。

透過已連線的工作階段，以一個小型要求和一個中等大小的獲准傳輸作比較。記錄失敗是否只在超過某個大小門檻後才開始，以及有否丟包。避免洪泛、窮舉式探測，或宣稱有一個適用於所有路徑的「神奇」MTU 值。

如客戶端提供文件列明的 MTU 設定，只在支援範圍內更改，並先保存基準。如果同一個可重現要求沒有改善，便還原原值。較小的設定能成功，表示存在路徑封包大小問題，但並不能確定是哪一跳丟棄了封包。

步驟 8：檢查裝置及網絡政策

查看受管理的裝置設定檔、端點保安、家長控制、強制私人 DNS、內容過濾、訪客網絡條款，以及明確禁止個人隧道的規定。在家居 Wi-Fi 上的工作手提電腦仍可能受裝置政策約束；在公司 Wi-Fi 上的個人手機亦可能受網絡政策約束。

不要為了繞過規則而移除裝置管理、停用保安軟件或偽裝流量。請詢問網絡擁有者該端點和連接埠是否獲准。如果過濾器由你管理，按準確的時間戳記和目的地查閱記錄，只在政策容許時加入範圍最窄、有文件記錄的放行規則。

如果你要的是在兩個網絡上都能用的連線，而不是修好這份設定，託管客戶端是更短的路。安裝 AethoVPN，在兩個獲准網絡上都連接 App 內的同一個位置；如果這個位置在限制較嚴的網絡上停滯，就換一個負載指示為綠色的位置。開始 3 天免費試用，把兩個網絡並排對照。這些結果反映的是託管服務在你這兩個網絡上的表現；如果要修好自己的 VLESS 設定，仍以上文的 REALITY 握手檢查為準，因為 AethoVPN 公開的設定流程沒有列明任何協議。

步驟 9：分辨路徑過濾與伺服器故障

B 失敗後，不改設定再測 A。若 A 亦失敗，伺服器、帳戶、證書或服務狀態可能已改變；若 A 仍穩定成功，而 B 總在同一階段失敗，接入路徑便是較強變數。

只把 B 上第二部獲授權裝置用作確認。兩部都卡在 TCP，較應檢查網絡；只有一部失敗，便比較系統協議族、客戶端版本、防火牆及 VPN 權限。在證明網絡這個常數之前，不要把個案併入籠統的裝置差異調查。

單一症狀不能證明偵測。擠塞、IPv6、DNS、連接埠、MTU 和政策都可能造成指定網絡故障。採用證據支持的最窄解釋。

步驟 10：把證據交給正確負責人

向服務營運者提供經遮蔽的版本、時間、協議族、TCP 結果、REALITY 錯誤、已到達時的 VLESS 錯誤，以及單變數結果。網絡擁有者通常只需目的地址類別、連接埠、時間及普通 HTTPS 結果，不要洩露憑證，也不要要求對方替你繞過政策。

若你管理兩端，把客戶端時間與伺服器 accept、handshake、auth、outbound 日誌關聯。A 成功而 B 沒有 accept，問題在較早路徑；已有 accept 但認證失敗，則返回設定和時鐘證據。

VPN 連線測試指南適合確認連線後的路由，不能反推握手前為何失敗。

總結

• 固定設定、裝置、伺服器及時間範圍後再比較網絡。
• 找出第一個差異階段：DNS、協議族、TCP、REALITY、VLESS、路由或目標。
• 分別檢查連接埠、IPv4/IPv6、DNS、MTU、SNI、政策及過濾。
• 故障後重測網絡 A，排除伺服器狀態改變。
• 測試應獲授權、有限、可復原而且不含秘密。

常見問題

流動數據可用能證明 Wi-Fi 封鎖 REALITY 嗎？

不能，只能證明路徑相關差異。Wi-Fi 的 DNS、IPv6、連接埠、MTU、登入頁、裝置設定或過濾都可能是原因。

應在故障網絡更改 serverName 嗎？

不應該。名稱必須配合伺服器 serverNames 及目標行為，隨機替換通常只會製造無效設定。

IPv6-only 網絡能存取 IPv4-only 伺服器嗎？

有時可借助 DNS64/NAT64，但並非普遍成立。直接 IPv4 不經 DNS 合成，可能無法到達。

為何連線成功後大型頁面仍然停頓？

這可能是握手後的 MTU 或丟包問題。調整受支援 MTU 前，先比較小型請求和中等請求。

TCP 逾時能證明審查或封鎖嗎？

不能。它只代表沒有收到可用回應。路由、防火牆、端點故障、擠塞及刻意過濾可能表現相同。

可以關閉防毒軟件或裝置管理測試嗎？

不要這樣做。只在自己管理的裝置使用日誌及獲准臨時控制，不能移除機構管理和安全保護。

哪些資訊可安全傳送給支援人員？

傳送版本、時間、網絡類型、DNS 和協議族、首個失敗階段及 A/B 結果。不要傳送完整設定、密鑰、權杖或訂閱網址。

免責聲明：本文只用於獲授權故障診斷，不授權繞過網絡政策、掃描第三方系統或削弱認證和裝置保護。

來源：

1. Project X, "VLESS": https://xtls.github.io/en/config/outbounds/vless.html
2. Project X, "REALITY": https://github.com/XTLS/Xray-docs-next/blob/main/docs/en/config/transports/reality.md
3. XTLS, "REALITY README": https://github.com/XTLS/REALITY/blob/main/README.en.md

Sources checked 2026 年 9 月 9 日。

---

延伸閱讀：

• 理解完整 VPN 路徑
• VLESS Reality 故障檢查清單
• 排查一般 VPN 連線失敗
• 驗證連線後的路由
• 排查 IPv6-only 接入網絡