問題診斷 / 依症狀查找

V2Ray 疑難排解手冊

連線、訂閱、DNS 與代理設定：先找出故障環節，再調整對應參數。

本頁是系統化查閱手冊，不必從頭讀到尾。首次安裝與匯入請先依照入門指南操作；設定已完成但結果不如預期時，請依下方症狀前往相關章節。桌面端以 v2rayN 為主，Android 端則分別說明 v2rayNG 與 v2flyNG。不同介面的選單名稱可能略有差異，請以功能和實際監聽值為準。

診斷紀錄 · 每次只變更一項條件

建議記錄：發生時間、網路類型、目前使用的用戶端、代理模式、目標應用程式，以及同一時間的錯誤日誌。先保留修改前的設定截圖，再執行一次可重現的請求。

只截取故障前後相關的日誌行。分享前請刪除訂閱網址、伺服器位址、使用者識別資訊、密碼和連線連結；不要公開完整設定檔。

無法上網：先分辨本機入口與遠端連線

「已啟動」只代表用戶端嘗試執行，不表示瀏覽器流量已進入代理，也不代表已連上遠端伺服器。先釐清現象：是所有應用程式都無法連線，還是只有一個瀏覽器？是所有網站都打不開，還是只有特定類型的目標失敗？關閉代理後，一般網路連線能否恢復？依此可將問題分為基礎網路、本機監聽、應用程式接入與遠端連線四個環節，避免一開始就更換所有節點。

建立不經代理的對照測試

在 v2rayN 中先清除系統代理，並確認 TUN 已關閉，再用瀏覽器連線平常可直接存取的網站。如果仍無法連線，請檢查 Wi-Fi 是否需要登入驗證、系統時間是否正確，以及網路介面卡是否已取得 IP 位址。公共網路通常須先直接開啟認證頁面；完成驗證前測試節點，只會得到一堆難以判讀的逾時結果。不要把基礎網路問題當成訂閱故障處理。

確認直連正常後，還原一組已知可用的設定，暫時只保留一種接入方式。桌面端可先使用系統代理，不啟用 TUN，也不要同時執行其他代理程式。前往「參數設定」檢查本機監聽連接埠，再從執行日誌確認核心已啟動。如果介面顯示的連接埠與日誌不一致，請以此次成功啟動後的實際監聽資訊為準；連接埠並非固定值，修改後也要同步更新手動設定代理的應用程式。

以明確指定代理的請求，區分兩段連線

以下 Windows 指令會明確指定 HTTP 代理入口，適合確認「應用程式是否未使用系統代理」。範例假設目前 HTTP 或混合監聽連接埠為 10808；若設定不同，請先替換連接埠。此指令不適用於只提供 SOCKS 的入口。測試目標也應選擇目前網路可存取且回應穩定的 HTTPS 網站。

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

若顯示無法連線至本機代理，請先處理核心未啟動、連接埠填錯或連接埠遭占用等問題。若已連上本機代理，之後才出現遠端連線或 TLS 錯誤，請繼續查看下一章。明確指定代理的請求成功、瀏覽器卻失敗時，應優先檢查瀏覽器的獨立代理設定、擴充功能與應用程式快取，不必立刻修改伺服器設定。這種對照測試比只看系統匣圖示可靠，因為它確實經過本機入口。

檢查路由是否將請求送往錯誤出口

前往「路由設定」，確認目前選用的規則集符合預期。若某個目標被規則送往直連，即使伺服器正常，也可能出現與代理失效相同的現象。可暫時使用規則較少的測試設定，只確認目標能否透過代理存取，驗證後再還原原有分流。不要長期擴大代理範圍來掩蓋規則錯誤，否則之後很難判斷是哪條規則生效。

若只有特定應用程式出問題，請確認該應用使用 HTTP、SOCKS，還是自有的連線方式。系統代理通常不會自動涵蓋所有程式，也不保證接管所有 UDP 流量。先查看應用程式是否支援手動指定代理，再決定是否需要 TUN。若只有啟用 TUN 後才失敗，請記錄虛擬網卡、權限與路由的變化，並依照TUN 模式說明重新檢查，不要同時修改 DNS 與節點。

最後將結果整理成一句可重現的描述，例如「直連正常，明確指定 HTTP 代理成功，瀏覽器失敗」。這樣已將排查範圍縮小至應用程式接入層。若「直連正常、本機連接埠可連線，但所有遠端請求都失敗」，才需要檢查節點與傳輸參數。復原後請儲存有效設定並移除臨時測試規則，避免下次啟動又切回有問題的方案。

節點逾時：分辨連接埠、交握與目標網站故障

逾時表示在限定時間內沒有收到預期回應，但無法據此判斷卡在哪個環節。連線至伺服器連接埠、建立加密傳輸、通過身分驗證，以及由伺服器連線至目標網站，都可能各自逾時。先在執行日誌中找出此次請求的第一筆相關錯誤，不要只看最後一行「失敗」。記錄錯誤發生前是否已建立連線，以及失敗是否只與特定目標或網路類型有關。

先確認能否連上伺服器入口

開啟目前伺服器的編輯視窗，核對提供方給的位址與連接埠。複製位址時請留意前後空格，不要把完整網頁網址填進伺服器位址欄，也不要將訂閱網址當成節點位址。網域名稱與連接埠應分開填寫。若訂閱內容近期有變動，請先更新對應群組，再重新選取有效項目；手動修改舊項目後，下一次更新訂閱時不一定會保留。

在 Windows 中可用以下指令測試伺服器的 TCP 入口。範例網域僅用來說明指令語法，執行時請換成目前節點的實際位址與連接埠，並避免公開分享替換後的指令。測試失敗表示本機無法連上該 TCP 入口；測試成功則只能證明連接埠可連線，無法確認協定、使用者識別資訊或傳輸參數正確。採用其他傳輸方式的設定，也不能只靠這項測試完成驗證。

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

若多個節點只在同一個網路中失敗，可換到另一個可信任的網路，使用同一組設定再次測試。不要同時更換網路與節點，否則無法判斷是哪個變數造成差異。若某一台伺服器在所有網路中都失敗，其他伺服器卻正常，請向設定提供方確認入口狀態。頻繁縮短測試間隔不會增加逾時資訊，反而可能觸發連線限制；適度間隔後再測一次即可。

連接埠可通後，再核對傳輸與安全參數

TCP 入口正常但日誌出現交握錯誤時，請逐項核對協定、傳輸類型、TLS 設定與伺服器名稱。WebSocket 的路徑與 Host、gRPC 的服務名稱、REALITY 的公鑰與短識別碼，都必須與伺服器端設定相符；連接埠相同不代表參數可以互換。路徑的大小寫與開頭斜線也可能影響比對，建議重新匯入完整連線資訊，不要靠猜測補齊欄位。

裝置時間不正確也會影響憑證有效期判斷或部分驗證流程。請先啟用系統自動校時，再檢查日誌中的憑證名稱、有效期與信任鏈提示。不要將「略過憑證驗證」當成日常修復方式；這會跳過本應發現的問題，也無法修正伺服器名稱設定錯誤。若伺服器憑證本身異常，應由服務維護方修復；用戶端只需填入正確的連線參數。

依不同錯誤判斷排查方向

日誌線索	常見含義	優先檢查項目
`connection refused`	連線遭主動拒絕	目標連接埠、監聽服務、防火牆拒絕規則
`i/o timeout`	某段讀寫等待逾時	錯誤關聯位址、發生階段、目前網路
`certificate`	憑證驗證失敗	系統時間、伺服器名稱、憑證鏈
`EOF`	對端提早結束連線	傳輸類型、身分驗證、伺服器端日誌

這些關鍵字並不能直接對應唯一的診斷結論。例如讀寫逾時可能發生在目標網站一側，對端提早結束連線也可能是中間網路設備造成。必須搭配前後日誌與對照測試判斷。若已連上伺服器，但只有單一網站無法存取，請檢查該網站的路由與伺服器端存取條件；不要只因目標網站一次異常，就認定整個節點失效。

伺服器清單中的延遲測試，可能使用不同目標與連線方式。連接埠測試成功但實際連線測試失敗，通常表示還需要檢查協定之後的連線環節。詳情請參閱節點延遲與下載速度測試說明。回報給維護方時，請提供發生時間、協定類型、錯誤階段與已完成的網路對照，不要傳送完整憑證，才能讓對方更容易提出可執行的建議。

訂閱失敗：分別檢查請求、解析與群組顯示

更新訂閱包含三個獨立步驟：用戶端下載網址內容、解析回應並轉成伺服器項目，再寫入指定訂閱群組。介面顯示「失敗」時，請先確認是哪個步驟出錯。請求失敗通常與網路、網址或憑證有關；解析失敗通常是回傳了網頁或不相容的格式；更新成功卻看不到項目，則可能只是選錯群組。反覆點選更新通常不會改變這些條件。

核對網址與更新時使用的網路

在 v2rayN 中前往「訂閱分組設定」，編輯目標群組並確認網址已完整儲存。訂閱連結可能包含存取憑證，請從可信任來源完整複製，不要手動拼接，也不要在公開截圖中顯示。聊天軟體加入的換行、複製到結尾的中文標點，以及已過期的存取參數，都可能使程式請求看似相近、實際不同的網址。先儲存，再更新該群組。

確認目前介面提供的是「透過代理更新」還是「不經代理更新」，或查看功能相同的設定。如果現有節點已失效，而訂閱更新又指定必須透過這些節點，就會形成無法自行恢復的循環。此時先測試訂閱網址能否直連取得；若提供方要求使用可用代理存取，則須保留一組已知可用的連線作為更新通道，不要清空清單來解決。

瀏覽器能開啟訂閱網址，也不能直接證明用戶端一定讀得到內容。瀏覽器可能使用其他代理、保留登入狀態，或經過網頁驗證。請檢查用戶端日誌中的回應狀態：未授權或禁止存取通常需要重新確認帳戶與連結權限；找不到資源時請核對網址；伺服器錯誤則稍後重試並聯絡提供方。不要把這些回應一概歸咎於用戶端核心。

請求成功後，確認內容是否可辨識

網路回應成功，內容仍可能是登入頁、提示頁或網路驗證頁，而非節點資料。若日誌顯示沒有有效伺服器、解析失敗或不支援格式，請先向訂閱提供方確認該網址適用於哪類圖形介面用戶端。網頁上的訂閱說明不等於真正的訂閱內容入口；某些專用設定格式也無法直接匯入為通用連線清單。

不建議將完整訂閱內容貼到線上轉換頁面排查，因為其中可能包含所有存取憑證。請先在本機確認回應內容的類型，必要時只向維護方說明「回傳網頁」或「無法辨識的設定格式」。若手邊也有單筆連線連結，可先使用用戶端的剪貼簿匯入功能測試一筆；單筆可用但訂閱失敗，表示應聚焦檢查訂閱取得方式與格式，不必重新排查所有網路設定。

更新成功但清單空白或出現重複項目

返回伺服器清單，檢查目前的訂閱群組、搜尋框與篩選條件。更新其他群組，不代表目前檢視畫面會自動顯示其中所有內容；舊的關鍵字篩選有時仍在生效。確認群組儲存的是此次編輯的網址，而非名稱相近的其他項目。若同一網址建立了多個群組，請先核對內容再刪除重複群組，避免誤刪唯一有效的來源。

更新訂閱後若伺服器名稱或排序改變，原本選取的項目可能已被替換。請重新選取有效項目，再測試連線。手動修改過的伺服器參數也可能被訂閱更新覆蓋，因此個人化調整應放在獨立群組並註明來源。若問題是自動更新後才發生，記錄更新前後的時間與項目變化，比只說「更新後不能用」更有助於排查。

若只有自動更新失敗、手動更新正常，請檢查電腦休眠狀態、啟動順序與更新時的網路狀態。用戶端啟動時可能尚未連上網路，也可能在代理核心就緒前便已發出請求。先透過手動更新確認連線，再調整更新時機，避免把排程條件問題誤認為格式問題。Android 端還須考量背景執行限制，相關流程請見本頁末章。

首次設定可依照匯入訂閱步驟重新確認操作順序；概念問題可參閱常見問題。回報訂閱問題時，只需提供狀態碼、錯誤類型與群組操作流程，並隱藏完整網址及存取參數。修復後請驗證一次訂閱更新、一次伺服器選取與一次實際請求，三者都正常才算完成排查。

速度慢：分辨延遲、傳輸量與應用程式等待

「慢」至少包含三種情況：點選後要等很久才開始載入、開始傳輸後速度持續偏低、播放或會議期間反覆中斷。第一種常與 DNS 解析及建立連線有關，第二種較接近可用頻寬與壅塞，第三種可能涉及抖動、封包遺失或應用程式流量未正確接管。先記錄是哪一種，再選擇測試方式；只依清單上的單一延遲數字排序，很容易選到不適合目前用途的伺服器。

讓兩次測試具備可比性

使用同一台裝置、同一個目標與同一種代理模式，暫時關閉其他高流量工作。先測試一個節點，再只切換節點進行複測，避免同時更換路由與 DNS。下載大型檔案會消耗實際流量，也可能影響其他使用者，不必為了比較而長時間重複測試。觀察連線建立時間與穩定傳輸階段即可；瀏覽器命中快取後瞬間完成，不代表遠端連線真的比較快。

先檢查本機 Wi-Fi 品質與裝置負載。距離無線基地台太遠、頻段壅塞或系統正在同步檔案，都可能拖慢所有連線。可用同一網路中能直接存取的服務作為對照；若直連速度也明顯變慢，應先處理基礎網路。條件允許時，可改用有線連線測試一次。這不是要求長期使用有線網路，而是藉此排除無線連線這個變數。

延遲低，不代表大量傳輸速度快

連接埠連通測試主要反映建立連線所需時間；實際連線測試還會受到代理交握與測試目標影響；下載速度測試則較能顯示頻寬與壅塞。三者衡量的項目不同，不應期待數值完全一致。遠端線路的往返時間可能較長，但傳輸量穩定；也可能很快建立連線，卻在尖峰時段壅塞。選擇會議或互動應用程式時，應重視穩定性；長時間下載則還要觀察傳輸期間的表現。

若同一節點只在特定網站速度慢，請檢查目標網站本身、內容傳遞路徑與命中的路由。伺服器所在網路連往目標網站的路徑，與本機連往伺服器的路徑並不相同。可改用另一個穩定目標複測，或切換另一個節點存取相同目標；不要只因一個網站反應異常，就重設所有設定。測試方式的說明請參閱TCPing、實際連線與下載速度測試的差異。

檢查接入方式、分流與資源使用狀況

查看執行日誌，確認速度慢的請求是否走預期的出口。範圍過大的規則可能把目標送往不合適的路徑，也可能只有網頁使用代理，下載元件卻走獨立連線。特別是應用程式內的更新工具、媒體元件與命令列工具，未必會遵循同一套系統代理設定。先為應用程式明確設定支援的代理；確實需要接管流量時再測試 TUN，不要把擴大接管範圍當成通用加速方法。

桌面端同時啟用多層代理、虛擬網路與安全軟體掃描，可能增加額外處理。可逐一關閉重複元件進行短時間對照，但不要直接停用所有系統防護。觀察用戶端與核心的 CPU、記憶體使用量；若請求期間處理器持續繁忙，請檢查是否有大量重複連線或日誌寫入。除錯結束後請恢復一般日誌等級，避免長時間記錄詳細連線資訊，增加磁碟與隱私負擔。

只有在特定網路中出現「大型請求卡住、小型請求正常」時，才進一步考慮路徑 MTU 或分段問題。先比較系統代理與 TUN 的表現，確認現象可重現，再依用戶端支援的設定小幅調整。隨意填入過小的 MTU 會降低效率，也可能掩蓋其他故障。不要照抄號稱通用的參數；修改前先記錄原值，測試無改善就還原。

最後確認是否把 DNS 等待誤當成速度慢。若首次存取很慢、後續請求明顯正常，應重點記錄解析與建立連線階段；若整個下載過程都很慢，再檢查壅塞與連線穩定性。保留相同條件下的對照結果，不必公開具體伺服器資訊。恢復後請逐一撤銷臨時變更，只保留經複測證明有效的設定，避免累積難以解釋的「最佳化參數」。

DNS 問題：確認由誰解析，以及查詢走哪條路

DNS 故障常見的表現包括網域無法開啟、首次載入等待很久，或同一目標在不同應用程式中得到不同結果。不要只因瀏覽器顯示解析錯誤，就立刻更換所有 DNS 位址。一次存取可能經過作業系統快取、瀏覽器安全 DNS、代理核心解析或遠端伺服器解析；請先釐清目前請求在哪一層解析，再決定要修改哪個設定。否則新設定可能根本未被該應用程式使用。

系統解析結果不等於完整的代理連線結果

先查看日誌中報錯的是哪個網域：可能是目標網站、伺服器位址，也可能是 DNS 服務本身的網域。伺服器使用網域名稱時，核心必須先解析位址才能連上代理；這一步失敗會影響所有代理請求。若是目標網域解析失敗，則可能只影響部分網站，兩者的處理順序不同。請記錄錯誤中各網域的用途，不必公開實際位址。

Windows 可使用以下指令查看系統目前的解析結果。這適合確認系統 DNS 是否能回應，以及回應是否來自預期的伺服器，但無法證明瀏覽器或代理核心使用相同結果。即使成功取得位址後仍無法連線，問題也可能出在路由、目標連接埠或傳輸交握，不應把所有錯誤都歸因於 DNS。

Resolve-DnsName example.com

若要測試遠端解析，可使用 SOCKS 的網域轉送方式，讓代理連線接收網域名稱，而非先在本機解析成位址。以下假設目前 SOCKS 或混合入口為 10808。若入口只支援 HTTP，請改用適合該入口的測試方式，不要把協定不相符造成的錯誤誤判為解析失敗。

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

加密 DNS 也需要先有可用的連線路徑

使用 HTTPS 型 DNS 時，DNS 服務本身也必須能連線，其網域可能還需要引導解析。如果強制讓解析服務的連線經過尚未成功建立的代理，就可能形成循環依賴：代理等待伺服器解析，解析又等待代理連線。請先確保伺服器位址可基本解析，且 DNS 服務有可用的連線路徑，再新增分流策略；不要一次疊加多個彼此依賴的解析入口。

在 v2rayN 中檢查目前核心對應的 DNS 設定，並區分一般代理與 TUN 情境。不同核心的設定欄位不一定相容，不能直接將一份設定中的 DNS 區段貼到另一種核心。建議使用介面提供的設定入口，確認儲存後核心已重新載入。若修改的是未選用的設定檔，介面上看似已變更，實際執行的仍是舊方案。

一併檢查解析與路由比對

網域規則需要保留請求中的網域資訊，IP 規則則依賴目標位址與資料檔案。瀏覽器先行解析、應用程式只提交 IP，或流量探測未取得網域等情況，都可能讓網域規則無法比對。Sniffing 可為部分連線補充可辨識的目標資訊，但無法涵蓋所有協定，也不能取代 DNS。請先觀察請求包含哪些資訊，再檢查命中的規則，避免把「沒有取得網域」誤判為規則語法錯誤。

以下是 Xray 風格的路由規則片段，用來說明網域與 IP 條件的寫法，並非完整的用戶端設定。此範例需要可用的 geosite、geoip 資料，以及已定義的 direct 出站。兩種條件分開寫成兩條規則，比較容易觀察比對過程。不要用片段覆蓋完整設定檔；在圖形介面中應使用路由編輯功能建立對應規則。

{
  "rules": [
    {
      "type": "field",
      "domain": ["geosite:cn"],
      "outboundTag": "direct"
    },
    {
      "type": "field",
      "ip": ["geoip:private"],
      "outboundTag": "direct"
    }
  ]
}

資料檔案遺失、標籤拼錯或規則順序不合適，都可能導致非預期的出口。更完整的規則順序請參閱geosite 與 geoip 分流說明。排查時只暫時調整與目標相關的規則，不要為了解決單一解析問題而刪除整套分流；請保留原始設定，方便驗證後還原。

修改後請關閉瀏覽器舊分頁或重新啟動相關應用程式，必要時再清除系統 DNS 快取。清除快取只是讓新請求重新查詢，無法修正錯誤的伺服器位址或循環依賴。若只有瀏覽器異常，請檢查其安全 DNS 是否繞過系統設定；若只有 TUN 異常，請檢查虛擬網路中的 DNS 路由。最後同時驗證一般網域與目前伺服器網域，確認基礎連線和目標存取都已恢復。

系統代理無效：檢查應用程式是否連上本機入口

系統代理是一組供應用程式讀取的網路設定，不代表系統中的所有流量都會被強制接管。v2rayN 已設定系統代理，但某個應用程式仍直接連線，可能是因為它不讀取系統設定，也可能有獨立代理、環境變數或其他軟體覆蓋入口。先用明確指定代理的請求驗證核心，再確認系統設定是否已寫入，最後檢查目標應用程式。依此順序排查，可避免將接入問題誤判為節點故障。

核對實際連接埠與監聽位址

在「參數設定」中查看本機監聽位址、HTTP 或混合連接埠，並確認執行日誌沒有顯示啟動失敗。系統代理指向的位址應與此入口一致。單一裝置使用時通常指向回送位址；「允許區域網路連線」會影響其他裝置能否存取本機入口，並非修復本機代理的必要選項。不要為了讓瀏覽器正常運作而擴大監聽範圍，尤其是在公共網路中。

若曾修改連接埠，請先清除舊的系統代理設定，再套用目前設定，接著關閉並重新開啟目標應用程式。部分程式只會在啟動時讀取代理設定，舊連線也可能繼續沿用原路徑。請用工作管理員確認程式已完全結束，而不只是關閉視窗。若明確指定新連接埠後可以連線，但系統代理模式仍失敗，請優先檢查殘留設定與應用程式自身策略，不必再次修改伺服器。

依平台檢查設定的實際生效位置

平台	檢查位置	容易忽略的情況
Windows	設定 → 網路和網際網路 → Proxy	應用程式可能使用獨立設定或其他網路介面
macOS	系統設定 → 網路 → 目前的網路服務 → 詳細資訊 → Proxy	設定會依目前使用的網路服務而異
Linux	目前桌面環境的網路代理設定	桌面設定與終端機環境變數可能互相獨立

Windows 的使用者代理設定，可能與部分系統服務採用的網路設定不同。因此瀏覽器正常、背景服務失敗，不一定代表用戶端故障。不要為了單一服務貿然修改全域網路設定；請先確認該應用程式是否提供自己的代理入口。macOS 切換網路服務後，應重新檢查目前使用的服務，而非只查看先前連線的項目。

Linux 中，圖形應用程式、桌面工作階段與終端機程序可能各自讀取不同設定。終端機環境中的 HTTP_PROXY、HTTPS_PROXY 與 ALL_PROXY 也可能保留舊位址；大小寫變數的處理方式則依程式而異。請先使用明確指定代理的參數測試，再檢查目前程序繼承的環境變數，清除舊值後重新啟動終端機。不要讓所有變數同時指向不同協定的連接埠，否則更難判斷實際使用哪一個。

排除設定遭覆寫與代理迴圈

瀏覽器代理擴充功能、其他代理用戶端與網路管理工具，可能反覆寫入系統代理。關閉重複工具後，觀察位址是否仍自動變更。只保留一個負責管理系統代理的程式，避免兩個程序互相覆寫。若用戶端退出後網路仍異常，請先確認核心是否仍在背景執行，再使用「清除系統代理」；若程式已無法啟動，可到系統設定中手動移除指向失效本機連接埠的設定。

代理迴圈則是另一種問題：應用程式請求進入代理後，核心的出站連線又被送回入口，最後造成重複連線或資源持續升高。啟用 TUN 與其他系統層級代理元件時，尤其要留意排除路徑。請先退回僅使用系統代理的最精簡設定，確認正常後再逐項恢復流量接管功能。不要只靠不斷更換連接埠掩蓋迴圈，因為路由循環本身並未改變。

若應用程式明確使用自有網路堆疊，請依其說明填入 HTTP 或 SOCKS 入口，並留意 SOCKS 與 HTTP 的位址格式不可互換。部分即時通訊功能也會使用 UDP，網頁能開啟不代表語音連線也已接管。複測時請同時觀察應用程式表現，以及用戶端日誌中是否出現對應請求；若日誌沒有請求，這是重要線索，表示應先檢查接入，而非伺服器端。

復原後請記錄「哪項設定負責哪個應用程式」，並清除不再使用的舊設定。首次選擇模式可返回入門指南；分流相關判斷請參閱路由設定步驟。保留一組明確指定代理的測試指令作為基準，下次系統更新或切換網路後，就能快速判斷問題出在應用程式層還是連線層。

用戶端閃退：分開處理介面退出與核心失敗

「打不開」時，請先區分兩種程序層級：是圖形介面本身無法執行，還是介面可以開啟，但代理核心啟動後立即退出？前者多與程式檔案、執行環境、使用者資料或權限有關；後者通常可從核心錯誤日誌找到設定、連接埠或檔案路徑線索。不要一看到啟動失敗就刪除整個使用者目錄，訂閱、路由與本機設定可能都存放其中；請先備份，再逐步隔離問題。

保留現場，確認啟動失敗的範圍

先記錄雙擊程式後的具體狀況：完全沒有視窗、視窗出現後立即關閉、程式留在背景，還是主介面顯示核心執行失敗。查看工作管理員或系統活動監視器，確認是否已有另一個執行個體。若舊程序仍占用檔案或連接埠，重複啟動可能產生新錯誤。請先正常結束舊程序再試；不確定用途時，不要結束名稱相似的系統服務。

若介面無法開啟，請查看程式自己的日誌目錄或系統應用程式錯誤紀錄，優先尋找檔案無法讀取、缺少相依元件或權限遭拒等線索。程式放在受限制的目錄、從壓縮檔暫存位置啟動，或檔案未完整解壓，都可能影響執行。請依下載中心選擇適用的平台與處理器架構，完成正常安裝或解壓縮流程後，再從固定目錄啟動；不要混用不同發行版本的程式檔案。

核心啟動失敗時，先查看第一筆錯誤

介面正常但核心退出時，請開啟執行日誌，從啟動時間往後查看第一筆包含明確欄位或位址的錯誤。後續的「程序結束」「連線失敗」通常只是結果。若連接埠遭占用，請確認具體監聽位址與連接埠；設定錯誤則需找出欄位層級；資料檔案錯誤則需確認路徑。詳細方法請參閱Xray 核心啟動失敗排查，不要只根據最後一行提示反覆重裝。

Windows 可用以下指令檢查範例連接埠是否遭占用。請將連接埠替換成日誌實際提示的數值，再依回傳的程序識別碼到工作管理員核對程式。若發現連接埠被占用，請優先關閉重複的用戶端，或替目前用戶端選擇未占用的連接埠，並同步更新系統代理及手動設定的應用程式。不要任意終止不明程序，也不要把變更連接埠後發生的應用程式連線失敗，誤認為新的伺服器故障。

Get-NetTCPConnection -LocalPort 10808 -ErrorAction SilentlyContinue |
  Select-Object LocalAddress, LocalPort, State, OwningProcess

手動編輯 JSON 後無法啟動，請檢查多餘逗號、缺少引號、括號層級與欄位型別。語法正確不代表設定一定可用：欄位可能不屬於目前核心、出站標籤可能未定義，規則引用的資料也可能不存在。盡量透過圖形介面修改，並使用用戶端支援的檢查功能；不要直接用網路上的獨立設定片段取代完整設定，尤其不要混用不同核心的結構。

以獨立資料目錄隔離使用者設定

若程式本身可以執行，但載入原有使用者資料後就閃退，可先備份，再使用用戶端支援的獨立目錄或設定隔離方式建立乾淨的測試環境。請先將原目錄重新命名保留，不要直接刪除。若乾淨環境正常，再分批還原訂閱、伺服器與路由，每還原一類就啟動驗證一次。這樣可以找出損毀資料或不相容設定，而不是把舊問題整批複製回來。

更新後出現故障時，請先確認新舊程式是否混放在同一路徑，以及系統實際啟動的捷徑指向何處。桌面版與 WPF 版的介面和執行相依元件不同，不應靠互換執行檔來切換。處理器架構也必須符合裝置規格。只有日誌明確指出缺少執行環境時，才依對應發行說明補齊相依元件；不要安裝來源不明、號稱能修復問題的元件。

若安全軟體隔離了某個程式檔案，請先確認檔案來源與偵測紀錄，再透過系統提供的還原與例外機制處理，不要直接關閉所有防護。回報給支援人員時，請提供作業系統平台、處理器架構、所選發行版本及第一筆錯誤，不要上傳完整使用者目錄。更多關鍵字說明請參閱執行日誌解讀。最後請同時確認介面能啟動、核心正常執行，且實際代理請求成功，避免只修好視窗卻漏掉連線問題。

Android 專項：VPN 權限、分應用程式代理與背景執行

Android 端建議優先使用 v2rayNG；使用 V2Fly 核心設定時，可選擇 v2flyNG。兩款用戶端的介面與核心選項並不完全相同，排查時請先確認目前使用哪一款，不要照著另一款用戶端的選單名稱逐字尋找。下載入口請見Android 用戶端下載。開始前請保留訂閱資訊，並記錄問題是在按下連線按鈕後立即發生，還是在鎖定螢幕、切換網路或啟動特定應用程式後才出現。

確認 VPN 授權與實際接管狀態

首次啟動連線時，系統通常會顯示 VPN 連線授權提示。只有同意授權並成功建立本機 VPN 介面後，用戶端才能接管相關應用程式的流量。狀態列圖示只表示介面已存在，不代表遠端伺服器可用；連線後仍須開啟目標網站進行實際驗證。若授權視窗沒有出現或一閃即逝，請先到系統的 VPN 設定中檢查既有設定與管理政策。

同一個使用者環境通常無法同時執行多個使用 VPN 介面的網路工具。其他 VPN、區域網路工具或使用本機 VPN 的過濾程式，都可能取代目前連線。請先全部中斷，只啟動一個用戶端測試。若系統設定了某個 VPN 永遠開啟，或啟用了封鎖未經 VPN 連線的功能，也要確認指定的應用程式正是目前使用的用戶端；設定錯誤可能導致 VPN 中斷後所有連線都被系統封鎖。

檢查分應用程式規則是否與預期相反

開啟用戶端的分應用程式或應用程式代理設定，確認目前清單代表的是「只代理已選取的應用程式」，還是「略過已選取的應用程式」。兩者含義相反，不能只看勾選數量判斷。若瀏覽器正常但另一個應用程式失敗，請先確認該應用程式是否在實際接管範圍內。新安裝的應用程式可能尚未加入清單；修改後應中斷並重新連線，讓系統 VPN 路由與應用程式範圍重新生效。

用戶端的本機監聽入口與系統 VPN 模式也要分開理解。只啟用本機代理服務，不一定能讓一般 Android 應用程式自動使用；反過來，VPN 接管正常時，也不必為每個應用程式再填寫本機代理。若同時啟用 Wi-Fi 的手動代理設定，可能造成重複路徑。請先還原用戶端預設的 VPN 使用方式，取消多餘的手動代理，再驗證節點本身。

依序處理鎖定螢幕後斷線與切換網路失敗

若前景使用時連線正常，鎖定螢幕一段時間後卻失效，請先檢查系統電池管理是否限制用戶端。依裝置提供的設定允許必要的背景執行，關閉針對該應用程式的過度省電限制，並保留連線通知。不同裝置的選單名稱不盡相同，可從應用程式資訊中的電池、背景活動與網路權限尋找。不要一開始就對所有應用程式放寬背景限制，只需調整負責連線的用戶端。

Wi-Fi 與行動網路切換後，舊連線可能仍沿用原本的網路狀態。請先中斷再重新連線，觀察是否恢復；若每次切換網路都會重現，請記錄切換前後的網路類型與日誌。公共 Wi-Fi 也可能需要先完成網頁驗證。數據節省模式、漫遊限制，或應用程式只允許特定網路的權限，都可能造成「在家正常、外出失敗」的現象，應與伺服器故障分開檢查。

若只有特定網路出現網域異常，請核對系統的私人 DNS 設定與用戶端內部 DNS 設定。兩者不一定使用同一條連線路徑，不能假設關閉其中一項就會自動啟用另一項。先記錄原設定，暫時改回由系統自動選擇進行對照，再參考本頁 DNS 章節檢查伺服器網域與目標網域。若無法判斷結果，請勿連續新增多個 DNS 位址，否則更難重現故障路徑。

區分網頁、即時通訊與背景訂閱問題

網頁能開啟，但語音、遊戲或其他即時功能失敗，可能與 UDP、分應用程式範圍或伺服器端支援有關。請先確認該應用程式的流量已被接管，再核對節點協定與提供方的功能說明；不能只因網頁正常，就推斷所有傳輸方式都可用。若只有一個應用程式異常，可嘗試使用其內建網路診斷；不要為了單一功能同時重設所有路由與 DNS。

若訂閱在前景手動更新成功、背景自動更新失敗，請優先檢查背景網路限制與更新時機，不要立刻刪除訂閱。若安裝時提示套件不適用，請核對裝置架構，並依下載頁選擇 arm64 或通用版，不要把安裝相容性問題誤當成連線故障。更換用戶端前，請先確認原設定的協定與目標核心相容；三款用戶端的定位比較請參閱橫向評測。

若仍無法定位問題，請整理「何時正常、何時失敗、重新連線是否恢復」三項對照，再附上已隱藏敏感資訊的錯誤日誌。常見概念可回查名詞解釋，基本操作可返回入門指南。清楚的重現條件比反覆重裝更有幫助，也能讓下次遇到相同故障時，直接從已驗證的方向開始排查。