v2rayN 故障排除
連線、訂閱與用戶端設定

一、連線後無法上網：先判斷故障環節

比對直接連線與代理連線

「無法上網」可能由多種原因造成。先關閉用戶端並還原系統原本的代理設定，再開啟平常能直接連線的網站。如果仍無法連線，請優先檢查 Wi-Fi、閘道、系統時間與網路登入頁面。飯店、校園或公共 Wi-Fi 可能需要先完成網頁驗證；用戶端顯示已啟動，並不代表基礎網路已經連通。基礎網路尚未恢復前，請勿反覆更換協定。

確認直接連線正常後，再啟動用戶端，並確認伺服器清單中確實有作用中的伺服器，而不只是反白選取了一筆記錄。接著查看執行日誌，確認核心已成功啟動，且本機入站已開始監聽。系統匣中看得到圖示，只能代表圖形介面仍在執行；若核心啟動失敗、連接埠遭占用或設定產生失敗，瀏覽器仍可能連到沒有服務的本機位址。

選定同一個測試網站，分別記錄直接連線與透過代理連線的結果。每次只送出一個要求，並記下時間，方便在日誌中找到對應記錄。若瀏覽器出現錯誤，但用戶端完全沒有新增日誌，問題通常在應用程式接管或本機入口；若出現出站連線錯誤，則繼續檢查伺服器與協定。不要把瀏覽器快取中的舊錯誤頁面當成新測試結果。

使用明確代理確認本機入口

在 v2rayN 的參數設定中確認 HTTP 或混合入站的實際連接埠。以下範例假設連接埠為 10808；只有設定一致時才能直接執行，否則請先替換數字。在 Windows 上可使用 curl.exe，避免命令環境中的同名別名影響參數。此測試只用來確認要求是否經過本機入口，不代表所有網站都能正常連線。

curl --noproxy "" --proxy http://127.0.0.1:10808 --connect-timeout 10 --max-time 20 -I https://example.com

若顯示無法連線至本機連接埠，先檢查核心程序、監聽位址與連接埠類型，不必立刻修改遠端伺服器。若本機連線已建立，接著卻出現交握失敗或遠端逾時，請前往下一章。若收到網站的 HTTP 回應，即使狀態碼不是成功，也表示應用層已收到回應；請依內容判斷是目標網站限制、驗證問題，還是代理鏈路中的其他環節。

明確代理測試成功，但瀏覽器仍無法使用時，請優先檢查瀏覽器的獨立代理設定、代理擴充功能及系統代理。無痕視窗不一定會停用所有擴充功能，也不一定會略過系統設定。可改用沒有獨立代理規則的瀏覽器設定檔進行比對。若只有特定應用程式出問題，也要確認它是否遵循系統代理；瀏覽器能用，不代表所有程式都會自動使用相同入口。

還原基本設定，再逐項加回功能

若同時使用多項自訂設定，請先備份，再保留一台已確認可用的伺服器與簡單的路由設定。暫時停用額外代理鏈、複雜規則集及重複執行的網路工具，避免要求在多個本機入口間繞行。測試期間不要同時啟用系統代理、另一套流量接管工具與瀏覽器代理擴充功能，除非已清楚掌握各自的入口與出口，否則很難從日誌還原同一條連線路徑。

所有網站都無法連線時，請檢查共用的入口、DNS 解析與出站；只有特定類型的網域出問題時，則檢查路由規則、目標位址及網站本身的狀態。可暫時將測試網域指定到明確的代理出站，確認後再還原原有規則。不要長期以全域代理作為修復方式；這可能只是繞過錯誤規則，並未真正解決設定問題。

修復後，依序還原自訂路由、瀏覽器設定與其他網路工具，每次還原一項就重新測試同一個目標。最後關閉並重新啟動用戶端，確認設定在重啟後仍然有效。記下可用入口、作用中的伺服器及代理模式，下次遇到問題時便能與這份基準比對。若不確定連線設定步驟，請回到快速入門教學核對，不要重新匯入大量重複設定。

二、節點逾時：區分傳輸連線與協定交握

確認逾時發生在哪個階段

用戶端測試逾時，可能是伺服器網域解析失敗、無法連上目標連接埠，也可能是傳輸已連通但協定交握尚未完成。不同測試功能使用的目標與方法不盡相同，因此清單中的測試結果不能取代實際連線。先查看日誌中最早出現的錯誤；後續連續錯誤可能只是同一次失敗觸發的重試，不應視為多個獨立問題。

在 Windows 上可執行以下連接埠測試；位址與連接埠僅為教學範例，請換成設定中的實際值。測試成功只代表 TCP 連線可以建立，無法證明 VLESS、REALITY 或使用者驗證設定正確。測試失敗時，也要確認伺服器是否只接受特定網路路徑；不要只憑一次結果就認定用戶端損壞。

Test-NetConnection -ComputerName your-server.example.com -Port 443

如果伺服器使用的傳輸方式不只是一般 TCP 連線，這項測試的參考價值就更有限。若使用 UDP 路徑，還需檢查本機網路與伺服器端是否允許相關流量。一般網頁能開啟，不代表所有傳輸方式都可連通。改用 Wi-Fi 與行動網路連線同一目標進行比對，比連續修改多個協定參數更容易找出網路環境的差異。

逐項核對 VLESS 與 REALITY 參數

傳輸連接埠可連通但交握失敗時，請依伺服器端提供的原始資料逐項核對。伺服器位址決定連線目標；伺服器名稱用於安全交握，兩者不一定相同。不要自動將伺服器名稱改成連線位址，也不要因為位址使用某個連接埠，就自行推斷應關閉傳輸層安全性。用戶端與伺服器端必須使用相符的協定組合。

使用 XTLS Vision 時，也要確認流量控制與目前的傳輸方式、安全選項相符。不要看到類似設定可用，就把它的流量控制值複製到其他伺服器。REALITY 的公鑰、短識別碼與伺服器名稱都必須符合伺服器端要求；短識別碼可能有不同的設定方式，能否留空取決於伺服器端設定，不能只以某篇教學截圖為準。

系統時間明顯不準也可能影響安全交握。啟用作業系統自動校時後，確認日期與時間符合實際狀況。若錯誤訊息與憑證或伺服器身分有關，請檢查伺服器名稱、憑證部署及系統信任環境，不要把關閉身分驗證當成一般修復方式。隱藏交握錯誤後，連線或許看似恢復，但原本的設定與安全問題仍然存在。

釐清伺服器端、核心與本機網路的問題範圍

同一個網路下，只有一台伺服器持續逾時，而其他已知可用的伺服器正常時，請優先確認該伺服器的位址、服務狀態與帳號是否有效。若所有伺服器同時異常，而且剛好發生在路由器調整或網路切換後，應先檢查共用的網路路徑。比對測試必須使用相同參數，否則無法判斷差異來自網路還是設定本身。

同時確認所選核心是否支援設定所需功能。Xray 與 V2Fly 的功能並不完全相同，能匯入分享內容不代表核心一定能執行。REALITY 與設定相容性的背景說明，請參閱Xray 與 V2Fly 核心差異。只有日誌明確指出功能不受支援時，才依設定需求調整核心或用戶端。

向設定提供者回報時，請整理測試時間、使用的網路、連線目標、錯誤階段，以及已遮蔽敏感資訊的第一筆錯誤。不要只傳送「逾時」截圖，也不要公開訂閱憑證。如果相同設定在另一個網路環境正常，請說明兩種環境的差異；若所有環境都無法使用，則需要搭配伺服器端日誌調查。用戶端本身無法修復遠端未監聽、帳號停用或伺服器端參數不符等問題。

三、訂閱失敗：先區分取得、解析與更新

確認網址是否回傳正確內容

訂閱更新分為取得網址、解析內容與寫入伺服器清單三個階段。出現更新失敗時，先查看具體錯誤：網域解析失敗、連線逾時、驗證遭拒及內容無法解析，各有不同處理方式。有些服務會回傳正常的網頁狀態碼，但實際內容卻是登入頁面或存取提示；這不是有效的訂閱資料，反覆點選更新也不會改變結果。

請從可信任的設定管理頁面重新複製完整訂閱網址，確認通訊協定、路徑與查詢參數都沒有遺漏。聊天工具插入換行、手動刪除尾端字元，或複製時多帶前後空格，都可能改變網址。訂閱連結通常包含存取憑證，應視同密碼保管；不要貼到公開測速網站、線上解碼工具或問題討論區，也不要使用包含完整網址的截圖求助。

若日誌顯示驗證遭拒或資源不存在，先到原本的設定管理頁面確認訂閱是否仍有效、帳號是否有權限，以及網址是否已重設。伺服器節點可連線與訂閱網址可更新是兩回事：既有伺服器記錄仍可能可用，但訂閱存取憑證可能已變更。反過來說，成功取得訂閱也不代表其中每台伺服器目前都能連線。

確認更新要求使用哪條網路路徑

訂閱更新可能採直接連線，也可能依用戶端設定透過現有代理連線。先查看更新相關選項，不要假設它一定會跟隨系統代理。若用戶端剛安裝、尚無可用伺服器，而訂閱又必須透過代理取得，就會形成啟動上的依賴：沒有設定就無法取得設定。此時應使用服務提供者允許且可連線的網址，或可信任的手動設定入口，而不是反覆嘗試同一條失效路徑。

已有可用伺服器時，可讓該伺服器維持作用中，分別測試直接更新與透過代理更新，每次只切換更新方式。若其中一種成功，問題較可能出在訂閱網址的連線路徑或解析環境。不要同時變更系統代理、DNS 與更新方式；多個變數一起改動，即使更新恢復，也無從判斷真正有效的是哪一步。

若網址回傳網頁、重新導向異常或安全連線錯誤，請檢查系統時間、網路登入狀態，以及連線是否經過需要驗證的上游網路。不要為了取得訂閱而長期降低安全連線檢查。若要求被重新導向至登入頁，應從正常的服務管理入口確認授權狀態，不要將登入頁內容存成設定檔後匯入用戶端。

處理格式不相容、重複記錄與覆寫風險

成功取得內容但解析失敗時，請確認提供的格式適用於目前用戶端。分享連結集合、編碼後的訂閱文字，以及某些專用設定檔，不能任意互換。不要只依副檔名判斷格式，也不要盲目新增或移除編碼層來嘗試修復。優先採用設定提供者明確標示的用戶端格式，並確認其中的協定功能與所選核心相容。

更新前先備份訂閱群組，以及少量曾手動修改的記錄。重新整理訂閱可能會重建群組內容，手動變更的別名、位址或傳輸欄位可能遭新訂閱值覆寫。需要長期保留的手動設定，應放在獨立群組並清楚命名。不要同時維護多個指向相同網址的群組，否則伺服器清單看似變多，實際上只是重複記錄，排查時也容易選錯。

更新後若記錄消失，先檢查群組篩選、名稱篩選及訂閱回傳內容，不要立刻再次清空整份清單。清單空白可能是篩選條件造成，也可能是網址回傳了空資料。保留舊備份後，使用獨立測試群組驗證，便能區分介面顯示問題與遠端內容問題。顯示更新成功只代表用戶端完成某項操作，不代表內容一定符合預期。

最後選取更新後的正確記錄，設為作用中的伺服器，再次測試連線。部分用戶端不會自動將原本作用中的記錄對應到新建立的項目，因此「訂閱更新成功但無法連線」仍可能是尚未重新選取伺服器。如需了解訂閱與伺服器選擇的基本關係，請參閱常見問題；若日誌已進入協定交握階段，請返回節點逾時章節繼續排查。

四、速度緩慢與間歇卡頓：以相同條件比較

先區分首次開啟慢、持續緩慢與單一網站慢

網頁第一次開啟很慢，但之後傳輸正常，常見原因是 DNS 解析、建立連線或安全交握；下載開始後仍持續低速，則較可能與鏈路吞吐量、封包遺失、伺服器負載或本機裝置有關。影片偶爾停頓也可能源於目標服務的快取與排程。先描述可重現的症狀，不要把所有延遲都歸咎於「節點速度差」，以免更換伺服器後反而掩蓋真正問題。

比對時請固定裝置、網路、作用中的伺服器、測試目標與大致時間，並暫停雲端同步、系統下載及其他大量傳輸工作。優先測試自己確實需要使用的服務，不要只看單一通用測速結果。不同目標的連線路徑與服務策略可能不同，某項測速成績良好，也不代表檔案下載、影片播放或即時通訊一定正常。

比較前也要確認測試要求走相同路由。相同網域可能因規則更新、解析結果或應用程式設定改變而使用不同出口。請開啟連線日誌，確認目標最後選用的出站；若一次直連、一次走代理，兩次結果就沒有可比性。少量重複測試即可，不必高頻率並行送出要求，以免額外流量反過來影響觀察。

從本機網路、遠端鏈路與裝置資源逐步定位

先觀察不經代理的正常網路服務是否也變慢。若同樣卡頓，請檢查 Wi-Fi 訊號、路由器負載與寬頻上傳頻寬是否已滿。上傳壅塞會拖慢確認封包與互動要求；即使下載頻寬看似仍有餘裕，網頁也可能遲遲沒有回應。情況允許時，可改用有線網路或移至路由器附近測試，但不要同時更換伺服器，否則無法分辨改善來自哪個環節。

若只有代理流量變慢，分別比較同一台伺服器連線至不同目標，以及不同伺服器連線至同一目標。前者用來觀察目標網站與出口排程，後者用來比較伺服器路徑差異。跨網路鏈路會隨時間變動，短時間測試只能反映當下狀況。晚間壅塞、伺服器限速或遠端資源不足，都需要多次在相同條件下記錄，不能只憑一次速度高峰下結論。

也請查看系統工作管理員或資源監視器。若用戶端或其他程序持續大量使用處理器，或記憶體不足而頻繁換頁，瓶頸可能出在本機。大量並行連線、過於詳細的日誌及頻繁測速也會增加負擔。先減少非必要工作，並保留一般日誌等級；不要只因看到一次處理器使用率飆高，就立刻關閉安全軟體或修改系統網路參數。

審慎調整傳輸、多工與流量接管設定

連線多工並非對所有協定與網路都有幫助。有些組合可能增加隊頭等待時間，部分功能也受核心或協定限制。只有在設定提供者確認支援，且能進行前後比對時，才調整相關選項。不要把網路上找到的一整組「加速參數」複製到所有伺服器；錯誤的多工、流量控制或傳輸設定不但無法提升速度，還可能讓原本正常的連線變得不穩定。

若簡單網頁能開啟，但大型頁面或長連線經常停住，可進一步檢查接管模式、路徑 MTU 或 UDP 相關行為。不過 MTU 應列為後續排查項目，而非第一步。先比對明確代理與目前的流量接管方式；只有問題會隨接管方式改變時，才檢查其網路介面與相關設定。修改前記下原值，逐步調整並確認能還原，避免隨意嘗試多個數值，造成新的未知狀態。

只有單一網站變慢時，請查看瀏覽器開發者工具或應用程式提示，區分主文件、圖片、指令碼與 API 要求。網頁可能依賴多個網域，其中某項遭錯誤分流或解析失敗，就會讓整個頁面看起來卡住。此時應修正規則涵蓋範圍，而不是長期強制所有流量都經過同一出口。若目標服務本身回傳流量限制或帳號限制，用戶端設定也無法取代服務端處理。

調整完成後，至少測試首次開啟、持續傳輸與閒置後重新連線三種情境，確認沒有只改善一項卻影響其他項目。記錄有效變更與還原方式，並清除暫時使用的測速工作。Android 端若主要問題是螢幕關閉後卡頓，請前往行動裝置章節；背景執行遭凍結與鏈路吞吐不足的症狀相似，但前者需要調整系統執行策略，而非盲目增加連線數。

五、DNS 異常：確認在哪個環節進行解析

區分系統、瀏覽器與核心解析

DNS 問題常見症狀包括網域無法開啟、偶爾成功、連線至錯誤位址，或第一次要求等待過久。同一台裝置可能同時使用系統解析器、瀏覽器安全 DNS、用戶端核心 DNS，以及應用程式內建解析。它們不一定使用相同伺服器，也不一定走相同路由。先確認目前由哪個元件負責解析，再修改對應設定；不要只更換系統 DNS，就認定所有應用程式都會跟著變更。

在 Windows 上可使用以下命令檢查系統解析結果。這反映的是系統解析路徑，不代表用戶端核心或瀏覽器最終使用的結果。記下回傳位址、錯誤類型與查詢時間，再與用戶端日誌比對。直接輸入 IP 開啟網站也不是通用的驗證方式，因為許多網站仰賴主機名稱、安全交握與虛擬主機；IP 無法連線本身不能證明網路中斷。

Resolve-DnsName example.com

若系統解析正常但瀏覽器仍無法連線，請檢查瀏覽器是否啟用獨立的安全 DNS，以及它是否能連線至所選解析服務。反之，瀏覽器正常而某個應用程式失敗，也可能是兩者使用不同解析路徑。測試時先暫時統一一項設定並記錄原值；不要同時更換瀏覽器、系統與核心的解析設定，否則無法判斷結果由何而來。

排除解析迴圈與引導依賴

遠端解析服務本身可能使用網域名稱，而該名稱也需要先解析。如果系統把所有查詢都交給這項服務，但連線至它又需要尚未建立的代理，就會形成引導依賴。類似地，若伺服器位址使用網域名稱，而解析伺服器的要求又被指定必須透過該伺服器出站，也可能形成迴圈。設定時應保留明確可達的引導路徑，避免每一步都依賴下一步已成功。

以下是核心設定中的 DNS 片段，用來說明解析位址與查詢策略的關係，不是完整的用戶端設定，也不應直接覆寫圖形用戶端自動產生的檔案。實際使用時，請透過用戶端支援的選項修改，並參照所選核心的文件確認欄位作用。此片段展示一般 DNS 查詢，是否適用於目前網路與隱私需求，仍需另行評估。

{
  "dns": {
    "servers": [
      "1.1.1.1"
    ],
    "queryStrategy": "UseIP"
  }
}

DNS 伺服器是否可連線、查詢流量如何路由，以及解析結果後續如何建立連線，是三個不同問題。某台伺服器能回應查詢，不代表回傳結果適合目前的出站方式。在需要區分直連與代理的環境中，應讓網域規則、解析策略與出站選擇保持一致。不要把「解析更快」直接等同於「目標連線更快」，地理位置導向的解析結果也可能影響後續路徑。

檢查 IPv6、快取與規則命中

在雙堆疊環境中，網域可能同時回傳 IPv4 與 IPv6 位址。若本機取得 IPv6 位址，但實際出口不完整，應用程式可能先嘗試無法連線的路徑，造成明顯延遲。先分別確認兩類位址是否可連線，再決定是否調整查詢或連線策略。不要只因看到 IPv6 結果就關閉整個系統的 IPv6；調整局部策略較容易還原，也能避免影響其他相依服務。

修改解析設定後，舊結果可能仍留在作業系統、瀏覽器與核心快取中。確有需要時，可在 Windows 執行 ipconfig /flushdns 清除系統快取，但這不會清除所有應用程式的快取。先停止測試要求，視需要重新啟動相關應用程式或核心，再查詢一次。反覆清除快取卻不檢查設定，只會讓現象不斷變化，無法排除錯誤來源。

若只有少數網域異常，請檢查 hosts、用戶端自訂網域對應、廣告過濾或安全軟體是否改變了解析結果。規則中的網域比對與 IP 比對可能在不同階段執行，解析後取得的位址也可能命中另一條規則。應依據連線日誌確認最終出站，不要只看規則清單順序來推測。若需要暫時新增規則，請限定測試網域並註明移除條件。

驗證結果至少應涵蓋系統查詢、實際應用程式連線與用戶端日誌三個部分。成功解析只是其中一步，還需確認安全交握與網頁要求都已完成。若調整後只有瀏覽器恢復正常，請繼續檢查其他應用程式是否使用獨立解析；若所有網域都能正常解析但連線仍逾時，則返回傳輸與交握章節。將這兩類問題分開，才能避免伺服器連接埠故障時仍反覆修改 DNS。

六、系統代理無效：確認應用程式是否接管

了解系統代理與全裝置流量的差異

系統代理是一組供應用程式讀取的網路設定，不代表作業系統會強制將所有流量送進用戶端。瀏覽器通常會遵循相關設定，但命令列工具、遊戲、背景服務或使用獨立網路元件的應用程式可能不會。因此，啟用系統代理後，某個程式仍直接連線，不一定代表 v2rayN 設定失敗。先確認該應用程式支援哪種代理方式，再選擇適合的連線方法。

先查看 v2rayN 目前的系統代理狀態，確認並非清除代理或維持原設定。接著開啟作業系統的網路代理頁面，核對位址、連接埠，以及是否設定自動設定指令碼。不同代理方式的優先順序由系統與應用程式決定；手動代理與自動指令碼同時存在時，容易誤判。排查期間請保留一種明確的代理方式，並記下原始值，避免影響工作網路需求。

本機應用程式通常透過回送位址連線至本機入口；填入 127.0.0.1 時，指的是裝置本身。若手機也將代理位址設為這個值，就不會連到電腦。若要在區域網路中共用代理，必須填入主機的區域網路位址與正確的入站連接埠，並設定允許存取的範圍。這與本機系統代理是兩條不同路徑，不要只為了修復本機瀏覽器問題，就直接開放區域網路監聽。

核對協定、連接埠與應用程式設定

明確代理測試成功，但應用程式仍無法使用時，先檢查應用程式內是否有「直接連線」、「使用系統設定」或獨立代理選項。有些工具會讀取環境變數，另一些則讀取系統設定；即使它們在同一個終端機視窗中執行，行為也不一定相同。變更代理後，還要關閉既有連線或重新啟動應用程式，因為已建立的長連線不一定會立即切換至新出口。

連接埠必須與入口協定相符。HTTP 代理位址不能隨意指向只接受 SOCKS 的連接埠；混合入口是否同時接受兩種要求，應以目前用戶端設定為準。若要透過 SOCKS 讓代理端解析目標網域，支援此語法的工具可使用 socks5h；這與先在本機解析的行為不同，測試時請留意差異。

curl --noproxy "" --proxy socks5h://127.0.0.1:10808 --connect-timeout 10 --max-time 20 -I https://example.com

上述連接埠仍是假設值，請先確認它確實接受 SOCKS 要求。若 HTTP 測試成功但 SOCKS 測試失敗，不應立刻認定伺服器有問題；兩項測試可能使用了不同的本機入口功能。也請查看應用程式的代理略過清單，例如排除本機位址、特定網域或網段的規則；明確排除的要求本來就不會進入代理。

排除多種工具衝突與殘留設定

多款網路工具同時執行時，可能會反覆改寫系統代理。常見情況包括剛設定完成又被改回，或用戶端關閉後其他應用程式全部無法上網。先停止其他具有代理管理功能的程式，再觀察系統設定是否穩定。瀏覽器擴充功能也可能覆蓋系統設定，因此必須分別檢查系統與瀏覽器層級；不要只憑系統匣選單中的選項判斷代理是否生效。

用戶端異常結束後，系統可能仍保留指向本機連接埠的代理設定，但該連接埠已沒有程序監聽。可重新啟動用戶端並正常清除系統代理，或前往系統網路頁面移除失效的手動設定。不要反覆重啟路由器；要求尚未離開本機就已經失敗。恢復直接連線後，再檢查用戶端為何異常結束，避免問題再次發生。

若要在區域網路中共用代理，僅允許必要的網路範圍存取，並在防火牆中限制相應連接埠與網路設定檔。不要為了方便關閉整個防火牆，也不要將本機代理入口直接暴露至公開網路。詳細共用設定步驟請參閱v2rayN 允許區域網路連線說明。主機切換網路後，區域網路位址可能改變，其他裝置也需要一併核對。

最後請依序驗證啟用代理、讓應用程式重新連線、關閉代理及退出用戶端四個步驟。啟用後查看日誌，確認要求進入正確的出站；關閉後確認直接連線恢復；退出後確認系統沒有留下失效入口。若只有不支援系統代理的應用程式仍未接管，請依應用程式支援情況選擇獨立代理或適用的接管方式，不要繼續重複寫入相同的系統代理位址。

七、用戶端崩潰與核心退出：保留最早的錯誤

區分圖形介面退出與核心啟動失敗

視窗消失、系統匣圖示仍在、伺服器無法連線與核心反覆重新啟動，是不同層級的問題。先確認究竟是圖形程式退出，還是核心子程序停止。若介面正常但日誌顯示設定錯誤，應檢查產生的設定與功能相容性；若整個程式無法開啟，則檢查安裝套件架構、系統支援條件、執行相依元件與檔案存取權限。不要一開始就刪除所有設定目錄。

記下觸發故障的操作，例如啟動時立即退出、更新訂閱後退出、切換核心後失敗，或開啟特定設定頁時崩潰。接著查看用戶端日誌與作業系統事件記錄中的對應時段。保留最早出現的異常及其前後內容；後續連線失敗往往只是程式已停止執行的結果。若日誌量很大，先複製一份，再清除日誌並重現一次，避免有用資訊被新內容覆蓋。

分享診斷資料前，請檢查其中是否包含路徑、使用者名稱、訂閱憑證與完整設定。不要將整個使用者目錄打包公開，也不要上傳包含伺服器驗證資料的崩潰附件。通常用戶端名稱、系統架構、觸發步驟與已遮蔽敏感資訊的錯誤，就足以開始排查；若需要更多資料，應明確說明收集範圍並透過可信任管道處理，不要直接貼出所有本機檔案。

檢查安裝環境、權限與連接埠占用

請前往用戶端下載頁，依作業系統與處理器架構選擇安裝套件。Windows 桌面版與傳統 WPF 版採用不同的介面技術，執行條件也不同；切換前請先備份設定，不要將不同版本的安裝內容混在一起覆蓋。兩者的選擇方式可參閱Avalonia 桌面版與 WPF 版比較。不要為了解決介面問題，就隨意複製來源不明的執行元件。

可攜式目錄應放在目前使用者有正常讀寫權限的位置，避免受限制的目錄、唯讀媒體或頻繁同步的資料夾。若日誌顯示權限遭拒，請檢查實際路徑與權限，不要長期以系統管理員身分執行來掩蓋問題。安全軟體攔截時，先查看攔截記錄與來源，再依系統機制處理；停用所有防護不應成為標準安裝步驟。

核心回報連接埠遭占用時，可能是另一個用戶端執行個體仍在運作，也可能是其他服務使用了相同連接埠。先查看系統匣與程序清單，關閉重複的執行個體，再確認監聽狀態已恢復。若必須更換連接埠，也要同步修改系統代理與應用程式的獨立代理位址。只修改用戶端其中一處，會把原本的連接埠衝突變成應用程式無法連上本機入口，表面上看起來仍像網路故障。

使用獨立設定隔離損毀與相容性問題

若啟動錯誤緊接在某次設定變更後出現，請優先還原該項設定。若無法進入介面，在確認設定位置並完成備份後，可使用獨立測試目錄或新的使用者設定進行驗證。不要直接刪除原目錄，其中可能包含訂閱群組、手動新增的伺服器與路由規則。測試環境只加入一份已知可用的設定，有助於區分程式環境與舊設定是否損毀。

新環境正常、舊環境失敗時，逐項移回伺服器、訂閱與路由設定，每移入一項就重新啟動測試。若匯入某組規則後開始失敗，請檢查規則檔案路徑、欄位格式與核心支援情況。圖形用戶端能儲存某項內容，不代表最終產生的核心設定一定有效；應以啟動日誌中的欄位錯誤及實際執行結果為準。

若同一份基本設定在乾淨環境中仍會讓程式退出，接著檢查系統資源、磁碟空間、執行相依元件與軟體衝突。更新或重新安裝時請保留原始備份，並避免在測試過程中一次還原所有舊設定。只有明確找出不相容功能時，才選擇替代方案；不能因為重新安裝後暫時恢復，就忽略先前的觸發條件。

修復後請完整退出並重新啟動一次，確認核心只啟動一個執行個體、本機入口正常，且退出時系統代理會還原。接著驗證訂閱更新與常用路由，確認問題沒有被暫時使用空白設定掩蓋。記下觸發步驟與解決方式，比只寫「重新安裝後好了」更有用；往後環境改變時，也能快速判斷是否為同一問題。

八、Android 斷線與耗電：檢查授權與背景執行策略

確認 VpnService 授權與是否只有一個服務執行

Android 端首先要區分服務尚未啟動、服務已啟動但沒有流量，以及螢幕關閉後服務停止。v2rayNG 與 v2flyNG 透過系統提供的 VpnService 接管相關流量，首次連線時需要確認系統授權。授權通過只代表服務可以建立本機虛擬網路介面，不代表伺服器交握已成功。若狀態顯示正在執行但仍無法連線，還是要搭配日誌檢查作用中的伺服器、DNS 與出站參數。

在同一個使用者環境中，系統通常只允許一個此類 VPN 服務處於作用中狀態。啟動另一個網路過濾、工作網路或代理應用程式時，可能會取代目前服務。先確認系統設定中實際執行的是哪個應用程式，再查看常駐通知是否存在。不要同時啟動 v2rayNG 和 v2flyNG 比較速度；應先完全停止前者，再測試後者，否則結果會混入服務接管狀態的變化。

更換用戶端不代表原有設定一定相容。v2rayNG 使用 Xray 核心，v2flyNG 則提供 V2Fly 核心選項，請依設定所需功能選擇。若設定依賴 REALITY 或特定流量控制，先確認核心是否支援，不要把交握失敗誤認為系統授權問題。首次授權、背景設定與個別應用程式代理之間的操作關係，請參閱v2rayNG Android 設定重點。

處理螢幕關閉後斷線與網路切換

前景使用正常，螢幕關閉一段時間後才斷線時，請優先檢查應用程式的電池使用策略、背景執行權限，以及廠商提供的自動啟動管理。不同系統的選單名稱各異，可從應用程式資訊頁面尋找電池相關設定。先允許必要的背景活動，再鎖定螢幕重新測試；不要直接放寬所有應用程式的限制。常駐通知用來顯示服務仍在執行，不建議只為隱藏通知而破壞服務所需的背景條件。

放寬背景限制會增加耗電，請依實際穩定性需求調整。固定時間間隔比對螢幕關閉前後的日誌與系統電池統計，確認是程序遭結束、網路被凍結，還是遠端連線自然失效。服務通知仍在但要求失敗時，可能只需要重新建立連線，不一定是應用程式被系統關閉。反覆強制停止或清理背景程序，反而會破壞原本想維持的執行狀態。

在 Wi-Fi 與行動網路間切換會改變位址、路由與可達性，既有連線可能因此中斷。先等用戶端完成重新連線，再送出新的要求；不要用切換前保留的頁面判斷目前狀態。若每次切換都失敗，請檢查系統是否限制背景行動數據、是否啟用數據節省模式，以及用戶端的重新連線行為。若兩種網路各自可用、只有切換後失敗，才應集中檢查網路切換過程。

排查個別應用程式代理與異常耗電

只有部分應用程式沒有走代理時，請確認個別應用程式模式是「僅代理所選應用程式」還是「略過所選應用程式」。兩種清單的含義相反；選取應用程式卻未達到預期，往往是模式理解錯誤。修改後停止並重新啟動服務，再關閉目標應用程式的既有連線進行測試。系統元件、工作設定檔中的應用程式，以及同名應用程式複本可能具有不同身分；不能只看桌面圖示名稱判斷是否選對。

耗電偏高時，先確認統計的時間範圍、總執行時間與前景／背景使用比例。VPN 服務可能會被系統歸類為轉送網路流量，因此電池頁面的耗電占比不代表所有耗電都是用戶端額外造成的。比較前後數據時，應維持相近的網路使用量；一組持續播放影片、一組處於待機，兩者沒有比較參考價值。也要排除訊號微弱、分享網路與其他應用程式頻繁連線的影響。

若閒置時日誌仍持續重新連線，請檢查伺服器可達性、解析失敗與網路不穩。頻繁交握、自動測試與過密的更新工作可能增加裝置喚醒次數，應減少非必要的輪詢，而不是隨意調高所有逾時值。反過來說，逾時值太短可能會把暫時壅塞誤判為斷線，進而觸發更多重試。保留預設值或有明確依據的策略，逐項比對，比套用一整組所謂的省電參數更可靠。

最後安排前景連線、螢幕關閉待機、網路切換與個別應用程式連線四組測試，記錄每組的服務狀態與錯誤時間。若主要問題是耗電，可接著閱讀v2rayNG 耗電與背景執行排查；若所有情境都在相同交握階段失敗，請返回節點逾時章節。系統背景策略、核心相容性與遠端連線是三條不同線索，分開處理才能得到可重現的修復結果。