v2rayN 故障排除指南

無法上網：先確認請求卡在哪個環節

「客戶端已執行」和「應用程式已透過代理連上網路」是兩回事。一次連線通常會經過應用程式、系統代理或虛擬網卡、本機入站、路由規則、遠端節點，最後才到達目標服務。任何一個環節未接通，都可能造成網頁無法開啟。排查時先記錄故障範圍：是所有應用程式都無法連線，還是只有某個瀏覽器？是所有網站都無法開啟，還是只有特定網域？關閉客戶端後，一般網路是否恢復？掌握這些範圍，比只看單一錯誤訊息更容易縮小問題。

比對一般網路與代理網路

先結束其他代理工具，關閉 v2rayN 的系統代理與 TUN，確認一般網路能否開啟平常可直接連線的頁面。如果此時也無法連線，請先檢查網路連線、閘道、Wi-Fi 登入頁面與系統 DNS，不要急著更換節點。公共 Wi-Fi 有時必須先完成登入；啟動代理後，登入頁面反而可能無法顯示。確認一般連線正常後，再啟動 v2rayN，選擇一個已設定的節點並開啟系統代理，使用同一個瀏覽器瀏覽同一個測試頁面。

接著開啟客戶端日誌，清除目前畫面或記下開始時間，再送出一次請求。如果沒有新增連線紀錄，優先檢查應用程式是否使用系統代理、本機連接埠是否正確，以及瀏覽器是否被擴充功能接管。如果日誌已記錄目標網域與出站，表示請求至少已進入核心；接著確認錯誤發生在解析、遠端撥號、交握或目標回應階段。日誌層級設為資訊通常就足夠，只有在定位特定問題時才暫時提高詳細程度。

略過系統代理，直接測試本機入站

以下以 SOCKS 入站進行比對，連接埠必須改成客戶端設定中實際顯示的值。範例中的 10808 並非所有安裝環境都使用的固定連接埠。Windows 可在終端機使用 curl.exe；macOS 與 Linux 通常使用 curl。測試網址僅用於確認連線是否完成，不代表所有服務都正常；收到某種 HTTP 狀態碼也不等於代理故障，仍須依連線是否建立來判斷。

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

第一個指令明確指定代理，第二個則略過代理，請分別記錄兩次結果。socks5h 會將目標網域交由代理端處理，避免本機解析影響這次測試。如果第一個指令顯示無法連線至本機連接埠，請先檢查核心是否已啟動並監聽；如果代理請求成功但瀏覽器失敗，問題較可能出在瀏覽器代理設定、擴充功能或快取。不要把 HTTP 入站連接埠當成 SOCKS 連接埠；混用兩種協定可能造成空白回應或協定錯誤。

區分路由錯誤與目標服務故障

請求進入核心後，查看實際選擇的是 direct、proxy 還是 block。特定網站若誤觸 block 規則，更換節點並無幫助；應找出命中的網域規則。誤走 direct 也可能造成連線逾時。可以暫時切換至簡化的代理路由，重新測試同一請求；若恢復正常，再逐條還原原有規則。這種比對僅用於定位，不建議長期將所有請求交給同一個出站，尤其應保留區域網路與節點伺服器位址所需的合理直連路徑。

如果多個常用服務都正常，只有一個目標無法使用，也要考慮目標網站維護、帳戶限制、服務端區域政策或瀏覽器工作階段異常。使用另一個瀏覽器工作階段，並以同一網路下的另一台裝置交叉比對，比反覆重裝客戶端更有效。最後應分別驗證一個代理目標、一個直連目標與一個區域網路目標，並確認日誌中的出站符合預期。連線雖恢復，但路由錯誤，仍不算完整修復。

節點逾時：分別檢查位址、連接埠與交握問題

節點測試逾時，不一定代表伺服器已停止運作。客戶端測試可能包含網域解析、建立傳輸連線、協定交握與存取測試網址；其中任何一步失敗，都可能顯示為逾時。先確認是所有節點同時失敗，還是只有單一設定失敗；是目前使用的網路有問題，還是換到另一個網路也一樣。所有節點同時異常時，應優先檢查本機網路、DNS、代理循環或測試網址；只有單一節點異常時，再逐項核對該節點參數。

核對連線目標，避免把參數填錯欄位

開啟節點編輯頁面，依服務提供者提供的設定檢查伺服器位址、連接埠、協定、傳輸方式與安全設定。伺服器位址通常是網域或 IP，不應包含網頁協定前綴或路徑。WebSocket 路徑、Host 與 TLS 的 SNI 是不同欄位，不能只因文字看起來相似就互相替代。連接埠必須是遠端服務的監聽連接埠；本機 SOCKS 連接埠僅供應用程式連至客戶端。若填入伺服器連接埠欄位，連線就會被送往錯誤的服務。

如果節點來自訂閱，請先更新訂閱再檢查，以免繼續使用已遷移的位址。但更新可能覆寫訂閱管理的節點，手動修改前應另存一份副本以供比對。比對時一次只修改一項，不要同時變更傳輸方式、連接埠與安全參數。密碼、使用者識別碼、公鑰等欄位即使格式正確，也可能與伺服器不符；這類錯誤無法靠延長逾時時間修復，必須重新匯入有效設定。

從錯誤類型判斷連線進行到哪一步

日誌出現 connection refused，通常表示連線嘗試收到拒絕回應，請檢查連接埠、服務狀態與中間設備政策；i/o timeout 或撥號逾時，只能表示未能在等待時間內完成預期操作。network is unreachable 則較可能與本機路由或位址族有關。不要把這些訊息都解讀成同一種原因，也不要只因伺服器沒有回應 ping 就認定代理無法使用；服務可以不允許這類探測，同時仍接受正常連線。

如果 TCP 連線已建立，接著出現 TLS 或驗證錯誤，應改查交握參數。先同步系統時間，再核對 SNI、憑證對應的網域，以及客戶端選用的傳輸方式是否與伺服器一致。REALITY 設定還須核對公鑰、短識別碼、伺服器名稱與指紋等欄位，並確認所選核心支援這組設定。為了減少變因，排查時應沿用服務提供者明確支援的設定，不要臨時拼入其他協定的參數。

排除網路路徑與代理循環

使用同一個節點，在另一個可信任的網路上測試。如果手機熱點可用，但目前的 Wi-Fi 失敗，請優先檢查目前網路的出口限制、位址族支援與防火牆；如果所有網路都失敗，則應回頭檢查設定與遠端服務。切換網路後請重新建立連線，不要沿用舊網路上的工作階段。節點網域若同時回傳不同位址族，其中一個位址雖可解析卻無法連線，也會拖慢連線；先確認實際撥號使用的位址，再決定是否調整位址選擇策略。

啟用 TUN 後才開始逾時，常見原因之一是連往節點伺服器的流量又被送入代理，形成遞迴路徑。請確認節點伺服器位址已正確排除，或客戶端已建立相應的直連路由。另一個原因是訂閱網址或節點網域的解析依賴尚未建立的代理出站，造成啟動依賴。先關閉 TUN，使用一般網路完成解析與訂閱更新，再逐項恢復設定，有助於區分這類問題與真正的遠端無法連線。

最後應分開驗證節點連線與服務存取。客戶端測試網址異常，可能造成多個正常節點都顯示失敗；如果實際網頁可以正常瀏覽，應檢查測試網址與測試方式，而非立即刪除所有節點。記下錯誤發生時間、使用的網路與錯誤類型，向服務提供者回報時請隱藏存取憑據。憑證相關問題可接著參閱TLS 交握與憑證錯誤排除，修復後再恢復原本的路由與執行模式。

訂閱失敗：區分下載、解析與節點更新

訂閱匯入分為三個環節：儲存網址、下載訂閱內容，以及將內容轉換為節點清單。介面能儲存連結，不代表下載成功；下載到文字內容，也不代表客戶端能解析成節點格式。先確認錯誤發生在哪個環節，以及更新後清單是否真的有變化。已有節點仍能連線，但訂閱更新失敗時，請保留可用設定，優先修復更新管道，避免刪除整組節點後失去排查所需的連線路徑。

先檢查網址與服務狀態

在訂閱群組設定中核對完整網址，特別留意複製時混入的換行、前後空格與全形標點。有些網址包含查詢參數或存取權杖，不能只保留問號前的路徑，也不要自行修改其中的字元。瀏覽器開啟的管理頁面不一定就是訂閱介面，請使用服務提供者明確標示的訂閱網址。連結過期、訂閱帳戶狀態變更或存取權杖重設，都可能使原網址回傳錯誤頁面。

觀察回應類型有助於定位問題。未授權或禁止存取，通常與憑據、帳戶權限或服務政策有關；找不到資源可能表示路徑已變更；受到流量限制時，應降低更新頻率，並在允許的時間再試。伺服器暫時錯誤不應靠修改節點密碼解決。即使回應狀態看似成功，也可能下載到登入頁面或提示文字；請查看客戶端的解析錯誤，確認收到的內容不是網頁。

解決「訂閱需要代理，但代理又依賴訂閱」的循環

有些訂閱網址在目前網路無法直接存取，必須透過可用的代理更新。此時請選擇客戶端提供的「透過代理更新」方式，並確認目前節點確實可連線。如果才剛安裝客戶端、清單仍是空的，透過代理更新會因缺少可用出站而失敗。可以先使用服務提供者提供的單一節點設定完成首次連線，再更新訂閱；如果沒有獨立可用的設定，請聯絡服務提供者確認可存取的訂閱入口，不要反覆切換無效節點。

反過來說，原本可直接連線的訂閱網址透過代理更新失敗，也可能是代理端的 DNS、憑證或出口存取限制所致。請對同一網址分別嘗試直接更新與透過代理更新，並記錄結果。若只有一種方式失敗，就能將問題縮小至下載路徑。如果瀏覽器可以開啟但客戶端不行，還要檢查瀏覽器是否使用不同代理、登入工作階段或自動重新導向；瀏覽器帶有的帳戶狀態不一定會傳給客戶端的訂閱請求。

檢查格式，不要把解析失敗誤認為網路逾時

v2rayN、v2rayNG 與 v2flyNG 支援哪些協定和設定格式，取決於各自的實作與使用的核心。服務提供者可能為不同客戶端準備不同入口；下載到另一種格式的設定檔時，即使內容完整也可能無法匯入。先確認訂閱入口適用於目前的客戶端，再查看錯誤是無法識別格式、部分節點不支援，還是整份內容為空。遇到不支援的欄位時，不要任意刪除安全參數來換取匯入成功，這可能會改變原連線的設定意義。

更新成功卻「沒有新節點」時，請檢查目前選取的訂閱群組、搜尋篩選條件與排序方式。有些更新會替換節點識別資訊，原本選取的節點可能已不存在，需重新選取並套用。節點名稱沒有變，不代表伺服器位址與參數未更新；可以比對設定詳細資料。如果只剩部分節點，先檢查是否為協定支援差異，或訂閱服務回傳了不同內容，再判斷客戶端是否遺失資料。

控制更新頻率並確認實際結果

不要把連續點擊更新當成重試方法。頻繁請求可能觸發服務的流量限制，也會讓日誌難以對應單次操作。先暫停自動更新，手動送出一次請求，記下時間、下載路徑與錯誤訊息，再處理明確原因。恢復自動更新時，請設定合理的間隔，避免多台裝置在短時間內反覆請求同一網址。網路剛恢復時，可以先測試節點連線再更新訂閱，減少失敗請求彼此疊加。

修復後請確認訂閱群組更新成功、節點可供選取、核心已載入新設定，再進行一次實際連線測試。訂閱通常只負責同步節點，不保證桌面與 Android 裝置的路由、DNS、應用程式分流和 TUN 設定完全一致。電腦更新成功不能取代手機端驗證；跨裝置同步的界線可參閱v2rayN 與 v2rayNG 多裝置設定同步。請妥善備份可用設定，但不要將含有憑據的匯出檔放在公開目錄。

速度緩慢：分辨連線建立慢與持續傳輸慢

速度問題至少有三種表現：首次開啟頁面要等很久、開始傳輸後一直很慢，以及連線偶爾中斷後又恢復。這些情況可能分別與 DNS 和交握、持續頻寬和壅塞、網路切換或封包遺失有關。先描述實際症狀，不要只記錄一個測速結果。小檔案傳輸很快、大檔案卻很慢，與每個網站首次開啟都很慢，是兩種不同的排查方向。測試時應使用相同節點、目標與裝置，避免將目標伺服器差異誤判為節點效能差異。

固定條件，建立可重現的比較

先關閉正在使用網路的同步、下載與系統更新，再重做一次原本的操作。如果使用 Wi-Fi，可先靠近無線基地台進行比對；有條件時，也可比較有線與無線連線。如果一般直連服務也很慢，應先處理本機網路；若只有代理服務緩慢，再比較同一網路下的兩個可用節點。不要一邊切換節點，一邊更改 DNS 和路由，否則即使恢復正常，也難以判斷是哪項變更生效。

測試目標也應固定。不同下載網站可能限制單一連線的速度，網頁載入的第三方資源也可能位於不同網路。一項測速結果不能代表影片、會議與檔案下載的所有使用情況。記錄首次回應的等待時間、開始傳輸後是否穩定，以及是否反覆重新連線，通常比追求某個瞬間峰值更實用。同一節點在不同時段表現不同，可能是網路壅塞所致；應在相近條件下重複觀察，而非立即重裝客戶端。

首次開啟很慢：先檢查 DNS、交握與錯誤重試

頁面第一次開啟很慢、再次瀏覽卻明顯改善時，應優先觀察解析時間、位址選擇與連線重用。節點網域或目標網域有多個位址時，客戶端可能先嘗試無法連線的位址，等到失敗後才改用另一個。日誌中的重複撥號、交握失敗或解析逾時，比「測速偏低」更能指出問題原因。請檢查系統時間、傳輸參數與 DNS 路徑，確認連線不是靠不斷重試才偶然成功。

如果多數頁面的主要內容載入很快，但圖片、字型或指令碼一直等待，可能是資源網域被路由到不同出站，或某條封鎖規則影響頁面載入。可以在瀏覽器的網路面板查看失敗資源的網域，再對照客戶端日誌，不要直接認定整個網站都是節點太慢。暫時切換至簡化路由後若恢復正常，請逐條檢查規則順序與規則集內容。特定網域規則應放在較廣泛的規則之前，避免先被前面的條件比對到。

持續傳輸緩慢：檢查壅塞、裝置資源與傳輸條件

開始傳輸後速度穩定但偏慢，先查看本機處理器、記憶體與磁碟使用率是否接近負荷上限。大量背景連線、過於詳細的日誌、即時掃描或裝置省電模式，都可能增加負擔。行動裝置過熱後也可能降低處理器頻率，導致同一連線愈來愈慢。桌面端應在一般電源模式下重新測試；Android 端則要留意裝置溫度與背景工作。減少不必要的並行工作，比盲目疊加多個最佳化選項更容易得到可判斷的結果。

如果只有 TUN 模式下傳輸大型檔案會停頓，而系統代理模式正常，應考慮虛擬網卡路徑、MTU 與額外封裝。路徑可能能傳送小型封包，卻無法正常處理較大的封包，造成連線成功但傳輸卡住。不要直接照抄網路上的固定 MTU 數值；先比較兩種模式，確認問題確實隨虛擬網卡路徑出現，再依客戶端提供的設定小幅調整，並保留還原方式，最後以原本的服務重新測試。

協定名稱本身無法直接決定速度。VMess、VLESS、Trojan 與 Shadowsocks 的表現，也取決於傳輸組合、伺服器負載與網路路徑。若沒有相符的伺服器設定，只更換協定並不會帶來有效的最佳化。可以先閱讀代理協定差異與適用情境，了解參數限制，再依服務提供者支援的組合進行選擇。修復後不僅要驗證常用服務，也要確認直連服務沒有因路由調整而變慢。

DNS 問題：分辨系統解析、核心解析與代理端解析

DNS 負責將網域名稱對應至位址，但在代理環境中，解析不一定都由同一處完成。應用程式可以先在本機解析，再將 IP 交給代理；也可以把網域交給 SOCKS 或 HTTP 代理，由核心或遠端處理。TUN 也可能接管系統的 DNS 請求。因此，系統指令查得到位址，只能證明該解析路徑可用，不能證明瀏覽器、核心和遠端的解析路徑都正常。排查前請先確認是哪個網域無法連線，以及請求由哪個環節解析。

分別檢查節點網域與目標網域

如果節點伺服器使用網域名稱，客戶端首先必須解析節點位址；代理連線建立後，才可能存取目標網站。這是兩次不同的解析。若日誌顯示節點網域無法解析，應先檢查啟動階段使用的 DNS，而非修改目標網站的路由。如果目標網域無法解析，則要檢查應用程式是否提交網域名稱、核心是否啟用相應 DNS 設定，以及所選解析伺服器能否透過預期的出站連線。

Windows、macOS 與 Linux 都可以在具備相關工具的終端機中使用以下查詢指令進行基本比對。請查看回傳位址、使用的解析伺服器與錯誤類型，不要只看有沒有輸出。如果系統查詢成功但代理存取失敗，請搭配核心日誌繼續定位。查詢結果可能來自快取；變更設定後，應確認新請求確實使用新的解析路徑。只是不斷重新整理網頁，可能仍會使用瀏覽器儲存的舊結果。

nslookup example.com

透過代理測試，區分本機解析與代理端解析

在 SOCKS 測試中，socks5 通常會讓 curl 在本機解析目標網域；socks5h 則會將網域交由代理端處理。分別測試同一個目標，有助於判斷故障是否受到本機解析影響。請記得替換為實際的 SOCKS 連接埠。某一種方式成功，不代表另一種方式必須永久停用，而是表示兩條路徑有差異；最後應依路由需求與應用程式行為決定採用哪種方式。

curl --proxy socks5://127.0.0.1:10808 --connect-timeout 10 -I https://example.com
curl --proxy socks5h://127.0.0.1:10808 --connect-timeout 10 -I https://example.com

如果代理端解析正常、本機解析失敗，請檢查系統 DNS、瀏覽器安全 DNS 與網路提供的解析服務。如果兩者都失敗，但日誌顯示不同錯誤，應分別處理，不要一次修改多個設定。瀏覽器使用自訂加密 DNS 時，修改系統 DNS 可能不會影響它；反過來，瀏覽器查詢正常也不代表其他應用程式正常。可以暫時讓瀏覽器沿用系統設定進行比對，定位後再恢復符合需求的設定。

了解路由中的網域策略

domainStrategy 會影響路由比對時是否需要將網域解析成 IP。在 V2Ray 家族核心中，AsIs、IPIfNonMatch 與 IPOnDemand 的用途各不相同，不能簡單視為三種效能設定。以下是路由片段，並非可直接啟動的完整設定；它假設已存在名為 direct、proxy、block 的出站，而且具備相應的規則資料。圖形介面客戶端應優先透過路由設定輸入，避免直接覆寫整份自動產生的設定。

{
  "routing": {
    "domainStrategy": "IPIfNonMatch",
    "rules": [
      {
        "type": "field",
        "domain": ["geosite:category-ads-all"],
        "outboundTag": "block"
      },
      {
        "type": "field",
        "ip": ["geoip:private"],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "domain": ["geosite:cn"],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "network": "tcp,udp",
        "outboundTag": "proxy"
      }
    ]
  }
}

即使有明確的末尾比對規則，後續解析行為仍會受到規則順序與核心實作影響；不要認為選定某個策略後，所有請求都一定會進行 IP 比對。修改後請查看實際日誌，不要只看設定名稱。廣告網域規則、區域網路 IP 規則與地區網域規則各自依賴不同資訊；規則集遺失或類別名稱無法使用，也可能造成設定載入失敗。更完整的順序說明請參閱geosite 與 geoip 分流設定實作。

避免解析依賴循環，謹慎使用虛擬位址

加密 DNS 伺服器也需要網路連線；如果它必須透過代理才能連線，而節點位址又必須靠它解析，就可能形成循環。請為啟動所需的解析保留可用路徑，並確認 DNS 請求使用的出站符合預期。使用虛擬位址映射時，系統回傳的位址不一定是真實伺服器位址，這是機制本身的設計；但客戶端退出後殘留的路由、舊快取或誤用映射的區域網路網域，都可能導致應用程式無法連線。

修復時先恢復最簡單的解析設定，停用互相衝突的 DNS 接管功能，再逐項新增設定。區域網路主機名稱、印表機與內部服務通常需要本機解析，不宜一律交由遠端處理。每次調整後，請測試節點網域、代理目標、直連目標與區域網路名稱，確認四種需求都正常。關於 fake DNS、網域策略與規則集的含義，可參閱概念速查，避免為了開啟單一網站而破壞整套解析設定。

系統代理未生效：確認應用程式入口與 TUN 接管範圍

系統代理是作業系統提供給應用程式的代理設定，並不會強制接管所有連線。遵循系統設定的瀏覽器通常會使用它，但命令列工具、部分遊戲和使用自有網路堆疊的軟體可能會忽略設定。TUN 透過虛擬網卡與路由接管流量，涵蓋範圍不同，也會增加權限、路由與 DNS 等條件。因此，應用程式不走系統代理時，請先確認其網路機制，不要把「系統代理已啟用」當成所有流量必定進入核心的證據。

檢查系統實際儲存的設定值

在 v2rayN 中啟用系統代理後，開啟作業系統的網路設定，確認代理位址與連接埠是否已變成目前客戶端的本機 HTTP 或混合入站。位址通常是迴送位址，但連接埠必須使用實際設定值。如果核心監聽連接埠已變更，而系統代理仍指向舊連接埠，所有遵循系統設定的應用程式都會無法連線。如果系統顯示的是自動設定指令碼，而非手動代理，也要確認目前使用哪一種方式，避免兩種設定互相覆蓋。

關閉其他可能寫入代理設定的軟體，包括瀏覽器代理擴充功能、其他代理工具或裝置管理政策。公司或受管理裝置的代理設定可能由政策固定；即使客戶端修改了設定，也可能立刻被還原。遇到這種情況應遵守裝置管理規範，不要持續覆寫系統設定。一般個人裝置則可比對啟用前後的設定值是否改變，確認 v2rayN 修改的是目前使用的網路環境，而非已中斷的連線設定。

透過應用程式日誌確認是否真的走代理

送出一個新請求，查看客戶端連線紀錄。如果沒有紀錄，請檢查應用程式自己的代理設定；如果有紀錄但出站是 direct，代表系統代理可能已生效，只是路由選擇了直連。使用出口查詢頁面觀察位址變化也有侷限：如果該頁面符合直連規則，結果沒有變化並不能證明代理失效。應同時查看請求是否進入核心，以及選擇了哪個出站，再判斷問題出在入口還是規則。

終端機程式常受 HTTP_PROXY、HTTPS_PROXY、ALL_PROXY 與 NO_PROXY 影響。有些應用程式只識別小寫形式，有些則只支援部分設定。排查時先明確指定代理執行命令，確認本機入站正常，再檢查環境變數。若 NO_PROXY 包含目標網域或網段，該請求就會略過代理。修改變數後通常需要重新啟動應用程式或終端機；已執行的程序不一定會讀取新值。

分開處理 TUN 啟動失敗與啟動後異常

TUN 無法啟動時，先查看日誌中的權限、建立虛擬網卡與寫入路由錯誤。桌面系統可能需要提高權限或允許相關網路元件，但不應永久關閉系統防護。請只依據具體日誌處理遭拒絕的操作。如果核心已啟動，但建立虛擬網卡失敗，介面顯示執行中也不代表 TUN 已成功接管；請確認客戶端模式、網卡狀態，以及日誌中是否有相應的啟動紀錄。

TUN 成功啟動卻無法上網時，先關閉 TUN，使用系統代理測試同一節點。如果系統代理正常，問題較可能出在路由、DNS 接管或其他虛擬網卡衝突。同時執行多個 VPN 或虛擬網路工具，可能導致預設路由不斷變動。節點伺服器流量必須有正確的外部路徑，區域網路也需要相應的排除規則。不要清除所有排除項目，否則節點連線與本機服務可能一起被接管。

退出後恢復網路，保留可還原的設定

客戶端異常結束後，系統代理可能仍指向已關閉的本機連接埠。此時瀏覽器無法連線，但明確指定直連的測試正常，是很有價值的線索。請開啟系統代理設定，清除殘留項目，再檢查 TUN 是否留下虛擬網卡或路由。一般情況下，先正常結束客戶端、重新啟動，再執行關閉操作，比直接刪除網卡更穩妥；手動修改網路設定前，請記下原本的值，尤其是受管理網路的設定。

最後請分別測試瀏覽器、終端機，以及一個不遵循系統代理的應用程式，不能只測一種程式就判定修復完成。也要確認區域網路裝置與直連目標可正常連線，並確認結束客戶端後一般網路會恢復。應用程式代理與 TUN 各有適用情境，優先選擇能滿足需求且變因較少的方式。基本操作可回到快速入門教學確認；排查期間不要同時套用新的路由範本與接管模式。

客戶端閃退：分辨介面退出、核心退出與設定錯誤

客戶端視窗突然關閉、視窗仍在但無法上網，以及按下啟動後立刻停止，分別代表不同故障。v2rayN 圖形介面與代理核心屬於不同環節；介面正常不代表核心正在執行，核心退出也不一定會關閉視窗。先記下觸發條件：剛啟動就失敗、匯入某個節點後失敗、啟用 TUN 後失敗，還是執行一段時間後才失敗。能穩定重現的單一操作，是定位問題最好的起點。

先保留設定與日誌，再修復安裝

如果介面仍可開啟，先使用客戶端提供的功能匯出必要設定，並記下目前的訂閱群組、路由模式與 DNS 設定。備份可能包含存取憑據，應存放在受控位置。若無法進入介面，不要立即清除使用者資料目錄；請先保留該目錄的副本，再查看啟動日誌或系統的應用程式錯誤紀錄。複製日誌尋求協助前，請移除伺服器憑據、訂閱網址、使用者路徑等不必要的敏感資訊。

重新安裝前，請前往下載頁核對作業系統與處理器架構。Windows 的 v2rayN 桌面版與經典 WPF 版是不同的介面版本，不應混用兩者的程式檔案。macOS 請依晶片選擇對應安裝檔；Linux 則要同時核對處理器架構與發行版套件格式。如果系統提示缺少相依元件，請依照明確錯誤安裝官方執行環境，不要從不明的彈出視窗下載所謂的修復元件。

介面閃退：檢查啟動與資源錯誤

啟動後立刻退出時，請檢查系統是否阻止應用程式執行、安裝流程是否完成，以及使用者資料目錄是否可寫入。macOS 應先將應用程式放入適當的應用程式目錄，再處理系統安全提示；Linux 可從圖形終端機啟動已安裝的程式，查看標準錯誤輸出，並核對桌面工作階段所需元件。路徑權限或相依元件異常應有具體線索，不要長期使用管理員權限來掩蓋所有錯誤。

執行一段時間後才當機時，請觀察是否與大量連線、日誌累積、休眠後恢復或顯示環境變化有關。檢查磁碟空間與記憶體負載，減少不必要的詳細日誌，再以相同操作重新測試。裝置從休眠恢復後，網路介面可能已變更；先重新建立連線，不要立即重裝應用程式。如果問題只在某個介面操作時出現，可暫時避開該操作以維持連線，同時記錄操作步驟，避免將偶發的系統問題誤判為所有節點設定都已損毀。

核心立即退出：先查看第一個設定錯誤

設定載入失敗通常會指出欄位、出站標籤、規則資料或監聽連接埠問題。請優先處理日誌中最早出現的有效錯誤，後續大量錯誤可能只是連鎖反應。連接埠被占用時，先查明是哪個程式占用，結束重複執行的客戶端或修改本機入站連接埠，再同步調整系統代理。不要為了讓核心啟動而刪除所有路由規則；規則資料缺失與出站名稱錯誤應分別修正。

如果只有特定節點會讓核心退出，請核對協定與核心是否相容。v2rayNG 主要使用 Xray 核心，v2flyNG 使用 V2Fly 核心，兩者支援的功能並不完全相同；v2rayN 切換核心也無法讓原本不支援的組合自動相容。請確保節點、傳輸方式與核心相符，必要時從有效訂閱重新匯入。尤其不要為了略過載入錯誤而刪除 REALITY 等連線必要欄位；能啟動不代表就能正常連線。

以最小設定確認故障範圍

保留備份後，建立一個僅包含單一已知可用節點、基本路由與預設 DNS 的比對環境，暫時不要啟用 TUN、複雜規則或自訂設定。如果最小環境正常，再依序恢復訂閱群組、路由、DNS 與流量接管功能，每恢復一項就重新測試一次。這樣可以將問題縮小到特定設定層。測試環境不要和原環境同時監聽同一個連接埠，也不要讓兩個執行個體同時修改系統代理。

修復後，請正常結束並重新啟動一次，再確認訂閱、節點、系統代理與 TUN 的實際狀態。如果只能透過重新安裝恢復，但匯入舊設定後問題再次出現，原因較可能在設定而非安裝程式。關於核心與客戶端之間的關係，可參閱本站介紹與 Project V 生態系說明。回報故障時提供作業系統、架構、客戶端名稱、觸發步驟與已移除敏感資訊的錯誤文字，比上傳整份設定更安全，也更容易重現問題。

Android 連線異常：檢查 VPN 授權、應用程式分流與背景限制

Android 端的 v2rayNG 與 v2flyNG 透過系統 VPN 介面接管流量，排查方式與桌面端的系統代理不同。狀態列出現 VPN 圖示，只能證明系統介面已建立，不能代表遠端節點連線成功。先選擇一個有效節點，確認已完成啟動授權，再使用瀏覽器送出請求並查看客戶端日誌。如果啟動後立刻停止，應先檢查授權、設定載入與其他 VPN 衝突；如果持續執行但無法上網，再依序檢查節點、DNS 與路由。

確認系統授權與 VPN 使用狀態

首次連線通常需要核准系統的 VPN 請求。取消授權視窗、視窗被其他應用程式遮住，或裝置政策限制 VPN 功能，都可能導致客戶端無法建立介面。請開啟系統 VPN 設定，確認目前作用中的連線，並停止其他正在接管流量的 VPN 類應用程式。部分本機過濾工具也會使用相同介面，表面上與代理無關，實際上仍可能發生衝突。先只保留一個流量接管應用程式進行比對，再決定日常使用時如何安排它們的啟動順序。

檢查系統是否啟用了永遠開啟的 VPN，或封鎖未經 VPN 的連線。如果指定的是另一款已停用的應用程式，一般網路也可能無法使用；如果目前客戶端異常退出，而禁止直連的政策仍然生效，也會造成整台裝置斷網。調整這些設定前，請先了解其作用；測試結束後依使用需求恢復，不要永久關閉所有限制。受管理裝置應遵守管理者政策，反覆重裝無法解決授權限制。

部分應用程式正常、其他應用程式失敗時，檢查分流清單

應用程式分流可以設定為「僅代理選取的應用程式」，或「略過選取的應用程式」兩種相反模式。清單內容相同，模式不同，結果就會完全不同。先確認目前使用的模式，再核對故障應用程式是否列在清單中。系統元件、工作設定檔中的應用程式，以及一般個人應用程式，接管範圍也可能不同。瀏覽器正常但其他應用程式失敗時，不要立刻更換節點；先確認該應用程式的請求是否出現在客戶端日誌中。

應用程式流量進入 VPN 後，仍會經過網域與 IP 路由。清單決定是否接管流量，路由則決定接管後使用哪個出站，兩者不能互相取代。有些應用程式會使用自己的 DNS、固定 IP 或長連線，行為與瀏覽器不同；修改路由後，請完全結束並重新開啟該應用程式，避免舊連線繼續沿用原本的路徑。若存取區域網路裝置時出現問題，請檢查區域網路直連規則與應用程式接管設定，不要強制代理所有目標。

螢幕關閉後斷線：先檢查電池與背景執行限制

前景使用正常、螢幕關閉後失敗，是背景執行受限的重要線索。請查看系統電池管理是否允許客戶端在背景執行，並檢查省電模式、背景資料限制與裝置製造商的工作清理設定。不同裝置的選項名稱不盡相同，請依功能尋找。調整後讓裝置進入相同的螢幕關閉狀態，再觀察連線是否維持；只在螢幕亮起時測試，無法證明背景問題已修復。

同時分辨程序遭停止與網路暫時中斷。如果客戶端已退出，應優先檢查背景管理；如果仍在執行，但日誌顯示連線中斷，則可能是 Wi-Fi 與行動網路切換、網路休眠或遠端工作階段結束所致。允許背景執行不代表工作階段永遠不會中斷；網路變更後，客戶端仍須重新連線。切換網路後請等候新連線建立，再送出新請求，不要用舊工作階段的錯誤來判斷目前網路仍然無法使用。

分別驗證行動網路與 Wi-Fi

同一節點在 Wi-Fi 下正常、行動網路下失敗時，應檢查兩種網路的位址族與 DNS 差異，以及是否受到系統數據節省限制。可以暫時關閉額外設定的私人 DNS 進行比對，但這只是定位步驟，不代表必須長期停用。如果只有 UDP 相關服務異常，請確認節點、傳輸方式與伺服器端支援相應的轉發能力；不能因為網頁能開啟，就認定所有協定都正常。一般 HTTP 請求主要驗證的是另一種連線路徑。

Wi-Fi 切換後第一次連線變慢，也可能與舊解析快取和位址變更有關。先停止再重新啟動連線，確認日誌中的伺服器位址來自目前的解析結果，再考慮調整 DNS。公共網路需要登入認證時，請先完成認證再啟動 VPN。如果關閉客戶端後仍無法上網，應回頭檢查系統網路與 VPN 政策，不要繼續修改節點。系統時間不同步也會影響 TLS；Android 裝置同樣需要確認自動設定時間與時區已啟用。

選擇合適的客戶端並完成完整驗證

Android 優先推薦 v2rayNG；v2flyNG 使用 V2Fly 核心，是另一種選擇，但更換客戶端並不能解決所有問題。使用特定核心功能的節點，應先確認相容性再匯入。請依裝置架構選擇安裝檔；如果不確定，可前往Android 下載說明查看對應入口，不要因為安裝失敗就任意更改節點協定。在兩個客戶端之間共用訂閱時，仍須分別檢查應用程式清單、DNS 與路由設定。

最後應驗證前景瀏覽、螢幕關閉後的新請求、Wi-Fi 與行動網路切換、區域網路存取，以及停止 VPN 後一般網路是否恢復。每個情境都應使用相同服務進行比對，並確認變更沒有影響其他使用情況。初次設定流程請參閱訂閱匯入與連線教學；不熟悉術語時，請先查閱概念速查。保留可用設定與已移除敏感資訊的排查紀錄，下次遇到相同症狀時，就能從已確認的環節繼續檢查。