一、用戶端已啟動，卻無法上網
先分辨「所有網站都無法開啟」和「只有部分網站無法開啟」。前者優先檢查代理入口與伺服器連線；後者優先檢查路由規則與 DNS。瀏覽器顯示無法連線，不足以證明伺服器故障：請求可能根本沒有進入用戶端，也可能進入後被路由到不適合的出口。請依下列順序檢查，並記錄每一步的測試結果。
確認選取的伺服器與執行狀態
在 v2rayN 伺服器清單中，確認目前有選取一個伺服器項目。只匯入訂閱卻未選取項目，或訂閱更新後原項目遭到取代，都可能讓後續檢查失去對象。開啟用戶端記錄，先確認啟動時是否出現設定讀取錯誤、核心啟動失敗、連接埠占用或連線失敗。若啟動階段就發生錯誤，先處理記錄中的第一個明確錯誤，不要直接修改 DNS。
暫時改選另一個已知可用的伺服器重新測試。若只有一個項目失敗，優先檢查該項目的位址、連接埠與傳輸設定；若全部失敗，再檢查本機代理入口與網路環境。伺服器資訊應以訂閱提供者或自行管理的伺服器端設定為準，不要憑記憶填入使用者 ID、PublicKey 或 ShortId。修改前可先複製原項目，方便比對與還原。
檢查系統代理與流量範圍
在 v2rayN 的系統代理選單確認目前狀態。若瀏覽器使用系統代理，用戶端正在執行不代表作業系統已將瀏覽器流量交給它；將系統代理切換到需要的模式後，關閉並重新開啟瀏覽器視窗進行測試。也要檢查瀏覽器是否設定了獨立代理或擴充功能，這些設定可能會覆蓋系統代理。其他應用程式是否遵循系統代理，則取決於應用程式本身的實作。
若只想確認代理連線，可暫時切換至全域代理，測試同一個目標。全域模式能連線、原本的路由模式不能，表示入口與伺服器大致可用，接下來應檢查路由規則，而不是反覆重新安裝。測試後請恢復原模式，避免將診斷時的變更留在日常設定中。TUN 能接管更多流量，但不適合用來掩蓋尚未確認的系統代理問題。
透過記錄確認請求停在哪一層
在用戶端開啟記錄檢視，接著只瀏覽一個測試頁面，觀察是否出現相應的連線記錄。完全沒有記錄時，先檢查系統代理、應用程式獨立代理或 TUN 入口；有請求記錄但顯示目標解析失敗，請前往本頁 DNS 章節；若顯示連線到遠端逾時，請查看節點逾時章節。若記錄直接指出規則將流量導向直連或封鎖出口，應檢查路由設定。
測試時使用同一個瀏覽器、同一個目標與同一個伺服器，避免多個分頁的請求混在一起。不要把記錄中的「用戶端已啟動」解讀為「目標網站已透過代理連線」：這只代表程式已進入執行狀態。必要時分別測試一個通常直連的網站，以及一個明確需要目前代理規則處理的網站，比較兩次請求的規則比對結果。
排除本機網路與殘留代理設定
暫時關閉用戶端的系統代理設定，確認裝置在目前網路下能否正常開啟原本允許直連的頁面。如果直連也無法使用，先處理 Wi-Fi、有線網路、閘道或作業系統網路設定；代理用戶端無法修復中斷的基礎網路。再確認是否有其他代理應用程式占用相同的監聽連接埠，或系統中是否留有舊的代理位址。相較於反覆切換節點，記錄中的連接埠占用通常更值得優先處理。
排查完成後，將系統代理與路由模式還原為預定使用的狀態，再重做最初失敗的操作。若問題只出現在某個應用程式，先檢查該應用程式的代理選項與網路權限，不要把單一應用程式的狀況當成整台裝置故障。關於「連線成功但網頁無法開啟」等簡短問答，可參閱說明中心；需要重新建立基本設定時，請回到教學。
二、節點逾時或連線反覆中斷
節點逾時表示一次連線未能在規定時間內完成，並不能直接判定是某個特定原因。伺服器位址解析、目標連接埠、傳輸協定、傳輸層安全性及目前網路都可能造成影響。先確認是否只有一個節點逾時，再檢查其設定；若同一訂閱中的節點全部逾時，應先檢查共用的網路入口、訂閱內容與用戶端執行狀態。
先比對影響範圍，別把延遲測試當成最終結果
在同一個網路中，分別測試目前項目與另一個已知可用的項目，記錄是「單一節點失敗」、「同一群組失敗」還是「全部失敗」。用戶端的延遲測試只會探測特定連線路徑，無法取代網頁或應用程式的實際存取測試。延遲測試通過但網頁無法開啟時，應繼續檢查路由、DNS 與應用程式代理；延遲測試失敗但部分服務仍可使用時，也不要只憑單一數值就刪除伺服器。
再換到另一個正常可用的網路進行比對，例如從目前的 Wi-Fi 切換到行動網路。若同一份設定只在某個網路中失敗，請檢查該網路的 DNS、閘道，以及是否允許相應的連線方式。若在不同網路都失敗，但其他節點正常，問題較可能出在該項目的伺服器端狀態與欄位設定。保留測試時間與記錄中的錯誤類型，回報給設定提供者時，會比只說「節點不能用」更有幫助。
逐一核對伺服器設定欄位
在「編輯伺服器」中依序核對位址（address）、連接埠（port）、使用者 ID（id）、傳輸協定（network）與傳輸層安全性（TLS）。這些欄位必須與伺服器端設定一致，不能只因協定名稱相同就認為可以互換。使用 VLESS 與 REALITY 時，也要核對 SNI、Fingerprint、PublicKey、ShortId，以及伺服器端要求的流控（flow）；部分欄位可以留空，但是否留空須依實際伺服器設定而定。
修改時每次只變更一個有根據的欄位，並記下修改前的值。伺服器位址若是網域名稱，先確認目前網路能否解析；若是 IP 位址，DNS 通常不是該連線入口的首要疑點。若使用 WebSocket 等傳輸方式，也要檢查相應的路徑與主機名稱設定。比對匯入訂閱時取得的欄位與手動編輯後的項目，可以找出複製時遺漏的傳輸參數。
確認記錄中逾時發生的位置
若記錄顯示伺服器網域解析失敗，應先檢查本機 DNS 或訂閱使用的網域；若顯示連線至遠端逾時，則檢查位址、連接埠、基礎網路與伺服器端執行狀態；若連線建立後才出現安全交握錯誤，就應優先核對 SNI、憑證相關設定或 REALITY 參數。錯誤發生階段不同，處理方式也不同，不建議看到「timeout」就直接更換核心。
在 Windows 上，可使用系統內建的名稱查詢命令，協助判斷網域能否解析。以下網域僅為查詢語法範例；實際排查時請換成自己有權檢查的伺服器網域。查詢結果有回傳位址，只代表解析階段完成，不表示遠端連接埠可連通，也不代表協定交握成功。
nslookup v2raypeizhi.com中斷後自動恢復與連線穩定性
若連線一開始正常，使用一段時間後才中斷，請記錄中斷當下裝置是否進入休眠、網路是否由有線切換至無線，以及系統是否剛從待機恢復。行動網路切換或電腦休眠可能使既有連線失效；此時先重新發出請求，確認能否建立新連線。只有新連線也持續失敗，才依節點故障繼續排查。不要混淆應用程式保留的舊連線錯誤與建立新連線的能力。
同時確認用戶端是否有多個執行中的執行個體，以及本機安全軟體是否封鎖核心程序或監聽連接埠。若某個節點長期不穩，保留原始設定並與同一群組的其他項目比對；不要批次覆寫所有伺服器設定。想了解 Xray 與 V2Fly 的功能差異，可閱讀核心選擇筆記，但更換核心前應先確認協定相容性。
三、訂閱更新失敗或伺服器清單為空
訂閱更新包含「取得訂閱內容」與「解析內容並寫入群組」兩個階段。發生錯誤時，先分辨是沒有取得內容，還是取得內容後用戶端無法識別；清單為空也可能只是目前的篩選條件隱藏了伺服器。不要反覆修改原訂閱的位址、群組與篩選關鍵字，先保存目前設定，再逐項確認。
核對訂閱網址與目前網路
進入 v2rayN 的訂閱群組設定，確認網址沒有多出空格、換行或遭到截斷，並檢查該群組是否仍為啟用狀態。訂閱網址通常包含存取憑證，應視為私密資訊：不要將完整網址貼到公開截圖或求助文章。需要回報給提供者時，只描述錯誤類型、發生時間與用戶端，不要公開完整連結。
更新失敗時，先確認裝置本身能否瀏覽一般網頁，再依訂閱群組的更新方式檢查請求是否需要透過既有代理。初次匯入時若尚無可用節點，卻把訂閱取得路徑設成必須依賴目前代理，就可能陷入「必須先有節點才能更新」的循環。已有節點可用、只有訂閱請求失敗時，請分別測試直連與透過代理更新，選擇符合訂閱網址實際可連通狀況的方式。
分辨網路錯誤與內容錯誤
若記錄提示網域解析失敗或連線逾時，優先檢查網址對應的網域、網路連線與取得方式；若提示存取遭拒或回傳內容不是訂閱格式，請聯絡訂閱提供者確認授權與內容類型。用戶端能下載網頁，不代表該網頁就是可匯入的節點清單。如果網址在瀏覽器中開啟的是登入頁、說明頁或錯誤頁，繼續點選更新也不會產生有效的伺服器項目。
如果記錄指出解析失敗，先不要手動把回傳內容貼進伺服器編輯視窗。訂閱通常包含多個設定，單一伺服器欄位無法完整保留群組、篩選與更新規則。可新增一個暫時的訂閱群組，只填入已確認的網址進行測試；若臨時群組能正常更新，代表原群組的更新方式或篩選設定更值得檢查。確認原因後刪除臨時群組，避免重複伺服器長期並列。
伺服器已匯入，清單中卻看不到
檢查目前選取的訂閱群組、清單搜尋欄與關鍵字篩選條件。切換群組後，清單可能只顯示該群組的內容；篩選關鍵字也可能隱藏所有項目。先清除搜尋條件並顯示全部伺服器，再查看記錄或更新結果是否確實新增了項目。不要因為清單為空就立刻認定訂閱來源失效，尤其是在剛調整關鍵字規則之後。
匯入成功但數量與預期不同時，先確認訂閱提供者是否調整了內容，再檢查去重、篩選與群組歸屬。不同訂閱中的伺服器名稱可能相似，不能只靠名稱判斷設定完全相同。多個來源的日常整理方式，請參閱v2rayN 多訂閱群組管理；排查期間建議暫時減少篩選條件，恢復項目可見後再逐一加回。
讓更新過程可以重現
記錄「手動更新一次」的實際結果，不要連續快速點選。前一次請求尚未完成就再次觸發更新，記錄內容可能交錯，難以判斷是哪一次失敗。更新前後分別確認群組名稱、伺服器清單與最近一次明確錯誤；若有多個訂閱，請逐一更新群組，確認是單一來源失敗還是所有來源都失敗。所有來源都失敗時，通常應優先檢查裝置網路與請求方式。
若舊節點仍可使用，先保留它們以完成網路驗證，不要為了解決訂閱問題就刪除整組現有伺服器。若舊節點也同時失效，請檢查是否切換了網路或變更了系統代理狀態，再回到無法上網章節確認入口。訂閱更新與節點連線是兩條不同的連線路徑：前者失敗不代表已儲存的節點會立即失效；後者正常也不保證訂閱網址一定能連線。
四、可以連線，但網頁或下載速度很慢
速度問題先區分為「首次開啟慢」、「傳輸過程慢」與「只有特定應用程式慢」。首次開啟通常與 DNS、建立連線和安全交握有關；持續傳輸則也會受到伺服器負載、線路與本機網路影響。不要只看用戶端的延遲排序就判定傳輸速度，也不要同時換節點、改 DNS、啟用 TUN，之後卻把改善歸功於其中一項。
建立可比較的測試條件
在同一台裝置、同一個網路與相近的時間，分別使用原節點及另一個已知可用的節點，瀏覽同類型的頁面。先停止正在進行的大型檔案傳輸，再觀察是首次載入等待較久，還是頁面資源持續載入緩慢。若只有一個節點速度慢，優先檢查該節點與遠端狀態；若所有節點都慢，還要測試裝置不使用代理時的基礎網路。基礎網路本身壅塞時，更改用戶端設定通常無法解決根本原因。
瀏覽器會快取資源，重複開啟同一頁面的結果可能受到快取影響。比對時可選擇多個常用頁面，留意是否普遍出現相同情況，不必追求一次測試就得出精確速度。觀察用戶端記錄是否出現大量重試、交握失敗或連線重設；這些現象比單一延遲數值更能反映網路傳輸是否穩定。測試時保留原本的路由模式，避免改變實際使用的出口。
判斷是否因路由繞行
如果原本應該直連的服務也變慢，請檢查 v2rayN 路由設定中的規則順序、比對條件與出口。規則通常依序比對，前面的寬泛規則可能先攔截請求，讓後面的精確規則無法生效。開啟記錄，查看一個明確變慢的目標符合哪條規則，再決定是否調整；不要隨意移動整組規則碰運氣。
短暫切換至全域代理進行比對，有助於判斷分流情況，但無法單獨證明某條路由規則有錯：全域模式也可能把原本直連的流量改道。若「部分網站很慢、其他網站正常」，應分別記錄網域、解析結果與路由出口。修改規則後，至少重新測試原本變慢與原本正常的目標，避免解決一種情況，卻讓另一類請求走錯路徑。
檢查 DNS 等待與連線重試
若頁面長時間空白後才突然完整顯示，先檢查瀏覽器網路資訊與用戶端記錄是否停在解析或首次連線階段。DNS 問題不一定會完全連線失敗；解析到無法連通的位址、上游回應緩慢，或解析結果與路由不一致，都可能延長等待時間。相關檢查可直接前往DNS 章節；想了解分流解析與路由的配合方式，可參閱DNS 分流設定筆記。
若記錄顯示持續重新連線至同一個遠端，請依節點逾時章節檢查傳輸設定與網路穩定性。不要把重試造成的等待直接歸咎於 DNS。使用 TUN 時，也應比較關閉 TUN、僅使用系統代理時的狀況；若問題只在啟用 TUN 後出現，請檢查 TUN 接管範圍與本機其他網路工具是否衝突，不要先更換所有訂閱。
確認應用程式、裝置與網路的範圍
只有一個應用程式速度慢時，請檢查該應用程式是否自行設定代理、是否沿用舊連線，以及是否有獨立的 DNS 或網路加速設定。瀏覽器正常但下載工具很慢，通常表示兩者使用了不同入口；先釐清流量路徑，再判斷節點效能。電腦從休眠恢復後短暫變慢，可先重新建立連線，並在網路穩定時重新測試。
若同一網路下的多台裝置都變慢，請檢查路由器負載、無線訊號與網路服務供應商的狀態；若同一台裝置換網路後立即恢復，則應優先檢查原本的網路。必要時可將「網路、用戶端、節點、目標應用程式、路由模式、是否啟用 TUN」整理成簡單的比對表。這樣能找出哪個變數改變時問題也跟著變化，之後也方便還原設定。
五、DNS 解析錯誤、污染或解析結果與路由不一致
DNS 負責將網域名稱轉換成可供連線使用的位址；路由則決定請求從哪個出口送出。兩者不是同一個開關。瀏覽器顯示找不到伺服器、某個網域偶爾能開啟，或使用網域名稱失敗但使用已知位址可連線，都值得檢查解析路徑。先確認「由誰解析、何時解析、解析結果交給哪個出口」，再考慮更換上游或啟用 FakeDNS。
先確認解析的是伺服器網域，還是目標網站網域
連線至節點之前，用戶端可能需要解析伺服器位址；代理連線建立後，存取目標網站時又可能觸發另一輪解析。記錄中失敗的網域屬於哪一層非常重要：伺服器網域解析失敗，該節點從一開始就無法連線；目標網站網域解析失敗，則可能只有部分網站無法開啟。先記下記錄中明確出現的網域類型，不要把兩種問題混為一談，只說「DNS 有問題」。
可使用系統內建的查詢命令，確認目前裝置能否取得網域記錄。範例使用本站網域，只用來示範操作方式；解析結果會隨網路與時間改變，不應照抄為固定設定。命令執行成功，不代表用戶端一定使用相同的解析器；瀏覽器、作業系統、用戶端與 TUN 環境可能採用不同的解析路徑。比對結果時，請註明查詢是從哪個入口執行。
nslookup v2raypeizhi.com依網域與出口核對 DNS 設定
查看 v2rayN 的 DNS 與路由設定，確認目標網域最後是直連還是走代理，再檢查相應路徑採用的解析方式。直連流量若取得只能在另一個網路連通的位址，或代理流量在本機預先取得不適合的解析結果，都可能造成「規則看起來正確，連線卻失敗」。調整前先備份目前的 DNS 設定；每次只更換一個上游或一類網域規則。
使用自訂 DNS 設定時，請留意規則比對順序與預設上游：精確網域規則未比對成功時，請求會採用預設路徑。DoH、傳統 DNS 與系統解析可依需求搭配，但新增的上游本身也必須有可用的網路路徑；若上游網域仍需要解析，也要考慮其引導解析方式。詳細設定區塊與排查順序，請參閱V2Ray DNS 分流設定詳解。
何時檢查 FakeDNS
FakeDNS 會先為網域分配虛擬位址，再配合流量嗅探，將後續連線對應回網域。它常用於需要接管裝置流量，同時保留網域供路由比對的情境；並不是「DNS 出錯就開啟」的通用修復方式。若嗅探未涵蓋實際流量，或某個應用程式直接依賴解析取得的真實位址，啟用後反而可能產生新的相容性問題。
排查時，先在原有設定下記錄無法連線的目標，再單獨變更 FakeDNS 相關設定，並以同一個應用程式重新測試。只有啟用或停用這項設定能穩定改變結果時，才繼續檢查嗅探、虛擬位址映射與路由規則。原理與適用範圍請參閱FakeDNS 原理說明。不要把分配到的虛擬位址當成遠端伺服器的真實位址，也不要據此修改伺服器項目的 address 欄位。
處理快取與偶發的解析差異
修改 DNS 後，瀏覽器、作業系統或應用程式可能仍在使用先前快取的結果。先關閉並重新開啟測試用的應用程式，再於相同網路下重新測試；必要時使用系統提供的 DNS 快取清除功能。清除快取只能移除舊結果，無法修復錯誤的上游選擇或路由出口。若問題短時間後再次出現，應繼續比對實際請求路徑，而不是反覆清除快取。
若只有特定網域異常，請記錄網域、故障時段、使用的網路、路由比對結果與解析階段的記錄；若所有網域都異常，先檢查本機網路與 DNS 上游是否可連線。比對時不要同時啟用新的 DoH、FakeDNS 與 TUN。記下每一步「變更了什麼、結果如何、是否已還原」，才能確認究竟是哪一層解決問題。
六、系統代理已啟用，但應用程式沒有走代理
系統代理是作業系統提供給應用程式參考的一組代理設定，不是強制接管所有網路流量的總開關。v2rayN 可設定系統代理，也可透過 TUN 接管更多流量；兩者的作用範圍不同。排查時應先確認應用程式是否讀取系統代理，再確認代理位址與用戶端實際監聽的入口一致，最後才判斷是否需要 TUN。
確認設定是否已寫入系統
在 v2rayN 中檢查「系統代理」目前的選項，確認並非關閉狀態。切換後重新啟動要測試的應用程式，避免它繼續使用舊的代理設定或持續連線。可在 Windows 的系統代理介面交叉確認目前代理是否已寫入；如果介面顯示舊位址或舊連接埠，先檢查是否有其他工具也在修改系統代理，再回到 v2rayN 重新設定。
某些應用程式提供獨立代理選項，可能優先使用應用程式內的設定，也可能明確選擇「不使用代理」。先在應用程式設定中查找「使用系統代理」、「自動偵測」或「手動代理」等選項，不要預設它會遵循作業系統設定。瀏覽器可正常使用、但某個命令列工具無法使用，是常見的入口差異；應依該工具的代理機制處理，不能只憑系統代理開關判斷。
分辨系統代理、路由與 TUN
系統代理會影響遵循系統設定的應用程式是否將流量送到用戶端；路由則決定已進入用戶端的請求要從哪個出口送出。若記錄中完全沒有目標應用程式的請求，修改路由規則通常沒有幫助。先解決「請求是否進入」，再處理「進入後要去哪裡」。反之，若記錄中看得到請求，且比對到錯誤出口，就應檢查路由，而不是反覆切換系統代理。
若需要處理不遵循一般系統代理的流量，可使用 TUN；但啟動時可能涉及系統權限、虛擬網路介面，以及與其他網路軟體的相容性。先在只啟用系統代理的情況下建立可重現的測試，再啟用 TUN 比較結果。若一啟用 TUN 就無法上網，請立即關閉，並檢查用戶端記錄、權限與本機其他虛擬網卡；不要同時使用多個接管相同路由的工具。
依平台了解代理入口
桌面端以 v2rayN 為主，但不同作業系統與應用程式遵循系統代理的程度不一。檢查時使用同一個應用程式比對啟用前後的結果，再查看用戶端記錄是否出現相應請求。下表用於判斷排查方向，不代表其中所有應用程式都採用相同的代理方式；實際行為仍以應用程式設定與記錄為準。
| 環境 | 優先檢查 | 進一步確認 |
|---|---|---|
| Windows · v2rayN | 系統代理狀態、應用程式的獨立代理 | 用戶端記錄是否出現應用程式請求 |
| macOS · v2rayN | 目前網路服務的代理設定 | 切換網路後重新檢查設定 |
| Linux · v2rayN | 桌面環境與各應用程式的代理選項 | 確認應用程式是否讀取相應設定 |
| Android · v2rayNG / v2flyNG | 連線狀態、VPN 授權 | 在前景測試應用程式是否恢復連線 |
清除舊設定後重新測試
用戶端異常結束後，作業系統可能仍保留指向本機代理連接埠的設定。這時應用程式會將流量送往已停止監聽的入口，造成用戶端關閉後網頁也無法開啟。重新啟動 v2rayN 並正確關閉系統代理，或在作業系統網路設定中確認並清除舊代理；接著確認直連已恢復。若仍有不明代理位址生效，不要直接刪除設定資料夾。
若切換網路、從休眠恢復或啟動另一個網路工具後問題再次出現，請記錄是哪個操作改變了系統代理設定。最後分別測試直連、系統代理與目標應用程式：直連是否正常、用戶端是否收到請求、路由出口是否符合預期。依這個順序取得的三項結果，比「代理開著但沒用」更能精準定位下一步。
七、用戶端無法啟動、閃退或核心啟動失敗
無法開啟介面，與介面能開啟但核心無法啟動，是兩種不同的問題。先確認問題發生在哪個步驟：點兩下後沒有視窗、視窗開啟後立即關閉、匯入設定後退出，還是點選連線時核心報錯。保留記錄與目前設定，再檢查安裝環境及設定錯誤；不要先刪除所有使用者資料並重新安裝。
檢查安裝檔與執行環境
確認安裝的用戶端版本符合作業系統與處理器架構。桌面端優先使用 v2rayN；Windows 使用者可在下載中心的 Windows 區分辨桌面版與傳統 WPF 版，macOS 與 Linux 使用者則應依平台選擇。請將應用程式放在具有正常讀寫權限的位置，避免直接從權限受限或唯讀的位置執行，也不要在下載尚未完成時開啟檔案。
若更新後才開始發生啟動問題，先記下更新前後的操作、使用的安裝方式與錯誤內容，再確認是否仍有舊程序在執行。重複啟動多個執行個體可能造成監聽連接埠衝突；可在系統工作管理工具中結束沒有回應的舊執行個體，再單獨嘗試啟動一次。重新安裝前，請先保存訂閱群組與自行編輯的設定，避免「程式啟動故障」演變成「設定遺失」。
介面正常，但核心報錯
開啟 v2rayN 記錄，留意第一個明確的設定解析、連接埠監聽或核心啟動錯誤。若是連接埠占用，確認是否有其他用戶端執行個體或本機軟體占用了相應入口；若是設定解析錯誤，檢查最近修改的伺服器欄位、路由或 DNS 設定。不要只複製記錄末尾的「啟動失敗」，因為那通常是前面具體錯誤造成的結果。
可暫時選擇另一個未經手動修改的伺服器，並停用最近新增的自訂規則後重新測試。若這樣能夠啟動，再逐項還原原設定，找出觸發錯誤的項目。使用不同核心時，也要確認目前核心支援所選協定與參數；Xray 與 V2Fly 並非所有功能都能一一對應。詳細差異請參閱Xray 與 V2Fly 核心差異。
排除權限、安全軟體與設定損毀
若記錄顯示檔案讀寫失敗，請檢查程式所在目錄與設定目錄的權限，以及磁碟剩餘空間。安全軟體若提示封鎖，先查看實際涉及的檔案、動作與時間，再判斷是否與這次啟動失敗有關；不要為了排查而長期關閉系統防護。若要更換安裝位置，先備份自己的訂閱資訊與自訂設定，再使用適用於該平台的安裝檔重新安裝。
若程式只在載入現有設定時退出，可先完整備份，再使用乾淨設定測試介面能否開啟。若乾淨設定可以啟動，問題較可能出在原設定或其引用的檔案；若仍無法啟動，就應優先檢查安裝環境與系統記錄。不要公開上傳包含訂閱網址的完整設定檔；求助時只需提供已隱去敏感欄位的錯誤資訊。
建立可重複執行的復原順序
先確認介面能穩定開啟，再確認核心可以啟動，接著匯入一個有依據的伺服器設定，最後才還原訂閱、路由與 DNS 自訂項目。每還原一步就重新啟動並查看記錄，便能找出哪一步再次引入問題。若一次匯入所有舊設定後問題重現，仍無法判斷是哪個部分造成；因此，復原順序本身也是診斷過程。
問題解決後，再確認系統代理仍指向目前執行中的用戶端，並測試結束程式後系統代理能否正常關閉。閃退與代理殘留經常接連出現，但應分開處理：前者檢查程式與設定，後者檢查作業系統的代理狀態。若只是遇到常見的安裝疑問，可先參閱說明中心；需要從頭設定時，請依照教學重新操作。
八、Android 連線、背景執行與應用程式分流
Android 端優先檢查 v2rayNG；若需要使用對應 V2Fly 核心的用戶端，可選擇 v2flyNG。兩者都應依照下載中心的 Android 區，選擇符合裝置架構的安裝版本。桌面端「設定系統代理」的排查方式不能直接套用到手機：Android 用戶端主要依賴系統 VPN 授權建立裝置的流量入口，也會受到背景限制與應用程式分流設定影響。
點選連線後，先確認 VPN 授權
在用戶端選取伺服器並啟動連線時，留意系統是否顯示 VPN 連線要求。初次使用、重新安裝或權限變更後，可能需要再次確認授權。若用戶端顯示正在連線，卻一直沒有穩定的系統 VPN 狀態，先檢查授權流程是否完成，以及系統中是否有另一個 VPN 服務正在占用入口。不要在兩個同類服務之間快速反覆切換，先停止其中一個再測試。
若已顯示連線狀態，但所有應用程式都無法存取網路，請開啟用戶端記錄，檢查伺服器位址、連接埠與傳輸層設定，再用另一個已知可用的伺服器比對。手機從 Wi-Fi 切換到行動網路後，既有連線可能中斷；請重新發出請求確認是否恢復。若同一份設定只在某個網路中失敗，應優先記錄該網路條件，不要先刪除手機上的所有伺服器。
只有部分應用程式無法連線
檢查用戶端的應用程式代理或繞過設定，確認出問題的應用程式是否被排除。接著確認該應用程式是只有在背景時無法連線，還是留在前景也無法連線：前景仍失敗時，應優先檢查分流與應用程式本身的網路設定；只有背景失敗時，還要查看系統對背景活動的限制。有些應用程式會沿用代理切換前建立的舊連線，請完全關閉後重新開啟，再進行比對。
若瀏覽器可以使用、但某個應用程式無法連線，先不要認定節點失效。維持同一個節點與網路，分別測試兩個應用程式，並觀察用戶端記錄是否有請求進入。沒有請求記錄時，檢查應用程式分流、VPN 接管與系統權限；有請求但使用不同出口時，則檢查路由設定。應用程式本身採用的解析方式也可能不同，必要時可搭配本頁 DNS 章節進行比對。
鎖定螢幕或切換至背景後連線中斷
手機系統可能會限制背景活動，或在省電狀態下限制網路連線。先測試用戶端保持前景時是否穩定，再鎖定螢幕一段時間後重新測試；若問題只在背景出現，請檢查系統針對該用戶端的電池管理、背景執行與通知權限設定。不同裝置的選單名稱不完全相同，請依系統實際介面查找，不必照抄其他品牌手機的設定路徑。
即使允許背景執行，Wi-Fi 與行動數據之間切換時也可能需要重新建立連線。中斷時請記錄是否同時切換網路、是否啟用省電模式，以及用戶端是否仍顯示執行中。每次只調整一項系統設定並重新測試，避免為了維持背景連線而一次關閉多項無關的系統限制。連線恢復後，再確認裝置日常使用時的電池耗電量符合個人需求。
訂閱與兩款用戶端的設定差異
Android 訂閱失敗時，同樣要先分辨是取得失敗、內容解析失敗，還是清單遭到篩選。複製訂閱網址時，注意不要帶入空格或換行，也不要在公開截圖中顯示完整網址。若 v2rayNG 使用了依賴特定核心功能的設定，不應假設匯入 v2flyNG 後行為完全相同；應根據實際協定參數與用戶端記錄判斷相容性。
排查完成後，請檢查選取的伺服器、VPN 狀態、應用程式分流、背景權限與目前網路，並逐項記錄最後生效的設定。若桌面端與手機端使用同一份訂閱，卻得到不同結果，先比對兩者的網路與核心支援能力，不要立即修改訂閱來源。想了解三款用戶端各自適用的平台與定位，可參閱用戶端比較；基本匯入步驟仍可從教學開始。