V2Ray 故障排除大全

一、建立可重現的診斷基線

先描述現象，不要先猜原因

有效的排查始於一條可重現的路徑。先記錄目前使用的用戶端、所選節點、系統代理模式、路由模式、發生時間與失敗的應用程式，再區分「所有網站都無法開啟」「只有特定網域失敗」「瀏覽器正常但其他應用程式失敗」「可以連線但速度明顯下降」等現象。節點名稱本身不能證明節點可用，清單中的延遲值也不能取代完整的連線測試。最好保留一個先前可正常運作的節點或設定作為對照；如果新舊設定在同一網路下表現不同，便能快速將範圍縮小至節點參數或路由規則。

接著進行最小化測試：關閉其他代理用戶端、瀏覽器代理擴充功能、封包擷取工具與臨時網路加速功能，只保留一個 V2Ray 用戶端執行；暫停自訂路由規則，切換至用戶端提供的基礎代理模式；選定一個節點後保持不變。桌面端還應確認系統時間、時區與日期正確，因為 TLS 憑證驗證依賴系統時間。行動網路與 Wi-Fi 的出口條件不同，測試時要明確記錄目前使用哪一種網路，避免切換網路後仍將結果歸因於原本的設定。

依層級判斷故障位置

一次請求大致會經過應用程式、系統代理或虛擬網路介面、本機入站、路由與 DNS、遠端節點及目標伺服器。若瀏覽器完全沒有請求進入用戶端日誌，通常應先查應用程式與系統代理；若日誌出現連線節點逾時，重點在本機網路到節點的鏈路；節點握手成功但目標網域解析失敗，則應檢查 DNS；只有某一組網域走錯出口，便檢查路由匹配順序。這種分層方式比反覆重裝用戶端更有效，也能避免把多個獨立問題混在一起。

儲存日誌與本機監聽證據

日誌應涵蓋「啟動用戶端—選擇節點—發起一次失敗的存取—停止測試」的完整過程。不要只截取最後一行，因為真正原因常出現在前面的設定載入或入站監聽階段。v2rayN 可查看主視窗的日誌區域與核心日誌；v2rayNG、v2flyNG 則可從日誌頁面觀察連線、路由與錯誤資訊。分享日誌前應刪除訂閱網址、節點憑證、使用者識別資訊與完整伺服器位址，只保留錯誤類型、發生順序與必要參數。

桌面端可以確認本機代理連接埠是否處於監聽狀態。以下指令只會檢查本機連接埠，不會驗證遠端節點；連接埠號碼應替換為用戶端設定中實際顯示的 SOCKS 或 HTTP 連接埠。

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

若連接埠未監聽，問題仍在用戶端啟動、連接埠衝突或核心載入階段；若透過明確代理執行的指令可以存取，而瀏覽器無法存取，問題通常位於系統代理或應用程式代理層；若明確代理同樣失敗，再檢查節點與 DNS。完成這一輪後，應能寫出簡短結論，例如「本機 HTTP 連接埠正常監聽，瀏覽器請求已進入日誌，但連線至節點位址時逾時」。這個結論就是後續排查的起點，而不是籠統地說「V2Ray 不能用」。

二、啟動代理後無法上網

區分本機斷線與代理鏈路失敗

「連線後無法上網」通常包含兩種情況。第一種是系統代理已指向用戶端，但用戶端本機入站沒有正常監聽，所有遵循系統代理的應用程式都會立即失敗；第二種是本機入站正常，流量已進入核心，但遠端節點、路由或 DNS 未完成請求。先觀察用戶端日誌：存取網頁時完全沒有新增記錄，表示流量未進入用戶端；若出現目標網域與出站記錄，則表示系統代理至少已將請求送到本機核心。

先關閉系統代理並退出用戶端，確認直接網路本身可用。如果直接網路也無法存取常用網站，應先修復 Wi-Fi、網路卡、閘道或本機 DNS，不要繼續修改節點。直接網路恢復後，再啟動用戶端但暫不啟用系統代理，確認核心沒有啟動錯誤；最後啟用系統代理並存取固定的測試頁面。這樣的啟動順序可以判斷故障是在原始網路、核心啟動，還是代理接管後才出現。

檢查連接埠、模式與程序歸屬

v2rayN 的 HTTP、SOCKS 與區域網路監聽是不同設定。系統代理必須指向目前實際監聽的 HTTP 連接埠，不能照抄另一台裝置或舊設定中的連接埠。若連接埠被其他程式占用，核心可能啟動失敗，也可能自動切換後與系統代理記錄不一致。檢查日誌中是否有 address already in use、bind failed 或 listen failed 類型的訊息；發現衝突後，應退出占用程式，或在用戶端中改用未使用的連接埠，再重新設定系統代理。

瀏覽器能開啟網頁而命令列工具不能，並不一定是節點問題。許多命令列程式不會自動讀取桌面系統代理，需要明確設定代理參數或相應的環境變數。反過來，某些應用程式保存了自己的手動代理位址，即使系統代理已關閉，仍會繼續連線至舊連接埠。排查時應檢查應用程式內部的網路設定，分清「跟隨系統」「手動 HTTP」「手動 SOCKS」與「直連」。只有使用相同的代理入口測試，結果才具有可比性。

回到最簡單的路由設定

複雜的分流規則可能將 DNS、節點網域或目標請求送往錯誤的出站。暫時停用自訂規則集，選擇基礎全域代理模式進行對照。如果全域模式恢復正常，節點鏈路大致正常，問題位於規則匹配；如果全域模式仍然失敗，便繼續檢查節點參數與 DNS。恢復分流時，應從少量明確規則開始，先設定私有位址與本地網路直連，再設定確定的網域規則，最後設定預設出站。規則通常依順序匹配，前面的寬泛規則會遮蔽後面的精確規則。

還要檢查出站標籤是否確實存在。規則引用的標籤與目前設定中的代理、直連、攔截出站必須完全一致，大小寫與拼字差異都可能導致載入失敗或落入預設出站。訂閱更新後，用戶端管理的出站結構可能發生變化，因此不應將另一套完整設定中的標籤機械式複製到目前的用戶端。若核心日誌明確提示找不到 outbound、invalid field 或設定解析錯誤，應先恢復用戶端產生的預設設定，再逐項加入自訂內容。

恢復網路狀態

用戶端異常退出後，系統代理可能仍保留為本機位址，而對應連接埠已無人監聽，於是瀏覽器看起來像完全斷網。重新開啟用戶端並執行「清除系統代理」，或在系統網路設定中關閉手動代理，再重新測試直連。若使用虛擬網路模式，還要正常停止該模式，讓路由表與 DNS 設定恢復；僅強制結束程序可能留下暫時的網路狀態。恢復後重新啟動用戶端，先確認直連，再確認明確的本機代理，最後才啟用系統級接管。

若只有區域網路資源無法存取，請檢查私有網段是否被代理。家用路由器、印表機、儲存裝置與公司內部服務通常使用私有位址，應由直連出站處理。將私有位址規則放在預設代理規則之前，並確認虛擬網路模式沒有把區域網路探索流量錯誤送往遠端。若只有單一網站失敗，可在瀏覽器私密視窗中排除快取與擴充功能影響，並查看該網域在日誌中最後命中了哪個出站。完成這些檢查後，通常便能把「無法上網」拆解為明確的連接埠、規則、DNS 或節點問題。

三、節點逾時與握手失敗

看懂逾時、拒絕與握手錯誤

節點清單顯示逾時，只能表示測試請求未能在限定時間內完成，不能單獨證明伺服器永久不可用。連線逾時通常表示前往節點位址與連接埠的 TCP 或 UDP 路徑未能及時建立；連線被拒絕表示目標位址可達，但對應連接埠沒有服務接受連線；連線被重設表示鏈路建立後由其中一端主動中斷；TLS 握手錯誤則應進一步檢查伺服器名稱、傳輸層、安全參數與系統時間。不同錯誤指向不同層級，不能一概歸結為「節點失效」。

先對同一訂閱中的兩個節點進行實際連線測試。如果所有節點在目前網路下同時逾時，而切換至另一個網路後恢復，應優先檢查本機網路出口、防火牆或路由路徑。如果只有一個節點逾時、其他節點正常，問題更可能位於該節點的位址、連接埠或遠端服務。如果同一節點在多台裝置與不同網路下都失敗，再聯絡設定提供者核對節點狀態與參數，比不斷更改用戶端設定更直接。

逐項核對節點參數

手動匯入節點時，位址、連接埠、使用者識別資訊、協定、安全層、傳輸方式、伺服器名稱與路徑需要成套一致。VLESS、VMess 等協定的欄位不能互相套用；WebSocket、gRPC、TCP 等傳輸方式對應的路徑、服務名稱與請求標頭也各不相同。最常見的問題不是欄位缺漏，而是從舊節點複製設定後只修改位址與連接埠，卻留下不匹配的伺服器名稱或傳輸參數。應將用戶端編輯頁與原始設定逐欄位對照，不要依賴節點備註判斷。

啟用 TLS 時，伺服器名稱通常用於憑證驗證與握手，不能隨意替換成節點 IP。系統時間誤差過大，可能導致憑證尚未生效或已過期的判斷異常。若日誌出現 certificate、handshake、server name 或 verify failed，應先校準系統時間，再核對伺服器名稱與安全設定。不要透過關閉必要驗證來掩蓋參數不一致；正確做法是取得與伺服器端一致的設定。若使用 REALITY 等安全方式，還需保持公鑰、短識別碼、伺服器名稱與流控參數一致。

延遲測試不等於可用性結論

ICMP ping、TCP 連線、代理握手與下載測速測量的是不同階段。伺服器可能不回應 ping，但代理連接埠正常；TCP 連接埠可以建立連線，但協定驗證失敗；實際連線延遲可能很低，持續傳輸頻寬卻相當有限。因此選擇節點時，應先使用用戶端提供的實際連線測試確認代理握手，再透過實際網頁與檔案傳輸驗證穩定性。關於三種測試的差異，可繼續閱讀V2Ray 延遲測試原理。

測試過程也應避免過多並發。一次對大量節點同時測速會占用本機連線、DNS 查詢與網路出口，部分路由器也會限制短時間內的大量新連線，結果可能出現整批逾時。先選少量節點依序測試，等待前一輪連線釋放後再比較結果。行動網路下的訊號切換、背景省電與網路類型變化也會使短時間測試失真，應在網路穩定後重新測試。

確認位址解析與協定所需網路

當節點位址是網域時，用戶端必須先解析該網域。若目前的 DNS 規則又要求透過尚未建立的代理查詢，就可能形成啟動依賴：沒有節點便無法解析 DNS，沒有 DNS 又無法連線節點。可暫時使用可靠的直連 DNS 解析節點網域，同時讓目標網域依既定策略解析。使用 UDP 的功能還要求本機網路、用戶端入站、遠端節點與出站路徑共同支援，不能只看用戶端是否勾選 UDP。

最終記錄應包含節點參數是否來自完整匯入、同組其他節點是否可用、切換網路後是否恢復，以及錯誤發生在 TCP 建立連線還是協定握手階段。若問題只發生在單一節點且可跨網路重現，只需保留日誌中的錯誤類型，不必暴露完整憑證。若所有節點只在目前網路下失敗，便應將重點轉向本機防火牆、路由器、DNS 與網路出口，而不是繼續編輯每個節點。

四、訂閱更新與匯入失敗

先判斷是下載失敗還是解析失敗

訂閱失敗至少可分為三個階段：用戶端沒有取得訂閱內容、已取得內容但格式無法解析、解析成功但節點沒有加入目前群組。更新時先查看日誌與提示文字。HTTP 逾時、連線失敗或網域解析失敗通常屬於下載階段；base64、JSON、YAML 或 unsupported scheme 類型的提示通常屬於內容解析階段；更新完成但清單沒有變化，則可能是群組選擇、去重、篩選或訂閱內容本身未變更。

確認更新的是目前正在查看的訂閱群組。v2rayN 支援多個訂閱群組，節點清單可能仍停留在另一個群組；更新指令也可能只套用於選定的群組。不要在同名群組之間反覆匯入同一個網址，應先查看群組屬性中的訂閱網址、啟用狀態與更新結果。Android 用戶端同樣要區分單節點匯入、剪貼簿批次匯入與訂閱管理，三者不會自動合併為同一個更新來源。

檢查訂閱網址的完整性

從聊天工具或網頁複製訂閱網址時，前後空格、換行、跳脫字元與遭截斷的查詢參數都可能導致請求失敗。應在訂閱編輯欄中確認網址從協定頭到最後一個參數完整且連續。某些網址帶有臨時權杖或裝置參數，少複製一個字元就會回傳未授權或空內容。不要將訂閱網址貼到公開日誌、截圖或線上分析工具中，因為它通常具有取得設定的權限。

若用戶端支援透過代理更新訂閱，應分別測試「直連更新」與「透過目前代理更新」。目前網路能直接存取訂閱服務時，直連路徑最簡單；需要經過既有節點才能存取時，則必須先有一個可用節點。若唯一訂閱中的所有舊節點都已不可用，透過代理更新便會形成死循環；此時應向設定提供者取得可直接存取的新網址或獨立設定，而不是繼續重新整理同一個失敗請求。

處理更新成功但沒有新節點

先查看更新時間與日誌是否確實發生變化，不要只看節點數量。訂閱服務可能回傳與上次相同的內容，用戶端也可能依節點識別資訊去重，因此數量不變是正常結果。檢查是否啟用了名稱篩選、正規表示式過濾、僅保留特定協定或刪除舊節點等選項。過濾表示式過寬時，新節點可能在解析後全部被排除；表示式語法錯誤時，部分用戶端會保留舊清單並提示更新失敗。

修改訂閱群組前，先匯出目前仍可用的設定，接著建立臨時群組匯入同一個訂閱。臨時群組可以排除舊快取、舊篩選條件與重複項目的影響。如果臨時群組也是空的，重點應放在訂閱回傳內容；如果臨時群組有節點而原群組沒有，則應檢查原群組的過濾、排序與更新設定。完成比較後再決定是否替換原群組，不要一開始就刪除唯一可用的節點。

辨識格式與用戶端能力差異

訂閱內容可能是協定連結集合，也可能是結構化設定。用戶端只能解析自身支援的格式與欄位。將完整核心設定當作普通訂閱匯入，或把單一分享連結放入訂閱網址欄，都可能得到格式錯誤。應確認提供者標示的匯入方式與目前用戶端一致。v2rayNG 使用 Xray 核心，v2flyNG 使用 v2fly 核心，兩者對部分新欄位與傳輸組合的支援範圍可能不同；同一份內容能在一個用戶端匯入，不代表另一個用戶端必然接受。

{
  "remarks": "example-subscription",
  "url": "https://example.com/subscription?token=xxxx",
  "enabled": true
}

上面的結構只用於說明需要核對的邏輯欄位，實際訂閱應透過用戶端介面新增，不要直接將範例當作用戶端設定檔。出現解析錯誤時，保留錯誤行附近的欄位名稱，並確認用戶端與核心來自目前下載頁提供的安裝入口。不要編造版本號來判斷相容性，應以用戶端實際顯示的功能與日誌為準。

若訂閱請求間歇性失敗，應在同一網路下間隔一段時間重試，並比較直連與代理更新結果。頻繁連續重新整理可能觸發伺服器端的請求限制，也會讓日誌堆疊得難以閱讀。最終應明確回答：請求是否成功、回傳內容是否可解析、節點是否進入目標群組、過濾規則是否刪除了結果。更多短問題可在說明中心按「安裝設定」分類繼續核對。

五、連線正常但速度變慢

分開測量延遲、頻寬與穩定性

速度變慢不能只看節點清單中的毫秒數。延遲決定短連線建立與互動回應，頻寬決定持續傳輸速度，封包遺失與抖動則決定影片、通話及長連線是否穩定。低延遲節點可能出口頻寬有限；延遲稍高的節點卻可能持續下載更快。測試時先開啟固定網頁觀察首屏回應，再進行持續傳輸，最後觀察數分鐘內是否反覆斷線。三種現象應分別記錄，避免以一次測速結果取代完整判斷。

建立對照組時，保持裝置、網路、目標資源與測試時間接近，只更換節點。先測量直連網路的可用頻寬，再測試兩條不同線路的節點。如果直連本身很慢，優先處理 Wi-Fi 訊號、行動網路品質與本機占用；如果所有節點速度都接近同一個低值，檢查裝置效能、虛擬網路模式與遠端出口；如果只有一個節點明顯較慢，則更可能是該線路壅塞或出口品質問題。

排除本機資源與並發影響

同步軟體、系統更新、雲端硬碟、影片播放與其他裝置都可能占用上傳或下載頻寬。尤其上傳頻寬被占滿時，確認封包無法及時送出，下載也會表現為卡頓。測試前暫停大量流量工作，並在路由器或系統工作管理員中觀察網路占用。瀏覽器同時開啟大量頁面、下載器啟用高並發、用戶端對所有節點平行測速，也會消耗連線數與 CPU，導致結果不穩定。

用戶端核心需要處理加密、傳輸封裝、路由匹配與 DNS。低功耗裝置在高吞吐量下可能出現 CPU 飽和，表現為速度達到某個上限後不再提升。可觀察系統資源：若傳輸時單一核心持續滿載，便減少複雜規則、關閉不必要的日誌等級，並比較系統代理模式與虛擬網路模式的差異。不要為了追求速度而隨意修改不理解的傳輸參數；用戶端設定必須與遠端服務一致，單方面調整往往只會導致連線失敗。

檢查路由是否繞行

速度問題有時其實是路由問題。原本應直連的本地或區域資源被送入代理，會增加路徑與出口負擔；原本應走代理的目標被誤判為直連，則可能反覆重試。查看日誌中的目標網域、解析結果與最終出站，確認規則命中符合預期。使用 geosite 與 geoip 分流時，網域規則與 IP 規則可能得出不同結論，且規則順序會決定最終結果。

先使用全域代理模式測試節點上限，再恢復分流模式。如果全域模式較快而分流模式較慢，應檢查 DNS 與規則匹配；如果兩者都慢，便繼續檢查線路與裝置。如果只有首次開啟頁面較慢、後續存取正常，常見原因是 DNS 查詢、首次 TLS 握手或連線建立；如果開始很快、持續傳輸後速度下降，則更像是線路壅塞、封包遺失、裝置溫度或頻寬限制。路由規則的實際設定方式可參考geosite 與 geoip 分流實戰。

使用可重複的測試方法

不要同時使用多個測速網站，再將結果混在一起。選擇固定資源，在相近時間測試直連、節點 A 與節點 B；每種狀態重複兩到三次，記錄中位表現而不是最高值。測試期間保持路由模式一致，並關閉瀏覽器快取對下載結果的影響。若目標資源本身會依不同出口進行不同調度，請換另一個穩定資源交叉驗證，避免將目標網站的單點壅塞誤判為節點速度。

實際連線延遲測試應限制並發，節點數量多時分組執行。若日誌中頻繁出現 retry、broken pipe、reset 或 idle timeout，即使平均速度尚可，也表示鏈路穩定性不足。此時應優先選擇封包遺失較少、重新連線較少的節點，而不是只選延遲最低的節點。影片與互動應用程式通常更重視穩定性，長時間檔案傳輸則更重視持續頻寬，選擇標準不能完全相同。

完成排查後，應能判斷瓶頸位於直連網路、裝置處理、路由繞行、DNS 首次查詢、單一節點線路或目標資源。若瓶頸隨時段變化，保留不同時段的對照記錄；若隨網路變化，重點比較 Wi-Fi 與行動網路；若隨用戶端模式變化，檢查虛擬網路介面與規則複雜度。這樣的結論比「測速很低」更適合後續處理。

六、DNS 解析錯誤、污染與洩漏式錯配

辨識 DNS 故障的典型表現

DNS 問題常見表現包括：網域無法開啟但直接存取已知 IP 有回應、同一網站在不同應用程式中結果不同、切換代理模式後解析位址改變，或日誌出現 lookup、resolve、no such host、SERVFAIL、NXDOMAIN 等資訊。也可能出現節點本身可以連線，但目標網域被解析至不適合的位址，最終表現為逾時或憑證名稱不匹配。排查時必須將「節點網域解析」與「目標網域解析」分開，兩者可能使用不同路徑。

先清除系統與瀏覽器快取，再重複查詢。瀏覽器可能啟用獨立的安全 DNS，不一定遵循系統或用戶端設定；系統也可能快取舊答案。測試時關閉瀏覽器獨立 DNS，或明確記錄其狀態，再使用系統查詢工具與用戶端日誌對照。Windows 可使用 nslookup 查詢，macOS 與 Linux 可使用 dig 或 nslookup。查詢結果不同並不代表其中一方一定錯誤，還要確認請求最終應由直連 DNS 還是代理端 DNS 處理。

nslookup example.com
nslookup example.com 1.1.1.1

dig example.com
dig @1.1.1.1 example.com

理解本地解析與遠端解析

本地解析會先在裝置端取得 IP，再由路由規則處理連線；遠端解析通常將網域交給代理端處理。前者方便依 IP 規則分流，也依賴本機 DNS 的結果；後者可避免本地解析路徑影響目標網域，但用戶端仍需處理節點位址與部分直連網域。具體模式名稱會因用戶端與核心設定不同而異，不應只根據某個開關名稱判斷，需配合日誌確認網域是在本地還是遠端解析。

若路由規則同時包含網域與 IP 條件，要注意解析策略是否會產生可供 IP 規則匹配的位址。只按網域匹配時，不一定需要提前解析；需要按 geoip 判斷時，核心可能會先解析再匹配。錯誤的策略會出現「網域規則未命中，IP 規則也沒有預期結果」的現象。應先定義需求：本地域名與私有位址直連，特定網域走指定出站，其餘請求走預設出站；接著選擇與需求一致的解析路徑。

防止啟動依賴與解析迴路

如果節點位址本身是網域，而設定又要求所有 DNS 查詢都透過該節點，就會產生解析迴路。解決方法是為節點網域提供可在代理建立前使用的引導解析，或讓節點網域走明確的直連 DNS。引導 DNS 只負責建立代理所需的少量解析，不應與目標網域策略混為一談。若日誌反覆出現對節點網域的查詢、連線尚未建立便再次發起 DNS 請求，通常應檢查這項依賴關係。

虛擬網路模式還可能接管系統 DNS。用戶端異常退出、網路切換或從休眠恢復後，系統可能保留已無法連線的 DNS 位址，表現為關閉代理後也無法解析。此時先正常停止虛擬網路模式，再查看系統網路卡的 DNS 是否恢復為自動或原有設定。不要在用戶端執行期間同時讓多個網路工具修改 DNS，否則很難確認最終生效的是哪一套設定。

用日誌驗證最終答案

修改 DNS 後不要只看網頁是否偶然開啟。應清除快取、查詢固定網域、記錄回傳位址，再從用戶端日誌確認該網域命中的出站。若同一網域有多個位址，短時間內變化可能來自正常的負載平衡；真正需要關注的是位址類別與出站是否符合路由設計。只有解析結果、路由命中與最終連線三者一致，才能認為設定有效。

當單一網域持續失敗時，請比較其根網域與子網域，檢查是否存在獨立的網域規則、hosts 覆寫或快取。hosts 條目的優先順序通常較高，舊條目會讓所有 DNS 設定看起來都沒有生效。若錯誤只出現在某個瀏覽器，請清除該瀏覽器的 DNS 與連線快取；若所有應用程式結果一致，則回到系統與用戶端層級。更換 DNS 服務只能作為對照，不應取代對解析路徑的確認。

DNS 修復後的驗收標準包括：用戶端冷啟動即可連線節點；系統查詢與預期解析路徑一致；瀏覽器與命令列採用相同代理入口時結果一致；切換網路、從休眠恢復及正常退出後，系統 DNS 都能恢復。若只有虛擬網路模式失敗，而普通系統代理正常，應繼續檢查虛擬介面的 DNS 接管、路由優先順序與系統權限。

七、系統代理設定未生效

確認應用程式是否遵循系統代理

系統代理不是所有程式都會自動使用的統一通道。瀏覽器與部分桌面應用程式通常會讀取系統代理；命令列工具、遊戲、背景服務與使用自有網路堆疊的程式可能忽略它。出現「瀏覽器正常、某個應用程式直連」時，先查該應用程式是否支援系統代理、是否保存了手動代理，以及是否需要單獨設定 HTTP 或 SOCKS。若應用程式明確不讀取系統代理，可考慮用戶端提供的虛擬網路模式，但啟用前要了解其權限、路由與 DNS 接管範圍。

反過來，瀏覽器代理擴充功能可能會覆寫系統設定。擴充功能指向舊連接埠、舊協定或另一個代理程式時，v2rayN 的系統代理狀態不會決定瀏覽器的實際路徑。排查時暫時停用擴充功能，使用瀏覽器預設網路設定；若恢復正常，再重新設定擴充功能。企業管理政策也可能鎖定代理項目，此時系統設定介面雖然可見，應用程式讀取的值仍可能由政策決定，應查看系統代理頁面是否提示由組織管理。

核對協定與監聽位址

HTTP 代理與 SOCKS 代理不能只靠連接埠號碼互換。系統代理通常需要 HTTP 入口，而某些工具可以直接使用 SOCKS。應在用戶端設定中確認每個入站的協定、監聽位址與連接埠，再讓應用程式填入相應設定。監聽於 127.0.0.1 表示僅本機可存取；允許區域網路連線後，用戶端可能會監聽所有介面，但這並非本機系統代理生效的必要條件。日常使用中不應為了修復本機代理而任意開放區域網路監聽。

可使用以下方式驗證明確的 HTTP 代理。若指令成功、系統代理模式下瀏覽器失敗，問題在系統代理記錄或瀏覽器覆寫；若指令連線本機連接埠時就被拒絕，請檢查核心程序與連接埠；若本機連線成功但遠端失敗，則轉而檢查節點、路由與 DNS。

curl -I --proxy http://127.0.0.1:10809 https://example.com/
curl -I --socks5-hostname 127.0.0.1:10808 https://example.com/

範例連接埠僅供示範，必須以用戶端目前的設定為準。--socks5-hostname 會讓網域透過 SOCKS 路徑解析，適合與本地解析方式作對照。不要同時執行多個會自動設定系統代理的程式，它們可能輪流覆寫系統值，導致介面狀態與實際登錄檔或網路服務設定不一致。

處理異常退出後殘留的代理設定

用戶端遭強制結束、系統突然關機或核心崩潰後，系統代理可能仍指向本機連接埠。此時所有遵循系統代理的應用程式都會失敗，看起來像網路中斷。先重新啟動原用戶端，執行清除或關閉系統代理，再正常退出；也可以進入系統網路設定手動關閉代理。恢復直連後，再啟動用戶端並重新設定。不要在網路已中斷時立即刪除所有設定，否則會失去判斷殘留連接埠與原始設定的依據。

Windows 環境還需區分不同帳戶與權限情境。以不同權限啟動的程式可能讀取不同的環境變數或設定範圍，背景服務也不一定使用目前桌面帳戶的代理。macOS 的代理設定會依網路服務儲存，Wi-Fi 與其他網路介面可能有不同設定；切換介面後，應確認目前活動網路服務的代理狀態。Linux 桌面環境可能同時存在桌面代理、環境變數與應用程式獨立設定，三者都要逐層核對。

環境變數與命令列程式

命令列程式常讀取 HTTP_PROXY、HTTPS_PROXY、ALL_PROXY 與 NO_PROXY。變數可能來自目前終端機、使用者設定檔、系統服務或容器環境。若終端機仍保存舊連接埠，即使桌面系統代理已更新，命令列請求也會失敗。檢查變數後重新開啟終端機，確保新程序讀取最新值。內部網域與本地位址通常應加入不經過代理的範圍，但規則應保持精確，過寬的排除項會讓本應使用代理的請求直接連線。

set HTTP_PROXY
set HTTPS_PROXY

env | grep -i proxy

清除變數前要記錄其來源，避免只在目前終端機暫時修改，下一次啟動又恢復舊值。容器與子系統擁有獨立網路命名空間時，127.0.0.1 可能指向容器自身，而不是主機，必須使用其能夠存取的主機位址，並確認用戶端是否允許相應介面連線。這屬於應用程式網路邊界問題，而不是節點協定問題。

最終應確認：核心連接埠實際監聽；系統代理指向相同連接埠與正確協定；瀏覽器沒有擴充功能覆寫；命令列變數沒有舊值；異常退出後代理能夠恢復；不遵循系統代理的應用程式已採用明確方案。若要重新安裝用戶端，應先從用戶端取得頁選擇對應平台，並在解除安裝前記錄目前的連接埠、群組與路由設定，避免安裝後將設定差異誤認為程式問題。

八、用戶端無法啟動、閃退與核心崩潰

區分介面程序與核心程序

v2rayN 等圖形化用戶端通常負責設定管理、訂閱、系統代理與介面顯示，實際連線則由 Xray 或 v2fly 核心程序處理。介面可以開啟但無法連線，可能是核心沒有啟動；介面直接退出，則應優先檢查執行環境、設定檔、權限與程式檔案。工作管理員或系統程序清單中只看到介面程序，不代表核心已正常執行。日誌停在「啟動核心」之前或之後，排查方向也不同。

首先完全退出用戶端，確認沒有殘留的介面與核心程序，再重新啟動一次。不要連續點擊多次啟動，否則多個執行個體會爭用設定檔與監聽連接埠。若用戶端提示已有執行個體正在執行，先在工作管理員中結束殘留程序，等待連接埠釋放後再啟動。若每次都在載入某個設定後退出，可暫時將目前設定匯出備份，然後切換到一個最簡單的已知有效設定進行測試。

檢查設定解析與寫入權限

手動編輯 JSON 時，一個多餘的逗號、錯誤引號或欄位類型都可能阻止核心載入。日誌中的 failed to parse、invalid character、unknown field 或 failed to load config 通常會指出欄位位置。應使用用戶端介面恢復預設產生的設定，再逐項加入自訂 DNS 與路由，而不是繼續在錯誤檔案上疊加內容。下面是一個語法完整的最小 JSON 結構示意，用於理解括號與陣列關係，不包含可直接連線的節點。

{
  "log": {
    "loglevel": "warning"
  },
  "inbounds": [],
  "outbounds": [
    {
      "protocol": "freedom",
      "tag": "direct"
    }
  ]
}

設定目錄不可寫入時，訂閱更新、建立日誌與儲存設定都可能失敗。檢查用戶端所在目錄與使用者資料目錄是否允許目前帳戶寫入，避免直接從唯讀位置執行。安全軟體隔離核心檔案時，介面可能顯示找不到核心，或啟動後立即結束；應查看系統安全性記錄，確認檔案來源與本站下載入口一致，再依本機管理政策處理。不要從不明來源補齊單一核心檔案，這會造成介面與核心組合不一致。

處理連接埠衝突與重複執行個體

核心啟動後立即退出，常見原因是本機連接埠已被占用。日誌會出現 bind、listen 或 address already in use。先查明占用程序，判斷它是舊用戶端執行個體、另一個代理程式還是系統服務。若是殘留執行個體，正常結束後重新啟動；若連接埠屬於必要服務，便在用戶端中修改 HTTP 與 SOCKS 連接埠，並同步更新系統代理、瀏覽器擴充功能與命令列環境變數。只修改用戶端連接埠而不更新使用方，會把「崩潰」轉變為「代理未生效」。

多個使用者帳戶、遠端桌面工作階段或開機自動啟動工作也可能啟動不同執行個體。檢查啟動項目與排程工作，確保只有一個用戶端負責設定系統代理。若需要平行執行不同設定，必須為每個執行個體分配獨立的資料目錄、日誌與監聽連接埠；一般排查不建議如此操作，因為結果難以歸因。

從乾淨狀態恢復，而不是盲目刪除

恢復前先備份訂閱群組、手動節點與自訂路由，但不要將訂閱網址與節點憑證放在公開位置。接著關閉系統代理與虛擬網路模式，正常退出用戶端，再將現有設定目錄重新命名為備份目錄。啟動用戶端產生新的預設設定，確認介面與核心都能執行，然後逐項匯入：先匯入單一節點，再匯入訂閱群組，最後加入路由與 DNS。在哪一步再次崩潰，就重點檢查該類資料。

若全新設定仍無法啟動，便轉而檢查執行環境、系統權限、程式架構與安全軟體記錄。macOS 需要確認系統允許開啟該應用程式；Linux 應從終端機啟動，以觀察缺少相依元件與權限錯誤；Windows 應查看應用程式事件與用戶端日誌。錯誤報告中保留異常模組、退出階段與錯誤代碼，但刪除個人路徑、訂閱內容與憑證。

若崩潰只發生在更新訂閱或大量測速時，應減少並發並觀察記憶體與磁碟空間；若只發生在從休眠恢復後，檢查網路介面變化與舊核心程序；若只發生在虛擬網路模式，檢查驅動程式、權限與其他虛擬介面衝突。完成排查後，應能確定是介面、核心、設定解析、連接埠、權限還是執行環境問題，再決定修復設定或重新安裝，而不是將所有異常都歸因於用戶端版本。

九、Android 連線與背景執行專項

確認虛擬網路授權與目前使用的用戶端

v2rayNG 與 v2flyNG 在 Android 上通常透過系統虛擬網路介面接管流量。首次啟動連線時需要系統授權；若授權被拒絕、被另一個虛擬網路應用程式占用，或系統在重新啟動後撤銷授權，用戶端可能顯示正在啟動，卻沒有實際接管流量。先停止其他使用同類系統介面的網路工具，再重新啟動目前的用戶端並確認授權提示。狀態列出現連線標記只是介面建立的線索，仍需透過日誌與實際存取驗證節點鏈路。

不要同時讓兩個用戶端保持連線狀態。v2rayNG 使用 Xray 核心，v2flyNG 使用 v2fly 核心，設定欄位的支援範圍可能不同。將同一個訂閱匯入兩個用戶端作對照時，應先停止前一個連線，再啟動後一個；否則系統只允許其中一個介面生效，結果會被誤判為節點故障。桌面端可使用 v2rayN 進行交叉驗證，但跨裝置比較時要考慮 Wi-Fi、行動網路與 DNS 路徑差異。

處理背景程序被停止與鎖定螢幕斷線

部分 Android 系統會限制背景程序、鎖定螢幕時的網路與電池使用。典型現象是前景連線正常，鎖定螢幕數分鐘後斷線，重新開啟用戶端又恢復。應在系統應用程式設定中允許用戶端持續於背景執行，關閉對該用戶端的嚴格電池限制，並確認系統沒有自動清理其通知或服務。不同裝置的選單名稱各異，可依「電池」「背景使用量」「自動啟動」「應用程式啟動管理」等實際設定尋找。

完成設定後不要只看用戶端按鈕狀態。建立連線、存取固定網頁、鎖定螢幕等待，再解鎖後重複存取並查看日誌時間線。如果日誌中間完全停止，通常是程序被系統暫停；如果日誌持續但連線重新建立，可能是網路介面在休眠期間切換；如果請求已進入日誌後節點逾時，則繼續檢查網路路徑。保持常駐通知通常有助於系統識別正在執行的網路服務，不應任意關閉相關通知類別。

Wi-Fi 與行動網路切換

從 Wi-Fi 切換至行動網路時，裝置 IP、DNS、最大傳輸單位與網路能力都會改變。舊連線通常需要重新建立，短暫失敗屬於切換過程的一部分；若切換後長時間沒有網路，應停止並重新啟動用戶端，讓虛擬介面繫結至新網路。反向切換回 Wi-Fi 時也應重新測試，尤其是需要登入網頁認證的公共網路：應先暫停代理完成網路認證，再重新連線。

若 Wi-Fi 正常而行動網路逾時，請比較節點位址是否能在行動網路中解析，檢查行動網路存取點是否限制特定連線方式，並更換訂閱中的其他節點作對照。若行動網路正常而家用 Wi-Fi 失敗，檢查路由器 DNS、防火牆與同一網路中的其他裝置。不要在切換網路的同時修改節點參數，否則無法判斷恢復是由網路變化還是設定變化造成。

分應用程式代理與繞過設定

Android 用戶端通常提供分應用程式代理。啟用後，必須確認目前模式是「僅代理選取的應用程式」還是「繞過選取的應用程式」。兩種模式方向相反，選錯後會出現瀏覽器正常、其他應用程式直連，或只有少數應用程式失敗。排查時暫時關閉分應用程式設定，讓所有應用程式使用相同路徑；確認基礎連線正常後，再逐一加入應用程式並測試。應用程式更新或重新安裝後識別資訊可能改變，也應重新核對清單。

區域網路應用程式、投放、列印與裝置探索可能需要繞過代理，但具體流量仍受虛擬介面路由控制。若區域網路存取失敗，確認用戶端是否允許繞過區域網路，並檢查私有位址是否走直連。不要用過寬的繞過範圍涵蓋所有流量；每增加一項後，都應使用目標應用程式驗證。若應用程式內還有獨立代理或安全 DNS，也要暫時恢復預設設定，避免與用戶端的虛擬網路設定疊加。

行動端日誌與最終驗收

行動端日誌採集應涵蓋連線啟動、切換網路、鎖定螢幕恢復及失敗應用程式發起請求的時間點。記錄系統是否顯示虛擬網路連線、用戶端服務是否仍在執行、請求是否進入日誌，以及節點是否重新連線。分享日誌前刪除訂閱網址、使用者識別資訊與伺服器完整資訊。若問題只出現在某個應用程式，還應記錄該應用程式是否啟用獨立 DNS、是否被分應用程式規則選中，以及瀏覽器對照是否正常。

最終驗收至少包含四項：前景持續存取正常；解除鎖定後能繼續存取；Wi-Fi 與行動網路切換後能自動恢復，或透過重新連線一次恢復；分應用程式規則符合預期。若 v2rayNG 與 v2flyNG 對同一份設定的表現不同，先確認該設定的核心欄位相容性，再決定使用哪個用戶端，不要把用戶端名稱差異當作唯一原因。需要重新取得安裝入口時，請回到Android 用戶端下載區。

完成九章排查後，若仍無法定位，可將問題濃縮為「在哪一層發生、哪種對照會改變結果、日誌顯示什麼錯誤」。例如「明確的本機代理可用，但系統代理無效」「節點在 Wi-Fi 下逾時，行動網路正常」「訂閱下載成功但解析為空」「鎖定螢幕後核心日誌停止」。再到說明中心尋找對應分類，或回到使用指南重建最小可用設定。系統化排查的目標不是嘗試更多設定，而是用更少的變數取得可驗證的結論。