V2Ray 用戶端
故障排除

無法上網：先區分底層網路與代理連線

停用代理，確認原本的網路是否正常

v2rayN → 清除系統代理，並關閉 Tun 模式；v2rayNG → 停止連線。先前往平常可直接開啟的網站，確認目前網路是否需要網頁驗證。公共 Wi-Fi 即使顯示已連線，也可能尚未完成登入；此時代理用戶端成功啟動，不代表裝置已能連上網際網路。若關閉用戶端後仍無法瀏覽，請優先檢查 Wi-Fi 訊號、路由器的網際網路連線狀態及系統網路設定，不要繼續修改節點參數。

切換至另一種網路重新測試，但不要變更節點或用戶端設定。例如從 Wi-Fi 切換至行動數據，觀察能否直接存取網站。若只有某種網路無法使用，排查範圍便可縮小至該網路的登入驗證、DNS 解析與存取政策；若所有網路都不通，則繼續檢查裝置本身。測試期間請暫停其他會接管網路的程式，尤其是其他 VPN、網路加速工具及具備代理功能的安全軟體，以免彼此覆寫路由。

依序檢查「核心啟動、節點連線、流量接管」

重新開啟用戶端，先查看日誌是否出現核心結束、設定載入失敗或連接埠遭占用。介面顯示正在執行，只代表前端仍在運作，核心程序可能已停止。確認核心能持續執行後，對目前的節點進行真實連線測試，再用瀏覽器實際開啟網頁。真實連線失敗時，請參閱節點逾時；測試通過但瀏覽器仍無法使用，則應優先檢查系統代理、應用程式代理及 DNS，不必立即更換協定。

桌面版可暫時關閉 Tun，只保留自動設定系統代理，減少變數。若此時瀏覽器恢復正常，而啟用 Tun 後失敗，請優先檢查虛擬網卡建立、執行權限及路由衝突。反之，Tun 可用但系統代理無效，通常應確認應用程式是否會讀取系統代理，以及系統設定中的位址和連接埠是否仍指向目前的用戶端。兩種方式無法互相證明所有設定都正確，因為它們接管流量的位置不同。

用少量網站測試，區分整體故障與單一網站故障

選擇兩個不同的網站，並同時觀察其他應用程式。若只有一個網站無法開啟，可能是目標服務維護、帳號受限、憑證錯誤或對應路由規則異常。瀏覽器出現憑證警告時，請先確認系統日期與時區，不要把關閉憑證驗證當成一般修復方式。若只有一個應用程式失敗，請檢查該應用程式的代理設定、獨立 DNS 與快取；所有應用程式都同時失敗，才較可能是共用連線路徑或系統接管層的問題。

網路恢復後，先退出用戶端一次，確認系統代理能正常清除，再重新連線測試。異常結束時留下的代理位址，可能讓下次開機後看起來仍然無法上網。不要直接重設整套網路：先保留故障發生時間附近的日誌與原始設定，只有在證據指向系統層時，才擴大處理範圍。基本流程也可參考首次連線檢查筆記交叉確認。

節點逾時：區分連線、交握與測試目標

先確認逾時發生在哪個環節

節點清單 → 真實連線測試，接著開啟日誌，查看同一時間的錯誤。連線逾時通常表示某個步驟未能在指定時間內完成，不代表伺服器已永久失效。網域解析失敗、無法連上伺服器連接埠、加密交握失敗，以及代理建立後測試目標沒有回應，都可能導致測試失敗。先查看錯誤所處階段及目標位址，再決定下一步；只看清單上的單一結果，很容易把不同原因混為一談。

若日誌停在連線伺服器位址，請確認訂閱是否剛更新、目前節點是否仍為使用中的項目，以及伺服器網域能否解析。換用同一群組的另一個節點比較，再切換網路測試。若只有單一節點失敗、其他節點正常，優先懷疑該筆設定或伺服器端；若同一群組全數失敗但其他群組正常，請檢查該群組的服務狀態；若所有群組都失敗，則回頭檢查裝置網路、系統時間及用戶端核心啟動狀況，避免一次修改所有節點。

連接埠可連線，不代表協定交握已完成

連接埠可連線只能證明有服務接受連線，無法確認使用者識別資訊、傳輸方式與加密參數是否相符。交握錯誤時，請逐項核對協定類型、伺服器連接埠、傳輸類型、TLS 開關、伺服器名稱與路徑。使用 WebSocket 等傳輸方式時，路徑及 Host 欄位也必須與伺服器端一致；使用 REALITY 時，公鑰、短識別碼和伺服器名稱同樣不能猜測填寫。最穩妥的恢復方式是從可信任的原始設定重新匯入，而非逐一嘗試隨機值。

系統設定 → 日期與時間，開啟自動校時後再試。時鐘明顯不準可能影響憑證效期判斷，部分協定驗證也依賴時間。若憑證網域不符，請核對伺服器名稱與服務提供者的說明，不要直接改成允許不安全的連線。若設定來自長期保存的剪貼簿，請確認內容沒有混入換行、全形字元或舊連接埠；手動編輯前先備份該筆節點，方便與重新匯入的項目比較。

排除測試網址與實際使用情況的差異

真實連線測試通常會透過代理存取指定目標。若目標暫時無法連線、回應方式改變，或因規則而使用不同出口，都可能讓節點被判定為失敗。先查看用戶端參數中的測試網址，確認仍是有效的網頁位址，再透過相同節點用瀏覽器存取另一個網站。不要為了讓測試通過而一再縮短逾時門檻，也不要把測試網址可連線，當成所有網際網路服務都正常。

需要進一步定位時，可在 Windows PowerShell 檢查 TCP 連接埠。以下命令僅檢查本機範例連接埠是否有人監聽，適合確認本地入口；若要檢查遠端伺服器，請在本機填入實際伺服器位址與連接埠。即使結果顯示成功，也不能證明代理驗證已通過。macOS 與 Linux 可使用系統網路工具進行類似檢查，但不必為單次排查額外安裝整套工具；用戶端日誌通常已提供足夠的階段資訊。

Test-NetConnection -ComputerName 127.0.0.1 -Port 10808

若同一節點在另一台裝置上可用，請比較兩端是否剛更新訂閱、使用相同的核心功能，以及是否有手動覆寫欄位。v2rayN、v2rayNG 與 v2flyNG 的介面相似，不代表所有設定擴充都能互通。保留服務提供者給的原始參數，並提供具體交握錯誤與失敗時間，比只回報「逾時」更有助於定位。日誌若含使用者識別資訊、訂閱網址或完整伺服器資訊，請勿直接公開。

訂閱失敗：區分下載失敗與內容無法匯入

先從訂閱群組的網址與更新方式查起

v2rayN → 訂閱群組 → 訂閱群組設定，檢查網址是否完整；v2rayNG → 訂閱群組設定，檢查相同項目。複製時常見的問題包括只選取部分連結、連同分享說明一起複製，或網址前後多了空格。訂閱網址可能含有個人存取憑證，排查時請只在本機查看，不要傳送到公開的轉換工具。若服務提供者重新產生過網址，舊網址可能已失效，必須重新複製目前有效的連結。

更新失敗時，先確認錯誤是逾時、解析失敗、憑證問題，還是伺服器拒絕存取。逾時先檢查目前網路；解析失敗請參閱 DNS 章節；憑證問題則先確認系統時間與憑證提示。若存取遭拒或資源不存在，通常需要核對帳號狀態、網址是否過期，以及服務提供者是否更換入口。不要反覆點選更新來確認帳號權限；相同結果重複出現，並不會帶來新的判斷依據。

分別測試直連更新與透過代理更新

更新訂閱本身也需要網路連線。若目前選用的節點已失效，而更新方式又設為透過代理，就可能陷入「必須先有可用節點，才能取得新節點」的循環。先試用用戶端提供的直連更新方式；若直連失敗，但已有另一條可用連線，則保持該連線，再嘗試透過代理更新。不同版本的選單文字可能不同，重點是確認這次請求實際走哪條連線，不要只切換按鈕而不查看日誌。

更新操作顯示成功後，也要確認取得的是節點內容。有些網路會將訂閱請求重新導向 Wi-Fi 登入驗證頁，有些服務則會回傳帳號到期說明或一般網頁。此時下載請求已完成，但解析器無法將內容轉換成節點。若用戶端支援查看更新日誌，請留意是否出現格式不支援、沒有有效伺服器或內容為空等提示。可在本機瀏覽器檢查回應是否為登入頁面，但不要保存或分享含有憑證的完整頁面截圖。

保留原有群組，以小範圍匯入測試格式

不要一開始就刪除整個群組再更新。先保留仍可使用的設定，必要時匯出至自己的受保護資料夾，再建立測試群組並匯入相同訂閱。若新群組可以匯入、舊群組卻失敗，請檢查舊群組是否設定篩選條件、自動排序、別名或其他覆寫選項。若兩個群組都無法匯入，請確認服務提供者提供的格式是否為該用戶端可辨識的格式。一般設定檔、單筆分享連結與整合訂閱並非相同輸入，不能只看網址外觀判斷用途。

訂閱更新會影響後續自動產生的設定。若將重要的手動修改直接套用在訂閱節點上，下次更新時可能被覆蓋；需要長期保留的調整，應先確認用戶端是否提供獨立的覆寫或自訂設定機制。更新完成後，檢查使用中的節點是否仍存在，重新選取有效項目，再進行一次真實連線測試。節點數量改變本身不代表出錯，服務提供者可能正常新增或移除項目；判斷依據應是設定是否有效，以及實際連線是否正常。

若只有某種新協定組合無法匯入，請前往安裝檔頁面確認用戶端選擇，再閱讀該用戶端支援的設定說明。Android 預設優先使用 v2rayNG，只有明確需要相應核心設定時，才考慮 v2flyNG。不同核心家族的擴充欄位各有差異，不能假設只要更改應用程式名稱就能相容。常見匯入方式與訂閱概念也可參閱FAQ，避免將格式問題誤判為所有節點都已失效。

速度慢：區分初次連線等待與持續傳輸

先描述慢在哪裡，再決定測試方式

網頁第一次開啟要等很久，但載入後內容很快；與大型檔案從頭到尾都下載緩慢，是兩種不同問題。前者通常應觀察 DNS 解析、建立連線與交握；後者較可能與頻寬、封包遺失、伺服器負載或流量政策有關。先關閉背景下載、雲端同步及正在播放的影片，固定使用一個節點、一個應用程式和同一個測試資源。Wi-Fi 訊號不穩時，盡量靠近無線基地台；桌面裝置若方便，也可改用有線網路，避免把本地 Wi-Fi 重傳誤認為代理效能問題。

先以可直接連線的同一項資源作為基準，再透過代理存取。若資源本身有限速，即使連線正常，也無法據此判斷出口效能。不同網站可能選用不同的內容傳遞入口，即使使用相同下載網址，也可能走不同路徑，因此單次測試只能反映當下的連線狀況。不要把真實連線測試的耗時當成下載頻寬；它主要反映建立請求所需的等待時間，無法呈現長時間傳輸中的壅塞與穩定性。

固定變數，比較節點、網路與時段

先在同一網路更換節點，再維持同一節點切換網路，最後換個時段重新測試。如此可分別觀察伺服器出口、本地網路與尖峰負載。若只有單一節點變慢，優先檢查該節點的服務狀態；若所有節點在某個 Wi-Fi 網路都變慢，優先檢查訊號、路由器負載及網路業者連線；若所有裝置存取同一目標都很慢，則需考慮目標網站或共用出口。每輪記錄現象即可，不必長時間持續占滿頻寬。

路由規則也會影響速度。某些原本可直接存取的資源，可能被送往較遠的代理出口；另一些網頁則可能主體直連，但圖片和介面仍走代理，讓人感覺部分內容卡住。請檢查目前的路由模式、規則順序與日誌中的目標去向。可暫時改用較簡單的路由方式比較，測試後再還原原設定。不要用永久全域代理掩蓋規則錯誤，也不要因某個網站變快，就認定所有應用程式都適合相同模式。

只有證據指向流量接管層時，才調整 Tun 與 MTU

關閉 Tun 後瀏覽器傳輸正常、啟用後大型檔案傳輸停頓時，應進一步檢查虛擬網卡、其他 VPN 與 MTU。部分連線路徑上，MTU 過大可能造成封包分段或重傳，但並非所有速度問題都由此引起。先記下原始值，只做小幅調整並用相同資源重新測試；若沒有穩定改善就還原。不要同時修改 MTU、DNS、傳輸參數與核心，否則即使問題消失，也無法判斷是哪項設定真正有效。

影音、遊戲等應用程式也可能使用 UDP 或 QUIC。某條連線能正常處理網頁 TCP 請求，不代表 UDP 轉送同樣正常。若只有這類服務卡頓，請確認節點與用戶端接管方式是否涵蓋相關流量，並查看應用程式是否自行切換至其他傳輸方式。暫時關閉瀏覽器的某項實驗功能，可作為短期比較，但不應視為所有使用者都適用的固定最佳化方式，更不該為了單次測速結果而修改無關的系統設定。

同時查看裝置資源使用狀況。大量規則、頻繁寫入日誌與並行連線，可能讓低效能裝置的處理器或儲存空間成為瓶頸。排查時請停止重複測速、關閉不必要的除錯等級日誌，再觀察正常使用情況；不要把關閉系統防護當成加速方式。共用代理時，也要確認是否有其他裝置同時占用出口；相關範圍與監聽設定請參閱區域網路共用設定筆記。若最後確認是伺服器端壅塞，微調本機用戶端通常無法解決，需改用可用出口，或向服務提供者回報發生時段與測試條件。

DNS 問題：確認由誰解析，以及查詢經過哪裡

網域解析失敗不代表代理伺服器無法使用

日誌出現解析失敗、找不到主機或反覆等待解析時，先釐清失敗的是代理伺服器的網域，還是最終存取目標的網域。前者發生於建立代理連線之前；若必須透過尚未建立的代理才能解析，就可能形成依賴循環。後者則應檢查用戶端 DNS、路由策略與目標應用程式的解析方式。瀏覽器頁面一直轉圈只是一種表面現象，不能據此判斷問題出在本機解析器或遠端解析器。

Windows 可在終端機執行以下命令，查看系統解析器是否有回應。此處使用公開文件網域，只檢查系統目前 DNS 的基本狀況。有回傳位址不代表網頁一定能開啟，也不代表代理核心使用相同的解析路徑。若系統查詢成功，但用戶端日誌仍顯示 DNS 錯誤，請繼續檢查核心設定中的 DNS 伺服器位址、查詢使用的出口及網域策略，不要反覆清除瀏覽器歷史紀錄來代替問題定位。

nslookup example.com

檢查系統、瀏覽器與用戶端三層設定

系統網路設定 → DNS，記下目前是自動取得還是手動指定。接著確認瀏覽器是否啟用安全 DNS，以及用戶端是否設定獨立 DNS。三種設定可以同時存在，但可能讓同一個網域得到不同結果，也可能繞過預期的分流規則。排查時先選定一條明確的解析路徑，暫時停用不必要的個別覆寫，重新測試後再逐項恢復。企業或校園網路若有內部網域，也要保留必要的內部解析能力。

使用加密 DNS 時，必須連線至解析服務本身的位址。若該位址也是網域，就需要先完成初始解析；若規則又要求它透過尚未成功建立的代理，仍可能形成循環。遇到這種情況，應依照用戶端文件設定可連線的引導解析與出口，而不是繼續增加更多解析服務。增加伺服器數量不一定能提升可靠性；錯誤的平行查詢與路由選擇，反而會讓結果來源更難判讀。

搭配路由規則理解查詢與連線的關係

以下是核心設定中的 DNS 與路由片段，用於理解欄位之間的關係，並非可直接匯入用戶端的完整檔案。內容展示了網域伺服器清單與依需求解析的策略；實際執行仍需要完整的入站、出站及其他必要設定。使用圖形介面用戶端時，應優先修改用戶端對應設定，避免直接編輯自動產生的檔案，因為重新啟動或切換節點時，內容可能會重新產生。也應分別確認不同核心支援的欄位。

{
  "dns": {
    "servers": [
      "1.1.1.1",
      "8.8.8.8"
    ]
  },
  "routing": {
    "domainStrategy": "IPIfNonMatch"
  }
}

依網域比對的規則，可能在解析前就決定流量出口；依 IP 位址集合比對的規則，則可能需要先取得 IP。解析結果、規則順序與連線目標必須一併檢視。若直接存取解析出的 IP 失敗，也不能立刻斷定是 DNS 問題，因為許多網站仰賴正確的網域與 TLS 伺服器名稱，直接輸入 IP 並不等同於原始請求。只有在了解目標服務的前提下，測試 IP 位址才有診斷價值。

修改解析設定後，舊結果可能仍保留在系統、瀏覽器或應用程式快取中。確認新設定已生效後，Windows 可執行以下命令，再重新啟動出問題的應用程式並發出新請求。清除快取只是讓系統重新查詢，不會修復無法連線的 DNS 伺服器。若網域只在某個網路失敗，請比較該網路的 DNS 與登入驗證狀態；若只有啟用 Tun 後失敗，則應優先核對 DNS 接管、虛擬網卡路由與其他網路工具的衝突。

ipconfig /flushdns

系統代理無效：核對應用程式入口與監聽位址

先確認用戶端與系統指向相同連接埠

v2rayN → 自動設定系統代理，接著開啟系統網路設定中的代理頁面，確認位址是否為本機迴送位址，連接埠是否與用戶端實際監聽的連接埠一致。常見的本機連接埠可能是 10808，但應以目前設定為準，不要照搬教學中的數字強行覆寫。核心未啟動、監聽連接埠遭其他程式占用，或系統仍保留舊連接埠，都可能導致「代理已開啟但無法存取」。先確認本機入口存在，再檢查遠端節點。

也要在用戶端參數設定中確認監聽入口接受哪種代理協定。若應用程式選擇 HTTP 代理，卻連到只接受 SOCKS 的入口，或情況相反，通常會立即連線失敗或收到異常內容。部分版本提供可接受多種代理協定的混合入口，也有版本將不同協定設定在不同連接埠。不要只憑連接埠號碼判斷類型。區域網路監聽與迴送位址監聽也不同；本機使用通常不需要開啟允許來自區域網路的連線。

系統代理只會影響會讀取該設定的應用程式

瀏覽器可能會讀取系統代理，也可能使用自行設定的代理或擴充功能。先暫停代理擴充功能，在瀏覽器設定中確認使用系統設定，再開啟新頁面並查看日誌。若用戶端沒有收到對應請求，流量可能根本沒有進入本機入口。命令列工具、遊戲及部分桌面程式不一定會讀取系統代理；請查看應用程式本身的網路選項，不能只因瀏覽器正常，就認定所有程式都會自動經過用戶端。

可用明確指定代理的請求與一般請求進行比較。以下命令要求本機的 10808 入口接受 HTTP 代理，且核心和使用中的節點都已啟動；若目前使用其他連接埠或協定，應依實際設定調整。在 Windows PowerShell 中使用系統提供的 curl.exe，可避免命令別名造成差異。若明確指定代理的請求成功，但一般瀏覽失敗，請優先檢查系統與瀏覽器入口；若明確指定代理也失敗，則繼續檢查監聽、節點與解析，不要先擴大流量接管範圍。

curl.exe --proxy http://127.0.0.1:10808 --head https://example.com/

區分系統代理、自動設定指令碼與 Tun

系統代理頁面可能同時有手動代理、自動設定指令碼與自動偵測。若保留舊指令碼網址或其他程式寫入的設定，實際路由可能與介面顯示的預期不同。先記下原始狀態，停止其他會修改代理的工具，再只保留本次排查所需的一種方式。受組織政策管理的裝置可能禁止修改設定，或在修改後自動還原；此類限制應交由裝置管理員處理，不應反覆提高權限來規避管理要求。

確實需要接管不會讀取系統代理的流量時，再考慮使用 Tun。啟用前先確認目前節點能透過一般代理正常存取；啟用後觀察虛擬網卡是否建立、預設路由是否變更，以及日誌是否出現權限錯誤。其他 VPN、虛擬機器網路或安全軟體都可能參與路由；若發生衝突，每次只暫停一個相關程式進行比較。不要把允許區域網路連線當成使用 Tun 的前提，兩者解決的問題並不相同。

退出前使用清除系統代理，接著確認系統頁面已恢復。若用戶端先前發生閃退，系統可能仍指向已停止的本機連接埠；此時需要手動關閉殘留的代理設定，再正常啟動用戶端。復原過程中請保存舊值，尤其工作環境原本就有代理時，不要直接刪除所有項目。系統代理與路由的基本差異可回頭參閱快速入門；若需確認不同平台的用戶端差異，請查看用戶端比較，不要在不同系統間照搬設定。

用戶端閃退：先保留現場，再隔離設定

區分介面結束、核心結束與背景停止

視窗消失不一定代表程式閃退，也可能只是最小化至系統匣；介面仍在，也不代表核心正常運作。先檢查工作列、系統匣與程序清單，再查看日誌是否持續記錄新請求。若前端持續執行，但核心反覆啟動後結束，請優先檢查設定、連接埠與權限；若按下啟動後整個程式立即關閉，則應查看系統應用程式錯誤紀錄、執行環境及設定讀取狀況。Android 背景停止情形請參閱下一章，不要直接套用桌面版的判斷方式。

操作前先停止自動重複啟動，保存應用程式日誌及錯誤發生時間附近的系統紀錄。Windows 可在事件檢視器的應用程式記錄中尋找對應錯誤；macOS 可查看系統提供的當機報告；Linux 可查看桌面啟動提示與使用者層級日誌。不必上傳整份紀錄，先擷取錯誤模組、結束原因與發生時間。日誌可能包含伺服器位址、使用者識別資訊與訂閱憑證，對外回報前應先遮蔽這些內容，但保留錯誤類型與上下文順序。

檢查架構、安裝方式與檔案寫入權限

前往安裝檔頁面，依作業系統與處理器架構選擇用戶端。程式無法啟動時，不要先從不同來源混合複製執行檔與核心檔案，以免相依元件不一致。Windows 桌面版與傳統 WPF 版採用不同介面方案，可依說明選擇對應版本進行排查，但遷移前應先備份原有設定。macOS 應確認晶片類型；Linux 則需核對發行版套件格式與系統架構，不能只看副檔名判斷是否適用。

程式所在資料夾、使用者資料夾及日誌資料夾都需要具備正常的寫入權限。唯讀位置、受控資料夾、磁碟空間不足或同步軟體占用檔案，都可能導致儲存設定或啟動核心失敗。先查看具體錯誤路徑，再將資料移至自己有寫入權限的位置，不要直接放寬整個磁碟的權限。若系統安全軟體提示封鎖，請先查看提示與檔案來源資訊，不要全面關閉防護；受組織管理的裝置也應遵循管理員的安裝政策。

以最精簡設定重現問題，不要直接清除原有資料

完整備份後關閉用戶端，再依照資料目錄說明建立獨立的測試設定。若用戶端支援可攜式或獨立資料目錄，請使用正式支援的方式，不要自行猜測目錄參數。測試環境只匯入一筆已知可用的設定，暫時停用 Tun、自訂路由與額外覆寫。若精簡環境能啟動，問題較可能出在原設定或某個擴充選項；若精簡環境仍然閃退，則繼續檢查安裝環境、系統架構與系統錯誤紀錄。

還原原設定時，依序加入訂閱、基本代理、路由與 Tun；每加入一項就啟動並測試。若某個步驟能穩定重現錯誤，請保留該步驟前後的設定差異。設定語法錯誤通常會在日誌中指出欄位或位置；若曾手動編輯 JSON，請檢查雙引號、逗號與欄位型別，不要使用文字取代功能批次修補所有檔案。若自動產生的檔案出錯，也應回頭追查來源設定，否則下次切換節點時仍可能產生相同錯誤。

更新後才發生問題時，請記下更新前後使用的介面方案、核心家族與設定變化，不要憑記憶填寫版本資訊。需要回報問題時，請提供作業系統、處理器架構、啟動方式、重現步驟，以及精簡設定是否也會失敗。若問題發生在休眠喚醒或網路切換後，也請補充電源與網路狀態的變化。恢復後先確認退出時能否清除系統代理，避免局部程式問題變成整個系統無法上網，最後再恢復自動啟動。

行動裝置專項：VPN 授權、背景執行與個別應用程式代理

確認 VPN 服務確實已建立，而非只有開啟應用程式

v2rayNG → 連線，首次啟動時需要取得系統 VPN 授權。此授權允許用戶端透過 Android VPN 服務接管本機流量，但不代表已連上遠端伺服器。完成授權後，仍須查看運作通知、應用程式日誌與實際存取狀況。若授權提示反覆出現，請檢查是否有其他 VPN 應用程式正在執行，以及系統是否受到工作設定檔或裝置管理政策限制。同一使用者環境中的 VPN 接管通常會互相競爭，測試前請先停止其他流量接管程式。

也要區分設定中的 VPN 模式與僅代理模式。VPN 模式透過系統介面接管符合條件的應用程式流量；僅代理模式主要提供本機代理入口，需要應用程式自行使用該入口。若誤選僅代理模式，用戶端內的測試可能正常，但一般應用程式不會有任何變化。先記下目前模式，使用 VPN 模式完成基本存取測試，再考慮進階用途。若系統設定了永遠啟用的 VPN，或封鎖未經 VPN 的連線，也要確認綁定的正是目前使用的用戶端。

鎖定螢幕後斷線，請檢查電池與背景執行限制

系統設定 → 應用程式 → v2rayNG → 電池，檢查是否限制背景活動，並依裝置提供的選項允許持續執行。不同廠牌的選單可能稱為背景執行、自動啟動或電池最佳化，設定路徑並不一致。先確認應用程式能顯示持續執行通知，再測試鎖定螢幕後的狀況。關閉通知不一定代表服務已停止，但會減少可觀察資訊；電池狀態、系統省電模式與背景數據限制則可能直接影響連線維持。

分別記錄螢幕保持開啟、鎖定後及切換網路後的狀況。若鎖定一段時間後才失敗，請優先檢查背景限制；從 Wi-Fi 切換至行動數據後失敗，請優先檢查網路恢復與舊連線重建；若行動數據始終無法使用、Wi-Fi 卻正常，則檢查數據節省功能、應用程式行動數據權限及該網路的連線狀態。調整省電選項後，請重新建立連線並以相同的鎖定條件再次測試；不能只看設定已儲存，就判定問題已解決。

個別應用程式代理必須確認清單的套用方向

v2rayNG → 設定 → 個別應用程式代理，先確認目前設定是僅代理所選應用程式，還是略過所選應用程式。兩種清單的套用方向相反：前者必須選取目標應用程式，流量才會進入代理；後者則必須確認目標應用程式未被排除。若瀏覽器正常但某個應用程式始終無法使用，先確認它是否列在清單中，以及相關元件是否屬於另一個應用程式。網頁跳轉、帳號登入或下載可能交由系統元件處理，不能假設整個操作都由同一個應用程式完成。

為了確認是否是清單造成問題，可先暫時停用個別應用程式代理，讓目標應用程式納入基本接管範圍，接著停止並重新建立 VPN 連線後再測試。若恢復正常，請回頭檢查清單方向或元件範圍；若仍然失敗，再檢查應用程式的獨立代理、DNS、目標服務與 UDP 支援。不要同時啟用多套篩選規則來試錯，規則越多，就越難判斷流量為何遭到排除。工作設定檔與一般使用者環境可能各有獨立的應用程式，也需分別確認系統允許的接管範圍。

切換網路後重新建立連線，再檢查核心相容性

切換 Wi-Fi 與行動數據會改變本機位址、路由與可達路徑，既有連線不一定能立即恢復。先停止連線，等待系統網路穩定後重新啟動，再進行一次真實連線測試。若只有某種網路無法使用，請參閱節點逾時與 DNS 章節，不要反覆重新安裝應用程式。啟用略過區域網路位址後，應另外測試本機裝置的存取；這項設定只會處理本機目的位址的路由，不會讓網際網路節點恢復，也不能取代個別應用程式代理。

Android 優先使用 v2rayNG；若需要 v2fly 核心設定，可依實際相容需求選擇 v2flyNG。兩者都應從Android 安裝檔入口依裝置架構選擇。切換前請保留原訂閱與必要設定，不要讓兩套 VPN 同時競爭。若問題來自協定擴充，先向服務提供者確認設定適用的核心，比直接複製所有進階選項更可靠。最後依照VPN 授權與背景設定筆記再次檢查，並測試鎖定螢幕、切換網路及手動停止三種狀態，確認不只是剛按下連線時正常。