V2Ray 疑難排解大全

「連線後無法上網」不代表節點本身失效。用戶端顯示已啟動，只能表示本地程序完成初始化，不能證明遠端握手、DNS 查詢與應用程式流量都已成功。第一步應明確範圍：是所有網站都打不開，還是只有網域無法開啟；關閉系統代理後能否恢復直接連線；同一節點在其他網路中是否可用；只有瀏覽器異常，還是命令列與其他應用程式也異常。這四個問題可以快速將故障縮小到網路、解析、代理接入或節點設定。

先恢復基準，再逐層啟用

在 v2rayN 中先關閉系統代理與 TUN 模式，保留用戶端程序執行，然後確認一般直接連線是否正常。若直接連線也失敗，應先處理路由器、網路驗證、網卡或本地 DNS，不要繼續修改 V2Ray 設定。直接連線恢復後，選擇一個已知可用的節點，只啟用系統代理，並將路由切換為全域代理進行短時間測試。全域模式可用而規則模式不可用，故障通常位於路由規則、GeoSite 資料或 DNS 分流；全域模式仍不可用，則繼續檢查節點與本地代理連接埠。

1. 退出其他代理、加速或流量接管程式，避免多個程式同時修改系統代理與路由表。
2. 檢查系統時間與時區。時間偏差會導致 TLS 憑證判定錯誤，也可能使包含時間欄位的驗證失敗。
3. 在用戶端中重新選擇節點並啟動核心，確認日誌中出現本地入站監聽，而不是啟動後立即退出。
4. 只啟用一種接入方式。一般瀏覽器測試優先使用系統代理，不要同時啟用系統代理與 TUN。
5. 分別造訪一個純 IP 目標與常用網域，判斷問題是否集中在 DNS。

Windows 可以使用以下命令確認本地連接埠是否處於監聽狀態。連接埠號碼應以 v2rayN 目前設定為準，常見設定會同時存在 SOCKS 與 HTTP 入口。若命令沒有輸出，表示核心沒有監聽該連接埠，可能是連接埠衝突、設定產生失敗或核心程序已退出。

netstat -ano | findstr LISTENING
curl.exe -x http://127.0.0.1:10809 https://example.com/

第二個命令用於繞過系統代理設定，直接向本地 HTTP 代理發出請求。若能返回頁面回應，表示「應用程式到本地代理，再到節點」的基本鏈路已成立，問題更可能出在系統代理開關或瀏覽器本身的設定；若提示無法連線至本地連接埠，應檢查入站連接埠；若已連線至本地連接埠但遠端失敗，則查看核心日誌中的握手、憑證、位址或路由資訊。

辨識設定錯誤與網路阻斷

節點設定需要逐項核對伺服器位址、連接埠、使用者識別碼、傳輸方式、TLS 開關、伺服器名稱與路徑。VMess、VLESS、Trojan 的欄位含義不同，不能只替換位址和連接埠後繼續使用舊傳輸參數。若訂閱提供的節點由用戶端自動產生，優先重新更新訂閱並重新選擇節點；手動輸入時，應與提供方提供的完整參數逐欄位比對，尤其注意 WebSocket 路徑前導斜線、gRPC 服務名稱以及 TLS 的伺服器名稱。

若同一設定在行動網路可用、家庭網路不可用，應檢查家庭網路是否存在 DNS 劫持、路由器過濾、雙層代理或異常的 IPv6 路由。反過來，家庭網路可用而行動網路失敗，則需要檢查行動裝置的背景限制、私人 DNS 與目前接入點。不要根據單次請求就認定是網路側故障，至少應在兩個不同網路、兩個不同節點之間交叉測試。交叉結果能區分「特定節點異常」、「特定網路異常」與「用戶端全域設定異常」。

連線恢復後，應將路由從全域模式切回實際使用的規則模式，再驗證中國大陸直連、代理目標與區域網路位址是否分別走向預期出口。有關模式差異可參考系統代理、全域模式與繞過中國大陸模式的差異。若切換後再次斷網，表示基本連線沒有問題，下一步應集中檢查路由規則與 DNS，而不是重新安裝用戶端。

逾時表示某一層在規定時間內沒有收到有效回應，但日誌中的「timeout」可能對應 TCP 建立連線、TLS 握手、協定驗證、DNS 查詢或目標網站回應。處理前先記錄逾時發生的位置與持續時間。如果多個節點同時逾時，應優先檢查本地網路、系統時間、DNS 與用戶端核心；如果只有單一節點逾時，優先檢查該節點的位址、連接埠、傳輸參數與遠端狀態。

用交叉測試劃分責任邊界

建立一個二乘二測試：同一節點分別在目前網路與另一個網路測試，再在目前網路測試另一個節點。節點換網後仍失敗而其他節點正常，問題集中在該節點；目前網路下所有節點失敗、換網後恢復，問題集中在本地網路路徑；所有組合都失敗，則應檢查用戶端通用設定或訂閱參數。交叉測試應保持用戶端版本、路由模式與 DNS 設定不變，否則無法比較結果。

「連線遭拒絕」與「連線逾時」的含義不同。遭拒絕通常表示封包已抵達目標主機，但指定連接埠沒有服務監聽，或中間設備主動回傳拒絕；逾時則可能是封包未抵達、返回路徑中斷或服務沒有回應。前者應先核對連接埠與遠端服務，後者應先檢查位址解析、網路路徑與防火牆。若日誌中連續出現短間隔重試，不要讓用戶端長時間反覆連線，應暫停節點，避免重試訊息淹沒真正的第一個錯誤。

TLS 與傳輸參數的核對順序

啟用 TLS 的設定至少涉及遠端位址、伺服器名稱與憑證比對。伺服器位址可以是 IP，也可以是網域；伺服器名稱通常用於 TLS 握手，兩者不一定相同。手動編輯時將伺服器名稱留空、誤填成節點備註或使用錯誤網域，都會造成握手失敗。若設定使用 WebSocket，還要檢查 Host 與 path；使用 gRPC 時檢查 serviceName；使用 REALITY 時核對公鑰、短識別碼、伺服器名稱與流量控制欄位。不要透過關閉憑證驗證來掩蓋欄位錯誤，這只會讓故障表象消失，卻無法證明設定正確。

IPv6 也會造成不穩定的逾時。網域可能同時返回 IPv4 與 IPv6 位址，而目前網路只有不完整的 IPv6 連線能力。常見表現是首次連線等待較長時間，之後回退到 IPv4，或同一節點時好時壞。可暫時在用戶端 DNS 或系統網路中優先使用 IPv4 進行驗證，但不應直接刪除所有 IPv6 設定。確認原因後，再依實際網路能力選擇優先策略。

節點能建立連線但存取特定網站逾時，應檢查目標網域是否被錯誤分流至直連、是否命中阻斷規則，以及 DNS 返回的位址是否與路由規則一致。可以暫時將目標網域加入明確的代理規則，並置於寬泛規則之前。修改規則後重新啟動核心或重新載入設定，再透過日誌確認命中的出站標籤。有關 domain、ip 與 geosite 的順序，可繼續閱讀V2Ray 路由規則設定實戰。

完成修復後至少驗證三類請求：節點伺服器網域解析、一般 HTTPS 網站存取，以及持續數分鐘的連線穩定性。只有一次握手成功不足以表示問題已消失。若在固定時間間隔後斷線，應繼續檢查網路切換、路由器連線追蹤、行動裝置省電策略與伺服器端閒置逾時，而不是單純增加用戶端連線逾時時間。

訂閱更新包含三個獨立步驟：用戶端請求訂閱位址、伺服器返回內容、用戶端解析並寫入節點清單。失敗提示往往只顯示最後結果，因此要判斷請求是否確實送出、HTTP 狀態是否正常、返回內容是否屬於用戶端支援的格式。節點清單為空不一定是網路問題，也可能是訂閱內容過期、位址複製不完整、返回登入頁面、篩選規則隱藏所有節點，或解析時遇到格式錯誤。

先檢查位址本身

重新複製訂閱位址時，應從來源頁面使用完整複製功能，不要手動截取。重點檢查位址開頭的協定、路徑、查詢參數與結尾字元。聊天軟體或文件編輯器可能將連接符替換成其他符號，也可能在結尾加入句號、換行或空格。若位址包含臨時憑據，不應放入公開日誌或截圖。確認系統時間準確，因為部分訂閱服務會判斷請求時間，時間偏差也會影響 HTTPS 憑證驗證。

在 v2rayN 中可以先單獨更新指定訂閱，不要同時更新所有群組。這樣能確認失敗屬於單一位址還是全域網路。如果指定訂閱失敗，保留錯誤提示並查看日誌中的 HTTP 狀態；如果所有訂閱都失敗，檢查系統代理、直接連線、DNS，以及用戶端是否將訂閱請求錯誤地送入尚不可用的節點。部分情況需要先直接連線取得訂閱，另一些情況則需要透過既有代理取得，應依訂閱來源的實際可達性選擇更新方式。

curl.exe -L --connect-timeout 15 "https://example.com/subscription?token=xxxx" -o subscription.txt

命令中的位址僅展示請求結構。實際檢查時不要在公共終端記錄或分享完整憑據。返回檔案如果是 HTML 登入頁面、錯誤說明或空檔案，用戶端自然無法產生節點；若返回一長段編碼文字或節點連結，再檢查用戶端是否支援對應格式。HTTP 301、302 表示重新導向，命令中的 -L 會跟隨跳轉；401、403 通常與憑據、權限或請求條件有關；404 表示路徑不存在；429 表示請求過於頻繁，應停止重複重新整理並稍後再試；5xx 則更可能是訂閱服務端暫時異常。

內容已下載但解析失敗

日誌顯示下載成功、節點仍為空時，應檢查訂閱群組的篩選條件。正規表示式篩選若設定過窄，可能會排除所有節點；去重規則也可能將名稱相近的節點合併。先停用篩選並重新更新，確認原始節點是否出現。若出現，再逐條恢復篩選條件。節點名稱含括號、加號或其他正規表示式字元時，需要注意這些字元在運算式中具有特殊含義，直接複製名稱不一定會按字面比對。

訂閱返回格式與用戶端核心是兩個概念。v2rayN 負責管理桌面設定，v2rayNG 使用 Xray 核心，v2flyNG 使用 v2fly 核心；同一訂閱中的某些傳輸或協定欄位，可能只有部分用戶端能識別。更新成功但特定節點匯入失敗時，應查看解析日誌並確認節點類型，而不是反覆刪除訂閱。Android 上可分別使用 v2rayNG 與 v2flyNG 進行相容性對照，但不要同時啟動兩個本地 VPN 接管。

當訂閱位址已失效，應從原提供管道重新取得，而不是自行修改 token 或猜測路徑。刪除舊位址後立即新增，也無法修復伺服器端的權限問題。若瀏覽器能取得內容而用戶端失敗，請檢查用戶端的 User-Agent 限制、系統代理路徑與 TLS 日誌；若用戶端成功但瀏覽器失敗，可能是瀏覽器擴充功能、快取或獨立代理設定造成差異。可參考下載頁常見問題核對用戶端選擇，再回到本章依請求、回應、解析三個階段定位。

修復後不要只看「更新成功」提示，還要確認節點數量合理、更新時間已變更、舊節點是否按預期替換，並隨機開啟兩個節點核對伺服器位址與協定欄位。接著選擇一個節點執行連線測試。訂閱成功只代表設定資料已進入用戶端，不代表其中每個節點都能建立網路連線；連線失敗時應轉到上一章繼續檢查逾時與握手階段。

速度問題需要先區分頻寬不足、延遲偏高、封包遺失、單一連線限制與用戶端資源瓶頸。網頁開啟慢不等於下載頻寬低，測速結果高也不代表互動延遲穩定。排查時固定測試時間、目標檔案、網路與節點，至少重複三次，避免將目標網站壅塞或短暫無線干擾誤判為用戶端問題。不要同時執行多個測速工具，它們會爭用頻寬並改變測試結果。

建立直接連線與代理兩組基準

先關閉代理，在同一網路測試直接連線的延遲、下載速度與封包遺失，再啟用一個節點重複測試。若直接連線本身波動明顯，應優先處理 Wi-Fi 訊號、路由器負載、網路線協商或電信業者網路。若直接連線穩定、所有節點都很慢，檢查本地 CPU、防毒軟體網路掃描、TUN 驅動與 MTU；若只有單一節點速度慢，則更可能是節點線路、遠端負載或節點到目標網站的路徑問題。

測速應涵蓋小型請求與持續傳輸。小型請求用於觀察 DNS、握手與首位元組時間，持續傳輸則用於觀察穩定頻寬。網頁首次開啟很慢、後續資源正常，常見原因是 DNS 或 TLS 建立連線耗時；下載開始很快、之後下降，可能與遠端限速、無線壅塞、封包遺失重傳或 CPU 達到上限有關；速度週期性歸零後恢復，應檢查網路切換、行動裝置省電與連線重建。

檢查傳輸、MTU 與路由

TUN 模式會增加虛擬網卡與路由處理環節。系統代理速度正常而 TUN 明顯變慢時，應檢查虛擬網卡驅動程式、嚴格路由、IPv6 與 MTU。MTU 過大可能導致分片或部分路徑封包遺失，表現為小型請求正常、大型回應停頓。可以逐步降低 TUN 介面的 MTU 進行對照，但每次只調整一個檔位，並在修改後重新連線。不要將 MTU 設定得過低，額外分片會降低效率。

規則分流也會造成「部分網站變慢」。目標網域可能直接連線，而頁面中的圖片、指令碼或介面走代理，兩個出口的 DNS 與連線狀態不同，最終表現為頁面等待。開啟核心存取日誌，觀察同一頁面相關網域命中的出站標籤。暫時使用全域代理後速度恢復，表示節點本身可用，應修正網域規則；全域模式仍然很慢，則繼續檢查線路與傳輸參數。GeoIP 與 GeoSite 資料過期也會造成規則分類偏差，更新方式可參考GeoIP 與 GeoSite 資料庫更新說明。

用戶端核心加密、TLS 與流量轉發會佔用 CPU。低功耗裝置或路由器上，單核心達到上限時，頻寬會受處理能力限制。桌面端可在傳輸期間觀察 CPU 與記憶體，確認是核心程序持續佔用，還是瀏覽器、同步程式或安全掃描佔用資源。若 CPU 資源充足但速度仍低，不應透過增加並行或連線數盲目解決，因為高並行可能進一步加劇封包遺失。

無線網路測試時盡量靠近存取點，並關閉大流量同步工作。若 2.4 GHz 與 5 GHz 的表現差異明顯，先處理本地無線環境。跨網路比較時要記錄網路類型與時段，不應將不同條件下的結果直接歸因於協定。完成調整後，恢復原有路由模式，分別測試瀏覽、影片、大檔案與長連線；若只有某一種業務異常，再針對對應目標與連線模型繼續分析。

DNS 問題常表現為網域打不開、同一網站時好時壞、代理連線成功但目標被錯誤分流，或瀏覽器與命令列得到不同結果。排查重點不是簡單更換一個 DNS 位址，而是確認「誰發起查詢、查詢送往何處、返回哪個位址、該位址如何進入路由匹配」。系統 DNS、用戶端內建 DNS、瀏覽器安全 DNS 與 TUN 劫持可能同時存在，多條解析路徑會造成結果不一致。

先判斷是否為解析故障

關閉用戶端後使用系統命令查詢目標網域，再開啟用戶端重複查詢，並記錄返回的 IPv4、IPv6 與解析耗時。若系統查詢失敗但指定公共 DNS 可以成功，問題可能在本地 DNS 或路由器；若命令列成功而瀏覽器失敗，應檢查瀏覽器快取、獨立 DNS 設定與擴充功能；若解析成功但存取失敗，繼續比較日誌中實際連線的位址是否與查詢結果一致。

nslookup example.com
nslookup example.com 1.1.1.1
ipconfig /flushdns

nslookup 用於觀察系統或指定伺服器的查詢結果，重新整理系統快取只會清除作業系統維護的記錄，不會清除瀏覽器與用戶端內部快取。執行重新整理後，應完全關閉測試應用程式再重新開啟。若用戶端啟用了 FakeDNS，返回的可能是保留位址，這屬於映射機制的一部分，不能直接當作一般公網位址判斷。此時應查看 FakeDNS 映射是否由核心接管，以及目標流量是否仍進入對應的代理入口。

理解 DNS 與路由的先後關係

路由規則既可以按網域匹配，也可以按解析後的 IP 匹配。若網域在進入核心前已由系統解析，核心可能只看得到 IP，網域規則就無法按預期運作；如果由核心負責解析，則可保留網域資訊，並根據規則選擇不同 DNS 與出站。設定時需要明確解析策略，不要同時依賴互相衝突的系統 DNS、瀏覽器 DNS 與用戶端 DNS。

以下是一段簡化的 Xray 風格 DNS 片段，用於說明伺服器清單與查詢策略的結構。具體位址與策略應依所在地網路調整。修改前應保留原有設定，並確認圖形用戶端在儲存設定時是否會重新產生該檔案。

{
  "dns": {
    "servers": [
      {
        "address": "1.1.1.1",
        "domains": [
          "geosite:geolocation-!cn"
        ]
      },
      {
        "address": "223.5.5.5",
        "domains": [
          "geosite:cn"
        ]
      }
    ],
    "queryStrategy": "UseIPv4"
  }
}

queryStrategy 控制返回的位址族。將其設為僅 IPv4 可用於驗證 IPv6 路徑是否異常，但不應未經測試就長期固定。若網路具備穩定的 IPv6，保留雙堆疊可以取得更合適的路徑；若 IPv6 只有位址而沒有可靠出口，網域解析出 AAAA 記錄後可能產生長時間等待。判斷依據應是系統路由與連通性測試，而不是只看網卡是否顯示 IPv6 位址。

分流 DNS 需要讓解析出口與存取出口在邏輯上保持一致。例如依規則直接連線的網域，通常使用能在直接連線網路中穩定存取的 DNS；代理網域則可由核心透過代理出口查詢。若先使用本地 DNS 取得區域化位址，再將存取送往遠端代理，目標可能返回不合適的內容節點；反過來，所有網域都透過遠端解析，也可能讓本地服務解析到不必要的遠端位址。規則應以實際存取路徑為準。

如果只有少量網域異常，可先使用明確的網域規則與指定 DNS 進行最小驗證，不要立即重寫整套 DNS。確認規則有效後，再擴大到 geosite 分類。資料庫更新後也要檢查規則名稱是否仍存在，以及用戶端是否載入正確檔案。有關資料檔案位置、載入機制與更新後的驗證方法，可閱讀GeoIP 與 GeoSite 資料庫如何更新。

最終驗證應包含系統查詢、用戶端日誌與實際存取三部分：查詢結果是否穩定，日誌是否顯示預期的 DNS 伺服器與出站，瀏覽器是否連線至對應位址。三者一致才表示解析鏈路清晰。若日誌中完全看不到目標網域的 DNS 請求，表示查詢可能發生在核心之外，應回到系統、瀏覽器或 TUN 接管設定繼續定位。

系統代理本質上是向作業系統寫入代理位址與連接埠，只有主動讀取這些設定的應用程式才會使用。用戶端顯示「系統代理已開啟」，並不表示所有程序流量都被接管。瀏覽器通常支援系統代理，部分命令列工具、遊戲、商店程式與使用自有網路堆疊的軟體可能會忽略它。遇到某個應用程式未生效時，先確認其他應用程式是否正常，再判斷是系統設定寫入失敗，還是目標應用程式沒有使用系統代理。

核對本地入口與系統設定

在 v2rayN 中記錄 HTTP 與 SOCKS 入站連接埠，然後查看系統代理是否指向 127.0.0.1 與正確連接埠。連接埠不能被其他程式佔用，也不能誤填為遠端節點連接埠。使用前一章的 netstat 命令確認監聽程序，再用明確代理參數進行測試。明確代理成功而瀏覽器失敗，表示核心與節點正常，問題集中在系統代理寫入、瀏覽器政策或擴充功能。

curl.exe -x http://127.0.0.1:10809 https://example.com/
curl.exe --socks5-hostname 127.0.0.1:10808 https://example.com/

第一個命令透過 HTTP 代理測試，第二個命令透過 SOCKS5 並讓代理端解析網域。兩個連接埠都必須依用戶端實際設定替換。HTTP 成功、SOCKS 失敗時檢查 SOCKS 入站；SOCKS 成功、HTTP 失敗時檢查 HTTP 入站或混合連接埠。兩者都成功而目標應用程式未生效，通常表示應用程式沒有讀取系統代理，或應用程式內部設定覆蓋了系統設定。

瀏覽器代理擴充功能可能覆蓋系統代理。排查時暫時停用擴充功能，並關閉所有瀏覽器程序後重新開啟。部分瀏覽器的安全 DNS 會獨立發起解析，即使 HTTP 流量經過系統代理，DNS 仍可能走另一條路徑，造成網域解析差異。企業政策、家庭安全軟體與網路過濾程式也可能改寫代理設定，應檢查系統設定是否在開啟後立即被還原。

區分系統代理與 TUN

系統代理適合支援 HTTP 或 SOCKS 代理的應用程式，修改範圍清晰，發生問題時容易回復。TUN 模式透過虛擬網卡與路由接管更多流量，適合不讀取系統代理的程式，但會引入 DNS 劫持、路由優先順序、MTU 與驅動相容性問題。不要因為單一應用程式忽略系統代理就立即長期啟用 TUN，先檢查該應用程式是否提供獨立代理設定；確實需要全域接管時，再依最小設定啟用 TUN。

TUN 開啟後完全斷網，應先關閉系統代理，避免兩條接入路徑重疊，再檢查虛擬網卡是否建立成功、預設路由是否寫入、區域網路網段是否被錯誤代理。遠端桌面、區域網路共用與路由器管理位址應保留直接連線規則，否則啟用 TUN 後可能失去本地連線。若存在其他虛擬網卡，應檢查路由優先順序，尤其是容器、虛擬機器與企業網路軟體建立的介面。

如果退出用戶端後仍無法瀏覽，請進入系統網路設定關閉手動代理，並檢查自動設定指令碼是否仍指向舊位址。接著重新開啟瀏覽器。若代理設定不斷自動恢復，請檢查啟動項目與其他網路工具。v2rayN 中也應使用「清除系統代理」，而不是只關閉視窗，因為關閉視窗可能只是最小化至系統匣，核心仍在執行。

完成修復後，分別驗證一個遵循系統代理的瀏覽器、一個帶有明確代理參數的命令列請求，以及原先異常的應用程式。三者結果可以說明問題位於系統設定還是應用程式本身。關於三種代理方式的流量範圍與選擇，可繼續查看系統代理、全域模式與繞過中國大陸模式的差異。

用戶端視窗關閉、核心程序退出與介面無回應是三類不同問題。視窗崩潰可能與圖形執行庫、設定資料庫或介面元件有關；核心退出通常由產生的設定無效、連接埠衝突、核心檔案無法執行或系統權限造成；介面無回應則可能是大量節點、日誌重新整理、訂閱解析或安全軟體掃描造成。排查前先確認退出的是圖形用戶端還是核心程序。

保存日誌與重現條件

不要在首次崩潰後立即清空設定或反覆重裝。先記錄崩潰發生的操作，例如啟動核心、更新訂閱、開啟設定、切換 TUN 或匯入設定。保存用戶端日誌、核心日誌與系統事件時間點，並記錄當時使用的路由模式與節點類型。可重複重現的問題比偶發崩潰更容易定位；若每次都在同一操作發生，優先檢查該操作讀取的設定或系統元件。

v2rayN 啟動後核心立即退出時，先關閉系統代理，避免本地連接埠失效造成斷網。查看核心輸出的第一個錯誤，常見類別包括 JSON 語法錯誤、欄位類型不正確、路由標籤不存在、入站連接埠被佔用與檔案存取失敗。後續大量重試訊息通常只是結果。若使用圖形介面產生設定，可切回預設路由與預設 DNS，再選擇一個一般訂閱節點，判斷是否由自訂設定引起。

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

以上片段展示一個合法的 SOCKS 入站結構，可用於對照欄位類型與 JSON 標點，不是完整的出站設定。JSON 不允許尾隨逗號，字串必須使用雙引號，連接埠應為數字。手動設定驗證失敗時，先恢復用戶端自動產生的設定，不要在多個位置重複編輯。圖形用戶端可能在啟動時覆蓋暫存檔案，直接修改產生的檔案通常不會成為長期設定。

連接埠、權限與執行環境

連接埠衝突會使核心無法監聽。使用 netstat -ano 查到佔用程序後，應確認該程序用途，而不是直接結束所有網路程序。可以在用戶端中調整本地入站連接埠進行驗證。若新連接埠可以啟動，表示原連接埠已被佔用；接著決定保留新連接埠，或關閉衝突程式。修改連接埠後，系統代理與應用程式內代理位址也必須同步，否則仍會連線至舊連接埠。

桌面用戶端依賴對應的執行環境。視窗完全無法開啟、系統事件記錄出現執行庫錯誤時，應根據Windows 安裝包頁面重新確認桌面版與經典 WPF 版的適用條件。不要混用不同目錄中的程式檔案與設定檔，也不要只覆蓋部分檔案。更新時先正常退出用戶端與核心，保留設定備份，再將新安裝包放到獨立目錄測試。

安全軟體可能阻止核心建立程序、監聽本地連接埠或建立虛擬網卡。處理時應查看攔截記錄與檔案來源，再以最小範圍放行必要程式。不要長期關閉所有系統防護。若用戶端在一般模式正常、TUN 模式崩潰，重點檢查虛擬網卡驅動、系統管理員權限與其他網路過濾驅動；若只有更新訂閱時無回應，檢查節點數量、篩選運算式與訂閱返回內容。

設定檔損壞時，可先備份原目錄，再建立全新的設定，讓用戶端產生預設檔案，然後手動加入一個節點進行測試。若新設定正常，逐項遷移訂閱、路由與設定，不要直接複製整個舊目錄。遷移到某一項後再次崩潰，即可確定問題來源。若新設定仍然崩潰，則檢查執行環境、權限、圖形驅動與系統日誌。

完成故障處理後，需要驗證冷啟動、更新訂閱、切換節點、開啟系統代理與正常退出五個操作。正常退出後確認系統代理已清除，重新啟動後確認設定能夠讀取。只有一次連線成功，不能證明設定資料庫與退出流程都正常。Windows 安裝與執行環境的完整檢查可參考v2rayN Windows 安裝設定完整流程。

Android 上的 v2rayNG 與 v2flyNG 透過系統 VPN 介面接管流量，故障除了節點設定外，也常與背景限制、私人 DNS、電池策略、網路切換及其他 VPN 應用程式有關。v2rayNG 使用 Xray 核心，v2flyNG 使用 v2fly 核心；兩者可用於比較不同核心的相容性，但同一時間只能保留一個作用中的 VPN 連線。排查時先完全停止另一個用戶端，不要只將介面切到背景。

連線按鈕顯示成功但應用程式無法存取

先觀察狀態列中的 VPN 標誌是否出現，再檢查用戶端日誌是否建立本地 VPN 介面。標誌沒有出現，通常是系統授權未完成、已有 VPN 佔用或用戶端遭系統阻止；標誌存在但所有應用程式都斷網，應檢查節點、DNS 與路由；只有部分應用程式異常，則檢查分應用代理、繞過清單與應用程式本身的專用網路設定。

分應用代理設定容易因模式理解錯誤而造成相反結果。「僅代理所選應用程式」與「繞過所選應用程式」的含義相反，更新應用程式或重新安裝後，應用程式識別項也可能改變。排查時先關閉分應用功能，讓所有應用程式使用同一路徑；基本連線正常後，再逐一加入清單。若啟用後某個應用程式仍直接連線，應確認它是否使用獨立程序、系統元件或內嵌服務。

Android 的私人 DNS 可能與用戶端 DNS 接管衝突。症狀包括節點顯示連線成功、網域請求長時間等待，但直接存取部分 IP 正常。可暫時將私人 DNS 恢復為自動，再重新連線用戶端進行測試。若問題消失，應決定由系統私人 DNS 還是用戶端負責解析，不要讓兩者形成不清楚的串聯。瀏覽器本身仍可能啟用安全 DNS，也需要單獨檢查。

背景斷線與網路切換

鎖定螢幕後斷線通常與電池最佳化、背景活動限制或系統清理有關。允許正在使用的用戶端在背景執行，並檢查省電模式是否限制 VPN。不同裝置的設定名稱各異，但核心目標一致：允許用戶端與核心程序在鎖定螢幕後維持網路。不要同時為多個同類用戶端開啟自動啟動與常駐，它們可能爭用 VPN 權限並增加狀態混亂。

從 Wi-Fi 切換至行動網路後，原有連線的本地位址與路由會改變。部分節點能夠自動重新連線，其他連線則會停留在舊網路。遇到切換後沒有流量時，可在用戶端中停止連線，等待系統網路穩定後重新啟動。若頻繁發生，查看日誌是否出現網路不可用、介面關閉或 DNS 逾時。把「切換網路後失敗」與「固定網路持續失敗」分開記錄，兩個問題的處理方向不同。

訂閱更新失敗時，應先確認瀏覽器在目前網路能否開啟訂閱請求，再查看用戶端更新日誌。行動網路可能對背景資料、漫遊資料或省流量模式有所限制。訂閱成功但節點無法連線，請依本手冊的逾時章節核對位址、連接埠、TLS 與傳輸欄位。對於 2015 年後的主流裝置，通常優先選擇 arm64 安裝包；無法確認架構時可使用通用版，具體入口請見Android 用戶端下載。

v2rayNG 與 v2flyNG 的核心支援範圍不同。某個節點在 v2rayNG 中可用、在 v2flyNG 中失敗，不應直接歸因於網路，先比較協定與傳輸欄位是否受對應核心支援。對照測試必須使用相同網路、相同節點、相同 DNS 條件，並完全停止另一個用戶端。若兩個用戶端都失敗，再檢查節點與系統網路；若只有一個失敗，保存該用戶端的第一個核心錯誤，用於判斷相容性。

行動端最終驗證應包含前景存取、鎖定螢幕後恢復、Wi-Fi 與行動網路切換、訂閱更新及分應用規則。每一步單獨測試，避免一次變更所有系統設定。若基本連線已穩定，再恢復私人 DNS、省電策略與應用程式清單；恢復某項後問題重現，即可確定衝突來源。仍未完成首次訂閱匯入的使用者，應返回快速上手教學依主流程設定，避免將初始化遺漏誤判為執行故障。