V2Ray 故障排解手冊

先建立不受快取干擾的測試條件

保留一個一般網頁和一個純 IP 連線測試作為對照，不要只用已開啟很久的頁面判斷結果。瀏覽器可能重用舊連線，也可能保留失敗後的 DNS 結果。關閉瀏覽器所有視窗後重新開啟，或使用新的無痕視窗測試。暫時停止其他代理工具、網路加速工具及具流量過濾功能的軟體，確保同一時間只有一個程式修改系統代理。若電腦同時連接有線網路、無線網路和虛擬網卡，請先只保留目前實際使用的網路介面，避免預設路由在多個出口間變動。

接著觀察用戶端主介面：目前節點應處於選取狀態，核心狀態應為執行中，日誌中不應連續出現設定解析失敗或連接埠繫結失敗。v2rayN 中「設定系統代理」和「啟動核心」是兩個不同動作；核心正在執行但系統代理未啟用時，一般瀏覽器不會自動將請求送入代理。使用 TUN 模式時，則應確認虛擬網卡已建立，且系統沒有跳出等待確認的權限要求。TUN 的原理和完整啟用步驟請參閱TUN 模式接管流量說明。

檢查本機監聽連接埠與應用程式代理

v2rayN 常見的本機入口是 SOCKS 與 HTTP 監聽連接埠，實際數值以用戶端設定頁為準。不要直接把教學中的範例連接埠當成目前設定。Windows 可在終端機檢查連接埠是否由用戶端程序監聽；若沒有結果，表示核心未成功建立入口。若發現其他程序佔用相同連接埠，應先識別該程序，再決定關閉衝突程式或修改本機連接埠，詳細流程請見本機連接埠佔用處理。

netstat -ano | findstr LISTENING
tasklist /FI "PID eq 程序編號"

手動設定瀏覽器或其他應用程式時，代理類型必須與監聽入口一致。SOCKS5 入口不能填作 HTTP 代理，HTTP 入口也不能填入只接受 SOCKS 的設定欄位。位址通常使用 127.0.0.1，不要填寫節點伺服器位址。若應用程式提供「代理 DNS」或「透過 SOCKS 解析網域」選項，可先啟用它進行對照測試；如此網域解析會與應用程式請求走同一入口，有助於排除本機 DNS 的影響。

用直連與代理結果劃分故障邊界

關閉系統代理後測試一般網路。若直連也無法開啟任何網頁，應先修復本機網路、閘道或目前網路的驗證流程，V2Ray 設定不是第一個排查對象。若直連正常、啟用代理後全部失敗，而本機連接埠確實正在監聽，應重點查看用戶端日誌中請求發往哪個出站。出現連線被拒絕，通常表示遠端位址可達但對應連接埠未提供服務；連線逾時則較接近網路路徑、位址錯誤或遠端節點無法連線；握手失敗則要核對協定、傳輸層、安全層、主機名稱和路徑。

如果只有部分網站無法開啟，先切換路由模式進行短時間對照。全域模式正常而規則模式失敗，問題通常在規則命中結果，而不是節點本身。檢查網域規則是否過早分配到直連或阻斷出站，並留意規則由上到下比對時的覆蓋關係。如果網頁能開啟但圖片、登入或驗證碼失敗，請檢查頁面引用的其他網域是否命中了不同規則。排查完成後應恢復原有分流目標，不建議長期依賴全域模式掩蓋規則錯誤。

最後檢查系統時間。VLESS、VMess、TLS 等連線都可能受到明顯時間偏差影響。啟用作業系統自動校時，並確認時區正確。完成校時後重新啟動核心，讓新連線重新握手。若同一節點在另一台裝置可用，而目前裝置仍失敗，應優先比較兩端的設定欄位、系統代理狀態與安全軟體策略；若所有裝置都在同一時間失敗，則更可能是節點端或目前網路路徑的問題。

區分測試類型與實際存取

TCP 測試只驗證目標位址和連接埠能否建立基礎連線，不能驗證 VLESS、VMess 或其他協定參數是否正確。實際延遲測試會透過節點存取指定網址，涵蓋本機入口、遠端握手、出站請求和目標回應，因此更接近實際使用，但也更容易受到測試網址無法連線、DNS 失敗或路由規則影響。出現「TCP 可用、實際測試逾時」時，應重點檢查協定驗證、TLS、傳輸路徑與測試網址；出現「TCP 直接逾時」時，優先檢查伺服器位址、連接埠及目前網路到遠端的可達性。

不要連續高頻率測試所有節點。批次測試會同時建立大量連線，可能觸發本機網路設備的連線數限制，也會讓日誌被重複錯誤覆蓋。選擇一個設定明確的節點，間隔數秒測試一次，並在每次測試後讀取對應時段的日誌。節點名稱只用於識別，真正決定連線的是位址、連接埠、使用者識別碼、傳輸方式、安全層和附加欄位。

逐欄位比較，不要依賴節點名稱

手動新增設定時，應逐項核對協定類型、遠端位址、連接埠、使用者識別碼、加密或流控設定、傳輸類型、路徑、Host、伺服器名稱以及指紋類選項。大小寫、開頭斜線和空格都可能改變結果。例如 WebSocket 路徑通常應與伺服器端完全一致；伺服器名稱用於 TLS 握手，不能因為節點位址是 IP 就隨意留空；REALITY 設定中的伺服器名稱、短識別碼和公開金鑰屬於同一組參數，混用不同節點的欄位會在握手階段失敗。

匯入訂閱後如果只有某一個節點失敗，可以複製該節點並逐欄位對照訂閱原文，但不要在原節點上反覆覆寫，以免失去比較基準。如果同一訂閱的所有節點都逾時，先嘗試其他網路，例如從公司網路切換到家用網路或行動網路。其他網路可用，表示用戶端設定大致正確，故障位於目前網路策略、DNS 結果或出口路由。所有網路都失敗，則應更新訂閱並確認節點資訊是否已變更。

確認位址解析與雙協定堆疊路徑

節點位址為網域名稱時，用戶端必須先完成 DNS 解析。可以在系統終端機查詢該網域，觀察是否回傳位址及其位址族群。如果只回傳 IPv6，而目前網路沒有穩定的 IPv6 出口，可能會在長時間等待後逾時；如果回傳多個位址，其中某個位址無法連線，也可能造成首次連線緩慢。可暫時切換至可靠的 DNS 進行對照，或在用戶端中調整網域解析策略，但不要長期固定訂閱網域對應的 IP，因為伺服器端位址可能變動。

若測試顯示有延遲數值但實際存取失敗，表示測試路徑與應用程式路徑不一致。檢查測試是否繞過自訂路由、應用程式是否使用系統代理，以及瀏覽器是否啟用了獨立代理擴充功能。最後使用一個節點完成實際網頁存取，再決定是否保留。延遲排序只能用於初步篩選，穩定性、握手成功率和目標存取結果更能說明節點是否適合目前網路。

先檢查訂閱位址本身

複製訂閱位址時，必須包含完整協定標頭、路徑和查詢參數。聊天軟體或文件可能只將前半段辨識為連結，導致參數遭截斷；位址兩端也可能混入空格、換行或中文標點。建議使用用戶端的訂閱管理視窗重新貼上，並將訂閱名稱設定為方便識別的短文字。不要把單一 vmess://、vless:// 分享連結放入訂閱位址欄，它們屬於單一節點的匯入內容；訂閱欄需要填入能回傳節點集合的位址。

訂閱服務可能要求有效的存取參數。若連結曾重新產生，舊位址即使能開啟，也可能只回傳錯誤說明或空內容。不要因為瀏覽器「出現了一段文字」就判斷訂閱有效，因為錯誤頁面同樣可能回傳正常的 HTTP 狀態。用戶端日誌通常會記錄請求狀態、回應類型或解析失敗位置。請特別留意未授權、禁止存取、資源不存在、重新導向次數過多及回應內容為空等提示。

判斷訂閱請求使用直連還是代理

首次安裝且節點清單為空時，訂閱更新通常只能使用目前的直連網路。已有可用節點時，部分用戶端允許透過代理更新訂閱。如果直連更新失敗、代理更新成功，表示訂閱服務無法透過目前直連路徑連線；反過來則可能是目前代理節點無法存取訂閱位址。排查時不要讓「更新訂閱時使用代理」和「自動更新訂閱」同時反覆執行，否則日誌會混合多次請求。先關閉自動更新，再手動選擇一種路徑測試。

系統代理與用戶端內部的訂閱請求不是同一概念。有些用戶端更新訂閱時直接由核心發起，有些則由應用程式程序發起，因此系統代理開關不一定會決定訂閱請求路徑。應以用戶端設定項目和日誌為準。使用公司網路、校園網路或需要網頁驗證的網路時，請先用一般瀏覽器完成網路驗證；未驗證狀態下，請求可能被重新導向至登入頁面，用戶端收到 HTML 後便會回報格式錯誤。

處理「更新成功但清單沒有變化」

先確認查看的是正確的訂閱群組。用戶端可能依訂閱名稱建立群組，更新後的節點進入其他群組，而目前介面仍顯示舊群組。檢查篩選條件、搜尋文字和隱藏無法使用節點等選項。其次觀察節點數量、名稱或更新時間是否有任何變化；伺服器端回傳內容未變化時，用戶端保留原清單屬於正常結果。若日誌顯示解析出零個節點，應檢查訂閱格式是否受用戶端支援，以及回傳內容實際上是否為錯誤說明。

v2rayN 用於 Windows、macOS 和 Linux 桌面環境，v2rayNG 與 v2flyNG 用於 Android。不同用戶端對訂閱擴充欄位的支援範圍可能不同。同一位址在一個用戶端可匯入、另一個用戶端卻為空時，不要立即修改所有節點；先查看未辨識欄位是否屬於用戶端不支援的擴充格式，並更新至下載頁提供的目前用戶端版本。用戶端更新後重新建立一個測試訂閱群組，避免舊資料庫中的殘留欄位影響結果。

若訂閱更新後節點重複，通常是同一位址被新增多次，或「追加節點」與「覆蓋更新」策略不同。保留一個訂閱來源，刪除重複的訂閱紀錄，再執行一次更新。不要只按節點名稱批次刪除，因為不同伺服器可能使用相同顯示名稱。需要轉移裝置時，優先在新裝置重新新增訂閱，不要同時匯入舊資料庫和同一訂閱來源，否則容易形成重複紀錄與過期設定並存。

最後檢查系統日期、網路代理和憑證信任。如果瀏覽器也無法開啟訂閱位址，先處理網路層；瀏覽器可存取但用戶端失敗，則收集用戶端日誌中的請求時間、狀態和解析錯誤，再針對相應階段處理。訂閱位址屬於存取憑證，不應貼到公開頁面或截圖中，排查截圖應遮住完整路徑與查詢參數。

建立可重複的對照測試

先關閉代理，在相同網路、相同裝置上測試一般網頁載入和一個穩定檔案的下載，記錄大致表現即可，不必追求單次峰值。接著啟用代理，只選擇一個節點，保持瀏覽器、測試目標和時段一致。測速期間暫停系統更新、雲端硬碟同步、影片播放及其他裝置的大流量工作。無線網路訊號弱、路由器負載過高或行動網路頻繁切換基地台時，任何節點都可能出現波動，應先排除本機連線問題。

區分「網頁第一次開啟很慢」和「持續下載很慢」。第一次開啟很慢但後續正常，常見原因是 DNS、TLS 握手或建立連線耗時；下載開始很快、隨後下降，可能是網路壅塞、遠端限速或封包遺失重傳；小型網頁正常但大型檔案很慢，表示基本連線沒有問題，應重點比較路徑品質和持續吞吐量。不要只根據一個目標網站下結論，目標服務本身的負載和區域調度也會改變結果。

比較節點與傳輸路徑

選擇地理距離和網路路徑合理的節點進行對照。延遲較低通常有利於互動，但低延遲不代表高頻寬；延遲略高但封包遺失較少的節點，持續傳輸可能更穩定。每次只切換節點，其他設定保持不變。若同一訂閱中的所有節點都很慢，而直連正常，應檢查本機代理模式、DNS 和安全軟體；若只有一個節點很慢，優先更換節點即可，不必修改整個用戶端。

傳輸層參數必須與伺服器端相符，不能為了「提速」任意切換。WebSocket、gRPC、TCP 等方式具有不同的連線特徵，但實際效果取決於伺服器端設定與網路路徑。錯誤的 Host、路徑或伺服器名稱可能表現為重試和間歇性失敗，而不是立即報錯。若日誌中連續出現重建連線、EOF、逾時或握手失敗，應先修復穩定性，再討論速度。

檢查路由、並行連線與本機處理開銷

在規則模式下，一個頁面的主文件、圖片、腳本和 API 可能命中不同出站。如果主頁面使用代理，但靜態資源直連失敗，使用者感受到的就是頁面長時間空白。開啟用戶端路由日誌，或暫時切換至全域模式進行對照：全域模式明顯改善時，逐項檢查頁面相關網域的規則命中情況。規則應從明確、具體的條件開始，再進入較寬泛的兜底規則，避免上方的大範圍直連規則提前攔截請求。

TUN 模式會處理更多程序的流量。啟用後速度下降時，請檢查是否也將系統更新、區域網路存取和大型檔案同步納入代理。合理設定區域網路與必要的直連規則，可減少無關流量經過遠端連線。同時，避免並用系統代理、瀏覽器代理擴充功能和另一套虛擬網卡接管；重複轉發可能形成迴圈，表現為 CPU 使用率升高、網頁反覆重試和速度驟降。

用戶端日誌等級長期設定過高，也可能增加磁碟寫入，尤其在大量短連線的情境下。診斷時可提高日誌詳細程度，確認問題後應恢復一般等級並清理過大的歷史日誌。安全軟體若對每個新連線執行深度檢查，也會增加首次開啟時間；可在不改變整體防護策略的前提下，確認用戶端程序和本機監聽連線是否遭到重複掃描。

DNS 解析緩慢時，頁面會在建立連線前等待。可配合本頁 DNS 章節檢查解析耗時，並參閱DNS 請求與代理連線設定。若 TUN 環境使用 FakeDNS，也應了解假位址映射與網域還原的邊界，相關原理請見FakeDNS 運作流程。完成效能調整後，重新測試至少兩個目標和兩個時段，避免把暫時性的網路波動誤判為固定設定問題。

判斷問題是否只發生在網域

如果日誌顯示目標網域解析失敗，而直接存取已知可達的 IP 有回應，故障便集中在 DNS；如果網域能解析出位址但連線仍逾時，還要檢查遠端路徑。Windows 可使用 nslookup，macOS 與 Linux 可使用 dig 或 nslookup 查看系統解析結果。查詢時分別記錄回傳的 IPv4 與 IPv6 位址，不要只看命令是否成功執行。

nslookup example.com

dig example.com A
dig example.com AAAA

系統查詢正常，不代表用戶端內部 DNS 一定正常。v2rayN、v2rayNG 和 v2flyNG 可由核心執行獨立解析，並根據路由選擇不同伺服器。若瀏覽器直連正常、使用代理後網域解析失敗，應查看用戶端日誌中的 DNS 伺服器、查詢類型和出站標記。如果請求被送往只能透過代理存取的 DNS，而目前代理尚未建立，就可能形成啟動依賴；反過來，將需要透過代理存取的解析請求強制直連，也會持續逾時。

釐清 DNS 與路由的執行順序

路由規則可以依網域、IP、連接埠或程序比對。網域規則需要核心保留目標網域資訊；IP 規則則可能要求先解析。設定中啟用按需解析時，只有規則需要 IP 條件才查詢位址，可減少不必要的解析。若所有網域都在路由前強制解析，再依回傳 IP 分流，目標服務使用動態位址時可能套用錯誤規則。排查階段應先使用較簡單的 DNS 設定，確認基本存取恢復後，再逐步加入分流伺服器、網域清單和位址策略。

以下是用來理解結構的核心 DNS 範例。實際位址與標籤應依目前網路和設定調整，不能直接覆蓋用戶端自動產生的完整設定。重點在於 DNS 伺服器可以指定出站，查詢策略也應與網路支援的位址族群一致。

{
  "dns": {
    "queryStrategy": "UseIP",
    "servers": [
      {
        "address": "1.1.1.1",
        "port": 53,
        "skipFallback": false
      },
      "localhost"
    ]
  }
}

處理快取、IPv6 與 FakeDNS 的邊界

修改 DNS 後應清除系統快取並重新建立瀏覽器連線。Windows 可在系統管理員終端機執行 ipconfig /flushdns；採用核心獨立 DNS 時，也應重新啟動用戶端核心，因為清除系統快取不會清除核心內部狀態。瀏覽器可能維護自己的主機快取，完全結束後再開啟比一般重新整理更可靠。若網路只穩定支援 IPv4，而解析優先回傳 IPv6，可暫時調整查詢策略進行驗證；確認後再決定是修復本機 IPv6 路由，還是讓用戶端優先使用目前可達的位址族群。

FakeDNS 常與 TUN 模式搭配使用：應用程式會取得一個保留位址，核心再依映射還原原始網域並執行路由。它能保留網域資訊，但並非所有區域網路應用程式和特殊協定都適合使用假位址。若發生區域網路裝置探索失敗、部分應用程式連線固定 IP 異常，應將區域網路網域、私有位址區段和必要系統服務排除在 FakeDNS 之外。不要把 FakeDNS 位址當成遠端真實位址寫入規則或用於手動連線。

若表現為「可以存取，但解析路徑與預期不一致」，應分開觀察應用程式發起的 DNS、用戶端使用的 DNS，以及節點連線所需的 DNS。節點伺服器網域必須在代理連線建立前完成解析，通常需要可直接存取的解析路徑；目標網站解析則可依路由經由不同出站。將這兩類查詢混在同一組複雜規則中，容易造成循環依賴。修復後，應同時驗證網域解析結果、用戶端日誌中的出站標記及實際網頁請求，具體檢測方式可繼續閱讀DNS 洩漏檢測與修復實作。

確認系統代理值與本機監聽一致

系統代理中的位址應指向本機入口，通常是 127.0.0.1 加上用戶端目前的 HTTP 連接埠。若用戶端修改了本機連接埠，但作業系統仍保留舊連接埠，啟用代理後便可能立即斷網。v2rayN 異常結束時也可能留下舊設定，因此重新開啟用戶端後，應先清除系統代理，再依目前設定重新設定。不要讓多個用戶端同時爭用同一連接埠，或反覆寫入系統代理。

Windows 可在系統網路設定中查看手動代理，也可以用命令讀取 WinHTTP 層的設定。請注意，WinHTTP 與一般桌面應用程式使用的代理設定並不完全相同，某個命令顯示「直連」不能單獨證明瀏覽器沒有使用代理。macOS 可依目前網路服務分別設定網頁代理和安全網頁代理；切換無線網路服務後，舊網路服務上的設定不一定會套用至目前連線。Linux 桌面環境可能使用圖形設定、環境變數或應用程式自身設定，三者應分別核對。

netsh winhttp show proxy

scutil --proxy

env | grep -i proxy

辨識忽略系統代理的應用程式

命令列工具通常會讀取 HTTP_PROXY、HTTPS_PROXY 或 ALL_PROXY 環境變數，但也可能要求在自身設定中指定。環境變數中的代理類型要與本機入口相符，作用範圍也要明確：只在目前終端機設定時，新開的另一個終端機不會繼承；寫入全域環境後，用戶端關閉時又可能留下失效位址。排查階段建議只在目前工作階段暫時設定，測試後再移除。

某些應用程式使用 UDP、直連通訊端或自有 DNS，不會遵循 HTTP 系統代理。此時可考慮使用 TUN 模式，讓虛擬網卡在網路層接管流量。啟用前應確認管理員權限、虛擬網卡驅動程式和路由設定正常，並排除區域網路位址，避免印表機、路由器管理頁面和檔案分享被送往遠端。TUN 不是修復錯誤節點的替代方案：節點握手本身失敗時，擴大接管範圍只會讓更多應用程式同時失敗。

處理代理殘留、迴圈與區域網路繞過

代理迴圈常見於瀏覽器擴充功能指向系統代理、系統代理又被另一個工具轉發，或用戶端自身的更新請求被錯誤送回自己的監聽連接埠。常見表現包括 CPU 使用率升高、日誌中同一目標快速重複出現，以及網頁持續載入卻沒有結果。關閉瀏覽器代理擴充功能和其他網路工具，只保留用戶端寫入的系統代理；確認恢復後，再決定是否需要應用程式層級規則。

系統代理的繞過清單應包含本機和必要的區域網路位址。存取 localhost、127.0.0.1 或私有網路裝置時，通常不應繞道遠端。若繞過範圍寫得過寬，例如用模糊萬用字元涵蓋大量網域，又會導致原本需要代理的請求改走直連。每條繞過規則都應說明適用對象，修改後分別用一個區域網路位址和一個外部目標驗證。

用戶端正常結束時通常會恢復系統代理，但系統強制關機、程序崩潰或權限不足時可能無法完成。若出現用戶端未執行卻整體無法上網，先在作業系統中關閉手動代理，再重新啟動瀏覽器。若經常發生，應檢查用戶端是否有足夠權限寫入設定、是否遭安全軟體阻止，以及是否有其他程式定期改寫代理。連接埠變更後同步更新系統代理的完整操作，可參考本機監聽連接埠衝突處理。

最終驗證應涵蓋三類應用程式：一個會讀取系統代理的瀏覽器、一個透過自身代理設定連線的工具，以及一個需要 TUN 才能接管的應用程式。三類結果可以釐清系統代理與 TUN 的邊界。不要為了讓單一應用程式運作而同時啟用所有接管方式；選擇能涵蓋目標流量的最小方案，後續路由與故障定位會更清楚。

從啟動日誌確認結束階段

如果用戶端視窗能開啟，先查看日誌目錄和主介面最後幾行資訊。設定解析錯誤通常會在核心啟動後立即出現，並指出欄位、JSON 位置或不支援的設定項目；連接埠佔用會顯示繫結失敗；執行數秒後結束，則可能與 TUN 權限、虛擬網卡、網路環境或某一項實際請求有關。不要在日誌尚未儲存時反覆重新啟動，先複製發生時間附近的錯誤文字，並遮住節點位址、使用者識別碼和訂閱參數。

如果介面完全無法開啟，請檢查系統工作管理員或活動監視器中是否存在殘留程序。殘留程序可能佔用資料庫和連接埠，使第二次啟動失敗。正常結束殘留程序後再啟動一次，不要連續點擊多個啟動入口。桌面端首選 v2rayN，應從用戶端下載頁選擇符合系統和處理器架構的安裝包。macOS 首次啟動涉及系統安全性放行和網路權限時，可參閱macOS 安裝與權限處理。

隔離使用者設定與程式檔案

升級後閃退不一定是程式本身損壞，也可能是舊資料庫、主題設定或自訂設定與新結構不相容。先備份訂閱位址和必要設定，再關閉用戶端。不要直接刪除原始資料目錄；將其重新命名，讓用戶端在空白設定下啟動。如果空白設定能正常執行，表示問題位於使用者資料。此時應逐步還原訂閱和設定，而不是一次將整個舊目錄覆蓋回去。

自訂 JSON 設定最容易造成核心啟動失敗。可以先切換至由用戶端產生的一般節點設定，確認核心能夠執行後，再檢查自訂檔案。JSON 不允許尾隨逗號，字串中的反斜線和雙引號需要正確處理，欄位類型也必須符合核心要求。以下命令可用於檢查 JSON 基本語法；檔名請依實際路徑替換。

python -m json.tool config.json

語法正確仍不代表設定語意正確。不存在的出站標籤、路由規則引用錯誤、重複監聽連接埠和目前核心不支援的欄位，都可能在載入階段失敗。應從日誌指出的第一個錯誤開始修復，後續錯誤有時只是第一處失敗引發的連鎖結果。

檢查權限、安全策略與系統資源

TUN 模式需要建立虛擬網卡並修改路由，權限不足時可能在啟用瞬間結束。先關閉 TUN，驗證一般系統代理模式能否執行；一般模式正常而 TUN 崩潰時，再檢查管理員權限、虛擬網卡狀態和系統中的其他 VPN 類網路驅動程式。多個虛擬網卡同時修改預設路由時，也可能導致核心啟動後失去網路並反覆重新啟動。

安全軟體可能隔離核心子程序、阻止其監聽本機連接埠，或限制它讀取設定目錄。應查看系統安全性紀錄中與用戶端啟動時間相符的事件，並依明確紀錄處理，而不是盲目關閉所有防護。程式目錄沒有寫入權限時，日誌和資料庫也可能建立失敗；請將用戶端安裝在目前使用者可讀寫的位置，並避免直接從壓縮檔預覽視窗執行。

執行一段時間後才崩潰時，還要觀察記憶體、磁碟空間和日誌大小。過於詳細的日誌在高連線量環境下會快速增長，磁碟空間不足會影響設定寫入與更新。清理舊日誌後將等級恢復為一般，再重新現問題。若崩潰只由某個節點觸發，複製該節點進行欄位對照；若空白設定也持續崩潰，則記錄作業系統、用戶端名稱、崩潰時間和系統事件資訊，重新安裝符合目前架構的用戶端。排查期間不要同時匯入大量訂閱，以免把設定問題和執行環境問題混在一起。

連線按鈕無效或 VPN 授權失敗

首次啟動連線時，系統會顯示 VPN 連線確認。未完成確認、系統中已有其他 VPN 服務，或工作資料設定有所限制時，用戶端便無法建立介面。先中斷其他 VPN 類應用程式，返回用戶端重新啟動連線，並完成系統確認。狀態列出現 VPN 標記只代表介面已建立，仍需查看用戶端日誌確認節點握手是否成功。若連線後立即停止，請檢查節點設定、目前網路和應用程式背景權限，不要只是不斷點擊啟動按鈕。

從一個用戶端切換到另一個用戶端時，應先在原用戶端停止服務，再開啟新用戶端。v2rayNG 使用 Xray 核心，v2flyNG 使用 v2fly 核心，兩者可作為 Android 上的不同選擇，但不應同時建立系統 VPN。訂閱可分別匯入測試，節點參數需要保持一致，避免把用戶端差異與節點差異混為一談。需要重新安裝時，請從Android 用戶端入口選擇 v2rayNG 或 v2flyNG，並優先依裝置架構選擇安裝包。

處理背景中斷與網路切換

系統的電池最佳化可能在螢幕關閉後限制用戶端於背景執行。將目前使用的用戶端加入允許背景執行的應用程式清單，並允許自動啟動或背景活動；不同裝置的設定名稱可能是電池最佳化、背景使用量、電量管理或休眠應用程式。只調整實際使用的用戶端，不需要為所有網路應用程式放寬限制。完成設定後鎖定螢幕數分鐘，再解鎖測試網頁和日誌，確認服務是否仍在執行。

從無線網路切換至行動網路時，本機 IP、DNS 與預設路由都會變更。多數情況下用戶端會自動重建連線，但舊連線可能在短時間內保留。切換網路後若無法存取，先停止再啟動一次服務，讓 VPN 介面重新繫結目前網路。頻繁在兩個網路間切換會讓測試結果混亂，排查時先固定一種網路完成驗證，再測試另一種網路。若只有某個網路失敗，應回到節點逾時和 DNS 章節判斷該網路的可達性。

檢查應用程式分流與私人 DNS

Android 的應用程式分流可以選擇哪些應用程式進入 VPN。採用白名單時，新安裝的應用程式可能預設不經過用戶端；採用排除模式時，被排除的瀏覽器也不會使用代理。排查「只有一個應用程式無法使用」時，先查看該應用程式是否已選取，再暫時關閉應用程式分流進行對照。所有應用程式恢復正常後，再重新啟用分流並逐一加入規則。系統元件、下載管理器和瀏覽器呼叫的外部服務可能屬於不同程序，因此只選取主應用程式不一定涵蓋完整請求流程。

系統私人 DNS 可能在 VPN 之外或之內形成另一條解析路徑，實際行為取決於系統和用戶端設定。若出現網域解析失敗但 IP 可達，先將私人 DNS 恢復為自動狀態進行對照，再檢查用戶端 DNS。瀏覽器本身的安全 DNS 也可能繞過核心規則，排查期間應保持預設設定。確認用戶端 DNS 正常後，再決定是否恢復系統層級的自訂解析。

區域網路存取失敗時，請檢查是否啟用了繞過區域網路，以及應用程式是否嘗試存取私有位址。某些裝置在 VPN 啟用後可能預設封鎖不經 VPN 的連線，導致印表機、路由器管理頁面或區域網路服務無法存取。應在用戶端中為私有位址設定明確直連，並確認系統沒有啟用會封鎖所有非 VPN 流量的嚴格選項。修改後分別測試區域網路位址和外部網頁，避免直連範圍過度擴大。

透過 QR Code 匯入後連線失敗時，請逐項比較協定、位址、連接埠、使用者識別碼、安全層、伺服器名稱和傳輸路徑。相機辨識可能截斷過長內容，剪貼簿也可能保留換行。匯入訂閱通常比手動掃描多個節點更方便更新，但訂閱更新失敗時，仍需依本頁訂閱章節檢查。最後保留一個能穩定重現問題的節點，分別在無線網路和行動網路測試；只有某種網路失敗屬於路徑問題，兩種網路都失敗而桌面端相同設定可用時，應重點比較 Android 用戶端中的 DNS、應用程式分流和傳輸欄位。

如果應用程式在背景中穩定執行，但訊息或同步延遲，不要直接將所有應用程式加入代理。先確認目標應用程式是否受到系統省電策略限制、是否依賴被排除的系統元件，以及其網域是否命中預期路由。Android 專題排查的核心，是分開驗證系統 VPN、用戶端核心和應用程式權限：VPN 介面存在、核心連線成功、目標應用程式進入介面，三項同時成立才算完整連線流程。