V2Ray 故障排解指南

建立可比較的基準

先退出用戶端或關閉系統代理，用瀏覽器造訪平時穩定可連線的網站，同時確認本機網路能正常取得位址。若直接連線也失敗，應先處理路由器、無線網路、網路線、驗證頁面或本機網路堆疊問題。代理用戶端無法修復底層網路中斷。直連正常後，重新啟動 v2rayN、v2rayNG 或 v2flyNG，保持原節點與原路由模式不變，再造訪相同網站。透過這項對照，可區分「網路本身無法使用」與「代理鏈路無法使用」。

桌面版還要區分「核心正在執行」與「系統流量已匯入核心」。v2rayN 的執行記錄中應出現本機入站成功監聽的資訊；若連接埠遭其他程序占用，核心可能啟動後立即退出，但介面系統匣圖示仍然存在。檢查設定中的本機 HTTP、SOCKS 連接埠，再確認瀏覽器或系統代理使用相同連接埠。若曾手動設定瀏覽器代理擴充功能，也要避免擴充功能仍指向舊連接埠。

1. STEP 01關閉代理，驗證直連
2. STEP 02確認核心與連接埠監聽
3. STEP 03核對系統代理位址
4. STEP 04更換節點進行對照

確認本機連接埠是否確實監聽

Windows 可在 PowerShell 中查看對應連接埠。以下以常見的本機連接埠為例，實際檢查時應替換成用戶端設定頁顯示的數值。若完全沒有輸出，表示連接埠尚未建立；若有程序記錄但程序並非目前的用戶端，則可能存在連接埠衝突。不要只憑「連接埠號看起來正確」下判斷，監聽中的程序才是有效證據。

WINDOWS / LOCAL LISTENER

Get-NetTCPConnection -State Listen |
  Where-Object { $_.LocalPort -in 10808,10809 } |
  Select-Object LocalAddress,LocalPort,OwningProcess

Get-Process -Id (Get-NetTCPConnection -LocalPort 10809 -State Listen).OwningProcess

macOS 與 Linux 可使用系統內建的網路工具查看監聽狀態。若結果只監聽於 127.0.0.1，表示只有本機程式可以存取，這是桌面單機使用時的正常範圍。只有明確需要讓區域網路裝置連入時，才考慮允許區域網路連線；排查單機故障時不應先擴大監聽範圍，因為這會增加變數，也無法解決系統代理指向錯誤的問題。

MACOS / LINUX / LOCAL LISTENER

ss -lntp | grep -E '10808|10809'
lsof -nP -iTCP:10809 -sTCP:LISTEN

依現象區分代理、路由與遠端故障

路由模式是這類症狀中最容易忽略的變數。規則模式會依網域、目標位址與規則集選擇直連或代理；全域模式通常會把更多流量交給代理出站。可短暫切換至全域模式進行診斷：若全域模式恢復正常，節點本身大致可用，問題多半集中在規則匹配或 DNS 回傳結果；若全域模式仍然失敗，則繼續檢查節點與傳輸層。診斷完成後應恢復原模式，再針對具體規則修正，不應把暫時診斷模式當成永久解決方案。

最後使用第二個已知可用的節點進行對照。只更換節點，不修改路由、DNS 與系統代理。若第二個節點恢復正常，故障位於原節點或其傳輸參數；若所有節點都失敗，則回到本機監聽、系統代理與用戶端核心檢查。透過這種單一變數替換，可避免把節點故障誤判為軟體故障，也能避免無意義地反覆安裝用戶端。

先確認伺服器位址與連接埠

開啟目前節點的編輯頁，逐項核對位址、連接埠、使用者識別碼、加密選項、傳輸方式、TLS 開關、伺服器名稱、路徑與 Host。由訂閱匯入的節點通常不需要手動改寫這些欄位；若曾為排查問題修改個別欄位，應優先重新對照訂閱的原始內容。位址欄位只能填入主機名稱或位址，不要連同協定前綴、路徑或連接埠一起貼上。連接埠必須是有效數字，並與伺服器端監聽設定一致。

當節點使用網域時，先確認本機可以解析該網域。解析成功只代表取得位址，不能證明對應連接埠可達。Windows 可使用 Test-NetConnection 檢查 TCP 建立連線；macOS 與 Linux 可使用 nc。指令中的範例網域與連接埠需替換成節點實際值。若 TCP 檢查失敗，繼續調整用戶端協定參數沒有意義，應先確認網路路徑、位址與連接埠。

TCP / REACHABILITY

Test-NetConnection server.example.net -Port 443

nc -vz server.example.net 443

測試結果需要結合情境解讀。網域可解析但連接埠失敗，可能是遠端未監聽、位址已變更、中間網路阻斷或本機安全軟體攔截；連接埠成功但用戶端仍逾時，則故障更接近 TLS、WebSocket、gRPC 或協定驗證層。不要用瀏覽器能否開啟節點網域來判斷服務是否正常，因為瀏覽器發出的是 HTTP 請求，而節點可能使用完全不同的路徑與握手格式。

檢查 TLS 與傳輸參數是否成組匹配

在 TLS 情境中，伺服器名稱通常會參與憑證與握手匹配。節點位址可以是位址值，但伺服器名稱仍需填入設定提供方指定的網域；將兩者機械式改成相同內容，可能導致握手失敗。若記錄出現憑證名稱不匹配、握手提前關閉或協定版本協商失敗，應恢復訂閱中的伺服器名稱與安全設定，不要關閉驗證來繞過錯誤。系統時間明顯不準也會影響憑證有效期判斷，因此應先讓系統時間與時區恢復自動同步。

WebSocket 節點要同時核對路徑與 Host。路徑通常以斜線開頭，大小寫與結尾字元都可能參與伺服器端匹配；gRPC 節點則要核對服務名稱。VMess、VLESS 等協定欄位不能脫離傳輸層單獨判斷：協定驗證正確但傳輸路徑錯誤，仍會在驗證前失敗。訂閱更新後若只有少數舊節點逾時，也可能是伺服器端參數已調整，而用戶端仍保留舊節點副本；應刪除舊副本後，再從訂閱重新產生。

使用對照組縮小故障範圍

準備三組對照：同一用戶端的另一個節點、同一節點使用另一條網路、同一訂閱在另一台裝置上使用。另一個節點可用，表示用戶端基礎鏈路正常；同一節點換網路後可用，表示原網路路徑存在差異；同一節點在所有裝置上都失敗，則更可能是遠端節點狀態或訂閱參數問題。每次只改變一個條件並記錄結果，三次對照通常比反覆重啟更有資訊。

延遲測試也需要正確理解。用戶端顯示的連線延遲通常是某種探測請求的完成時間，不等於所有業務流量的速度。部分節點可能不回應特定探測方式，但實際連線可用；也可能探測很快，後續 TLS 或應用程式請求卻失敗。因此應同時觀察真實網頁請求與執行記錄。遇到所有節點同時逾時時，再檢查系統時間、DNS、系統安全策略與用戶端核心是否正常載入，不要把所有節點逐一編輯。

若節點由訂閱管理，最終修復路徑應回到訂閱來源：確認訂閱仍然有效，更新後檢查節點參數是否變更，再刪除手動修改造成的重複項目。節點參數已確認無誤但遠端持續無法連線時，本機用戶端沒有可繼續修復的設定，應保留記錄中的階段資訊並更換可用節點。如此可清楚區分「遠端無法使用」與「本機設定錯誤」。

確認連結本身與更新路徑

先從訂閱管理頁複製目前連結，檢查開頭與結尾是否混入空格、換行、中文標點或重複字元。透過聊天工具轉傳的長連結可能被折行，複製時也可能只取得可見部分。不要手動解碼後再貼上，用戶端需要的是完整的原始連結。若服務方更新了訂閱位址，應刪除舊項目後重新新增，避免兩個名稱相近的訂閱並存，導致實際更新的是舊連結。

接著區分「更新訂閱時使用代理」與「直接更新」。當目前網路無法直接存取訂閱位址，而用戶端設定為直接更新時，請求會在解析或建立連線階段失敗；反過來，若用戶端強制透過已失效的節點更新，訂閱同樣無法請求。v2rayN 中可檢查訂閱更新相關的代理選項，Android 用戶端則要確認執行更新時的 VPN 連線狀態與分應用程式規則。切換更新路徑只能用於診斷，確認可用路徑後再固定設定。

1. STEP 01核對完整連結
2. STEP 02判斷是否成功發出請求
3. STEP 03辨識回應內容
4. STEP 04處理解析相容性

依回應結果判斷問題層級

如果記錄提供 HTTP 狀態，可先按類別判斷。重新導向不一定是錯誤，但用戶端需要能跟隨至最終位址；權限相關回應通常表示連結憑據、有效期或存取條件已變更；伺服器錯誤則代表訂閱端暫時未正常產生內容。狀態成功也不代表內容可解析：登入頁面、提示頁面或閘道錯誤頁同樣可能以成功狀態回傳，用戶端之後會回報格式錯誤或節點數量為零。

不要把訂閱連結貼到公開檢測頁面，也不要在求助截圖中完整顯示。連結通常具有存取憑據的作用，排查時只需記錄網域、回應狀態與錯誤類型。需要比較連結時，可以比較長度、開頭與結尾的少量字元，但應遮住中間參數。若用戶端記錄原樣輸出完整位址，分享前也要移除查詢參數。

解析失敗與節點清單為空

請求成功但解析失敗時，先確認用戶端類型。桌面版首推 v2rayN，Android 可使用 v2rayNG，v2flyNG 則是採用 V2Fly 核心的備選方案。較舊的用戶端可能不認識訂閱新增的協定欄位或傳輸選項，此時應從下載頁取得目前安裝包，再重新執行訂閱更新。不要在舊用戶端中逐一刪減陌生欄位，因為這可能讓節點表面上能儲存，實際握手仍然失敗。

節點清單為空也可能是訂閱分組、篩選或去重設定造成的。先取消名稱篩選，查看所有分組，並確認更新動作確實針對目前的訂閱。若設定依備註去重，多個同名節點可能只保留一個；若啟用自動移除舊節點，回應為空時也可能導致原清單被清除。重要設定應在更新前匯出備份；排查期間則關閉會改變清單結構的自動化規則，避免回應問題與本機篩選疊加。

如果同一訂閱在一台裝置可更新、另一台失敗，應優先比較兩端的用戶端版本、更新代理、DNS 與系統時間；如果所有裝置都得到相同錯誤，則應把重點放在連結與回應端。恢復後不要只看「更新成功」提示，還要確認節點數量合理、舊節點是否按預期替換，並隨機選擇一個節點完成實際連線。只有請求、解析與連線三步都通過，訂閱鏈路才算恢復。

使用固定對象建立對照

選擇一個直連時穩定、內容大小相對固定的網頁或檔案，分別在關閉代理、使用目前節點、使用另一節點三種狀態下測試。每次測試前等待目前下載結束，關閉佔用頻寬的同步、更新與影片工作，並保持相同網路。不要同時使用多個測速頁面取平均，因為測試端位置與連線數不同，會引入新的變數。目標不是得到漂亮數字，而是確認瓶頸會隨節點、網路還是特定目標網站而變化。

首次開啟很慢但開啟後傳輸正常，應重點檢查 DNS、TCP 建立連線與 TLS 握手；持續速率低但延遲正常，應重點檢查節點出口頻寬、鏈路壅塞與傳輸方式；速度週期性下降並伴隨重傳，通常與無線網路品質、封包遺失或路徑波動有關；只有單一網站緩慢，則可能是該網站到節點出口的路由或網站自身限制。將這些現象分開，比單看用戶端延遲更有效。

檢查本機鏈路與協定開銷

先在同一台裝置上測試直連網路。無線訊號弱、頻段擁擠、背景上傳佔滿上行頻寬，都會明顯拖慢代理連線。上行被佔滿時，確認封包與控制封包難以及時送出，即使下載頻寬仍有餘裕，網頁也會出現卡頓。可暫時關閉雲端同步、系統更新與大型檔案上傳，再使用有線網路或移至更靠近存取點的位置重新測試。如果直連本身已經不穩定，繼續切換協定通常無法得到可靠結論。

傳輸封裝會增加標頭與握手成本，但不應把所有效能問題歸因於某個協定名稱。WebSocket、gRPC、TLS 等組合的表現取決於實際路徑與伺服器設定。訂閱提供的節點參數通常是成組設計的，不要只為追求速度而手動關閉安全層或改變傳輸方式。錯誤組合可能偶爾成功建立連線，卻在持續傳輸時不斷重試。正確做法是選擇設定完整的另一個節點進行對照，而不是拆改現有節點。

路由、並行連線與測試誤差

在規則模式下，不同網域可能經由不同出站。測速頁面的主頁面、測試介面與靜態資源也可能分屬多個網域，最終測到的是混合路徑。診斷時可短暫使用全域模式，確認所有相關請求都經過同一節點；若全域模式明顯改善，應檢查規則命中情況，而不是直接判定節點效能異常。記錄中的出站標籤可協助確認請求究竟經由代理還是直連。

並行連線數同樣會改變結果。有些測速工具透過大量並行連線填滿頻寬，但實際瀏覽主要由許多短連線組成；前者數值高不代表後者一定順暢。反過來，單一連線速度低也不代表總吞吐量一定低。排查網頁緩慢應觀察 DNS 與握手，排查下載緩慢則固定單一下載物件，排查影片緩衝還要考慮內容分發節點選擇。每種情境使用相應指標，避免用一個數字解釋所有體驗。

若所有節點只在某一條網路上速度緩慢，換網路後恢復，問題更可能位於本機接入或網路路徑；若同一節點在所有裝置上都很慢，而其他節點正常，應優先更換節點；若只有特定目標緩慢，則檢查路由與目標端路徑。完成定位後，將暫時關閉的背景服務、路由模式與測試設定恢復，避免為了測速而形成不符合日常需求的設定。

辨識系統解析與內建解析

在一般系統代理模式下，應用程式可能先透過系統 DNS 取得目標位址，再將位址交給代理；部分應用程式會自行啟用加密 DNS，不再遵循系統設定；虛擬網卡模式則可能將更多 DNS 請求交由用戶端處理。三種路徑並存時，同一網域可能得到不同結果。排查前應暫時關閉瀏覽器單獨設定的 DNS 功能，讓測試路徑盡量單純，再查看用戶端記錄中是否出現對應網域。

使用系統查詢工具可以建立基準。Windows 可執行 Resolve-DnsName，macOS 與 Linux 可使用 nslookup 或 dig。先不指定伺服器，觀察系統預設結果，再與用戶端記錄中的目標位址比較。如果系統可以解析而用戶端回報解析失敗，應檢查用戶端內建 DNS 設定；如果兩者都失敗，則檢查目前網路提供的解析服務、系統網路設定與網域拼寫。

DNS / BASELINE

Resolve-DnsName example.com

nslookup example.com

dig example.com A
dig example.com AAAA

理解位址族群與路由匹配

網域可能同時回傳 IPv4 與 IPv6 位址。當前網路的 IPv6 路徑不完整時，應用程式可能優先嘗試 IPv6，等待失敗後才回退，造成首次存取明顯延遲。可透過查詢結果與連線記錄確認實際使用的位址族群，不要直接關閉整個系統的 IPv6。若用戶端提供位址策略，應選擇與本機網路能力相符的策略；修改後分別測試只回傳 IPv4 及同時回傳兩種位址的網域，確認沒有引入新的存取差異。

路由規則可以依網域匹配，也可以依解析後的位址匹配。若網域規則未啟用相應的嗅探或網域保留機制，應用程式提交的只有目標位址時，網域規則可能無法命中；反過來，過度依賴位址規則也會受到內容分發位址變化影響。診斷時應在記錄中查看命中的規則與出站標籤。暫時使用全域模式可驗證是否為規則問題，但最終修復應回到明確的網域或位址規則。

V2RAY / DNS STRUCTURE EXAMPLE

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

這段範例用於說明結構關係，不應直接覆蓋用戶端自動產生的完整設定。servers 的順序與網域範圍會影響查詢去向，localhost 代表使用系統解析路徑，queryStrategy 決定可接受的位址類型。圖形化用戶端可能在儲存時重新產生設定，因此應優先透過介面提供的 DNS 設定進行修改；只有明確了解產生邏輯時，才編輯自訂設定片段。

快取、污染結果與驗證閉環

修改 DNS 後仍取得舊位址，可能是系統、瀏覽器或用戶端快取尚未清除。Windows 可使用 ipconfig /flushdns 清理系統快取；瀏覽器需要完全退出後重新開啟；用戶端則可重新啟動核心。快取清理只應在設定變更後執行，不必每一步都反覆執行。若清理後短暫恢復又再次異常，應繼續檢查查詢實際流向，而不是把快取當成根因。

WINDOWS / CLEAR SYSTEM DNS CACHE

ipconfig /flushdns

有效的修復閉環應包含三項：系統工具能取得合理結果，用戶端記錄顯示查詢經過預期路徑，實際連線命中預期出站。只更換 DNS 位址而不確認後兩項，往往只是暫時改變結果。完成測試後恢復瀏覽器原有設定，再檢查多個應用程式，確保修復涵蓋實際使用路徑，而不是只讓某個測試頁面通過。

檢查位址、連接埠與代理類型

v2rayN 設定系統代理後，Windows 代理頁面應顯示本機位址與對應的 HTTP 連接埠。常見錯誤是把 SOCKS 連接埠填入只接受 HTTP 代理的位置，或用戶端調整連接埠後系統仍保留舊值。先在用戶端設定頁記錄 HTTP 與 SOCKS 的具體連接埠，再與系統頁面逐項比較。位址通常是回送位址；若填寫已變更的區域網路位址，離線或切換網路後就可能失效。

系統中可能還有自動設定指令碼、企業策略、瀏覽器擴充功能或其他代理軟體爭奪控制權。常見表現是用戶端剛寫入設定，幾秒後又被改回，或瀏覽器與系統頁面顯示不同代理。排查期間應暫時關閉其他會修改代理的程式與瀏覽器代理擴充功能，只保留一個控制來源。若裝置受到管理策略限制，應查看系統提示，不要透過反覆寫入登錄項目對抗策略。

WINDOWS / CURRENT USER PROXY

Get-ItemProperty 'HKCU:\Software\Microsoft\Windows\CurrentVersion\Internet Settings' |
  Select-Object ProxyEnable,ProxyServer,AutoConfigURL

輸出中的 ProxyEnable 可用於確認手動代理是否啟用，ProxyServer 顯示目前位址與連接埠，AutoConfigURL 則表示是否存在自動設定指令碼。讀取結果只用於診斷，應優先透過系統設定與用戶端介面修改，不建議直接編輯登錄項目。若用戶端退出後代理仍保持開啟，瀏覽器可能繼續向已關閉的本機連接埠傳送請求，因而出現「退出用戶端後完全無法上網」。此時關閉系統代理即可恢復直連。

區分系統代理與虛擬網卡模式

系統代理適合遵循作業系統代理介面的應用程式；虛擬網卡模式在更低層運作，可處理更多沒有代理設定的程式。兩者並非越多越好。若同時啟用且設定不當，流量可能重複進入用戶端或形成迴圈。診斷系統代理時先關閉虛擬網卡模式，確認瀏覽器能透過本機 HTTP 入站存取；需要涵蓋不讀取系統代理的應用程式時，再單獨評估虛擬網卡模式及其路由範圍。

命令列工具通常有自己的代理變數。例如某些工具會讀取 HTTP_PROXY 與 HTTPS_PROXY，但不會自動採用桌面系統代理。測試時可以只為目前終端機工作階段設定變數，不要一開始就寫入全域永久值。代理位址應使用用戶端實際的 HTTP 連接埠；關閉用戶端後也要清除變數，避免後續指令持續連線至失效連接埠。

SHELL / SESSION PROXY EXAMPLE

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

unset HTTP_PROXY
unset HTTPS_PROXY

依應用程式驗證請求是否進入核心

清空用戶端記錄，只在目標應用程式中發出一個可辨識的請求。如果記錄出現對應網域或位址，表示應用程式流量已進入核心，後續應檢查路由與出站；如果完全沒有記錄，問題仍在應用程式到本機入站之間。瀏覽器可先關閉所有代理擴充功能並重新啟動，辦公軟體與開發工具則要檢查各自的網路設定。不要因為瀏覽器可用，就推斷所有應用程式都會使用系統代理。

修復完成的標準不是系統開關顯示已開啟，而是目標應用程式的一次請求能出現在用戶端記錄中，並透過預期路由成功回傳。若記錄始終沒有請求，繼續更換遠端節點不會有效果。若請求已進入但失敗，則回到節點、DNS 或路由章節繼續排查。以記錄作為邊界，可以準確區分「應用程式沒有交出流量」與「核心沒有送達流量」。

區分介面程序與核心程序

v2rayN 桌面版包含圖形介面與實際處理流量的核心程序。介面仍可操作但所有請求失敗，可能是核心未成功啟動；介面直接關閉，則要檢查應用程式記錄與系統事件。先記錄當機發生在啟動時、切換節點時、更新訂閱時，還是開啟虛擬網卡時。能穩定觸發的動作才是定位依據，描述「偶爾當機」不如記錄「匯入某筆設定後點擊連線立即退出」有效。

檢查工作管理員或活動監視器，確認是否殘留舊核心程序。舊程序占用連接埠時，新核心可能啟動失敗；同時執行多個用戶端也可能爭用系統代理、虛擬網卡或監聽連接埠。退出所有相關用戶端，等待程序結束，再只啟動一個用戶端進行測試。若程序無法正常退出，可先儲存記錄後結束對應程序，不要直接重新啟動裝置來掩蓋殘留關係。

處理設定損壞與權限問題

若當機緊接在某次設定編輯或訂閱更新後出現，應先匯出目前設定，再建立最小測試環境。刪除最近匯入的異常節點，關閉自動啟動、自動更新訂閱與虛擬網卡，只保留一個結構明確的節點。如果最小環境可以啟動，再逐項恢復設定。不要一次複製整個舊資料目錄到新安裝位置，否則損壞設定與舊路徑會被完整帶回。

安裝目錄權限也會影響記錄、資料庫與核心檔案寫入。桌面用戶端應放在目前使用者可讀寫的位置，避免放入需要持續提升權限才能修改的目錄。若從壓縮檔執行，應完整解壓縮後再啟動，不要直接在壓縮工具的暫存檢視中執行。安全軟體隔離核心檔案時，用戶端可能只剩介面而無法連線；應查看系統安全記錄，確認檔案處置原因，再從安裝包頁面重新取得符合平台的用戶端。

Windows 桌面版與經典 WPF 版使用的介面技術不同。如果某個介面在目前系統環境中無法穩定啟動，可先確認執行環境與系統更新，再使用下載頁提供的另一個桌面入口進行對照。切換版本前保留訂閱位址與路由設定，首次啟動時使用乾淨目錄，不要覆蓋原目錄。如此可判斷問題位於介面執行環境，還是由共用設定觸發。

記錄、資源與可重現資訊

記錄層級過高可能在長時間執行時產生大量磁碟寫入，尤其是將每個連線都記錄為詳細除錯資訊時。日常使用應維持一般層級，只有在重現問題的短時間內才提高詳細程度。重現前清空舊記錄，執行一次觸發動作，隨後立即儲存。這能減少個人設定內容外洩，也避免在數萬行舊記錄中尋找真正錯誤。

還要觀察磁碟剩餘空間、記憶體使用量與系統休眠恢復。磁碟空間不足會導致資料庫或記錄寫入失敗；休眠恢復後網路介面變化，舊連線與虛擬網卡狀態可能未正確重建。若當機只發生在喚醒後，可先關閉用戶端再重新啟動，確認是否為恢復流程問題。若全新啟動也會發生，則繼續檢查設定與執行環境。

重新安裝應放在設定與環境對照之後。正確的重裝測試是：保留舊目錄不覆蓋，在新目錄啟動目前安裝包，不匯入全部舊設定，只加入最小設定。若新環境穩定，再逐步遷移訂閱與路由；若新環境仍在相同動作下當機，問題更可能與系統環境、驅動程式或特定設定格式有關。參考v2rayN Windows 安裝設定與常見問題，可進一步檢查桌面執行環境與系統代理殘留。

確認 VPN 介面與唯一占用

啟動連線時，系統應出現 VPN 授權並顯示對應狀態。Android 通常同一時間只允許一個應用程式占用系統 VPN 介面，因此其他 VPN、網路過濾工具或工作設定檔中的網路服務，可能使 v2rayNG、v2flyNG 無法建立介面。先中斷其他 VPN 類應用程式，再重新連線目前的用戶端。如果授權對話框不再出現但狀態立即關閉，可在系統 VPN 設定中移除舊授權後重試。

「始終開啟 VPN」與「封鎖未使用 VPN 的連線」是系統層級策略。設定正確時，它們可以約束流量路徑；但在用戶端核心啟動失敗、訂閱失效或節點無法使用時，也會讓裝置看起來完全斷網。排查期間先關閉這兩項，確認一般連線能恢復後，再單獨測試用戶端。完成故障定位後是否重新啟用，應依實際網路策略決定，不要把系統封鎖誤判為用戶端無法關閉。

解除背景與電池限制

部分裝置會在熄屏、切換應用程式或一段時間沒有前景活動後限制背景程序。典型現象是剛連線時正常，鎖定螢幕數分鐘後所有請求停滯，重新開啟用戶端又恢復。應在系統應用程式設定中允許用戶端於背景執行，將電池策略設為不受限制，並允許必要的背景資料。不同裝置的選單名稱可能不同，但判斷依據一致：用戶端程序在熄屏後是否仍維持，以及 VPN 狀態是否被系統回收。

不要同時為多個用戶端設定自動連線。v2rayNG 與 v2flyNG 可分別用於不同核心情境，但一次排查只執行其中一個。兩個應用程式交替爭用 VPN 權限，會造成狀態列圖示閃爍、連線剛建立就中斷，或系統始終切回另一個應用程式。先強制停止未參與測試的用戶端，再清除目前用戶端的電池限制與自動啟動策略。

檢查分應用程式、私人 DNS 與網路切換

分應用程式代理可以選擇哪些應用程式進入 VPN，也可以採用排除方式。誤解規則方向時，常見表現是瀏覽器正常但目標應用程式直連，或只有被排除的應用程式可用。診斷時先關閉分應用程式功能，讓所有應用程式走同一路徑；確認連線正常後，再逐一加入或排除應用程式。每次修改規則後，都要完全結束目標應用程式並重新開啟，避免舊連線繼續使用原本的路徑。

系統私人 DNS 與用戶端內建 DNS 可能同時生效。若私人 DNS 主機無法連線，網域請求可能在進入用戶端前就失敗；若應用程式自行使用加密 DNS，用戶端路由看到的也可能只有解析服務連線。排查時先將私人 DNS 暫時恢復為自動，關閉瀏覽器獨立 DNS，再測試系統查詢路徑。若恢復正常，再決定使用系統私人 DNS 或用戶端 DNS，盡量避免多層重複接管。

從無線網路切換至行動網路時，本機位址、預設路由與可用位址族群都會改變。部分既有連線不會自動遷移，導致 VPN 仍顯示已連線但請求停滯。切換網路後等待系統網路穩定，再中斷並重新連線用戶端。若只在某一種網路上失敗，保持節點與用戶端設定不變，重點比較該網路的 DNS、IPv6 路徑與驗證頁面。公共無線網路需要先在直連狀態完成網頁驗證，再啟動 VPN。

Android 上的訂閱更新還會受到背景資料與目前 VPN 路徑影響。更新回傳空清單時，不要立即刪除現有節點；先確認用戶端允許連網、訂閱連結完整，並分別測試連線狀態下更新與中斷後更新。v2rayNG 使用 Xray 核心，v2flyNG 使用 V2Fly 核心，訂閱中某些欄位的支援範圍可能不同。進行對照時應保持相同網路與相同訂閱，不要同時變更核心、節點與 DNS。

最後檢查應用程式記錄中的時間順序：VPN 介面是否建立、核心是否啟動、節點是否完成握手、DNS 是否回傳結果。若介面未建立，處理系統權限；介面已建立但核心退出，檢查設定與用戶端；核心正在執行但節點逾時，回到節點章節；只有特定應用程式失敗，則處理分應用程式規則。依照這個界線推進，可以避免清除整台裝置的網路設定，也能保留已驗證有效的設定。