V2Ray 訂閱失效與解析失敗自查清單：從連結格式到更新代理逐項排除

訂閱更新不是單一動作。用戶端會先讀取連結，完成網域解析與 HTTPS 連線，再取得回應本文，辨識編碼與節點協定，最後才將 VMess、VLESS 等項目寫入目前的訂閱群組。任何一層失敗，都可能在介面上顯示為「更新失敗」或「節點數量為 0」。因此，排查重點不是反覆點擊更新，而是先確認失敗發生在哪一層。

先判斷故障位於哪一層

開始操作前，先記錄更新時間、用戶端版本、使用中的訂閱群組以及錯誤原文。不要先刪除原有群組，因為舊節點、群組設定和更新日誌都是判斷依據。若用戶端允許複製日誌，應保留從點擊更新前 5 秒到錯誤出現後 10 秒的片段。

如果瀏覽器和用戶端都無法開啟同一個訂閱網址，優先檢查連結狀態、網域解析和存取權限。如果瀏覽器能取得一段文字，而用戶端卻顯示 Base64、JSON 或協定格式錯誤，問題更接近內容解析層。如果更新提示成功且新增了節點，但所有節點的延遲測試都失敗，表示訂閱本身已被讀取，後續應改查節點網址、連接埠、傳輸層和路由設定。

• 連線層：常見現象包括逾時、連線被拒絕、TLS 交握失敗或網域無法解析。
• 回應層：常見現象包括 HTTP 401、403、404、429，或回傳登入頁面而不是訂閱本文。
• 解析層：常見現象包括 Base64 長度錯誤、JSON 結構錯誤、無法辨識協定前綴。
• 寫入層：常見現象包括更新完成但節點數量為 0，或節點被篩選規則全部排除。
• 連線測試層：節點已顯示，但 TCP 延遲測試逾時，實際連線也無法建立。

檢查訂閱連結、回應狀態與有效期限

訂閱連結可能包含存取權杖、使用者識別碼、裝置參數或有效期限資訊。複製時少一個字元、結尾混入空格、聊天工具截斷查詢參數，都會讓服務端回傳錯誤頁面。應從原始管理頁面重新複製完整網址，不要手動拼接，也不要把多個網址放進同一個輸入框。

1. 核對首尾

   確認網址以 https:// 開頭，第一個字元前和最後一個字元後沒有空格、換行或中文標點。完整複製查詢參數，尤其不要遺漏問號後的權杖部分。

2. 單獨存取

   在目前裝置的瀏覽器中開啟連結，記錄是否直接回傳文字、觸發檔案下載、跳轉至登入頁，或顯示 401、403、404、429 等狀態。

3. 檢查有效期限

   進入訂閱來源的管理頁面，核對帳戶狀態、到期時間、流量額度，以及訂閱是否已重新產生。網址一旦重設，舊權杖通常就不再有效。

4. 排除快取

   間隔 60 秒後再請求一次。若第一次回傳 429，連續點擊只會延長限流時間，應等待服務端允許下一次請求。

瀏覽器「能開啟」不代表回應一定可解析。正常的訂閱本文通常是較長的編碼文字、逐行排列的協定連結，或用戶端支援的結構化內容；如果頁面包含導覽列、驗證碼、登入表單和錯誤說明，它只是網頁回應。此時用戶端可能取得 HTTP 200，卻因本文類型不符而顯示解析失敗。

確認更新訂閱時使用的網路路徑

「目前節點可以存取網路」與「訂閱更新請求經過目前節點」是兩回事。用戶端可能讓瀏覽器流量經由系統代理，卻讓訂閱更新採用直連；也可能在核心尚未啟動時勾選透過代理更新，導致請求指向沒有監聽的本機連接埠。

v2rayN 的雙路徑測試

1. 確認核心

   先選擇一個仍可用的舊節點並啟動核心，觀察主介面底部的狀態。常見本機 SOCKS 連接埠為 10808，HTTP 連接埠為 10809，實際數值以「設定」→「參數設定」中的本機監聽設定為準。

2. 測試直連

   開啟「訂閱群組」，執行「更新全部訂閱（不透過代理）」，記錄耗時、HTTP 狀態和節點數量變化。

3. 測試代理

   再次開啟「訂閱群組」，執行「更新全部訂閱」，讓請求依照目前的代理設定傳送，並與直連結果比較。

4. 核對連接埠

   進入「設定」→「參數設定」，確認訂閱更新使用的本機位址與實際監聽連接埠一致。修改後重新啟動核心，再執行一次更新。

v2rayNG 與 v2flyNG 的網路檢查

Android 裝置應先確認主介面的連線開關已啟動，再更新訂閱。v2rayNG 使用 Xray 核心，v2flyNG 使用 v2fly 核心，兩者的訂閱請求仍取決於應用程式目前的網路、代理狀態，以及系統對背景網路的限制。常見本機 SOCKS 監聽值為 10808，但排查時應以應用程式設定頁顯示的連接埠為準。

• 在側邊選單進入「訂閱群組設定」，確認目標群組已啟用，網址沒有被舊內容覆蓋。
• 返回主介面，從右上角選單執行「更新訂閱」，觀察提示是逾時、解析失敗還是更新完成。
• 分別在目前網路和另一條可用網路下測試一次；只改變網路條件，不要同時修改訂閱網址和核心設定。
• 若連線開關啟動後立即斷線，先處理核心啟動錯誤，再測試「透過代理更新」路徑。

訂閱本文的編碼與協定格式排查

連線成功後，用戶端需要判斷回應本文屬於哪種格式。常見內容可能是 Base64 編碼後的多行節點連結，也可能直接包含以協定名稱開頭的連結。解碼後，每筆記錄仍須符合相應協定的欄位要求；VMess 通常包含一段編碼後的 JSON，VLESS 則通常將使用者識別碼、伺服器、連接埠和傳輸參數放在 URI 中。

可辨識項目的結構示意：
vmess://編碼後的節點設定
vless://使用者識別碼@伺服器位址:連接埠?type=ws&security=tls
trojan://驗證資訊@伺服器位址:連接埠?security=tls

檢查重點：
1. 每筆記錄是否完整佔一行
2. 協定前綴是否使用半形字元
3. 連接埠是否為 1 至 65535 的整數
4. 查詢參數之間是否使用 &
5. 回應是否混入網頁、錯誤說明或空白內容

標準 Base64 通常使用字母、數字、加號、斜線和結尾等號；URL 安全變體可能使用連字號和底線。用戶端通常能相容常見變體，但複製截斷、在本文開頭插入提示文字、錯誤的換行轉換，仍會破壞長度。不要為了「修復」而任意補字元，因為能夠解碼不代表節點欄位完整。

節點名稱中的中文、空格和特殊符號通常需要正確編碼。若只有某一筆記錄失敗，可以先逐行檢查訂閱本文，觀察失敗是否總發生在同一個項目附近。若刪除單筆異常記錄後其餘項目能夠匯入，表示網路與整體編碼基本正常，問題集中在該節點的欄位或轉義方式。

• VMess：檢查解碼後的 JSON 是否完整閉合，位址、連接埠、使用者識別碼和傳輸類型是否存在。
• VLESS：檢查使用者識別碼與伺服器之間是否有 @，連接埠後的參數是否使用半形問號與連接符。
• TLS 參數：伺服器名稱、指紋和安全類型應與服務端設定一致；欄位能解析不代表交握一定成功。
• WebSocket 參數：路徑中的斜線和特殊字元需要保持編碼，不能在訂閱產生過程中被二次改寫。
• 空回應：HTTP 狀態正常但本文長度為 0 時，用戶端沒有任何可寫入項目，應檢查訂閱產生端。

用戶端版本、核心與群組設定

同一份訂閱在舊版失敗、新版成功，通常與協定欄位、分享連結格式或核心能力變化有關。v2rayN 7.x 與早期 6.x 的介面和部分設定入口有所差異；相較於部分 1.8.x 版本，v2rayNG 1.10.x 內含更新的 Xray 核心與匯入處理。排查記錄應寫明完整版本號，而不是只寫「最新版」。

1. 記錄版本

   記下用戶端完整版本與核心版本。例如只寫「7.x」不足以比對解析行為，應保留關於頁面顯示的完整版本資訊。

2. 升級用戶端

   從本站下載頁取得目前穩定版本，先結束舊程序，再依對應平台完成更新。保留原設定副本，避免覆蓋後失去故障樣本。

3. 建立新群組

   不要立即修改舊群組。在「訂閱群組」→「訂閱群組設定」中建立測試群組，貼上同一個網址並執行一次更新。

4. 關閉篩選

   暫時清空包含、排除、正規表示式篩選和去重條件。若節點數量從 0 恢復為具體數字，問題就在群組過濾，而不是訂閱解析。

5. 比較數量

   記錄服務端顯示的節點數量、用戶端匯入數量和被過濾數量。例如來源顯示 24 筆、用戶端寫入 0 筆，應優先檢查格式或篩選；寫入 23 筆則檢查單筆異常記錄。

群組篩選是「更新成功但清單為空」的常見原因。包含規則只保留名稱符合的節點，排除規則則移除符合的節點；正規表示式中過於寬鬆的點號或萬用字元範圍，可能會把所有項目都過濾掉。測試時先清空篩選，再逐條恢復規則，每次記錄節點數量的變化。

更新成功但節點仍無法使用

訂閱能夠更新，只能證明用戶端取得並解析了設定，不能證明每個節點都在線上。下一層要檢查伺服器位址解析、目標連接埠、傳輸方式、TLS 參數、系統時間與路由分流。此階段不要繼續修改訂閱網址，因為網址已經完成它的作用。

• 先執行 TCP 延遲測試。若 20 個節點都在相近時間逾時，優先檢查本機網路、DNS 或共用的伺服器網域。
• 若只有單一節點失敗，請比較它與可用節點的位址、連接埠、傳輸類型和安全參數。
• 系統時間偏差會影響 TLS 憑證有效期限判斷，應開啟日期、時間和時區的自動同步。
• 檢查路由模式是否將節點伺服器位址錯誤送回代理出站，形成循環連線。
• 確認系統代理連接埠與用戶端監聽連接埠一致；v2rayN 常見 HTTP 連接埠為 10809，但實際設定優先。

延遲測試結果也要分辨類型。TCP 延遲只檢查目標連接埠能否建立連線，不能完整驗證 VMess、VLESS、TLS 或 WebSocket 工作階段。實際連線測試還會經過驗證、傳輸層封裝與路由，因此「TCP 80 毫秒但無法存取」通常表示連接埠後的協定參數存在問題。

最小化連線驗證

1. 選擇一個欄位完整、名稱明確的節點，暫時關閉複雜的路由規則。
2. 啟動核心，確認本機 SOCKS 或 HTTP 連接埠已在監聽。
3. 只讓一個測試應用程式經過代理，避免其他流量干擾日誌。
4. 觀察日誌中最早出現的錯誤，而不是只看後續反覆重試。
5. 恢復路由規則後再次測試；若此時失敗，問題集中在分流條件或出站標籤。

一份可重複使用的十分鐘自查流程

複雜問題適合分層處理，但日常排錯需要固定順序。以下流程將高機率且低成本的檢查放在前面，避免一開始就重新安裝用戶端或重建所有設定。每完成一步都記錄結果，尤其是回應狀態、耗時、節點數量和錯誤原文。

1. 保存現場

   記錄用戶端與核心版本，保存舊群組、更新時間、節點數量和第一筆錯誤日誌。

2. 重新複製連結

   從原始管理頁面複製完整訂閱網址，檢查首尾空格、換行、權杖和有效期限。

3. 查看回應

   確認回傳的是訂閱本文，而不是登入頁、驗證碼、空白頁面或 401、403、404、429 狀態。

4. 切換路徑

   分別測試直連更新與透過代理更新，核對 10808、10809 等本機連接埠是否與實際設定一致。

5. 建立新群組

   在空白測試群組中匯入同一個網址，關閉包含、排除、正規表示式篩選與去重條件。

6. 驗證節點

   更新成功後再測試 TCP 與實際連線，依照 DNS、連接埠、TLS、傳輸層和路由的順序繼續定位。

如果流程停在第二步，通常是連結或帳戶狀態問題；停在第三步，通常是服務端回應或存取限制；停在第四步，通常是網路路徑與本機連接埠問題；停在第五步，通常是格式、版本或篩選問題；只有前五步都通過，才需要深入檢查節點協定與服務端設定。

常見問題