V2Ray 故障排除指南

無法上網：先找出連線中斷點

比較直連與代理兩種情況

「無法上網」不是足以判斷問題的描述。先確認是所有應用程式都無法連線、只有瀏覽器出問題，還是僅特定網站無法開啟。退出代理用戶端，還原系統原有的代理設定，再嘗試連上平常可直連的網站。如果仍無法上網，優先檢查網路連線、無線網路、閘道器，以及需要登入的網路驗證頁面。基礎網路尚未恢復時，反覆更換節點通常只會增加干擾。

確認直連正常後，啟動用戶端並選擇一個已取得合法使用權限的節點。桌面端優先使用 v2rayN，Android 裝置使用 v2rayNG；有 V2Fly 設定需求時再考慮 v2flyNG。不要同時執行多個會接管系統流量的工具。先關閉 TUN 與複雜的分流設定，只在確認支援系統代理的瀏覽器中測試一般代理路徑，以縮小問題範圍。

依照請求經過的環節逐一檢查

一般連線會依序經過應用程式代理設定、本機監聽連接埠、路由規則、節點連線與目標服務。用戶端介面能開啟，只代表管理程式仍在執行；選取節點也不代表核心已成功啟動。查看用戶端執行日誌，先確認啟動成功訊息、監聽位址與連接埠，再檢查發出請求時是否有相應紀錄。若沒有請求紀錄，先確認應用程式是否真的將流量交給用戶端。

若日誌顯示本機連接埠繫結失敗，檢查是否有另一個用戶端執行個體或其他程式占用連接埠。變更監聽連接埠後，也必須同步修改應用程式的代理連接埠。不要把本機入站連接埠誤填為遠端節點連接埠。前者接收本機應用程式的請求，後者用來連線至伺服器；即使兩者數值相同，也沒有自動關聯。

以單一變數測試，逐步找出原因

保留相同節點，只將用戶端路由暫時改為明確的代理路徑，再連線至同一目標。若問題排除，原因可能在分流規則；若仍無法連線，再換用另一個已知可用的節點，其餘設定保持不變。每次記錄調整項目與結果，避免改了許多設定後雖然恢復，卻無法判斷是哪項調整生效。測試結束後還原原本模式，避免把暫時的全流量代理當成最終設定。

若只有單一網站無法連線，先查看該服務的狀態，並用其他正常網站進行比較。網頁主文件能開啟，但圖片或登入功能失敗，可能是附屬網域走了不同路徑，也可能是目標服務拒絕目前的出口。此時應確認失敗請求的網域與路由，而不是直接判定整個節點失效。

復原的標準是能夠重複驗證：關閉用戶端後連線失敗，依既定設定啟動後恢復，而且日誌中的目標、出站與預期相符。保存這份最小可用設定，之後再逐項啟用分流、TUN 或應用程式專屬設定。連線測試的詳細步驟請參閱首次連線與真實連線速度測試指南。

節點逾時：區分連接埠、交握與通訊協定

先確認逾時發生在哪個階段

節點逾時可能發生在網域名稱解析、建立傳輸連線、TLS 交握或通訊協定驗證階段。先從日誌找出第一筆相關錯誤，不要只看最後一行籠統的連線失敗訊息。記下目標主機、連接埠、錯誤類型與發生時間。同一節點在不同網路下的結果差異，通常比單次速度測試數值更有診斷價值；測試時仍應維持相同的節點參數與用戶端模式。

TCPing 主要用來觀察連接埠是否能建立連線，無法驗證完整的代理通訊協定、驗證資訊及目標網站連線。連接埠可連線但實際請求失敗，可能是使用者識別資訊不符、傳輸路徑錯誤或 TLS 參數不一致。反過來說，某種測試方式失敗，也不代表所有實際流量都無法使用。應搭配連接埠測試與用戶端的真實連線測試，不要將兩者視為相同指標。

核對遠端位址與傳輸參數

先確認節點位址前後沒有空格，連接埠在有效範圍內，且與服務提供方提供的資訊一致。接著檢查通訊協定、使用者識別資訊、密碼、傳輸類型及附加欄位。WebSocket 的路徑與 Host、gRPC 的服務名稱都必須完全相符；看似細微的斜線或大小寫差異，也可能讓請求送到錯誤的服務。不要依照其他節點的填寫方式自行猜測欄位。

若位址使用網域名稱，先確認該網域目前能正常解析。暫時改用服務提供方確認過的位址，只能作為受控的診斷方式，不應任意修改依賴網域驗證的設定。連線位址、TLS 的 serverName 與 HTTP Host 用途不同：分別決定連線目標、驗證的服務身分，以及要送出的應用層主機名稱，不應簡單要求三者永遠相同。

處理 TLS 與 REALITY 錯誤

顯示憑證尚未生效或已過期的訊息，可能是裝置時間錯誤，也可能確實是伺服器憑證有問題。先同步系統日期、時區與時間，再確認 SNI 是否符合伺服器要求。不要把停用憑證驗證當成一般修復方式。這可能掩蓋網域填錯、憑證鏈不完整或連到錯誤主機等根本原因；即使之後可以連線，也不能證明設定正確。

REALITY 連線也要核對伺服器公鑰、shortId、serverName、指紋及服務提供方要求的 flow。欄位是否支援，取決於所選核心與用戶端實作；不能因節點名稱包含某個術語，就推定一定相容。遇到未知欄位或不支援通訊協定的訊息，先確認核心類型，再核對設定來源。相關差異請參閱Xray 與 V2Fly 核心差異。

比較不同網路並檢查伺服器

在同一裝置上，分別使用可信任的無線網路與行動數據進行測試。若只有其中一種網路失敗，檢查網路驗證、存取策略、位址類型及電信網路路徑；若所有網路都失敗，但其他節點正常，則優先檢查該節點。測試期間暫停其他下載工作，避免本機壅塞拉長交握時間。不要無限制提高逾時門檻，以免掩蓋明確無法連線的問題。

若有伺服器管理權限，確認服務程序是否監聽正確位址、主機防火牆與上游安全規則是否允許目標連接埠，並查看同一時間的服務日誌。若沒有管理權限，將已移除敏感資訊的時間、錯誤階段與測試網路提供給服務方確認。不要公開完整節點連結。若日誌只在重新連線時偶爾出現逾時，之後便持續正常，也應檢查裝置從睡眠恢復與網路切換的情況，而不是直接重裝用戶端。

完成修改後，使用相同目標連續進行幾次簡單連線，確認交握能穩定成功，再還原正常分流設定。憑證問題的詳細判斷方式請參閱TLS 憑證與 SNI 排查指南。若連接埠可連線但驗證仍失敗，請回頭核對參數，不要繼續反覆調整系統代理。

訂閱失敗：檢查取得、格式與解析

將更新流程拆成三個階段

訂閱更新分為取得網址內容、辨識內容格式，以及將節點匯入用戶端三個階段。出現更新失敗時，先判斷是網路錯誤、HTTP 狀態異常，還是內容解析失敗。原有節點仍可使用，不代表訂閱網址能正常取得；訂閱更新成功，也不代表每個新節點都能連線。兩條流程應分別驗證，不能以其中一項結果代替另一項。

在用戶端的訂閱群組中核對網址是否完整，留意複製時是否漏掉查詢參數、換行，或混入說明文字。網址中的存取憑據屬於敏感資訊，不應放進公開截圖或線上轉換網站。不要為了方便顯示而修改網址編碼；其中的百分比編碼與分隔符號可能會影響伺服器辨識。先備份原網址，再重新貼上服務提供方給的完整內容。

確認更新請求實際使用的連線路徑

部分用戶端可設定訂閱更新使用直連，或透過目前的代理連線。若直連無法連上訂閱服務，可在已有可用節點的前提下測試透過代理更新；但若目前節點已失效，繼續依賴該節點取得訂閱可能形成循環。請檢查更新設定，不要只切換瀏覽器代理。沒有可用節點時，請透過正常網路取得服務提供方提供的有效設定，避免任意使用不可信的轉換服務。

逾時通常表示連線路徑或解析可能有問題；連線遭拒可能是伺服器連接埠未開放；與身分驗證相關的狀態則應檢查訂閱權限。遇到請求頻率限制，請依服務方規定等待，不要連續按下更新。若伺服器回應錯誤，記下時間與狀態資訊，稍後再試；反覆刪除並重建群組無法修復遠端服務異常，反而可能遺失仍可用的節點。

辨識實際回傳內容，不要只看副檔名

訂閱內容可能是一組經編碼的分享連結，也可能是用戶端支援的其他結構。原生 JSON 設定、單一分享連結與訂閱網址並非相同類型的輸入，應使用對應的匯入入口。伺服器回傳的登入頁面、過期提示或錯誤頁面，即使狀態看似正常，也不是節點資料。遇到解析錯誤時，應確認實際內容類型，不要只憑網址結尾是否包含特定副檔名判斷。

分享連結中的通訊協定欄位與傳輸參數必須受到用戶端支援。有些匯入工具能辨識基本節點，卻忽略額外參數，最後造成「匯入成功但無法連線」。請比對匯入後的節點編輯頁面與原始參數，重點檢查 TLS、安全層、傳輸類型與特殊通訊協定欄位。格式差異與轉換限制請參閱訂閱格式與分享連結互轉。

更新成功後檢查清單

先取消節點清單中的搜尋與篩選，再選取剛更新的訂閱群組。有些用戶端會保留舊的作用中伺服器或清單選取狀態，導致新節點已匯入卻沒有顯示。若伺服器確實回傳空清單，應確認訂閱權限、方案狀態或服務方的節點篩選條件，不要盲目重複匯入。同一網址建立多個群組也不會增加可用性，只會讓節點來源更難追蹤。

清理訂閱前，保留一個仍可用的舊節點或設定備份。自動更新可能會覆蓋手動修改的訂閱節點；若需要長期調整，請使用用戶端支援的獨立設定或群組策略，不要依賴臨時修改永久保留。恢復後，測試一個新節點的實際連線，並確認下次更新仍能取得內容。常見匯入問題可繼續參閱常見問題。

速度慢：分辨延遲、傳輸量與應用程式等待

先釐清哪個環節變慢

網頁顯示前等待很久、檔案下載持續緩慢、影片偶爾停頓，都是不同的現象。前者可能與 DNS、建立連線或交握有關；後者則更受網路路徑頻寬、封包遺失及目標服務負載影響。先記錄發生時間、使用的網路、節點與目標類型。不要用單次短連線的延遲直接推估下載速度，也不要把瀏覽器顯示的所有等待時間都歸因於代理路徑。

選擇相同且可信任的目標，在相近時間分別測試直連與代理路徑。測試目標應能代表實際使用情境，避免將快取命中的靜態頁面與大型檔案下載直接比較。暫停背景同步、系統更新及其他裝置的大量流量工作，再觀察結果。無線訊號不穩或本機上傳頻寬已滿時，即使節點本身正常，也會出現明顯的請求排隊與回應延遲。

建立可重複的節點比較方式

保持網路與目標不變，只切換節點；接著保持節點不變，再切換網路。這樣才能分辨問題出在節點路徑還是本機網路。真實連線速度測試更接近完整請求，但結果仍受測試目標、服務負載與測試時間影響。不要同時對所有節點進行大量並行測試，這可能占用頻寬、觸發伺服器限制，也會讓測量結果失去可比性。

節點的地理名稱不代表實際端對端路徑。距離較近不一定比較不壅塞，延遲較低也不保證可用傳輸量較大。若只有特定服務速度慢，可能與出口至該服務的路徑、內容傳遞網路的選擇或目標服務的流量限制有關。此時更換出口進行比較，比反覆修改本機監聽連接埠更有意義；但仍應先排除該服務本身異常的可能。

檢查是否有多重流量接管或錯誤分流

確認系統代理、TUN、瀏覽器代理擴充功能及其他網路工具是否同時生效。多個接管層疊加可能讓連線繞路，甚至將用戶端的出站流量再次送回入站。測試時暫時只保留單一路徑。若關閉某一層後恢復，接著檢查該層的排除規則與路由，不要長期依賴來源不明的效能選項掩蓋問題。

分流錯誤也可能表現為「部分內容載入很慢」。例如主頁面直連、資源網域走代理，可能增加額外的連線建立時間；應該走代理的目標若被規則送到不適合的直連路徑，也可能反覆等待逾時。查看日誌確認實際出站，再調整相應規則。規則通常依序比對，較寬泛的規則放在前面，可能會優先於後面的精細規則；詳情請參閱路由分流設定實戰。

通訊協定與裝置資源的限制

傳輸多工、並行連線或其他進階選項並非通用的加速功能。在不同網路、目標與伺服器設定下，效果可能相反；參數不相容也可能造成連線重設。先還原服務提供方給的基本參數，確認連線穩定後，再逐一測試。不要為了縮短測試時間而停用身分驗證或安全層，這與傳輸量問題不是同一類調整。

也要留意裝置資源。低電量模式、持續過熱、CPU 長時間忙碌、磁碟空間不足，以及詳細日誌持續寫入，都可能影響用戶端回應。若介面卡頓但下載速度正常，問題可能出在管理介面或本機資源，而非遠端頻寬。關閉不必要的即時更新與長時間除錯日誌，再比較相同的連線操作。

若只有使用 TUN 時大型檔案傳輸卡住、小型請求卻正常，可考慮路徑 MTU 或封裝相關問題，但應先排除 DNS 與路由因素。只有在用戶端提供相應設定，而且了解如何還原時，才進行小範圍測試，不要任意照抄網路參數。以實際工作能持續完成且連線不反覆重設作為復原標準，並記錄測試條件，避免把某一刻的偶然峰值當成長期效能結論。

DNS 問題：檢查解析器與請求路徑

區分節點網域與目標網域

DNS 至少涉及兩個不同對象：用戶端必須先找到節點伺服器，代理請求也可能需要解析目標網站。節點網域無法解析時，連線會在進入遠端通訊協定前失敗；目標網域解析異常時，則可能出現節點已連線、部分網站仍無法開啟的情況。先從日誌確認發生問題的是哪個網域，不要看到解析錯誤就立刻替換所有 DNS 設定。

也要確認由哪個元件負責解析。應用程式可能使用系統解析器，也可能啟用自己的加密 DNS；代理核心也可能有獨立的 DNS 設定。SOCKS 請求還有由應用程式先解析，或將網域交由代理端解析的差異。因此，系統命令查詢正常，只能證明該次查詢路徑正常，不能直接代表瀏覽器或核心使用的解析路徑也沒有問題。

查看系統查詢結果

在 Windows、macOS 或 Linux 的終端機中，可以使用下方查詢指令，查看系統預設解析器對範例網域的回應。若系統沒有這項工具，使用系統內建的網路診斷介面即可，不必額外安裝不熟悉的工具。指令執行成功只代表取得查詢結果，仍須留意回傳的是 IPv4、IPv6，還是明確表示網域不存在的回應，以及是否發生查詢逾時。

nslookup example.com

排查實際故障時，應查詢日誌中的目標網域；範例網域僅用於說明語法。再與代理用戶端日誌交叉比對：系統查詢成功、核心查詢失敗時，優先檢查核心 DNS 位址與出站路徑；若系統查詢本身就逾時，則檢查本機網路、路由器或選用的解析服務。不要將憑證錯誤誤認為解析失敗，兩者發生在不同階段。

辨識解析循環與位址類型問題

若連線至某個 DNS 服務必須先使用代理，而代理節點的網域又必須依靠該 DNS 才能解析，就可能形成啟動循環。應為節點網域保留可連線的引導解析路徑，並確認 DNS 服務本身不會因錯誤路由而被送回用戶端。設定加密 DNS 時，尤其要區分服務網域解析與後續請求；不能只填入一個位址，就認定所有相依條件都已解決。

以下片段展示 V2Ray 內建 DNS 的基本結構，以及僅查詢 IPv4 的診斷方式，並非完整的代理設定。此設定仰賴目前網路能連線至列出的解析服務；不同核心支援的欄位與 DNS 路由方式也應分別確認。使用圖形介面用戶端時，請優先透過對應設定項目調整，避免直接修改日後會由用戶端重新產生的執行檔。

{
  "dns": {
    "servers": [
      "1.1.1.1",
      "8.8.8.8"
    ],
    "queryStrategy": "UseIPv4"
  }
}

只有在 IPv6 路徑明顯異常時，才暫時限制位址類型進行比較。若限制後恢復，接著檢查網路的 IPv6 可達性、路由與用戶端設定，不要把停用 IPv6 當成所有裝置都適用的固定解法。網域同時回傳多個位址時，不同應用程式可能選用不同結果，因此同一裝置上的連線表現也可能不同。

處理快取與瀏覽器個別設定

修改 DNS 後，舊快取可能使測試仍連到原本的位址。關閉並重新開啟測試應用程式，依照作業系統提供的方法清除 DNS 快取，再重新送出請求。瀏覽器的安全 DNS、應用程式內部快取與系統快取不一定會同步清除。排查時記錄清除了哪一層，避免在同一頁面反覆重新整理，卻誤以為已使用新的解析結果。

最後將目標網域、查詢方式、回傳的位址類型與實際出站路徑對照起來。若只有一個網域失敗，檢查是否有 hosts 覆寫或專屬分流規則；若所有網域都失敗，但已建立的連線仍可傳輸資料，問題較可能出在解析層。恢復後重新啟用必要的瀏覽器設定，並確認節點啟動與首次連線都能各自完成，避免留下只有快取存在時才可用的設定。

系統代理失效：檢查應用程式與本機入站

了解系統代理適用的範圍

系統代理通常是提供代理位址給支援這項設定的應用程式，並不會自動改道裝置上的所有網路連線。瀏覽器可以連線，但某個應用程式仍直接連線，可能只是該應用程式沒有讀取系統代理設定。命令列工具、背景服務、部分遊戲或內建網路元件的程式，也可能使用獨立的代理設定。先確認應用程式支援哪種連線方式，再決定使用系統代理、應用程式內代理或 TUN。

v2rayN 的系統代理狀態與路由模式並非同一概念。前者決定應用程式是否將流量導向本機連接埠，後者則決定進入核心的請求使用哪個出站。選擇分流模式不會自動為所有應用程式設定代理；啟用系統代理也不代表路由一定會選擇代理出站。兩層設定都要分別確認，不要只看系統匣選單中的單一項目。

檢查監聽位址、連接埠與通訊協定

先從用戶端設定與啟動日誌確認實際監聽位址及連接埠。只供本機使用時，通常以迴路位址較為合適。應用程式填入的 HTTP 代理連接埠，必須對應支援 HTTP 的入站；SOCKS 入口則需要相應的通訊協定支援。混合連接埠是否可用，取決於用戶端與核心設定，不應只憑其他指南提供的連接埠數字推斷。

以下片段用來說明兩個互相獨立的入站。這不是節點設定，也不包含遠端出站；連接埠僅供示範，實際使用時必須以本機設定為準。在這類設定下，應用程式須依通訊協定選擇對應連接埠。若用戶端已產生監聽設定，不要直接將片段附加進去，以免重複繫結導致整個核心無法啟動。

{
  "inbounds": [
    {
      "tag": "local-socks",
      "listen": "127.0.0.1",
      "port": 10808,
      "protocol": "socks",
      "settings": {
        "auth": "noauth",
        "udp": true
      }
    },
    {
      "tag": "local-http",
      "listen": "127.0.0.1",
      "port": 10809,
      "protocol": "http",
      "settings": {}
    }
  ]
}

檢查平台設定是否遭到覆寫

在 Windows 中查看目前使用者的代理設定，並區分手動代理與自動設定指令碼。部分應用程式讀取的網路堆疊設定不同，不要假設瀏覽器能用，就代表背景服務也使用相同代理。退出用戶端後，若系統仍指向本機連接埠，但該連接埠已沒有程式監聽，就會出現直連網路正常、應用程式卻全部顯示連線失敗的殘留狀態。

macOS 的代理設定與目前的網路服務有關。切換無線網路、有線連線或新增網路服務後，應檢查目前實際使用的服務，而不是只查看以前修改過的項目。Linux 桌面環境的代理設定也不一定涵蓋終端機與系統服務；若應用程式讀取環境變數，也要檢查舊程序是否仍保留啟動時的值。設定變更後，重新啟動測試應用程式會更可靠。

排除代理擴充功能與繞過規則

瀏覽器代理擴充功能、自動設定指令碼、應用程式內代理與系統設定可能互相覆寫。暫時關閉其他代理來源，只保留一種連線入口，觀察連線時是否有核心日誌。若仍沒有日誌，檢查應用程式的繞過清單，目標可能已被指定為直連。若已有日誌但出站路徑錯誤，應改查路由規則，不要繼續反覆切換系統代理。

TUN 可以接管更多類型的流量，但需要系統權限、虛擬網路介面與正確路由，不應在不明原因的系統代理失效時盲目改用。先確認一般入站路徑正常，再單獨啟用 TUN。復原標準是目標應用程式產生預期的請求日誌、命中正確出站，且退出用戶端後系統網路設定能如預期還原。其他模式問題可對照使用說明中的連線步驟。

用戶端閃退：分辨介面、核心與設定

先確認是哪個程序結束

視窗消失、介面沒有回應與核心退出，是三種不同問題。視窗關閉後系統匣圖示仍在，可能只是縮小到系統匣；管理介面正常但連線全數中斷，可能是核心啟動失敗；整個程式直接退出，則應檢查系統錯誤紀錄與用戶端日誌。先記錄發生問題時正在執行的操作，例如啟動、切換節點、更新訂閱或從睡眠恢復，才能縮小觸發條件。

不要一開始就刪除設定資料夾。先退出程式並確認相關程序已結束，再備份設定、訂閱群組與必要的使用者設定。日誌可以保留，但分享前要移除敏感資訊。若程式無法進入介面，仍可透過系統提供的檔案管理與診斷工具，查看最近變更的檔案和應用程式錯誤紀錄；不要從不明來源下載所謂的修復指令碼。

確認系統、處理器架構與安裝方式

重新安裝前，先確認安裝套件與作業系統及晶片類型相符。桌面版 v2rayN 的桌面版與經典 WPF 版採用不同的介面實作，系統需求應以實際安裝套件的說明為準。缺少執行環境、系統版本過舊或處理器架構不符，都可能導致程式在主視窗出現前就退出。安裝入口與平台選擇請參閱用戶端安裝套件，不要只看檔名片段自行判斷相容性。

檢查安裝目錄是否可寫入、使用者目錄是否有足夠空間，以及程式是否放在受限制的網路位置或暫存目錄。需要寫入設定的程式若無法建立檔案，可能會出現設定遺失、更新失敗或反覆退出的情況。先依照安裝方式，將程式放在適當的本機位置後再測試；不要長期以最高權限執行來掩蓋目錄權限問題。

讀取第一筆啟動錯誤

核心日誌中的連接埠遭占用、設定解析錯誤、無法讀取資源檔及不支援欄位，通常都有明確提示。先處理最早出現的有效錯誤，後續連線失敗可能只是連鎖反應。檢查是否同時啟動兩個用戶端，或舊程序仍占用監聽連接埠。關閉重複執行個體後重新啟動，比任意更換整套網路參數更容易確認原因。

手動編輯設定後發生錯誤，應優先還原最近一次變更。JSON 中的逗號、引號、陣列與物件括號都必須符合語法；語法有效也不代表目前使用的核心一定支援相關欄位。圖形介面用戶端通常會重新產生執行檔，因此直接修改產生的檔案，可能在下次啟動時被覆寫。長期自訂設定應使用用戶端明確支援的入口。

使用獨立設定重現問題

在已有備份且了解用戶端資料存放位置的前提下，使用獨立的測試資料目錄，或重新命名原資料目錄，讓程式以初始設定啟動。測試執行個體不要與原執行個體同時運作。若初始狀態正常，逐步還原一個訂閱、一個節點與必要設定；還原某項後問題再次出現，就能將範圍縮小到相應資料或功能。

若空白設定也會閃退，應優先檢查系統相容性、執行環境、安裝檔案與安全軟體的封鎖紀錄。若發現封鎖事件，先閱讀事件詳情並確認來源，不要直接關閉整套防護機制。若只有啟用 TUN 時失敗，請檢查權限與虛擬介面；一般代理可以正常運作，就表示不必清除並重建所有節點資料。

從睡眠恢復後卡住、執行很久才退出等問題，也要觀察記憶體、控制代碼、磁碟與網路切換情況。縮小自動測速、頻繁重新整理或定期更新等工作的範圍，確認問題是否由特定操作觸發。恢復後至少測試啟動、匯入、連線與正常退出四個環節，再重新啟用自動工作。整理回報時，提供用戶端名稱、系統架構、重現步驟與已移除敏感資訊的錯誤內容，不要只寫「打不開」，也不要上傳完整設定資料庫。

Android 專項：VPN 授權、背景執行與應用程式分流

區分本機 VPN 接管與遠端連線

v2rayNG 與 v2flyNG 可透過 Android 的 VPN 服務介面接收應用程式流量。系統顯示 VPN 圖示，只能證明本機接管服務正在運作，不能證明遠端節點已完成交握。先查看用戶端日誌與實際連線結果，再判斷問題層級。首次啟動時須取得系統授權；若授權遭拒，或被其他服務取代，用戶端就無法如預期接管流量。

同一使用者空間通常只能有一個作用中的 VPN 服務。其他 VPN、安全類網路工具，或使用相同介面的應用程式，可能會搶占目前連線。先停用其他接管服務，再重新啟動要測試的用戶端。系統中的「永遠開啟 VPN」與「封鎖未經 VPN 的連線」設定，也可能導致用戶端尚未啟動時整台裝置都無法上網；調整前記下原有狀態，測試後再依需求還原。

安裝套件與核心選擇

安裝時依裝置架構選擇 arm64 或通用套件。較新的主流手機通常採用 arm64，但不能只憑購買年份判斷；若不確定，請查看系統或裝置資訊，或使用提供的通用套件。安裝失敗也可能與儲存空間、安裝來源權限或既有應用程式的簽章差異有關，不要把所有安裝錯誤都歸因於網路問題。

Android 裝置可優先考慮採用 Xray 核心的 v2rayNG；需要相容 V2Fly 設定時，可選擇 v2flyNG。兩者並非只差介面不同的同一款應用程式，通訊協定特性與欄位支援須依核心判斷。包含 REALITY 等特性的節點，應先確認相應支援情況。安裝入口請參閱Android 用戶端下載；移轉前請備份必要設定，不要假設應用程式資料可以直接互通。

處理鎖定螢幕後斷線與背景程序遭終止

若前景使用正常，鎖定螢幕一段時間後失效，應優先檢查電池最佳化、背景執行與背景資料限制。不同裝置的設定名稱可能不同，請在系統應用程式管理中找到對應用戶端，允許必要的背景活動，並依裝置提供的方式避免過度節電。不要一次關閉所有應用程式的省電限制，只對需要持續連線的用戶端進行最小範圍調整。

也要區分程序遭終止與網路閒置連線失效。前者常見的現象是用戶端通知或 VPN 圖示消失；後者可能仍顯示已連線，但第一次請求需要重新連線。查看恢復前後的日誌，再決定該調整背景執行策略或節點連線。螢幕亮起後立即恢復，也可能是系統重新允許網路連線，不能只憑這個現象就判定伺服器主動中斷。

檢查依應用程式設定代理與網路切換

只有部分應用程式無法連線時，請檢查依應用程式代理的包含或排除模式。兩種模式的意思相反：選取清單中的應用程式，可能表示只代理這些程式，也可能表示略過它們。新增或重新安裝應用程式後，清單與實際應用程式識別資訊也可能需要更新。先選一個明確的測試應用程式，確認其請求出現在日誌中，再逐步還原完整清單。

從無線網路切換至行動數據後，舊連線可能因位址變更而失效。停止後重新啟動連線，觀察問題是否排除；若每次切換都會失敗，請檢查用戶端對網路變更的處理方式與系統背景限制。同時檢查數據節省模式、行動網路權限與目前使用的存取點。若只有某個無線網路無法使用，也應先完成網頁驗證，避免將網路驗證頁面誤認為節點或 DNS 故障。

手機上的 VPN 接管不一定會涵蓋分享熱點中其他裝置的流量；手機瀏覽器正常，也不能證明熱點裝置使用了相同路徑。不要為了解決熱點問題就任意開放本機監聽或擴大存取範圍。恢復後依序驗證前景連線、鎖定螢幕後連線、無線網路與行動數據切換，以及停止連線後能否正常直連。若仍有異常，請回到本頁對應的節點、DNS 或訂閱章節；若要重新確認基本流程，請返回使用說明，重新檢查匯入與連線驗證。