V2Ray 疑難排解指南

01 / 應用程式 → 本機入口 → 核心 → 對外連線

無法上網：拆解連線路徑

「用戶端已連線」通常只代表本機服務已啟動，無法證明遠端驗證成功，也無法證明瀏覽器流量已進入代理。排查時先記下用戶端名稱、作業系統、目前伺服器別名、系統代理模式、路由模式及 Tun 狀態，再記錄無法連線的網站和發生時間。不要一開始就刪除設定或重設網路；原始記錄與設定是判斷問題所在的依據，清除後便難以比較前後差異。

先確認基本網路，再檢查本機入口

結束用戶端並還原原本的系統網路設定，測試平常可直接連線的網站。若直連也失敗，先檢查無線網路是否需要登入網頁認證、網路線是否鬆脫、網卡是否取得 IP 位址，以及系統是否留有手動代理設定。啟用代理時，公共網路的認證頁面可能無法顯示；請先完成認證再啟動用戶端。若只有某個網站直連失敗，還不足以證明整體網路異常，至少再測試另一個不同的目標交叉確認。

基本網路正常後，重新開啟 v2rayN，選取已匯入且參數完整的伺服器，先關閉 Tun，只測試系統代理這條路徑。檢查用戶端設定中的本機監聽位址與連接埠，並確認核心啟動記錄沒有錯誤。下列命令僅適用於本機連接埠確實為 10808，且入口接受 HTTP 代理的情況；若連接埠不同，請替換成實際值。這項測試可排除瀏覽器是否讀取系統代理的變因，但不會略過核心路由規則。

curl.exe --proxy http://127.0.0.1:10808 --connect-timeout 10 --max-time 20 --head https://example.com/

命令若傳回網站回應標頭，即使狀態表示存取受限，通常也代表請求已抵達某個 HTTP 服務；仍須搭配憑證與回應內容確認目標。若無法連上本機連接埠，優先檢查核心是否正在執行，以及連接埠是否一致。若代理通道建立失敗或遠端交握錯誤，請轉查伺服器連線環節。HTTP 入口不可當成 SOCKS 入口使用；協定設定錯誤時，即使連接埠可連線，請求仍無法正確解析。

利用記錄區分入口、對外連線與目標網站

開啟 v2rayN 的記錄視窗，記下目前時間，只連線一次目標網站，再查看新增的相關記錄。完全沒有相關記錄，可能是應用程式沒有使用代理，也可能是目前記錄層級不會記錄正常請求；不能單憑「沒有記錄」就判定流量未進入。可暫時提高記錄詳細程度，並用明確指定代理的命令交叉比對。記錄顯示連線遭拒，代表已連到某個端點，但服務未接受連線；若持續等待直到逾時，則還要檢查位址、網路路徑與伺服器狀態。

若明確指定代理後連線成功、瀏覽器卻失敗，請檢查瀏覽器擴充功能、自訂代理及安全 DNS 設定，再依系統代理章節檢查應用程式是否接管流量。若所有代理請求都失敗，但直連正常，優先改用來自不同設定來源的可用伺服器。若只有單一網域連線失敗，先檢查該網域的路由比對與解析結果，不要立即更換整份訂閱。伺服器、目標網站與用戶端是三個不同對象，應分別驗證。

最後關閉臨時除錯記錄，恢復所需的系統代理或 Tun 模式，再開啟一開始無法連線的應用程式。瀏覽器可能沿用舊連線，必要時請完全結束後重新開啟。記下「哪一項變更讓結果不同」，比只記「重開後就好了」更有用；前者能在故障重現時快速定位，後者則無法區分網路偶然恢復或設定修正。

02 / 位址 → 連接埠 → 傳輸 → TLS → 驗證

節點逾時：定位交握階段

節點測試顯示逾時，不代表伺服器一定離線。測試可能要先解析伺服器網域，再建立傳輸連線、完成安全交握與協定驗證，最後才向測試網址送出請求。任何一步失敗都會影響結果。先確認使用的是 TCP 連線測試、實際連線測試，還是網頁速度測試；它們涵蓋的連線路徑不同。尤其採用非 TCP 傳輸的設定，一般 TCP 探測無法直接代表實際協定是否可用。

先核對伺服器端點，別急著改協定

在伺服器編輯視窗核對位址與連接埠，確認位址欄沒有帶入 https://、路徑或尾端空白，連接埠則須符合伺服器實際監聽的設定。若使用網域位址，先確認能否解析；若使用 IP 位址，則要確認是否仍為目前的服務位址。Windows 可用下列命令測試 TCP 是否可連通，範例網域請換成自己的伺服器位址。測試成功只代表 TCP 連線已建立，不代表協定驗證、TLS 或目標請求也能完成。

Test-NetConnection -ComputerName example.net -Port 443

測試失敗時，在不修改設定的前提下，改用手機熱點等其他網路進行比較。若另一條網路測試成功，優先調查原網路的對外連線、防火牆或路由限制；若兩條網路都失敗，再檢查伺服器監聽狀態、入口防火牆及位址是否已失效。若沒有伺服器管理權限，請將失敗時間、端點及錯誤階段提供給設定提供者，不要持續隨機更換連接埠。連接埠與伺服器設定不一致，只會造成新的故障。

區分 TLS、傳輸參數與協定驗證

連上連接埠後仍然失敗，請查看記錄是否出現憑證驗證、交握、驗證或傳輸路徑相關錯誤。TLS 設定須核對伺服器名稱，也就是常見的 SNI 欄位，並確認系統時間正確。憑證名稱通常不必與連線使用的 IP 相同，但必須符合伺服器憑證及設定要求。使用 WebSocket 時還要核對路徑與 Host；使用 gRPC 時則要核對服務名稱。把這些欄位一律填成位址欄中的網域，並不是通用的修復方法。

REALITY 設定除了伺服器位址，也須依來源核對公鑰、短識別碼及伺服器名稱等欄位。REALITY 與一般 TLS 憑證設定不同，不應套用相同參數。VLESS、VMess 與 Trojan 的身分欄位也不能互換。更新訂閱後，舊伺服器項目可能仍留在其他群組中；請確認目前選取的是新項目，而不只是別名看起來相同。憑證錯誤的詳細排查步驟，請參閱系統時間與 SNI 疑難排解筆記。

不要長期略過憑證驗證來掩蓋交握故障，也不要為了消除逾時而不斷延長等待時間。逾時門檻只會影響多久後判定失敗，無法修復錯誤位址或驗證參數。每修正一個欄位，就重新發起一次實際連線，確認記錄已進入下一階段。若連接埠可連通、交握成功，但測試網址失敗，問題可能已轉移到伺服器對外連線、DNS 或測試目標本身；請更換目標交叉驗證，而不是繼續修改用戶端身分資訊。

03 / 取得訂閱 ≠ 連線伺服器

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

訂閱更新是獨立的網頁請求，使用的網路路徑未必與目前伺服器相同。先分辨「沒有下載到內容」與「已下載內容但用戶端無法匯入」。前者通常與位址、網路、帳戶狀態或憑證有關；後者可能是回傳頁面不正確、格式不符或欄位不受支援。更新失敗時請保留既有伺服器，不要刪除群組；舊設定有時仍可建立連線，有助於恢復取得訂閱的網路路徑。

核對位址與訂閱群組

在 v2rayN 的「訂閱群組」中開啟相應群組設定，核對訂閱網址是否複製完整，尤其要檢查問號後的查詢參數、尾端字元，以及是否誤帶換行。訂閱連結中的權杖屬於存取憑證，請勿貼到公開記錄、截圖或線上解碼工具。從聊天視窗複製文字時可能一併帶入標點；富文字連結顯示的名稱也可能不是真實網址，建議重新使用設定提供者提供的複製功能取得連結。

確認正在更新的群組與編輯的群組相同，再試用「更新訂閱（不透過代理）」。若本機網路能連到訂閱服務，這個方式可避免依賴已失效的伺服器。若直連請求逾時，而目前代理已經過實際連線驗證，再嘗試透過代理更新。兩種方式都失敗時，請分別記錄錯誤；不要只因按鈕名稱不同，就認定用戶端一定採用預期的對外路徑，還須搭配記錄與目前代理狀態判斷。

依回傳內容選擇處理方式

若出現未授權或禁止存取，通常須核對帳戶狀態、訂閱權杖與伺服器權限；重複按更新不會改變權限。若提示請求過於頻繁，請停止連續重試，等候伺服器允許的間隔後再試。若出現憑證錯誤，請檢查裝置時間與憑證鏈。若請求成功卻提示沒有可用伺服器，可能取得的是登入頁、維護頁、驗證頁或其他用戶端格式；HTTP 請求成功不代表訂閱內容正確。

訂閱內容可能是用戶端支援的分享連結集合或編碼資料，並非看到一段文字就能通用匯入。不要自行變更其他設定格式的名稱後匯入，也不要把訂閱網址填進「從剪貼簿匯入分享連結」，期待所有用戶端都能自動辨識。請依來源提供的用戶端類型選擇匯入入口。若訂閱中的新欄位無法辨識，可先到下載頁核對用戶端，再備份設定後更新用戶端，避免直接手動修改整份訂閱內容。

更新完成後確認目前項目

更新結束後，查看群組中的伺服器是否符合預期，再重新選取要測試的項目。有些群組設定會保留舊伺服器或目前選取項目，不能只看「更新完成」就認為所有項目都已替換。別名相同也不代表位址、連接埠與安全參數相同。若更新後馬上無法連線，先比較新舊設定的協定、傳輸與安全選項，再向來源確認是否遷移伺服器或調整參數。

若只有排程更新失敗、手動更新成功，請檢查排程執行時用戶端是否已啟動、系統是否尚未連上網路，以及代理是否還沒有可用伺服器。啟動順序造成的失敗，不需要修改訂閱格式。恢復後請完整測試一遍：手動更新成功、群組內容可見、選取新項目、實際瀏覽網頁成功。首次建立訂閱群組的操作仍請參閱快速入門教學；本章只處理這條連線路徑中斷的位置。

04 / 分開測量傳輸量、等待時間與穩定性

速度慢：建立可比較的測試條件

「速度慢」至少包含網頁首次開啟慢、持續下載慢、影片緩衝及連線間歇中斷四種情況。首次開啟慢通常與 DNS、交握及建立連線有關；持續下載慢較可能是頻寬、壅塞或目標限速；中途斷線則還要檢查無線網路、裝置休眠及伺服器連線策略。先記下問題發生在哪個步驟，再選擇合適的測試方法。延遲低不代表傳輸量高，單次測速結果也不能代表所有網站的速度。

固定網路、目標與測試時段

測試時使用同一部裝置、同一個網路、同一個檔案或網頁，並暫停系統更新、雲端硬碟同步及其他大量傳輸工作。盡量使用有線網路或訊號穩定的無線網路進行比較，避免把無線干擾誤判為伺服器問題。連續測試數次並記錄時段，不要同時測速大量伺服器；並行測試會占用本機頻寬，也可能觸發遠端的連線數量限制。測試完成後等連線結束，再進行下一組比較。

先比較直連可連線目標的基本表現，再比較代理路徑的表現。若兩組目標不同，只能用來判斷本機網路是否普遍異常，不能直接計算代理造成的速度損失。若要公平比較兩台伺服器，應使用相同目標與相同請求方式。某個下載來源可能依來源位址限速，也可能只提供較慢的對外路線；因此「換伺服器後比較快」只能證明這組搭配較合適，不一定代表原伺服器整體效能不足。

分開檢查解析等待與傳輸等待

若每次首次開啟網頁都要等很久，但之後下載正常，優先檢查 DNS 逾時、IPv6 回退及 TLS 交握。瀏覽器開發人員工具中的網路時間軸可區分解析、連線、等待回應與下載內容等階段；使用代理時，部分階段可能由代理完成，解讀數值須搭配實際連線路徑。可用明確指定代理的命令排除瀏覽器擴充功能影響，再依DNS 章節比較解析路徑。不要只因首次開啟慢，就直接修改緩衝區或執行緒數。

若持續傳輸速度偏低但網頁回應正常，請改用另一個不同的下載來源，確認是否只有特定目標較慢。再換一條本機網路，判斷瓶頸是在本機對外連線還是遠端路徑。路由策略也會影響結果：原本應直連的大型檔案若被規則送進代理，可能繞遠路；原本應經代理的目標若被錯誤直連，也可能反覆等待重試。測試期間可暫時切換路由模式進行比較；確認後應修正具體規則，不要長期忽略分流需求。

只有症狀符合時才調整進階參數

不要把啟用多工視為必要設定。實際效果取決於核心、協定與伺服器支援情況；多工可能減少部分連線開銷，也可能在封包遺失時影響多個請求。UDP 轉送能否使用，同樣取決於用戶端、對外協定、伺服器及網路條件，無法靠單一開關保證。語音或遊戲異常時，應先確認應用程式是否真的經過代理，以及 UDP 路徑是否已建立，再決定是否調整；不要只看網頁能不能開啟。

Tun 情境中，若小型網頁正常、大型請求卻卡住，可檢查路徑 MTU，但這只是可能原因之一，不能據此直接下定論。先關閉 Tun，改用明確指定的代理進行比較；只有差異能穩定重現時，再參考用戶端目前提供的 MTU 設定逐步調整，並保留原值。公司網路、虛擬機器及多層隧道都會改變有效封包大小，照抄他人的數值未必適用。每次調整後都要重新測試相同的大型請求。

若問題只在固定尖峰時段出現，請保留不同時段的比較記錄並回報服務提供者。用戶端無法修復上游壅塞或遠端出口容量不足。測試完成後，請還原記錄層級、路由與暫停的應用程式，避免除錯環境與日常使用環境差異過大，造成測試正常、實際使用仍然緩慢。

05 / 伺服器解析與目標網域解析是兩條不同路徑

DNS 問題：確認由哪一端解析

先區分伺服器網域與目標網站網域。用戶端必須先取得伺服器位址，才能連線到遠端；目標網站的網域則可能由應用程式、作業系統、核心或遠端解析。瀏覽器啟用安全 DNS 後，也可能使用自己的解析路徑。因此，系統命令能解析網域，不代表代理核心取得相同結果；透過代理成功開啟網頁，也不代表系統 DNS 已恢復。排查第一步應釐清實際路徑，而不是立即更換解析器位址。

分別驗證系統與核心的解析結果

Windows 可使用下列命令查看系統查詢結果。記下回應中的位址類型、是否逾時，以及換網路後結果是否改變。網域有多個有效位址不一定是異常；內容傳遞服務可能依地區及網路回傳不同結果。直接用 IP 位址瀏覽 HTTPS 網站也不是可靠的替代測試，因為伺服器可能依賴網域進行憑證驗證及虛擬主機選擇；出現憑證錯誤，不能直接證明原本的網域解析有問題。

Resolve-DnsName example.com

接著查看核心記錄是否出現解析逾時、解析器無法連線或沒有可用位址。若伺服器位址本身是網域，而遠端 DNS 又必須透過尚未建立的代理，可能形成啟動依賴循環：連線代理需要先解析網域，解析網域卻又需要先連上代理。請依用戶端提供的引導解析或伺服器網域解析設定解除依賴，確保啟動階段所需位址能透過目前網路取得；不要把所有解析請求都強制送進尚未建立的隧道。

了解網域策略如何影響分流

路由中的 AsIs、IPIfNonMatch 與 IPOnDemand，控制的是路由比對時如何使用網域解析結果，不能簡單理解成三種「DNS 速度模式」。AsIs 不會為這個步驟主動將網域轉成 IP；IPIfNonMatch 會在網域規則未命中時解析網域，再嘗試比對 IP 規則；IPOnDemand 則在比對需要 IP 的規則時才觸發解析。實際對外連線仍可能需要解析，不能把路由策略等同於所有 DNS 行為。

以下是核心路由欄位的局部範例，不是完整設定，也不應直接覆蓋用戶端產生的設定檔。範例展示先比對網域分類，再比對位址分類的概念；需要已有對應的地理資料檔案，以及名為 direct 的對外連線。透過 v2rayN 編輯路由設定時，請確認用戶端確實將規則寫入目前使用的路由集合。規則順序及其他較早執行的規則仍會影響最終結果。

{
  "routing": {
    "domainStrategy": "IPIfNonMatch",
    "rules": [
      {
        "type": "field",
        "domain": ["geosite:cn"],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "ip": ["geoip:cn"],
        "outboundTag": "direct"
      }
    ]
  }
}

檢查瀏覽器快取、IPv6 與 Tun 接管

若只有瀏覽器異常，請檢查瀏覽器安全 DNS、擴充功能及快取；若所有應用程式都異常，再檢查系統與核心。IPv6 解析成功不代表目前網路具備可用的 IPv6 對外連線；反過來說，停用 IPv6 也不是通用修復方法。應先比較位址類型與連線記錄，確認是否有某一類位址持續連線失敗，再調整用戶端的解析或對外連線策略。修改後可能需要等待快取到期，或重新啟動相關應用程式，避免繼續沿用舊結果。

Tun 的 DNS 接管是否生效，取決於用戶端實作、系統路由及應用程式行為；不能認為啟用 Tun 後，所有 DNS 都必定走相同路徑。若記錄出現異常的虛擬位址，先確認是否啟用了 FakeDNS 類機制，不要直接把該位址寫進系統 hosts。清除快取前先記下舊結果，修改解析設定後再進行比較。關於前綴與比對順序的詳細說明，請參閱自訂路由規則筆記；直連、代理與阻斷的具體分流組合，請參閱直連、代理與阻斷設定。

06 / 分開檢查系統設定、應用程式設定與虛擬網卡

代理無效：檢查流量接管方式

系統代理是一組供應用程式讀取的設定，不是所有流量都必須經過的總開關。Tun 則透過虛擬網路介面與路由接管流量，兩者作用的層級不同。排查時先只啟用一種方式：桌面瀏覽器優先從「自動設定系統代理」開始，確認本機入口與遠端連線都正常後，再測試 Tun。兩種方式一起啟用，又同時修改 DNS，會讓故障原因混在一起，很難判斷是哪一層的變更造成結果不同。

確認系統設定與應用程式實際讀取的設定一致

在 v2rayN 底部狀態列選擇「自動設定系統代理」，再進入作業系統的代理設定，確認是否確實填入本機位址與連接埠。連接埠必須與用戶端監聽入口一致，不能只確認位址是回送位址就結束。若系統設定會自行還原，請檢查是否有其他代理程式、瀏覽器擴充功能、裝置管理原則或安全軟體正在改寫設定。不要讓多個用戶端同時管理系統代理，也不要反覆搶用同一組設定。

Windows 下有些命令列程式和背景服務不會使用桌面系統代理；部分程式讀取環境變數，另一些則使用獨立的代理設定。瀏覽器能連線、命令列卻失敗，不一定代表用戶端有問題。請先依應用程式文件設定代理，或使用支援明確指定代理參數的請求進行比較。macOS 的代理設定與目前網路服務相關；切換無線網路、網路線或其他服務後，應檢查目前生效的服務，而不是只查看之前設定過的服務。

使用單一入口排除連接埠與略過清單問題

檢查系統代理的略過清單，以及瀏覽器是否為目標網域設定直連規則。內部網路位址直接連線通常是合理設定，不要只為了讓記錄出現項目，就強迫所有內部網路流量送到遠端。若目標被略過，請依實際用途修改特定規則。其他裝置若要連到本機代理，則是另一種情境，牽涉監聽位址、防火牆與存取控制；不要為了解決本機瀏覽器問題而隨意開啟區域網路監聽。

Tun 失效時先檢查權限與路由

先關閉其他 VPN 或隧道程式，再依用戶端提示授予建立虛擬介面及修改路由所需的權限。Windows 通常需要系統管理員權限；其他桌面平台則依目前用戶端的權限提示操作。啟用 Tun 後，請查看記錄確認介面確實建立，不要只看開關是否亮起。若系統要求權限時取消對話框，介面狀態可能無法即時反映底層結果，應以記錄和實際介面狀態為準。

若一啟用 Tun 就無法上網，先關閉 Tun 並確認網路恢復，再檢查多張網卡、虛擬機器網路、企業連線軟體及殘留路由。若遠端伺服器的連線被錯誤地重新導入自己的隧道，可能形成迴圈；DNS 接管衝突也可能讓所有網域看起來都無法使用。不了解路由用途時，不要大量刪除系統路由。請優先使用用戶端的正常停止功能還原設定，再逐一停用衝突程式進行比較，並保留恢復方式。

修復後，分別測試需要代理的應用程式、區域網路服務及系統網路連線檢查。系統網路圖示顯示異常，可能只是其檢查目標無法連線，應以實際請求結果判斷。主視窗狀態列、記錄及參數設定的位置，請參閱v2rayN 主介面說明。最後應清楚記下日常使用方式：哪些應用程式會讀取系統代理、哪些需要個別設定，以及何時才需要 Tun。

07 / 分別處理圖形介面啟動與核心啟動

啟動失敗：保留現場再恢復

雙擊後沒有視窗、視窗開啟後立即關閉，以及介面正常但核心停止，是三種不同問題。先查看工作管理員是否已有用戶端程序，確認視窗是否縮到系統匣，或移到已中斷連線的顯示器。不要連續雙擊啟動多個執行個體；它們可能搶用本機連接埠或設定檔，讓單一故障變成多執行個體衝突。需要結束程序時先記錄錯誤，再正常退出；只有程式沒有回應時才考慮強制結束。

確認安裝格式、處理器架構與可寫入的目錄

請到用戶端下載頁核對作業系統與處理器架構。Windows 桌面版與經典 WPF 版採用不同的介面技術，所需執行環境也可能不同，應以安裝檔說明與啟動提示為準，不要把另一版本的相依需求當成通用答案。Linux 還須區分 deb 與 rpm 套件格式；macOS 則先確認是 Apple Silicon 還是 Intel。架構不符、作業系統版本未達需求或缺少相依項目，都無法靠修改伺服器參數解決。

若使用解壓縮版程式，請先完整解壓至目前帳戶可寫入的目錄，不要直接在壓縮檔預覽視窗中執行，也不要只複製主程式而漏掉附帶檔案。若設定寫入失敗，請檢查目錄權限、磁碟剩餘空間及同步軟體是否占用檔案。安全軟體攔截時應查看具體記錄，確認被處理的是哪個檔案；不要為了啟動程式而全面關閉裝置防護，也不要從不明來源下載所謂缺少的元件。

核心啟動失敗：從第一個錯誤開始處理

圖形介面正常但核心無法啟動時，先查看記錄中最早出現的錯誤，而不是最後一行「已停止」。連接埠遭占用、設定語法錯誤、未知欄位、缺少地理資料檔案及權限不足，處理方式都不同。若本機監聽連接埠衝突，先查明占用程序，不要直接結束不熟悉的系統服務。Windows 可用下列命令查看連接埠與程序；範例連接埠仍須符合用戶端實際設定。

Get-NetTCPConnection -State Listen -LocalPort 10808 |
  Select-Object LocalAddress, LocalPort, OwningProcess

Get-Process -Id 1234

第二個命令中的程序識別碼僅為範例，請替換成第一個命令查到的值。若占用者是另一個用戶端執行個體，請結束重複執行個體；若是必須保留的程式，可修改本機監聽連接埠，並同步更新系統代理與應用程式內的代理設定。只修改其中一處，會讓啟動問題變成入口連線失敗。若查詢沒有結果，也要留意錯誤訊息指向的可能是其他監聽連接埠，不要直接假設所有衝突都發生在同一個連接埠。

設定錯誤應依記錄指出的對象與欄位定位。JSON 多餘的逗號、錯誤的資料型別及未閉合的引號都會造成解析失敗；能通過 JSON 解析器，也不代表符合核心欄位要求。自訂片段必須與所用核心相容，Xray 與 V2Fly 支援的欄位不能直接互換。用戶端產生的執行設定可能在重新啟動後被覆寫，請回到用戶端設定或自訂設定入口修改，不要只編輯暫存輸出檔案。

用最小化設定判斷是否為使用者資料問題

還原前先備份訂閱群組、路由、自訂 DNS 及必要的使用者設定，並妥善保護其中的訂閱憑證。結束程式後，依用戶端支援的方式使用獨立設定目錄，或重新命名原設定目錄，再以最小化設定測試；程式仍在執行時不要移動資料庫。若乾淨設定能啟動，請逐項還原設定：先還原一台伺服器並驗證，再還原路由及進階選項。一次匯入整份舊資料，可能也會把故障一併帶回來。

若最小化設定仍然閃退，請查看作業系統的應用程式錯誤記錄、權限提示與執行環境資訊，再考慮重新安裝。提交問題記錄時，請註明重現步驟與錯誤文字，並隱去身分欄位、訂閱網址及個人目錄中的敏感資訊。更多設定錯誤範例，請參閱核心啟動失敗記錄診斷。恢復成功的標準不只是視窗能開啟，還包括核心持續執行、本機入口可連線，以及結束後重新開啟時設定仍然正確。

08 / VPN 授權 → 應用程式範圍 → 背景執行 → 網路切換

Android 專項：連線與背景斷線

Android 優先使用 v2rayNG；確實需要 V2Fly 核心時再考慮 v2flyNG。兩者支援的設定功能與欄位可能不同，排查時不要直接用同一份複雜設定互相覆蓋。先確認安裝檔與裝置架構相符；主流新款裝置通常採用 arm64，但仍應以裝置系統為準。不確定時，請查看下載頁的通用套件說明。安裝失敗時先查看系統提示的原因，不要修改安裝檔或繞過系統簽章檢查。

取得 VPN 授權後，仍須驗證遠端連線

首次連線時允許系統 VPN 授權，並確認系統是否顯示相應連線。若已有其他 VPN 應用程式正在執行，請先中斷該連線，再測試 v2rayNG。Android 通常只允許同一使用者或個人資料環境中的一個一般 VPN 服務占用該連線位置；兩個應用程式反覆接管可能造成看似隨機的斷線。系統顯示鑰匙圖示，代表本機 VPN 服務已建立，不表示伺服器驗證成功，也不表示訂閱中的每個設定都可用。

在 v2rayNG 中選取目標設定後連線，開啟應用程式記錄，只進行一次實際網頁瀏覽。若顯示伺服器解析失敗，先依 DNS 章節檢查；若交握失敗，則依節點逾時章節核對傳輸與安全參數。需要比較時，先用相同設定分別測試無線網路與行動數據，不要換網路時順便更換伺服器。行動數據流量限制、漫遊權限及系統網路控管也可能影響結果，請在系統設定中逐項確認。

檢查應用程式分流代理與系統私人 DNS

若只有某個應用程式無法連線，請開啟分應用代理設定，確認目前採用的是「僅代理選取的應用程式」還是「略過選取的應用程式」。勾選相同應用程式，兩種模式的結果正好相反。檢查目標應用程式是否位於工作資料夾、應用程式分身或其他使用者空間；這些環境可能不在目前 VPN 的接管範圍內。修改應用程式清單後，依用戶端要求重新建立連線，並完全結束目標應用程式後再試，避免舊連線繼續沿用原路徑。

系統「私人 DNS」或「專用 DNS」的名稱會因裝置而異，也可能與用戶端內建 DNS、瀏覽器安全 DNS 一起影響解析。若問題只在特定網路出現，請先記下原設定，再暫時切換為系統自動模式進行比較，接著檢查用戶端的網域策略與解析器是否可連線。不要同時修改三個位置；否則即使恢復連線，也無法判斷問題出在哪項設定。若網頁能開啟、單一應用程式卻失敗，還應檢查應用程式本身的代理與網路限制。

鎖定畫面後斷線：優先檢查背景管理

若前景使用正常、鎖定畫面一段時間後失效，優先檢查電池最佳化、背景活動權限、自動啟動限制及系統數據節省模式。允許用戶端持續在背景執行，並確認系統沒有禁止它在背景使用行動數據。不同裝置廠牌的設定位置各異，請依系統實際選單操作，不必找名稱完全相同的選項。將應用程式留在最近使用清單，不能取代所有背景權限；仍須比對鎖定前後的記錄與連線狀態，確認服務是否遭到終止。

若系統支援「永遠開啟 VPN」，可等基本連線穩定後再評估是否啟用。「沒有 VPN 時封鎖連線」會改變斷線後的網路行為：用戶端停止時，系統也可能封鎖一般網路連線。排查時應記下此選項的狀態，避免把系統主動封鎖誤認為伺服器故障。若要暫時恢復直連，應先了解並調整相應策略，而不是只關閉用戶端的連線按鈕。受組織裝置管理原則控管的裝置，請依管理規定操作。

切換網路後短暫等待或需要重新連線，可能與舊連線、位址變更及系統網路恢復有關；若每次切換都持續無法連線，請檢查 VPN 是否會自動重建、伺服器網域是否重新解析，以及新網路能否連上遠端連接埠。最後請在常用應用程式中實際測試，不要只依賴應用程式內的延遲測試。初次匯入與連線步驟請參閱設定教學；若要更換安裝格式，請返回Android 用戶端下載，並先備份現有設定。