V2Ray 故障排查：依症狀定位連線問題

先區分「本地斷網」與「代理路徑中斷」

用戶端系統匣圖示顯示執行中，只能代表圖形介面與核心程序已啟動，不能證明流量已抵達遠端。排查時先暫時關閉系統代理或 Android 的 VPN 連線，然後造訪本地網路中原本可正常開啟的網站。如果關閉用戶端後仍無法存取，問題就在目前的 Wi-Fi、網路線、行動網路、閘道或系統網路堆疊，不應繼續修改節點參數。重新連線、關閉再開啟網卡，或改用另一條網路測試，通常比反覆匯入訂閱更快。

若直接連線正常、啟用代理後所有網站都失敗，下一步查看用戶端日誌。v2rayN 可從日誌區域觀察 Xray 啟動與連線紀錄；v2rayNG、v2flyNG 可開啟日誌頁後重新造訪一次目標網址。重點不是日誌行數，而是第一次出現的錯誤。包含 connection refused 通常表示目標連接埠明確拒絕連線；timeout 表示交握未在限定時間內完成；no such host 指向網域名稱解析；certificate 或 handshake 則應檢查系統時間、SNI 與傳輸安全參數。

用最小設定排除路由規則干擾

複雜路由可能把瀏覽器流量分配到不可用的出站，也可能把原本應由代理處理的網域錯誤送入直連。先保留一個確認可用的節點，將路由模式暫時切換為全域代理，關閉額外的自訂規則、鏈式代理、Mux 與實驗性 DNS 功能，再測試一般 HTTPS 頁面。如果全域模式可用而規則模式不可用，故障就在路由比對，不在節點本身。恢復規則時應一次只啟用一組，且每次變更後建立新連線，避免瀏覽器繼續重用舊的 TCP 或 HTTP/3 工作階段。

圖形介面的路由規則最後會轉換為 Xray 設定。規則會依用戶端產生的順序參與比對，網域、IP、連接埠與網路類型可能同時決定出站。下面的最小結構只保留代理與直連兩個出站，用於理解問題邊界；實際用戶端會補充入站監聽與節點憑證。

{
  "outbounds": [
    {
      "tag": "proxy",
      "protocol": "vless",
      "settings": {}
    },
    {
      "tag": "direct",
      "protocol": "freedom"
    }
  ],
  "routing": {
    "domainStrategy": "AsIs",
    "rules": [
      {
        "type": "field",
        "ip": ["geoip:private"],
        "outboundTag": "direct"
      }
    ]
  }
}

檢查連接埠佔用、時間與殘留程序

桌面用戶端會在本機監聽 SOCKS、HTTP 或混合代理連接埠。若同一連接埠已被另一個代理程式、舊核心程序或除錯工具佔用，新核心可能啟動失敗，但介面仍保留上次的狀態。Windows 可在終端機執行 netstat -ano 查看監聽連接埠與程序編號；macOS 與 Linux 可使用 lsof -iTCP -sTCP:LISTEN。發現衝突後，應先結束相關程式，再從用戶端完整重新啟動核心，不要只切換節點。

netstat -ano | findstr LISTENING
lsof -iTCP -sTCP:LISTEN
date

系統時間也必須準確。TLS、REALITY 及訂閱伺服器的 HTTPS 連線都會依賴時間判斷。時間偏差較大時，常見情況是所有節點同時失敗、訂閱也無法更新，或日誌持續出現憑證尚未生效、憑證已過期等提示。啟用系統自動校時後，徹底結束用戶端並重新啟動，讓新建立的連線使用校正後的時間。若上述檢查均正常，再從下載頁確認使用的是對應平台用戶端，並重新完成一次最小設定，而不是直接覆蓋大量舊設定。

延遲測試結果不等於實際網頁速度

v2rayN 的延遲測試可能採用 TCP 建立連線、實際延遲或其他可用性檢測方式，不同方式回答的問題不同。TCP 建立連線成功只代表遠端位址與連接埠可以完成基本交握，不能證明協定驗證、TLS、REALITY 或目標網站存取一定成功；實際延遲測試會經過更多處理，但仍可能受測試位址、DNS 與目前路由影響。因此，不應只憑一個逾時標籤刪除節點。正確做法是先查看測試類型，再實際造訪網頁，並結合日誌確認逾時發生在解析、連線遠端、TLS 交握還是出站存取階段。

單一節點逾時而同一訂閱中的其他節點正常，通常是該節點位址、連接埠、傳輸參數或服務狀態的問題。所有節點同時逾時，則更像是本地網路、系統時間、DNS、核心啟動或網路環境變化。若只有某一網路下全部失敗，切換到另一網路後恢復，應優先檢查目前的路由器、防火牆、企業網路政策或 UDP 可用性，不要同時修改每個節點。

逐項核對位址、連接埠與傳輸參數

手動設定節點時，伺服器位址不能帶有協定前綴、路徑或多餘空格；連接埠必須是整數；UUID、使用者識別碼、密碼等驗證欄位要完整複製。VLESS 與 VMess 不是可互換的協定，傳輸層的 TCP、WebSocket、gRPC 也不能只憑連接埠猜測。使用 TLS 時要核對伺服器名稱與主機欄位；使用 REALITY 時還需要符合公開金鑰、短識別碼、指紋與伺服器名稱。任何一項不一致，都可能表現為交握逾時或建立連線後立即關閉。

WebSocket 節點還要核對路徑與 Host，路徑通常以斜線開頭，大小寫和附加查詢部分都可能影響伺服器端比對。gRPC 要檢查服務名稱，不能把它填入 WebSocket 路徑。若節點來自訂閱，優先重新更新訂閱而不是手動「修正」欄位，因為訂閱提供者可能已調整參數。重新匯入前可先複製目前訂閱群組作為紀錄，但不要讓兩個同名節點同時參與自動選擇，以免混淆測試對象。

不要用延長逾時時間取代問題定位

將連線逾時從幾秒提高到很長時間，只會讓不可用節點更晚回報失敗，通常不會修復協定或連接埠錯誤。合理的重新測試方式是選擇一個節點、關閉自動切換、建立全新連線，然後觀察從按下連線到第一筆錯誤日誌之間發生了什麼。若 TCP 可以連線但 TLS 交握失敗，重點檢查 SNI 與時間；若 TLS 完成後驗證失敗，重點檢查使用者識別碼與協定；若代理已建立但存取特定網站逾時，則轉向路由、DNS、MTU 或目標端連線問題。

UDP 情境還需要單獨判斷。某些網路的 UDP 不穩定，瀏覽器可能優先使用 HTTP/3，DNS 也可能透過 UDP 查詢，因而出現「部分網頁一直轉圈、一般 TCP 測試卻正常」。可暫時關閉瀏覽器的 HTTP/3，將 DNS 改為 TCP 或 HTTPS 方式，觀察故障是否消失。若只有 UDP 失敗，不應判定整個節點完全不可用，而應依實際應用需求調整傳輸方式與路由。

自動選擇或負載策略會增加排查變數。測試期間固定一個出站，避免用戶端在多個節點間切換；確認單一節點穩定後，再恢復自動選擇。若某節點在桌面端與 Android 上同時失敗，且兩台裝置使用不同網路，節點參數或遠端狀態的可能性更高。若同一節點只在一台裝置失敗，則應比較兩端的核心類型、路由規則、DNS 設定與系統時間，而不是重新購買或反覆匯入相同訂閱。

先分清訂閱網址與單一節點分享連結

訂閱網址通常會回傳一組節點資料，用戶端儲存網址後即可再次更新；以 vmess://、vless:// 等開頭的分享連結通常只描述一個節點。把單一節點連結放進訂閱管理器，可能出現格式錯誤或更新後沒有清單；把訂閱網址當作單一節點掃描，也可能無法解析。兩者差異可參考分享連結與訂閱網址說明。排查時先確認複製的是完整網址，沒有在通訊軟體中換行、截斷，也沒有遺漏結尾參數。

訂閱更新涉及兩段連線：用戶端先連線到訂閱伺服器取得內容，再解析內容產生節點。下載階段失敗時，日誌常見 DNS、TLS、HTTP 狀態或連線逾時；下載成功但解析失敗時，通常會提示格式不支援、資料為空或個別項目異常。先記錄錯誤屬於哪一段，可以避免把網路問題誤判為節點格式問題。

檢查系統代理與訂閱更新路徑

訂閱更新可能選擇直連，也可能透過目前代理。若訂閱網址只有在代理連線可用時才能存取，而目前節點已失效，就會形成「必須先有節點才能更新節點」的循環。此時可切換到仍可用的舊節點，再執行更新；也可以檢查用戶端的訂閱更新代理選項，確認它是使用系統代理、目前代理還是直連。不了解各選項含義時，不要同時啟用多層代理，因為請求可能被送回本機代理連接埠而形成循環。

反過來，若訂閱伺服器在直連網路中可存取，透過代理卻失敗，應暫時改用直連更新。更新完成後先不要刪除舊群組，確認新清單包含預期節點，再清理重複項目。對於多個訂閱，逐一更新比「一鍵全部更新」更容易確認具體失敗的網址。訂閱名稱只是本地標籤，不參與連線；真正需要檢查的是網址、更新方式、使用者代理要求與回傳內容。

用 HTTP 狀態與回傳內容定位問題

狀態碼能快速劃分責任邊界。回傳 401 或 403 往往表示網址中的權杖、路徑或存取條件已失效；404 多見於連結被替換或複製錯誤；429 表示短時間內請求過多，應停止連續重新整理並稍後重試；5xx 表示訂閱伺服器暫時異常，本地反覆重裝用戶端通常沒有幫助。若狀態為 200 但清單為空，應檢查回傳的是節點文字、網頁提示還是登入頁面。圖形用戶端可能只顯示「解析失敗」，詳細日誌通常能看到回應類型或解碼錯誤。

桌面端可使用系統內建工具僅查看回應標頭，避免將完整訂閱內容輸出到共用螢幕或公開日誌。下方命令中的網址僅為本地範例，不包含真實訂閱資訊：

curl -I "https://example.invalid/subscription"
nslookup example.invalid

若網域無法解析，轉到本頁 DNS 章節；若 TLS 報錯，校正時間並檢查憑證名稱；若回應正常但用戶端解析失敗，可建立一個空白訂閱群組，僅匯入該網址，以排除舊快取與重複名稱節點的影響。v2rayN、v2rayNG 與 v2flyNG 對常見分享格式的處理細節可能不同，因此同一訂閱在不同用戶端出現差異時，應檢查訂閱是否包含該用戶端無法識別的擴充欄位，而不是直接假設是裝置網路故障。

處理更新後節點沒有變化

更新成功但清單看似沒有變化，可能是訂閱確實回傳相同內容，也可能是用戶端啟用了保留自訂節點、依備註合併或快取顯示。先比較節點數量、備註與伺服器位址，再完全離開清單頁面後重新進入。若用戶端提供清除訂閱快取或不保留舊節點的選項，可在確認已有備份後使用。不要只憑節點名稱判斷是否更新，因為提供者可能保留名稱但替換位址，也可能更改名稱而維持相同連線參數。

系統時間錯誤也可能讓 HTTPS 訂閱與節點連線同時失敗，這是最容易被忽略的共同原因。若所有訂閱突然出現憑證錯誤，同時所有 TLS 節點都無法使用，先同步時間，再重新啟動用戶端。只有一個訂閱失敗時，則集中檢查該網址。完成更新後，手動選擇一個新節點並實際存取，不要讓自動選擇繼續使用已刪除節點的快取參照。

將速度問題拆分為延遲、吞吐量與穩定性

「速度慢」至少包含三種不同現象：網頁首次開啟等待很久，通常與 DNS、建立連線和延遲有關；大型檔案持續下載速率低，更接近鏈路吞吐量、壅塞與裝置效能；速率忽高忽低或影片週期性緩衝，則要檢查封包遺失、無線網路干擾、節點負載、協定重傳與背景流量。只看一次延遲數字無法解釋所有現象，應在相同裝置、相同本地網路及相近時間內比較兩個節點，並保持路由、DNS 與測試目標一致。

測試前暫停雲端同步、系統更新、遊戲平台下載及其他裝置的大流量工作。無線網路應先靠近路由器測試一次，再使用網路線或另一條網路重新測試。若直接下載本身就很慢，代理無法消除本地接入瓶頸；若直連穩定而所有節點都不穩，應檢查本機代理鏈路、MTU、核心負載及網路對 UDP 的處理；若只有單一節點緩慢，則更可能是節點線路或遠端負載。

檢查路由是否造成繞路

規則模式會依網域、IP、連接埠與協定選擇出站。網域先由本地解析成某個 IP 後，如果 domainStrategy 與規則集搭配不當，同一網站的主頁、圖片與影片可能分別走不同出站，表現為頁面能開啟但媒體資源很慢。排查時暫時使用全域代理，比較同一項資源。如果全域模式明顯改善，應檢查規則命中順序、網域規則與 IP 規則是否衝突，以及 DNS 回傳結果是否符合預期。

路由規則不是越多越好。大量重疊規則會增加維護難度，舊規則集還可能把新增網域歸入不適合的出站。先使用用戶端內建的簡潔規則集，確認基本連線穩定後，再加入必要的自訂項目。每次只增加一組規則，並在日誌中確認對應網域最後使用的出站標籤。若某個應用程式直接連線 IP，網域規則可能不會命中，此時需要依應用特徵、目標 IP 或連接埠設計規則，但應避免過寬的網段把無關流量一併送入代理。

Mux、並行與傳輸方式的取捨

Mux 可以讓多個邏輯連線重用底層連線，在特定高延遲情境中減少重複交握，但不保證提升吞吐量。對於長時間的大流量傳輸，重用連線可能讓封包遺失影響多個請求；某些伺服器設定也不適合由用戶端單方面啟用。排查速度時先關閉 Mux，建立基準後再單獨啟用比較。若關閉後更穩定，就維持關閉；若大量短連線明顯改善，再評估啟用。不要同時調整 Mux、並行數、分片、DNS 與路由，否則無法確認是哪項變更產生效果。

WebSocket、gRPC、TCP 等傳輸方式由伺服器設定決定，用戶端不能任意切換來「加速」。參數不符通常會直接失敗，而不是得到更快的鏈路。REALITY 與 TLS 解決的是交握及安全傳輸條件，也不是速度按鈕。真正影響吞吐量的因素包括本地接入品質、裝置 CPU、遠端容量、鏈路壅塞、封包遺失率、往返時間以及應用程式本身的並行策略。

觀察裝置資源與 MTU 症狀

低效能裝置在高吞吐量加密、複雜規則或大量並行連線時，可能出現 CPU 使用率升高。桌面端可同時觀察工作管理員或系統監視器，Android 則可留意裝置發熱與背景限制。如果速度上升時 CPU 接近滿載，請減少複雜路由、關閉不必要的日誌與並行功能，再比較不同核心用戶端的表現。v2rayNG 使用 Xray 核心，v2flyNG 使用 v2fly 核心，適合作為 Android 上的對照，但節點協定必須獲對應核心支援。

MTU 問題常表現為小型網頁可以開啟，但大圖片、上傳或特定 HTTPS 頁面卡住。VPN、通道與某些寬頻接入疊加後，有效封包大小可能降低。可先切換網路驗證：如果同一裝置在另一個網路完全正常，原網路的 MTU 或路由設備值得檢查。Linux 可使用禁止分片的 ping 逐步縮小封包大小，但不同系統的參數寫法不同，測試結果也會受目標是否回應影響，因此只能作為線索。圖形用戶端沒有必要因為一般速度波動就直接修改底層 MTU；先確認症狀與網路有關，再於系統或路由器層級謹慎調整。

最後的比較應使用相同檔案、相同時段及至少數分鐘的持續傳輸，記錄平均速率與中斷情況。單次峰值沒有代表性。確認節點穩定後，再恢復規則模式、自動選擇與日常 DNS 設定，每恢復一項就重新測試一次，才能知道效能損失來自節點還是本地設定。

辨識 DNS 故障的典型界線

DNS 會將網域轉換為 IP。解析失敗時，直接存取已知 IP 可能仍有回應，而使用網域存取會提示找不到伺服器；解析到不適合的位址時，頁面可能連線逾時、憑證名稱不符，或同一網站在不同網路上的表現不同。若所有網站都失敗，不要立即判定是 DNS，因為本地代理連接埠、節點與系統代理同樣會造成全面中斷。更可靠的判斷方式是分別查詢網域、查看用戶端 DNS 日誌，並比較關閉代理前後的結果。

桌面系統可使用 nslookup 或 dig 檢查基本解析。命令輸出中的 DNS 伺服器、回傳位址與錯誤類型，比單純「能否開啟網頁」更有價值。若系統查詢成功但透過代理存取失敗，可能是 Xray 內建 DNS、路由規則或瀏覽器安全 DNS 使用了另一條解析路徑。瀏覽器、系統與用戶端同時啟用各自的安全 DNS 時，排查會變得困難，建議暫時保留一條明確路徑。

nslookup example.com
dig example.com A
dig example.com AAAA

理解本地解析、遠端解析與路由的關係

網域可以在進入代理前由系統解析，也可以交由代理核心的 DNS 模組處理。前者便於使用系統快取，但解析結果會受本地 DNS 影響；後者可讓網域與路由規則保持更一致，但必須正確設定 DNS 出站與查詢路徑。Xray 的 domainStrategy 還會決定路由比對時是否解析網域。AsIs 會盡量依原始網域處理，IPIfNonMatch 會在網域規則未命中時解析 IP，再嘗試比對。策略選擇要與規則結構配套，不是數值越複雜越好。

下面是一個簡化的 DNS 結構，使用一般位址展示欄位關係。實際使用時應依網路環境與用戶端介面設定，不要直接覆蓋用戶端自動產生的完整檔案。

{
  "dns": {
    "queryStrategy": "UseIP",
    "servers": [
      {
        "address": "1.1.1.1",
        "domains": ["geosite:geolocation-!cn"]
      },
      "localhost"
    ]
  },
  "routing": {
    "domainStrategy": "IPIfNonMatch",
    "rules": [
      {
        "type": "field",
        "ip": ["geoip:private"],
        "outboundTag": "direct"
      }
    ]
  }
}

設定範例中的公共解析位址不一定適合所有網路。關鍵是確認查詢從哪裡發出、使用哪個出站、回傳 A 記錄還是 AAAA 記錄，以及結果如何參與路由。如果查詢以直連方式送出，而目前網路無法穩定連到該解析服務，就會出現間歇性逾時；如果查詢透過代理送出，但代理尚未建立，又會形成啟動依賴。用戶端預設設定通常比從多篇教學拼接出的複雜設定更容易維護。

清理快取並處理 IPv6 差異

修改 DNS 後，系統、瀏覽器與用戶端可能仍保留舊結果。Windows 可執行 ipconfig /flushdns 清理系統快取；Linux 的具體命令取決於目前執行的解析服務；macOS 可透過重新連線網路或重新啟動對應解析服務來刷新。瀏覽器還可能維護獨立連線池，應完全關閉相關頁面後重新開啟。清除快取只能解決舊記錄問題，無法修復錯誤的 DNS 路由或無法連線的解析伺服器。

ipconfig /flushdns
resolvectl flush-caches

IPv6 是另一個常見分支。網域若同時回傳 A 與 AAAA 記錄，系統或應用程式可能優先嘗試 IPv6。目前網路看似已分配 IPv6 位址，但實際出口不穩定時，就會出現首次連線等待、部分網域失敗或等候回退後才開啟。可以暫時讓 DNS 只回傳 IPv4 結果進行比較；如果問題消失，應檢查本地 IPv6 連通性與用戶端查詢策略，而不是永久依賴反覆重新整理。反之，在 IPv6 網路正常時粗暴停用它，也可能失去更合適的路徑。

FakeDNS 的適用範圍與退出條件

FakeDNS 會為網域分配保留位址，再由核心在連線階段還原網域，方便透明代理與依網域分流。它不是一般 DNS 的簡單替代方案。某些應用程式會檢查回傳 IP、快取位址後繞過代理，或直接使用內建解析邏輯；在這些情況下，可能出現登入失敗、區域網路裝置無法連線、推播異常或 UDP 應用程式不穩定。遇到這類邊界情況時，應先關閉 FakeDNS，使用一般 DNS 建立基準。更完整的機制說明可閱讀FakeDNS 運作原理與適用情境。

若只有區域網路主機名稱、印表機或路由器管理位址失敗，應確保私有位址與本地域名使用直連解析，不要交給遠端 DNS 或 FakeDNS。若只有瀏覽器失敗而其他應用正常，檢查瀏覽器自身的安全 DNS；若所有應用都失敗，檢查系統 DNS 與用戶端 DNS 入站。依「系統查詢—用戶端查詢—瀏覽器查詢」三層逐一驗證，比頻繁更換公共 DNS 更容易找到真正的衝突點。

確認系統代理與本地入站連接埠一致

系統代理的本質，是將支援代理設定的應用程式指向本機 HTTP 或 SOCKS 監聽連接埠。用戶端介面顯示「系統代理已啟用」時，仍需確認系統設定中的位址與連接埠，和目前核心實際監聽的值一致。常見位址是迴路位址，連接埠則由用戶端設定決定。若曾更改本地連接埠但系統仍保留舊值，應用程式會連到不存在的監聽連接埠；若舊用戶端程序仍佔用該連接埠，流量可能進入錯誤的執行個體。

先在用戶端日誌中確認入站已啟動，再使用連接埠查看命令驗證監聽程序。不要把遠端節點連接埠與本地代理連接埠混為一談：遠端連接埠供核心連線伺服器使用，本地連接埠供瀏覽器連線用戶端使用。系統代理只需填寫本地監聽位址，不應填寫節點位址。修改後徹底關閉並重新開啟瀏覽器，因為已建立的連線可能會繼續沿用舊路徑。

理解不同應用程式對系統代理的支援差異

瀏覽器和多數桌面網路程式會讀取系統代理，但並非所有應用程式都會遵循。部分程式使用自己的代理設定，部分命令列工具只讀取環境變數，也有應用程式直接建立網路連線。因此「瀏覽器可用、某個應用程式直連」不代表系統代理整體失效。應先在明確支援系統代理的瀏覽器中建立基準，再查看目標應用是否提供 HTTP、HTTPS 或 SOCKS 設定。

命令列工具通常需要明確設定環境變數。下面範例會將 HTTP 與 HTTPS 請求指向本地 HTTP 代理連接埠，連接埠應替換為用戶端目前顯示的實際值。環境變數只對目前終端機工作階段及其子程序生效，關閉終端機後通常不會保留。

set HTTP_PROXY=http://127.0.0.1:10809
set HTTPS_PROXY=http://127.0.0.1:10809

export http_proxy=http://127.0.0.1:10809
export https_proxy=http://127.0.0.1:10809

SOCKS 代理還涉及網域解析位置。某些工具的 socks5 寫法會在本地解析網域，而 socks5h 會將網域交由代理解析。若命令列只有網域失敗而 IP 可以連線，這項差異值得檢查。不要同時在應用程式內設定代理、在系統中設定代理，又讓透明代理接管相同流量，否則連線可能重複進入用戶端。

排查 PAC、繞過清單與規則模式

系統代理模式可能是全域、PAC 或維持不變。PAC 透過腳本決定哪些位址使用代理；腳本未更新、快取舊內容或規則未涵蓋目標網域時，瀏覽器就會直接連線。全域系統代理會把支援系統代理的請求統一送入用戶端，但進入用戶端後仍會受到 Xray 路由規則影響，因此「系統全域」不等於「所有流量都走代理出站」。排查時要分別觀察作業系統這一層與核心路由這一層。

系統繞過清單通常包含區域網路位址與本地主機名稱。清單寫得過寬時，某些一般網域也可能繞過代理；寫得過窄時，路由器管理頁與區域網路服務又可能被送入代理。建議保留迴路位址與明確的私有網段，不要用模糊萬用字元涵蓋大量網域。若公司環境透過政策統一下發代理，用戶端可能無法持續覆蓋系統設定，此時應比較修改前後系統代理值是否被自動恢復。

處理結束後殘留代理與休眠恢復

用戶端異常結束、系統強制終止程序或裝置從休眠恢復後，系統代理可能仍指向本地連接埠，但對應核心已停止。這時所有遵循系統代理的應用程式都會失敗，而關閉系統代理後立即恢復。解決時先在系統網路設定中關閉代理，再重新啟動用戶端並由用戶端重新啟用。正常結束用戶端通常會執行還原動作，但不能依賴異常程序完成清理。

Windows 上還要區分目前使用者的代理設定與部分舊程式讀取的不同介面；macOS 上應確認修改的是目前使用中的網路服務；Linux 桌面環境可能同時存在系統代理、桌面代理與應用程式環境變數三種來源。不要在所有位置同時填寫，先選擇一種明確方式驗證。使用 v2rayN 進行 Linux 桌面安裝與自動啟動時，可參考Linux 桌面安裝指南，檢查使用者服務與桌面工作階段是否處於相同環境。

最後的驗證應查看用戶端存取日誌中是否出現目標網域。日誌完全沒有紀錄，表示流量沒有進入用戶端，應繼續檢查應用程式與系統代理；日誌出現目標網域但使用 direct，表示問題在路由規則；日誌顯示走代理後逾時，則回到節點與 DNS 章節。利用日誌分層定位問題，可以避免在系統代理失效時反覆更換節點。

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

v2rayN 由圖形介面、設定資料與代理核心共同組成。視窗無法開啟、開啟後立即消失、介面正常但連線按鈕無反應，分別可能屬於不同層級。若介面仍可操作但日誌提示核心退出，重點查看產生的設定與連接埠；若程式本身沒有視窗，應檢查系統事件、啟動終端機輸出、檔案權限與執行相依元件。不要把所有啟動問題都歸因於節點，因為損壞的節點通常只會導致連線失敗，不一定會讓整個介面無法顯示。

排查前先完整結束相關程序，再重新啟動一次。多次雙擊可能啟動多個執行個體，造成設定檔鎖定或本地連接埠衝突。桌面端應從工作管理員或系統監視器確認圖形程序與 Xray 程序是否殘留。若重新啟動系統後恢復，仍應檢查上次日誌中的連接埠佔用與異常結束原因，避免問題在下次休眠後再次出現。

從第一筆設定錯誤向上追查

核心載入設定時會驗證 JSON 結構、欄位類型、協定參數與參照標籤。日誌中後續的大量退出訊息通常由第一筆設定錯誤引起，真正有價值的是最早出現的 failed to load config、未知欄位、缺少出站標籤或 JSON 解析位置。手動編輯 JSON 時，逗號、引號與括號最容易出錯；圖形用戶端產生設定失敗時，則可能是某條自訂路由、DNS 項目或節點附加參數不合法。

JSON 不允許註解，也不允許在最後一個成員後保留逗號。字串中的反斜線與雙引號需要跳脫。下面的結構語法完整，可用於對照基本層級，但不包含可連線的節點：

{
  "log": {
    "loglevel": "warning"
  },
  "inbounds": [
    {
      "tag": "socks-in",
      "port": 10808,
      "listen": "127.0.0.1",
      "protocol": "socks"
    }
  ],
  "outbounds": [
    {
      "tag": "direct",
      "protocol": "freedom"
    }
  ]
}

若錯誤只在啟用自訂設定後出現，先停用自訂項目，讓用戶端重新產生預設設定。確認預設設定可以啟動後，再分段加入 DNS、路由與出站。設定檔結構及各區塊職責可參考V2Ray JSON 設定結構解析。不要直接將其他用戶端的完整設定覆蓋到目前用戶端，因為介面可能依賴自身產生的入站標籤、連接埠與管理介面。

檢查目錄權限、路徑與安全軟體攔截

用戶端需要讀取設定、寫入日誌並啟動核心子程序。安裝目錄不可寫入、使用者目錄權限異常、路徑所在磁碟唯讀，都會造成啟動失敗。Linux 上尤其要避免先以管理員身分啟動一次，再以一般使用者執行相同設定目錄，因為前一次產生的檔案可能屬於管理員。修正檔案擁有者與權限後，以一般桌面使用者重新啟動。macOS 與 Windows 則應確認程式目錄未被系統保護政策阻止寫入，並查看安全軟體是否隔離核心檔案或阻止子程序執行。

路徑包含特殊字元時，現代用戶端通常能夠處理，但外部腳本、舊設定或自訂命令可能錯誤拆分路徑。可將設定目錄暫時移到簡短的使用者目錄進行比較。不要把設定放在即時同步目錄中測試，同步程式可能在用戶端寫入時建立衝突副本或暫時鎖定檔案。確認問題與路徑有關後，再逐項恢復原位置。

保留診斷資料並安全重建設定

需要重設時，先結束用戶端並複製設定目錄作為本地備份，然後只重新命名目前設定目錄，讓用戶端產生一套全新設定。若新設定可以啟動，表示程式檔案與系統執行環境基本正常，問題位於舊設定。此時應重新加入訂閱與少量必要規則，不要立刻把整個舊目錄覆蓋回去。可以依訂閱、路由、DNS、介面設定的順序逐類恢復，每次啟動後驗證一次。

若全新設定仍無法啟動，再考慮重新安裝。應從用戶端下載頁選擇與平台及處理器相符的 v2rayN；Android 使用 v2rayNG，或在需要 v2fly 核心時選擇 v2flyNG。重新安裝前記錄日誌錯誤、作業系統、處理器架構與重現步驟，這些資訊比一張「無法啟動」的截圖更有助於定位問題。不要捏造或猜測版本相容性，以下載頁目前提供的套件類型與系統需求為準。

若閃退發生在匯入某個節點後，可在新設定中先匯入其他節點，再單獨匯入可疑連結。若發生在啟用特定 DNS 或路由功能後，則保留預設設定並逐項重現。只要確定「加入哪一項後開始失敗」，就能把問題縮小到具體設定，而不必同時更換系統、用戶端與訂閱。

確認 VPN 權限與系統中唯一的連線執行個體

v2rayNG 和 v2flyNG 在 Android 上通常透過系統 VPN 介面接管流量。首次連線時需要確認系統授權；若取消授權視窗，用戶端可以儲存節點，卻無法建立 VPN。狀態列出現 VPN 圖示只代表介面已建立，仍需透過日誌確認核心與節點連線成功。系統通常同一時間只保留一個 VPN 服務，其他 VPN 類應用程式、工作設定檔管理工具或系統網路功能可能搶佔介面，導致剛連線就中斷。

排查時先關閉其他 VPN 類功能，徹底停止 v2rayNG 或 v2flyNG，再重新開啟並授權。不要讓兩款用戶端同時處於自動連線狀態。若切換用戶端後舊 VPN 圖示仍未消失，可在系統網路設定中中斷目前 VPN，再啟動目標用戶端。節點在桌面端可用、在 Android 上立即失敗時，應先比較 Android 匯入後的協定、傳輸、安全方式、伺服器名稱與路徑，確認 QR Code 或剪貼簿內容沒有被截斷。

處理省電策略與背景限制

螢幕熄滅幾分鐘後連線中斷、重新點亮後恢復，通常與背景限制有關。Android 製造商的省電策略可能暫停用戶端程序、限制背景網路，或清理長時間執行的 VPN 服務。應在系統應用程式設定中允許用戶端於背景執行，取消針對該用戶端的電池最佳化，並允許必要的自動啟動或背景活動。不同裝置的選單名稱各異，但判斷標準相同：用戶端在鎖定螢幕後應繼續執行，系統不應將其列為受限應用程式。

只將用戶端留在最近使用的工作列表中不一定足夠；某些系統的「鎖定工作」也不等同於允許背景網路。調整後應鎖定螢幕等待一段時間，再透過訊息同步、網頁請求或用戶端日誌確認連線是否持續。若只有從行動網路切換到 Wi-Fi 時中斷，可能是網路變更後舊連線未及時重建。返回用戶端手動停止再啟動，可判斷是否屬於重新連線問題。在頻繁切換網路的情境下，應避免同時啟用系統永遠開啟 VPN、其他自動化網路工具與用戶端自身的自動連線，以免多個機制互相競爭。

應用程式分流與繞過設定的排查順序

Android 用戶端可依應用程式決定哪些流量進入 VPN。設定方向容易混淆：有些介面表示「僅代理所選應用程式」，有些則表示「繞過所選應用程式」。若誤解選項含義，就會出現瀏覽器正常、目標應用程式直連，或只有少數應用程式能連網。排查時先關閉應用程式分流，讓所有應用程式進入同一條 VPN 路徑，確認節點與 DNS 正常後，再啟用分流並只選擇一個測試應用程式。

系統應用程式、工作設定檔中的應用程式與一般使用者應用程式，可能屬於不同的設定範圍。若目標應用程式呼叫系統元件開啟網頁，主要應用程式與系統元件可能走不同路徑，表現為登入頁與正文的連線結果不一致。此時應同時觀察用戶端日誌中是否出現目標網域，並檢查相關系統元件是否被分流規則排除。不要一開始就加入大量應用程式清單，清單越長越難判斷實際方向。

解決區域網路存取、熱點分享與 DNS 差異

啟用 VPN 後無法存取路由器、區域網路儲存裝置或印表機，應檢查「繞過區域網路」或私有位址直連規則。區域網路位址通常不應送往遠端節點。若使用 IP 可以存取、使用本地主機名稱卻失敗，問題更接近本地 DNS 或多點傳送解析，而不是節點。關閉 FakeDNS、讓區域網路網域使用本地解析，並確保私有網段走直連，可以建立更清楚的基準。

裝置熱點分享是另一層網路轉送，連線到本機熱點的裝置不一定會自動使用手機上的 VPN。即使手機瀏覽器已透過用戶端連線，熱點下游裝置也可能使用獨立出口。不要只憑手機狀態列判斷共用裝置的路徑，應在下游裝置上單獨驗證。若需求只是讓手機應用程式存取，關閉熱點分享可減少變數；若需要處理分享流量，則要確認用戶端與系統是否提供相應支援，不能把一般 VPN 模式的行為直接推論到熱點。

Android 的私人 DNS 與用戶端 DNS 可能同時存在。私人 DNS 設定無法連線時，部分應用程式會持續等待；用戶端啟用 FakeDNS 或遠端 DNS 後，也可能與系統策略產生不同的解析結果。排查時將私人 DNS 恢復為系統自動，關閉用戶端進階 DNS，只保留預設設定。基本連線恢復後，再依實際需求逐項啟用。若只有某個應用程式失敗，還要考慮應用程式內建 DNS、QUIC 或憑證鎖定機制，不能把所有差異都歸咎於用戶端錯誤。

收集日誌並在兩款 Android 用戶端之間對照

重現問題前，先清空或記住目前的日誌位置，然後執行一次明確操作，例如中斷後重新連線、開啟一個失敗的網域或鎖定螢幕等待。記錄第一筆錯誤、使用的網路類型、是否啟用應用程式分流、DNS 模式與節點協定。若日誌完全沒有目標請求，檢查應用程式分流；若有請求但解析失敗，檢查 DNS；若節點連線逾時，回到位址、連接埠與網路；若鎖定螢幕後核心日誌停止，重點檢查背景限制。

v2rayNG 使用 Xray 核心，是 Android 的首選用戶端；v2flyNG 使用 v2fly 核心，可用於協定相容性與執行行為對照。進行對照測試時，應匯入同一份受支援的節點，並盡量保持 DNS、路由與分流簡單。若兩款用戶端在同一網路都失敗，而桌面端在另一網路正常，應讓 Android 切換網路重新測試；若只有其中一款失敗，則比較核心支援與產生的設定。不要同時更換用戶端、節點與網路，否則測試結果無法說明原因。

完成排查後，恢復必要的背景權限、應用程式分流與 DNS 設定，並逐項驗證。長期穩定的設定通常比堆疊大量實驗選項更容易維護。首次設定步驟可返回使用指南重新核對；涉及憑證交握的錯誤，可繼續閱讀TLS 與憑證報錯檢查清單。