V2Ray 無法連線
故障排除大全

先建立可重現的診斷順序

先判斷故障發生在哪一層

V2Ray 用戶端的一次連線至少會經過基礎網路、用戶端介面、代理核心、遠端節點、系統代理或虛擬網卡、DNS 解析及目標應用程式七個環節。頁面無法開啟只是最終表現，不能直接表示節點失效。基礎網路中斷、核心未啟動、系統代理指向舊連接埠、節點參數不一致、網域解析異常，都可能產生相似結果。有效的排查方式不是反覆切換所有開關，而是先確認故障邊界：關閉用戶端接管後，一般網路能否存取；用戶端日誌是否出現核心啟動成功；本地監聽連接埠是否存在；節點連線是在建立 TCP 時失敗，還是在 TLS 或協定握手階段失敗；受影響的是只有瀏覽器，還是所有應用程式。

建議先記下四項現場資訊：使用的平台與用戶端、故障開始前做過的變更、受影響的應用程式範圍，以及日誌中第一次出現的錯誤。記錄「第一次錯誤」比複製最後幾十行更有價值，因為後續的連線關閉、重試失敗通常只是連鎖結果。若問題發生在更新訂閱後，也應保留舊設定檔群組，不要立即刪除。舊設定檔可以運作而新設定檔不行，排查範圍就能直接縮小到訂閱內容或新參數；新舊設定檔都無法運作，則應優先檢查網路、系統代理與用戶端執行狀態。

用最小變數法重現

每輪測試只改變一項條件，並在變更後完整重新連線。例如測試節點時，先固定相同網路、相同用戶端和相同路由模式，只切換一個節點；測試系統代理時，先固定一個已知可連線的節點，再分別比較「關閉系統代理」、「自動設定系統代理」和「TUN 模式」。若一次同時更換節點、更新訂閱、切換核心並修改 DNS，即使恢復連線，也無法知道真正起作用的是哪一項，之後故障仍會重複出現。

最小測試環境應盡量簡單：關閉重複執行的代理工具，退出會修改網路堆疊的除錯軟體，暫停瀏覽器中的獨立代理設定，暫時使用用戶端預設路由。桌面端優先使用 v2rayN 作為基準測試；Android 可在 v2rayNG 與 v2flyNG 中依訂閱所需核心選擇。用戶端安裝來源與架構不確定時，先到下載頁核對平台和安裝類型。不要在核心無法啟動的情況下繼續研究路由規則，因為所有上層測試都會失去意義。

讀取日誌時掌握階段關鍵字

日誌應按階段理解，而不是只搜尋「error」。出現監聽位址與連接埠，表示核心已讀取設定並開始接收本地連線；出現連線遭拒，通常表示目標連接埠沒有服務或中間設備主動拒絕；出現逾時，表示在規定時間內未完成連線；出現憑證網域不相符、握手失敗或伺服器名稱相關提示，應檢查系統時間、SNI、TLS 與傳輸設定；出現 DNS 查詢失敗，則先處理解析鏈。日誌可能包含伺服器位址和訂閱資訊，轉交他人前應刪除帳號識別資訊、驗證欄位及完整訂閱網址。

啟用用戶端後完全無法上網

先區分基礎網路故障與代理接管故障

第一步是關閉 v2rayN 的系統代理或中斷 Android 用戶端連線，但不要急著刪除設定。接著用瀏覽器造訪平時可以正常開啟的網站，並測試區域網路閘道。關閉代理後仍無法存取，表示故障位於基礎網路、無線連線、閘道或系統 DNS，繼續切換節點沒有意義。關閉代理後立即恢復，則表示用戶端接管了流量，但本地代理沒有正確轉送。常見原因包括核心未啟動、系統代理連接埠與實際監聽連接埠不一致、所選設定不可用，以及路由將所有請求送往錯誤出口。

桌面端還要觀察故障影響範圍。瀏覽器和系統元件都失敗，優先檢查系統代理；只有某個應用程式失敗，檢查該應用程式是否忽略系統代理、是否儲存了獨立代理位址；區域網路位址也無法存取，檢查路由模式是否錯誤地代理了私有位址。TUN 模式下所有應用程式一起斷網，則重點查看虛擬網卡、路由表、DNS 接管和執行權限。不要把「系統代理」和「TUN」視為同一項功能：前者主要為遵循系統代理設定的應用程式提供入口，後者透過虛擬網卡接管更廣泛的網路流量，兩者的故障點不同。

確認本地核心與監聽連接埠

v2rayN 介面顯示已選取伺服器，不等於代理核心已成功執行。切換設定後查看日誌開頭，確認核心設定載入完成，並出現本地 SOCKS 或 HTTP 監聽資訊。如果日誌提示位址已被占用，通常是另一個用戶端程序、上次異常結束留下的背景程序，或其他軟體占用了相同連接埠。先退出重複用戶端，再透過系統工具查看連接埠占用情況。Windows 可以在終端機執行以下命令，將範例連接埠替換為用戶端設定中顯示的本地連接埠：

netstat -ano | findstr LISTENING
netstat -ano | findstr :10808
tasklist /fi "PID eq 程序編號"

macOS 與 Linux 可使用 lsof -iTCP -sTCP:LISTEN 或 ss -lntp 查看監聽狀態。若連接埠沒有出現，回到第二章處理核心啟動錯誤；若連接埠存在，再測試系統代理是否指向相同連接埠。修改連接埠後必須重新套用系統代理，只改變用戶端監聽值而不更新系統設定，會讓應用程式繼續連線到舊連接埠並出現連線遭拒。

檢查路由模式與錯誤殘留

排查階段先選擇用戶端提供的基礎路由模式，不要從複雜的自訂規則開始。若「繞過區域網路及中國大陸位址」模式可以運作，而自訂模式完全斷網，應檢查規則順序、預設出站和網域比對。路由通常依序命中，過於寬泛的阻擋規則放在前面，會截斷後續代理規則；只定義局部規則卻沒有合理的預設出口，會讓未匹配流量的去向不明。恢復連線後再逐條加回規則，每次至少測試網域、純 IP、區域網路位址三類目標。

Windows 在用戶端異常結束後可能保留系統代理。此時瀏覽器仍會嘗試連線到已停止的本地連接埠，表現為退出軟體後所有網站都無法開啟。重新啟動 v2rayN 並關閉系統代理，或進入系統網路設定關閉手動代理即可。macOS 需要檢查目前網路服務的網頁代理與安全網頁代理是否仍啟用；Linux 桌面環境還可能分別儲存 HTTP、HTTPS 與 SOCKS 設定。處理殘留設定時，只清理目前確認由用戶端設定的代理項目，不要任意重設全部網路設定。

節點逾時、連線遭拒與握手失敗

分開處理三類錯誤

「逾時」、「連線遭拒」和「握手失敗」指向不同階段。逾時表示用戶端發起連線後長時間未取得預期回應，可能是位址無法到達、連接埠遭過濾、鏈路丟包或伺服器沒有回應；連線遭拒通常表示目標主機可達，但指定連接埠沒有服務，或中間設備明確回傳拒絕；握手失敗則表示基礎連線可能已建立，問題發生在 TLS、協定驗證、傳輸層或伺服器名稱驗證階段。若把三種情況都視為「節點失效」，就會錯過本機時間、SNI、傳輸路徑和參數複製錯誤。

先固定一個節點進行原始網路測試。網域節點要分別確認網域能否解析、解析結果是否穩定，以及連接埠是否能建立 TCP 連線。Windows 可使用 PowerShell 的 Test-NetConnection，macOS 與 Linux 可使用 nc。這些測試只判斷網路與連接埠，不驗證 VMess、VLESS、Trojan 或 TLS 參數，因此連接埠可達不代表完整代理一定可用，但連接埠不可達時應先處理位址、網路和伺服器狀態。

Test-NetConnection example.com -Port 443

nc -vz example.com 443

範例網域需要替換為設定中的伺服器位址。若網域無法解析，請轉到 DNS 章節；若解析正常但連接埠持續逾時，可換一個網路做對照。同一節點在不同網路下結果不同，表示問題更可能位於目前的網路路徑；所有網路都失敗，而同一訂閱中的其他節點可用，則該節點本身或節點參數更值得懷疑。

逐項核對協定與傳輸參數

手動設定時，伺服器位址、連接埠、使用者識別碼、加密方式、傳輸類型、路徑、Host、TLS、SNI 和指紋等欄位必須與伺服器端一致。雖然匯入訂閱會自動填入，但更新失敗、格式轉換或舊設定殘留仍可能造成欄位不完整。檢查時不要只比較位址和連接埠。WebSocket 路徑多一個斜線、gRPC 服務名稱不同、TLS 開關不一致、SNI 使用錯誤網域，都可能讓 TCP 連線成功後立即中斷。

TLS 相關錯誤首先檢查系統日期、時間與時區。憑證有效期判斷依賴本機時間，偏差過大時會判定尚未生效或已過期。接著核對 SNI 是否為憑證涵蓋的網域，而不是任意填寫伺服器 IP。不要把略過憑證驗證當作常規解決方法，它只會掩蓋網域、憑證或伺服器設定問題。詳細的憑證錯誤類型可繼續閱讀TLS 憑證錯誤排查清單。

理解用戶端測試與實際存取的差異

用戶端中的連通性測試、延遲測試和實際網頁存取可能使用不同的請求方式。某個測試失敗但網頁可用，不應只憑測試結果刪除節點；測試成功但網頁無法開啟，則要檢查系統代理、DNS 與路由接管。排查時應以實際應用程式請求和核心日誌為主，同時記錄測試方式。不要比較單次測試的瞬間結果，應在相同網路、相同路由和接近的時間重複驗證。

如果同一訂閱群組中的所有節點同時出現握手失敗，應優先檢查系統時間、用戶端核心、訂閱內容是否發生結構變更，以及目前網路是否影響共同使用的網域或連接埠。如果只有單一節點失敗，重點核對該筆設定。若 v2rayN 在切換核心類型後開始報錯，應確認設定使用的協定特性是否受到目前核心支援。Xray 與 V2Fly 具有共同來源，但對部分協定擴充的支援並不完全相同，不能只替換核心名稱就假定所有設定相容。

訂閱更新失敗或匯入後清單為空

先確認訂閱請求是否真正送出

訂閱更新涉及訂閱網址解析、網路請求、伺服器回應、內容解碼和設定轉換等多個階段。提示「更新失敗」時，先查看日誌中的 HTTP 狀態、逾時資訊或格式錯誤。請求逾時通常表示目前網路無法存取訂閱網址，或更新請求沒有按預期經過可用代理；回傳未授權或禁止存取，通常與連結失效、帳號狀態或存取限制有關；回傳成功但清單為空，則要檢查回應內容是否為用戶端支援的訂閱格式。

複製訂閱網址時要保留完整查詢參數。聊天工具、筆記軟體或瀏覽器網址列可能截斷末尾字元，也可能將特殊字元轉換成可見文字。建議從原始來源重新複製，再在用戶端中覆蓋原網址。訂閱網址屬於帳號憑證的一部分，不應發布到公開頁面或截圖中。為訂閱群組設定名稱只影響本地識別，不會修復遠端連結；同名群組也不代表兩個連結的內容相同。

區分直連更新與透過代理更新

部分環境下需要透過已可用的代理存取訂閱網址。如果用戶端目前沒有任何可連線設定，而更新又依賴代理，就會形成「需要訂閱才能連線、需要連線才能更新」的循環。解決方式是保留一個已知可用的舊設定，先連線後更新；或依服務提供者提供的方式匯入初始設定。不要在更新失敗時立即清空全部伺服器清單，因為舊設定往往是恢復訂閱請求的唯一基準。

v2rayN 的訂閱更新選項可能允許使用系統代理或目前代理，具體行為應配合日誌確認。若日誌中的訂閱請求直接逾時，而瀏覽器在啟用代理後可以開啟相同網域，表示用戶端更新路徑可能未經過代理。Android 上還要確認 v2rayNG 或 v2flyNG 在背景執行更新時擁有網路權限，且未被系統的資料限制阻擋。切換無線網路與行動網路進行對照，可以快速判斷是否為目前接入網路的問題。

處理「更新成功但沒有節點」

更新成功只表示請求和解析流程沒有拋出明顯錯誤，不代表內容包含有效節點。先檢查群組是否套用了篩選、節點是否進入其他群組，以及介面是否保留搜尋關鍵字。取消篩選後仍為空，再查看回應內容類型。常見訂閱可能是經過編碼的連結集合、結構化設定或用戶端專用格式；如果伺服器回傳登入頁面、錯誤說明或空白文字，用戶端可能只顯示無法識別格式。

當舊節點在更新後全部被取代，可查看訂閱設定中的更新策略。覆蓋更新適合由訂閱統一維護的群組，本地手動修改的節點則不應混在同一個自動覆蓋群組中。若需要保留本地參數，先複製到獨立群組，再執行更新。關於桌面端和 Android 端的標準匯入入口，可參考訂閱連結匯入步驟；自動更新間隔、代理更新與失敗原因可參考訂閱更新失敗處理方法。

連線成功但速度慢或波動明顯

先排除測試方式造成的誤判

速度問題要在可比較的條件下判斷。單一網頁載入緩慢可能來自目標網站、瀏覽器擴充功能、快取或圖片資源，不等於代理鏈路整體變慢。建議選擇相同網路、相同裝置和相同下載目標，分別測試關閉代理、啟用代理且固定節點，以及切換另一個節點三種狀態。每輪測試前停止背景同步、大型檔案更新和雲端硬碟工作，並避免同時執行多個測速工具。比較重點是穩定吞吐量、首次連線時間和長連線是否中斷，而不是只看一次瞬間峰值。

如果關閉代理也很慢，先處理本地無線訊號、路由器負載和電信商鏈路。直連正常而所有節點都慢，檢查用戶端路由、TUN、DNS 與裝置資源；只有單一節點速度慢，則更可能是該節點線路、壅塞或遠端負載。桌面端與 Android 在同一網路使用相同設定時都很慢，可以降低裝置因素的優先級；只有一台裝置變慢，則檢查該裝置的省電、背景限制、虛擬網卡和安全軟體。

分清延遲、頻寬與丟包

延遲影響連線建立和互動回應，頻寬影響持續傳輸速度，丟包會導致重傳和明顯波動。三者不是同一項指標。連線建立較慢但持續下載穩定的節點，可能延遲較高但頻寬足夠；初始回應快速但傳輸反覆下降的節點，可能存在壅塞或丟包。用戶端的基礎測試只能提供有限參考，最終仍應以實際使用情境驗證。不要根據一次延遲排序而頻繁自動切換節點，頻繁切換會中斷既有連線，也會讓排查樣本失去一致性。

協定封裝、TLS、傳輸方式和路由路徑都會增加額外負擔，但通常不應只憑協定名稱判斷速度。相同協定在不同伺服器、網路與時段的表現可能完全不同。先選擇參數正確且連線穩定的節點，再比較網路路徑。若日誌中持續出現連線重設、重試或寫入逾時，速度下降可能是連線品質問題，而不是裝置運算能力不足。

檢查 TUN、MTU 與路由繞行

TUN 模式會接管更多流量，也增加虛擬網卡、DNS 和路由處理環節。系統代理模式正常而 TUN 明顯變慢時，先檢查是否存在其他虛擬網卡、重複路由或安全軟體過濾。某些網路下 MTU 不合適會表現為小型網頁可開啟、大型檔案卡住或特定網站載入不完整。不要任意把 MTU 調至極端值，應先恢復用戶端預設值，再依目前網路逐步測試較小值，並在每次修改後重新連線。

分流規則也可能造成繞行。目標網域先被遠端 DNS 解析成與預期不同的位址，再被 IP 規則二次匹配，可能改變出站方向。複雜規則集之間存在重疊時，應查看日誌中的路由命中結果。排查階段可暫時使用簡單模式，確認速度恢復後，再逐項加入網域規則、IP 規則和遠端 DNS。規則越多不代表判斷越準確，清楚的優先順序比規則數量更重要。

檢查裝置資源與並行連線

桌面端出現高資源占用時，先確認消耗資源的是介面程序、代理核心還是其他應用程式。大量並行連線、持續輸出日誌、TUN 接管和即時安全掃描都可能增加負載。關閉不必要的詳細日誌，減少重複執行的用戶端，並確認系統沒有同時啟用多套代理。Android 裝置在省電模式、溫度較高或背景受限時，連線可能被降頻或暫停；將用戶端加入允許背景執行的範圍後再測試。

如果速度慢只發生在特定應用程式，檢查應用程式是否使用 QUIC、獨立 DNS 或內建代理。可暫時比較瀏覽器與系統下載工具的表現，判斷問題是否局限在應用程式層。若所有應用程式在固定時段同時變慢，記錄發生時段、網路類型和節點群組，不要不斷修改用戶端。穩定重現後，才能區分本地設定與外部鏈路變化。

DNS 解析失敗、污染快取與分流錯位

辨識 DNS 故障的典型表現

DNS 問題常表現為網域無法開啟但直接存取已知 IP 有回應、部分網域間歇性失敗、用戶端日誌出現 lookup 或 resolve 錯誤，以及切換網路後短暫恢復。也可能出現更隱蔽的分流錯位：網域解析成功，但回傳位址被錯誤規則匹配，導致流量走向與預期不同。排查 DNS 時要同時回答三個問題：查詢由誰發起、傳送至哪個 DNS，以及解析結果如何參與路由。

先關閉代理測試系統 DNS，再啟用用戶端比較結果。Windows 可使用 nslookup 或 PowerShell 的 Resolve-DnsName；macOS 可使用 dig，並透過 scutil --dns 查看系統解析器；Linux 可使用 resolvectl query 查看 systemd-resolved 的查詢結果。測試時記錄網域、回傳位址和使用的伺服器，避免只寫「DNS 不通」。

nslookup example.com
Resolve-DnsName example.com

dig example.com
scutil --dns

resolvectl query example.com
resolvectl status

清理快取前先保存證據

系統、瀏覽器、用戶端核心和應用程式都可能快取解析結果。立即清空所有快取雖然有時能暫時恢復，但會失去判斷線索。建議先比較系統工具與瀏覽器結果：系統工具回傳正常而瀏覽器失敗，檢查瀏覽器安全 DNS、擴充功能和自身快取；系統工具與用戶端日誌結果不同，檢查用戶端內建 DNS；所有工具都失敗，再檢查目前網路提供的 DNS 和網路連通性。

確認需要清理後，Windows 可執行 ipconfig /flushdns；macOS 可以重新啟動目前網路服務或刷新系統解析快取；Linux 則依實際使用的解析服務重新啟動對應元件。清理後應重新發起查詢並記錄結果。如果每次清理只能短暫恢復，表示根因不是快取本身，而是上游 DNS、規則或網路持續回傳異常結果。

核對用戶端 DNS 與路由的關係

V2Ray 設定中的 DNS 不只是「填入一個伺服器位址」。查詢可能依網域規則選擇本地或遠端解析器，回傳的 IP 又可能繼續參與 IP 路由匹配。如果網域先以本地解析，但存取流量依代理規則傳送，解析結果與代理出口看到的目標可能不一致；如果啟用 fake DNS 或 TUN DNS 接管，還要確認虛擬位址能被核心正確還原。排查時先關閉複雜的網域分流與 fake DNS，使用一條明確的解析路徑驗證，再恢復進階設定。

以下範例展示 Xray 風格設定中的簡化 DNS 結構。實際伺服器位址與查詢策略應依網路環境設定，重點是保留清楚的本地與遠端職責，並讓路由規則與 DNS 標籤相互對應：

{
  "dns": {
    "servers": [
      {
        "address": "1.1.1.1",
        "domains": ["geosite:geolocation-!cn"]
      },
      {
        "address": "223.5.5.5",
        "domains": ["geosite:cn"]
      }
    ],
    "queryStrategy": "UseIP"
  }
}

設定範例不能直接覆蓋現有的完整設定，因為核心類型、規則資源和網路條件可能不同。若目前用戶端由訂閱管理，優先透過介面中的 DNS 與路由設定調整，避免手動編輯後被下一次訂閱更新覆蓋。使用 V2Fly 核心的 v2flyNG 時，也要確認相關欄位屬於目前核心支援範圍。

處理瀏覽器與系統結果不一致

現代瀏覽器可能啟用獨立安全 DNS，從而繞過系統解析路徑。若系統命令可以解析、瀏覽器卻連到錯誤位址，先在瀏覽器網路設定中確認解析方式，並暫時關閉擴充功能做對照。某些應用程式會快取連線和解析結果，即使系統 DNS 已更新，舊程序仍會繼續使用原結果；完全退出應用程式後重新開啟，比只重新整理頁面更可靠。

TUN 模式下如果只有網域失敗而純 IP 請求可達，檢查 DNS 流量是否被虛擬網卡接管、53 連接埠是否被其他軟體占用，以及系統中是否存在多個啟用中的網路介面。無線、網線、虛擬網卡同時連線時，系統可能將 DNS 請求傳送到優先級較高但不可用的介面。先停用無關介面進行驗證，再調整長期使用的介面優先順序。

系統代理未生效、部分應用程式不走代理

確認系統設定與用戶端監聽一致

系統代理的本質，是將支援該設定的應用程式請求導向本地 HTTP 或 SOCKS 連接埠。用戶端顯示「系統代理已啟用」時，仍要核對系統設定中的位址和連接埠是否與核心實際監聽一致。通常本機位址應指向回送介面，連接埠應與 v2rayN 設定頁和日誌中的監聽連接埠相同。若曾修改連接埠、切換設定目錄或同時執行多個執行個體，系統可能仍保留舊值。

Windows 可在系統網路代理頁面查看手動代理，也可用命令檢查 WinHTTP 狀態：

netsh winhttp show proxy

需要注意，Windows 的使用者層級系統代理與 WinHTTP 代理並不完全相同。瀏覽器能透過使用者代理存取，不代表系統服務或命令列工具會使用相同設定。macOS 的代理依網路服務儲存，切換無線網路與網線後應分別檢查；Linux 桌面環境、終端機環境變數和個別應用程式也可能各自維護代理設定。排查時要先確認目標應用程式讀取哪一套設定。

處理只有部分應用程式直連

部分應用程式不遵循系統代理，或只支援 HTTP 代理而不讀取 SOCKS 設定。此時節點和核心可以完全正常，但應用程式流量仍會直接連線。先用瀏覽器驗證本地代理，再檢查目標應用程式是否提供獨立代理選項。若應用程式支援代理，填入用戶端的本地監聽位址和對應協定連接埠；若不支援且確實需要接管，可評估使用 TUN 模式。不要為了一個應用程式修改所有路由規則，先確認它是否進入本地代理入口。

命令列工具通常會讀取環境變數。暫時測試時可以只在目前終端機設定，關閉終端機後便會自動失效。以下範例使用本地 HTTP 連接埠，連接埠應替換為用戶端實際值：

set HTTP_PROXY=http://127.0.0.1:10809
set HTTPS_PROXY=http://127.0.0.1:10809

export http_proxy=http://127.0.0.1:10809
export https_proxy=http://127.0.0.1:10809

前兩行適用於 Windows 命令提示字元，後兩行適用於 macOS 與 Linux 常見 shell。測試結束後清除變數，避免日後用戶端未執行時仍指向失效連接埠。應用程式內代理、環境變數與系統代理疊加時，通常以應用程式自身設定優先，因此系統設定正確卻仍失敗時，要檢查應用程式是否儲存了舊代理。

區分 PAC、全域代理與 TUN

PAC 或自動設定模式會依規則決定哪些請求使用代理，適合遵循系統代理並支援自動設定的應用程式。全域系統代理通常會將更多受支援的請求交給本地連接埠，但仍無法涵蓋完全忽略系統代理的程式。TUN 透過虛擬網卡處理更廣泛的流量，代價是需要正確的路由、DNS 和權限設定。選擇模式應依應用程式範圍決定，不應把 TUN 當成修復所有問題的第一步。

若 PAC 模式下部分網站不走代理，而全域模式可以，問題多半在 PAC 規則、快取或應用程式對 PAC 的支援。先刷新系統代理設定並重新啟動目標應用程式，再核對規則匹配。若全域系統代理也不生效，但直接在應用程式中填入本地連接埠可以運作，表示系統設定未被該應用程式讀取。若啟用 TUN 後所有應用程式都斷網，回到第二章檢查虛擬網卡與路由，而不是繼續修改節點。

用戶端無法啟動、閃退或核心反覆結束

先區分介面程序與核心程序

v2rayN 由圖形介面與代理核心協同運作。介面可以正常開啟，但核心可能因設定錯誤、連接埠占用或權限問題立即結束；反過來，核心殘留在背景時，重新開啟介面又可能提示連接埠占用。排查時先觀察工作管理員或系統程序清單，確認是哪個程序結束。介面閃退應查看應用程式日誌與系統事件，核心結束則優先查看用戶端日誌中啟動命令之後的第一個錯誤。

設定檔損壞是常見原因之一。若問題發生在匯入新節點、編輯路由或更新訂閱後，先切回先前可用的設定。不要直接刪除整個設定目錄；先複製備份，再讓用戶端以新的空白設定啟動。空白設定可以啟動、原設定載入即結束，表示問題集中在設定內容或資料庫。空白設定也無法啟動，則檢查執行環境、權限、檔案路徑和安全軟體處理記錄。

檢查連接埠、路徑與執行權限

核心啟動時需要讀取設定、載入規則資源、建立日誌並監聽本地連接埠。安裝目錄沒有寫入權限、路徑被同步軟體鎖定、檔案被其他程式占用，都可能導致啟動失敗。桌面端建議將用戶端放在目前使用者可讀寫的一般目錄，避免直接從壓縮檔預覽視窗執行。下載平台或架構選錯也可能造成程式無法執行，可前往下載頁重新核對 Windows、macOS、Android 與 Linux 對應入口。

連接埠占用可依第二章的方法查看。若發現舊核心程序，先正常退出用戶端，等待程序結束後再啟動；程序無法結束時，才透過系統工具停止。不要藉由不斷更換隨機連接埠來掩蓋重複程序，因為系統代理和應用程式內代理可能仍會指向舊連接埠。修改連接埠後要同步更新系統代理，並檢查防火牆是否允許本地回送通訊。

處理升級後啟動異常

升級用戶端後出現異常，常見原因包括舊設定欄位與新介面不相容、執行相依元件變更、核心檔案未完整替換或舊程序仍在占用檔案。先完全退出用戶端和核心，再重新啟動。若仍然失敗，備份訂閱網址、路由與必要設定，使用新目錄啟動目前安裝包，然後逐項匯入。不要直接將舊目錄全部覆蓋到新目錄，否則可能把損壞檔案和不相容設定一併帶回。

v2rayN 桌面版與經典 WPF 版的介面技術和平台範圍不同，遇到顯示或執行環境問題時，應先確認使用的是哪一個版本，而不是在兩個版本的目錄之間混用設定檔。兩者差異可參閱v2rayN 桌面版與 WPF 版選擇說明。切換版本前備份訂閱與自訂規則，再用獨立目錄測試，就能避免舊檔案干擾。

分析閃退是否由資源或規則觸發

用戶端只在更新訂閱、測速或啟用 TUN 時結束，表示故障可能由特定操作觸發。訂閱包含大量設定時，解析、去重與測試會造成更高的瞬間資源占用；複雜路由資源載入失敗，也可能讓核心啟動後立即停止。先關閉自動測速與自動更新，使用單一手動設定驗證基本執行，再逐項恢復功能。若只在某一訂閱群組發生，保留日誌並檢查該群組是否含有異常欄位。

日誌持續快速增加會占用磁碟並影響執行。排查時可以短時間啟用詳細日誌，重現後立即恢復一般等級，並保存關鍵片段。不要長期保留包含完整連線資訊的除錯日誌。若系統磁碟空間不足，用戶端可能無法寫入設定或更新資源，應先釋放空間並確認目錄可寫入。

建立可復原的設定管理習慣

穩定執行後，應分別保留訂閱網址、自訂路由和用戶端設定的備份，避免把所有復原希望都放在同一個程式目錄。更新前記錄目前使用的用戶端類型、核心類型和關鍵連接埠，出現問題時才能準確回復。備份內容應放在受控位置，不要公開分享訂閱網址或驗證欄位。

如果用戶端能以空白設定穩定執行，建議依以下順序逐項恢復：先加入單一節點並驗證連線，再加入訂閱，接著恢復系統代理設定，最後加入自訂 DNS、路由和 TUN。每一步都啟動一次並查看日誌。如此即使再次閃退，也能明確知道是哪一類設定觸發，不必從整個目錄重新猜測。

Android 上的連線中斷與背景限制

確認虛擬網路授權與用戶端狀態

v2rayNG 與 v2flyNG 在 Android 上通常透過系統虛擬網路介面接管流量。首次連線或系統重設授權後，系統會要求確認連線權限。用戶端介面顯示正在啟動卻沒有建立有效連線時，先查看是否有被遮住的授權對話方塊，再確認狀態列中的虛擬網路狀態。若另一個網路工具正在占用同類介面，需要先中斷舊連線，再啟動目前的用戶端。

匯入設定後必須明確選取一個節點。訂閱群組存在不表示已選取可連線設定；更新成功也不代表核心已啟動。連線後開啟日誌，確認核心載入設定、建立本地入口並嘗試連線遠端。若日誌在啟動階段直接回報設定錯誤，先使用一個結構簡單的節點驗證，不要同時啟用分應用程式代理、複雜 DNS 和自訂路由。

處理鎖定螢幕後斷線與背景遭停止

Android 的省電策略可能在鎖定螢幕、待機或記憶體不足時限制背景程序。典型表現是前景使用正常，鎖定螢幕一段時間後連線失效，重新開啟用戶端又恢復。應在系統的電池與背景管理中允許 v2rayNG 或 v2flyNG 持續執行，並確認未被自動休眠。不同裝置的設定名稱各異，但判斷方法一致：保持相同節點，分別測試亮屏前景、短時間鎖定螢幕和長時間鎖定螢幕，觀察用戶端程序與連線狀態是否被系統停止。

只把應用程式鎖定在最近使用的工作列表中不一定足夠，還要檢查背景網路、資料節省和省電限制。無線網路在休眠時被關閉，也會造成連線中斷；切換到行動網路後，用戶端可能需要重新建立連線。網路切換後短暫重新連線屬於正常過程，若長時間沒有恢復，可手動中斷再連線，並查看日誌是否仍在使用舊網路介面。

檢查分應用程式代理與繞過設定

分應用程式代理允許只接管指定應用程式或排除部分應用程式，但選擇邏輯設定錯誤時，會出現「瀏覽器可用、其他應用程式直連」或相反結果。先關閉分應用程式功能，驗證全域接管是否正常；正常後再啟用，並確認目前模式是只代理選取的應用程式，還是繞過選取的應用程式。應用程式更新、重新安裝或工作設定檔空間可能改變應用程式識別碼，原有清單不一定仍能匹配。

若只有系統元件或某個應用程式無法連線，檢查它是否被排除、是否使用獨立 DNS，以及是否限制虛擬網路。不要透過不斷切換節點來處理明顯的應用程式範圍問題。修改分應用程式清單後應重新連線，使路由規則完整重新載入。工作設定檔與主要使用者空間可能擁有獨立網路策略，應分別驗證，不要假定一處設定會對所有空間生效。

在無線網路與行動網路之間做對照

同一節點在無線網路可用、行動網路逾時，或結果相反，表示設定本身可能有效，差異來自接入網路、DNS、位址族群或 MTU。分別記錄兩種網路下的網域解析、連線錯誤和使用的傳輸方式。若行動網路優先使用 IPv6，而節點網域回傳的位址無法到達，可檢查用戶端位址策略與 DNS 查詢策略；若無線網路存在需要網頁驗證的入口網站，應先關閉用戶端接管完成驗證，再重新連線。

網路切換時舊連線可能仍保留在原介面，導致短時間內請求失敗。先等待用戶端自動重新連線；仍未恢復時，中斷並重新連線一次。若每次切換都必須重新啟動應用程式，檢查系統是否限制背景網路變化通知，並確認用戶端沒有被凍結。不要頻繁清除應用程式資料，這會刪除訂閱、群組和路由設定，卻不一定能解決網路切換問題。

選擇 v2rayNG 與 v2flyNG 的排查基準

Android 首先依設定所需核心選擇用戶端。v2rayNG 使用 Xray 核心，適合需要 Xray 相關協定特性的設定；v2flyNG 使用 V2Fly 核心，可作為對應生態系設定的選擇。兩款用戶端同時安裝時，不要同時連線，也不要假定同一設定在不同核心下具備完全一致的支援。對照測試應固定網路和節點，只更換用戶端，並記錄具體錯誤。

若 v2rayNG 能連線而 v2flyNG 不能，或結果相反，先核對對應核心是否支援該協定與傳輸特性，而不是將問題歸因於手機網路。關於 Xray 與 V2Fly 的功能邊界，可閱讀Xray 與 V2Fly 核心差異。需要重新安裝時，前往Android 下載入口選擇與裝置架構相符的版本，保留原有訂閱資訊後再遷移。