V2Ray 故障排除指南

01 / 先確認影響範圍

無法連線：從本機連線開始排查

「連線成功」通常只代表用戶端已開始處理流量，不代表一定能連上目標網站。瀏覽器無法開啟頁面時，先記下發生時間、使用中的節點、代理模式及受影響的應用程式，再判斷是所有連線都中斷，還是只有特定網站無法開啟。保留這些條件，後續測試才有比較基準；如果一邊切換節點、一邊更換網路，即使暫時恢復，也很難判斷是哪個步驟發揮作用。

先區分基礎網路與代理連線

先在用戶端停用系統代理，並暫時關閉已啟用的 TUN 模式，再試著開啟平常可直接連線的網站。如果仍然失敗，請檢查 Wi-Fi 是否需要網頁認證、網路線是否接妥、系統日期是否正確，以及其他裝置能否使用同一個網路。此時不宜繼續修改訂閱或路由設定，因為代理啟用前的基礎連線就已異常；應先恢復網路，再重新啟動用戶端。

基礎網路正常後，開啟 v2rayN，選取要測試的設定並設為作用中伺服器，再查看底部或獨立的日誌視窗。重點不是只找醒目的錯誤訊息，而是確認啟動後是否立即發生設定解析失敗、監聽位址被占用或核心程序結束。能開啟介面不代表核心已經執行；如果核心未能成功監聽，瀏覽器將請求送至本機連接埠後，仍然無法繼續。

在「設定 → 參數設定」中確認本機監聽連接埠；部分介面會將相關項目放在「Core 基礎設定」，名稱可能因介面實作而異。記下實際數值，不要只照教學範例填寫。本文使用的 10808 僅供示範；如果用戶端設定不同，測試指令也要同步更換。系統代理連接埠、瀏覽器手動代理連接埠與用戶端監聽連接埠必須相符。

以明確指定代理的方式測試，縮小排查範圍

以下 Windows 指令會先檢查回送位址是否有程式監聽，再透過 SOCKS 代理送出一次請求。第二個測試僅適用於該連接埠確實提供 SOCKS 服務的情況；若使用混合連接埠，也要確認其中包含該協定。測試網址使用示範網域，實際驗證時應改用已知可連線的 HTTPS 網址。不要因為示範網站暫時無法連線，就直接判定是用戶端故障。

Test-NetConnection -ComputerName 127.0.0.1 -Port 10808
curl.exe --proxy socks5h://127.0.0.1:10808 --connect-timeout 10 --max-time 20 --head https://example.com/

如果連接埠測試失敗，請回頭檢查核心啟動狀態與連接埠占用情況；如果連接埠測試成功但請求失敗，請查看同一時間的核心日誌，繼續檢查節點連線與網域解析。如果明確指定代理的請求成功，但瀏覽器仍無法連線，代表至少這條代理連線可正常運作；下一步應檢查瀏覽器擴充功能、系統代理及應用程式本身的代理設定，而不是馬上重新安裝用戶端。

分辨整體網路故障與單一應用程式故障

只有一個網站無法開啟時，先改測另一個同類網站，再觀察日誌中的出口選擇。如果其他網站正常，問題可能與目標網站、分流規則、憑證或帳戶狀態有關。瀏覽器顯示的 HTTP 錯誤頁面也不同於連線逾時：收到明確的回應狀態，通常表示請求已抵達某個服務，不能將所有頁面錯誤都歸因於節點離線。

只有一個應用程式無法連線時，請確認它是否會讀取系統代理。部分程式使用獨立的網路設定，有些流量則使用 UDP；不能只憑瀏覽器能開啟網頁，就認定所有應用程式都應正常運作。先在應用程式設定中確認代理協定與連接埠；若確實需要接管更多流量，再了解 TUN 模式的權限需求與路由影響。不要同時啟用多個流量接管工具碰運氣，否則很難判斷流量是從哪裡進入。

02 / 檢查連線建立過程

節點逾時：分辨連接埠問題與交握失敗

逾時表示某個階段未能在等待時間內完成，不代表節點設定一定有誤。用戶端的延遲測試、建立 TCP 連線、TLS 交握及實際網頁請求，可能使用不同目標與測試方式，因此結果不能互相取代。先保留原始錯誤訊息與發生時間，再依「本機監聽 → 伺服器位址解析 → 伺服器連接埠 → 協定交握 → 目標連線」的順序檢查。

先確認用戶端實際使用的設定

在 v2rayN 中確認作用中伺服器是否就是剛才測試的項目，尤其要留意同名節點、不同訂閱群組，以及更新後重新出現的舊設定。節點名稱只是標籤，不能用來判斷實際位址或協定。開啟編輯視窗，核對伺服器位址、連接埠、使用者識別碼、傳輸方式與 TLS 設定，並逐項比對設定提供者提供的原始資訊，避免自行補上看似熟悉的參數。

使用 TLS 的設定中，伺服器位址與交握時使用的伺服器名稱不一定相同；後者通常對應 SNI 或 serverName。使用 WebSocket 時，也要確認路徑與 Host；使用 gRPC 時，則要確認服務名稱。每個欄位都有特定用途，不應隨意用網站網域取代。若匯入的訂閱內容完整，請優先保留原始值，先確認是否誤選其他項目或過期設定。

系統時間也會影響交握。如果日誌出現憑證尚未生效、已過期或名稱不符等訊息，先檢查裝置日期、時區與自動校時狀態，再核對伺服器名稱。不要把關閉憑證驗證當成一般修復方式，這可能掩蓋位址設定錯誤或中間設備的干擾。若裝置時間正確但憑證仍異常，應請服務維護人員檢查憑證與服務設定。

分別驗證連接埠是否可連線，以及協定是否可用

Windows 可使用以下指令檢查遠端 TCP 連接埠；此處的位址與連接埠僅用來示範語法，請改成設定中的實際值。測試期間不要公開含有帳戶識別資訊的完整連結。測試成功只代表 TCP 連線可以建立，不代表驗證、TLS、傳輸層與代理出口都已正常運作；測試失敗也可能是防火牆、網路路徑或服務未監聽所致，不一定是用戶端介面有問題。

Test-NetConnection -ComputerName example.com -Port 443

如果 TCP 連接埠無法連線，先在同一台裝置上改用已知正常的網路重測，再與另一組設定比較。不要在短時間內大量重複測試，因為等待連線逾時本身就需要時間。如果只有某個網路無法連線，請保留網路差異作為線索；若多個網路都無法連線到相同服務連接埠，應請服務維護人員檢查監聽連接埠、入口規則、憑證續期與服務運作狀態。

依比對結果判斷應在哪一處修復

連接埠可連線但交握失敗時，應優先檢查協定與傳輸參數，並確認使用的核心支援該設定組合。V2Fly 與 Xray 並非在所有欄位上都完全相容；設定能匯入，不代表目前的核心一定能執行。如果啟動日誌明確指出欄位未知或功能不受支援，請依設定需求選擇相容的用戶端選項，而不是不斷刪除欄位，直到日誌不再報錯。

如果節點測試正常，但實際請求失敗，應檢查伺服器端的目標連線能力與用戶端路由。節點測試通過，只能證明測試涵蓋的連線路徑正常。修復後仍須以原本的目標請求重新測試，並確認日誌是否命中預期出口；若需要更詳細的分層說明，可閱讀節點逾時排查順序，記錄連線成功停在哪一層，避免從頭猜起。

03 / 分辨取得內容與解析內容

訂閱失敗：先檢查更新連線路徑

訂閱更新至少包含取得網址內容、辨識內容格式及寫入節點清單三個步驟。「更新失敗」可能發生在任一環節，與已儲存的節點能否連線沒有必然關係。先保留現有群組，不要一開始就刪除所有節點。記下更新時使用的是「更新訂閱（不透過代理）」還是透過代理更新，以及日誌中最後一筆與訂閱相關的錯誤。

確認完整網址，但不要公開存取憑證

在「訂閱群組設定」中開啟對應群組，確認網址沒有多餘空格、換行、全形標點或遭截斷的查詢參數。訂閱網址通常含有可識別帳戶的資訊，複製時應從可信任來源取得完整內容，不要只複製瀏覽器顯示的一部分。本文範例統一使用 https://example.com/sub；這不是可用的訂閱網址，也不應直接填入用戶端並期待產生節點。

如果原網址曾出現在聊天紀錄、截圖或公開文件中，請先依提供者的方式重設訂閱存取憑證，再使用新網址。排查時只需記錄網域能否解析、回應狀態與錯誤摘要，不必把完整連結交給他人。即使是暫時求助，也應隱藏查詢參數、使用者識別資訊與完整訂閱回應；節點清單中還可能包含其他連線資訊，不能只遮住名稱。

確認帳戶狀態是否有效，以及訂閱入口是否已變更。清單為空可能是目前群組沒有可用項目，也可能是提供者尚未替該帳戶配置內容；這和用戶端無法解析是兩種不同問題。先查看更新日誌中的回應與項目數量，再向設定提供者確認帳戶狀態。不要猜測網址路徑或手動修改存取參數來尋找替代入口。

分別測試直接連線更新與透過代理更新

如果目前節點已失效，而更新訂閱又必須透過該節點，就會陷入「需要新節點才能更新，必須更新才能取得新節點」的循環。如果目前網路可直接連上訂閱網域，先使用「更新訂閱（不透過代理）」。若無法直接連線，但另有已知可用的設定，再嘗試透過代理更新。兩種方式都失敗時，應分別記錄結果，不要只寫「訂閱無法開啟」。

直接在瀏覽器開啟訂閱網址，可協助判斷是否出現驗證頁面或網頁提示，但不能據此認定用戶端也能順利更新。瀏覽器可能使用不同的代理、快取或登入狀態；用戶端收到的回應也可能不同。尤其遇到要求登入、網頁驗證或網路認證的頁面時，回應狀態看似成功，內容卻可能是 HTML，而非用戶端能辨識的訂閱資料。

處理格式不相容與更新後的差異

有些訂閱入口會依用戶端類型提供不同格式。能透過瀏覽器下載，不代表內容適用於 v2rayN、v2rayNG 或 v2flyNG。如果日誌顯示內容已取得，卻無法辨識出節點，請在提供者的訂閱選項中選擇適合該用戶端的格式。不要將任意設定檔改成其他副檔名，也不要把完整訂閱交給來源不明的轉換服務，以免連線資訊外洩。

更新後節點數量有變化時，先檢查目前的篩選條件、選取的訂閱群組與清單排序，再確認項目是否真的遺失。名稱相同的節點也可能已有新位址，舊項目被取代不一定是錯誤。如果有手動新增的設定，應放在獨立群組管理；更新訂閱前保留必要的本機備份，但不要把備份放進公開共享資料夾或會自動上傳的截圖資料夾。

04 / 維持一致的測試條件

速度慢：分辨延遲與傳輸速度

網頁開啟緩慢、下載速度低與影片緩衝，並不是同一種效能問題。網頁載入涉及解析、建立連線、交握與多個資源請求；下載更仰賴持續傳輸能力，互動式應用還會受到延遲波動與封包遺失影響。先說清楚是哪種操作變慢，再選擇相應的對照測試。只依節點清單中的單一延遲數值排序，無法判斷它在所有用途上都比較快。

建立可重複的效能測試

測試時固定使用同一裝置、同一網路、同一目標及相近時段，並暫停背景同步、系統更新與其他下載。先確認本機直連速度是否也變慢，再比較不同節點對同一請求的表現。如果同時更換測試網站與節點，目標伺服器的負載差異也會影響結果。一次速度變化只能當作線索，應在相同條件下再次測試，避免把偶發波動當成穩定結論。

使用 v2rayN 的測試功能時，先分辨 TCP 連線測試與實際請求測試。前者主要觀察連線能否及時建立，後者會涵蓋更多連線環節；顯示空白或逾時，也可能是測試目標無法連線，而非所有目標都失敗。記下測試類型與目標，並搭配瀏覽器實際連線結果判斷。不要為了取得好看的數字反覆修改測試設定，最後反而失去比較基準。

Wi-Fi 訊號強，不代表連線穩定。可以在同一台電腦上靠近路由器重新測試，或在條件允許時改用有線網路比較；行動網路則要留意訊號變化、熱點分享與電信方案的速度限制。如果家中多台裝置同時傳輸大量資料，對外連線壅塞會影響所有節點。這時更換用戶端通常沒有幫助，應先排除本機網路競爭，再觀察代理路徑是否仍明顯偏慢。

觀察速度在哪個階段變慢

如果第一次開啟頁面很慢，重新整理後明顯加快，應優先檢查 DNS、連線重用與交握階段；如果一開始很快，持續下載速度卻逐漸下降，則要檢查伺服器頻寬、目標限速與網路壅塞。如果只有某個網站變慢，請改用同類目標比較，並檢查分流規則是否命中、請求是否走了不合適的出口。不要只因為一個網站的表現，就將所有流量改成相同的路由方式。

日誌可以協助觀察連線是否頻繁重建、解析是否反覆失敗，但排查期間不宜長時間使用極高詳細度的日誌。大量寫入磁碟會增加負擔，也會留下更多瀏覽紀錄。擷取問題發生前後的短時間日誌即可；找到原因後，請恢復日常日誌層級。若要分享日誌，只保留錯誤前後的必要內容，並移除訂閱網址、使用者識別資訊及不適合公開的連線目標。

使用 UDP 的應用程式，需要確認協定組合、用戶端設定與伺服器端都支援相應流量。瀏覽器網頁正常，不代表即時應用使用的資料路徑也相同。有些網路對 UDP 的處理方式不同，因此應以應用程式本身的連線狀態為準。切換至 TUN 模式前，先了解它會接管哪些流量；不要把它當成提高頻寬的開關，因為它只會改變流量入口，不會憑空增加出口能力。

避免用高風險設定掩蓋效能問題

遇到大型頁面部分卡住、某些連線正常但其他連線長時間等待時，可將路徑 MTU 列為後續排查項目，但不要一開始就隨意設定過小的數值。先排除 DNS、協定不相容與目標故障；確認問題和特定網路或通道模式有關後，再依用戶端說明逐步調整並記錄原始值。每次調整後，都要重新測試正常網站與原本出問題的目標，避免只修好一處卻影響其他連線。

傳輸方式、連線多工與並行參數並非越大越好。伺服器資源有限或連線不穩定時，提高並行數可能加劇資源競爭；多工設定不相符也可能造成相容性問題。優先使用設定提供者建議的組合，只有在測試條件明確時才逐項嘗試。如果換用另一個可用節點就能恢復，而且本機設定沒有變動，記錄節點差異通常比繼續堆疊參數更有幫助。

05 / 確認由哪一端解析網域

DNS 異常：追查解析路徑

DNS 會將網域轉換為連線所需的位址，但在代理環境中，系統、瀏覽器、用戶端與遠端都可能參與解析。遇到「找不到伺服器」或網域相關逾時時，不要立刻把所有 DNS 位址都換成同一個公共服務。先確認解析失敗的是節點伺服器網域，還是要連線的網站網域；接著查明由哪一層發出查詢，以及查詢本身是否有可用的網路路徑。

先分清入口網域與目標網域

如果用戶端尚未連上節點，就已提示伺服器位址解析失敗，問題發生在代理入口之前。此時若將所有解析請求都交給尚未建立的代理處理，可能形成循環依賴。先使用系統工具查詢節點網域，確認目前網路的解析服務是否可用；必要時依設定提供者的建議選擇合適的解析路徑，但不要將節點網域直接換成任意查到的位址，因為憑證與路由也可能依賴該網域。

如果節點已連線，只有部分目標網域無法連線，請查看用戶端日誌中的解析錯誤與出口選擇。使用網域規則分流時，網域是否保留、在哪個步驟轉換為位址，都會影響規則比對。瀏覽器若啟用獨立的安全 DNS，查詢結果也可能與系統不同。先記錄目前設定，再一次只調整一個項目進行比較；不要同時修改瀏覽器、系統與用戶端的 DNS。

以下查詢指令適用於 Windows 與常見桌面環境。它們主要反映系統目前使用的解析路徑，不代表用戶端內建解析器必定會得到相同結果。查詢成功後仍須驗證實際 HTTPS 請求；直接開啟解析出的 IP 並不是相同的測試，因為許多網站會依網域進行憑證驗證、虛擬主機選擇與內容傳遞。

# Windows PowerShell
Resolve-DnsName example.com

# 支援 nslookup 的系統
nslookup example.com

透過代理測試，確認由哪一端負責解析

在 SOCKS 測試中，socks5h 會將目標網域交由代理端解析；有些工具使用 socks5 時，則會先在本機解析。兩種結果不同，表示值得進一步檢查解析路徑，但不能只靠這項差異判斷故障位置。還要搭配用戶端的 DNS 設定、路由策略與日誌，確認遠端解析請求實際送往何處，以及是否被錯誤地導回本機。

使用加密 DNS 時，也要先確認解析服務本身能否連線。若解析服務以網域作為位址，可能需要先行解析；如果它的連線也依賴目前故障的路徑，就會在啟動階段持續等待。不要照抄來源不明的整段設定。應先確認它負責哪些網域、透過哪個出口連線，以及失敗時如何處理，再依目前核心支援的格式填寫，避免混用不同核心的欄位。

IPv4 與 IPv6 的連線能力差異，也可能造成「有時能開啟，有時一直等待」。網域可能同時回傳兩類位址，但目前網路可能只為其中一類提供完整路徑。先比對日誌中實際嘗試的位址類型，再在用戶端支援的範圍內暫時調整策略進行比較。不要因為一次失敗就永久關閉整台裝置的 IPv6；應先確認調整確實與問題相關，並記下如何還原原始設定。

搭配路由規則一起檢查 DNS

排查路由時可從簡單規則開始。以下是 Xray 格式的路由片段，並非可直接啟動的完整設定；其中 proxy 與 direct 必須對應現有的出口標籤。此範例用來說明網域規則與位址規則的差異，不應直接取代用戶端產生的所有設定。圖形介面用戶端通常會重新產生執行設定，持久修改應透過「路由設定」等受支援的入口完成。

{
  "routing": {
    "domainStrategy": "AsIs",
    "rules": [
      {
        "type": "field",
        "domain": ["domain:example.com"],
        "outboundTag": "proxy"
      },
      {
        "type": "field",
        "ip": ["geoip:private"],
        "outboundTag": "direct"
      }
    ]
  }
}

規則通常依序比對，過於寬泛的前置規則可能讓後續精確規則無法命中。區域網路位址也不應隨意送往遠端代理，否則本機管理頁面與內部網路服務可能受到影響。修復 DNS 後，重新確認同一目標是否命中預期出口；查詢有回傳位址，不代表路由與連線都已完成，最好保留一筆實際請求日誌作為驗證。

最後再考慮清除快取。Windows 的 ipconfig /flushdns 只會清除系統 DNS 快取，不會自動清除瀏覽器獨立快取、用戶端快取或遠端快取。先修正問題來源，再關閉並重新開啟相關應用程式測試；如果每次清除快取都只能短暫恢復，就應繼續檢查解析策略與網路切換，而不是把反覆清除快取當成長期的處理方式。

06 / 確認應用程式的流量入口

系統代理未生效：確認流量接管範圍

系統代理是作業系統提供給應用程式的一組代理設定，並不會強制接管所有網路流量。在 v2rayN 中選擇「自動設定系統代理」後，通常只有會讀取相應設定的應用程式會使用代理；獨立代理設定、瀏覽器擴充功能、命令列環境變數與 TUN 模式也可能形成其他流量入口。排查時先確認目標應用程式實際讀取哪一組設定，再處理對應位置。

確認系統代理位址與本機監聽狀態

Windows 使用者請先在 v2rayN 的「系統代理」選單中選擇「自動設定系統代理」，再到系統「設定 → 網路和網際網路 → Proxy」確認實際生效的位址與連接埠。具體項目可能是手動代理或設定指令碼，請以用戶端目前的運作方式為準。不要只看系統匣圖示的顏色；其他程式改寫系統設定後，用戶端介面不一定會立即反映所有變更。

如果代理位址是本機回送位址，必須與用戶端實際監聽的連接埠相同。127.0.0.1 只代表目前這台裝置，適用於本機應用程式連線至本機用戶端，不能用來讓手機連上電腦代理。如果連接埠曾經變更，系統或瀏覽器可能還保留舊值。先透過明確指定代理的請求確認新連接埠可用，再重新套用系統代理設定，避免在沒有程式監聽的位址上反覆切換模式。

macOS 可在「系統設定 → 網路」中選取目前的網路服務，再進入「詳細資訊 → 代理」檢查設定；不同系統版本的介面名稱可能略有差異。Wi-Fi 與有線連線可能對應不同的網路服務，切換網路後要確認選取的項目。Linux 桌面環境的系統代理入口及應用程式讀取方式不盡相同，有些應用程式只會使用自身設定，不能直接照搬其他桌面環境的操作方式。

排除多組代理設定互相覆蓋

如果瀏覽器與其他應用程式的狀況不同，請暫時停用瀏覽器中的代理擴充功能，並檢查是否設有啟動參數或管理政策。命令列工具則可能讀取 HTTP_PROXY、HTTPS_PROXY、ALL_PROXY 與 NO_PROXY 等環境變數。修改環境變數後，已啟動的程序可能仍保留舊值，需要重新開啟終端機或應用程式；切換系統代理不一定會同步變更這些變數。

不要同時執行多個會修改系統代理或預設路由的工具。它們可能輪流覆蓋位址，也可能讓原本應直連的代理出口再次進入另一條通道，形成循環。先退出其他流量接管程式，只保留一個用戶端與明確的流量入口，再測試原本的應用程式。若必須搭配使用，應先確認每一段的監聽位址與流向，不要仰賴預設設定自動銜接。

「不變更系統代理」不等於「清除系統代理」。前者通常會保留系統目前的狀態，後者才會主動移除用戶端設定的代理入口。因此，關閉視窗、結束系統匣程式與清除代理也不能互相取代。退出用戶端後無法連線時，先確認系統是否仍指向本機連接埠；恢復正常設定後再測試，不要靠重新啟動失效節點維持基礎網路。

分開排查區域網路分享與 TUN

手機要使用電腦代理時，請在電腦的「參數設定」中啟用「允許來自區域網路的連線」，確認監聽連接埠與電腦的內網位址，再視需要設定防火牆的輸入規則。防火牆規則應限於可信任的網路與必要連接埠，不要為了排查而整體關閉防護。手機與電腦也必須能在區域網路中互相連線；訪客網路隔離與熱點限制都可能造成阻擋。

TUN 模式異常時，應優先檢查虛擬介面、權限與路由是否建立成功。啟用後如果連節點伺服器本身都無法連線，請確認是否出現出口流量再次被接管的循環。先關閉 TUN，透過明確指定的本機代理確認節點可用，再單獨啟用 TUN 進行比較。更多分享設定請參閱允許區域網路連線設定；重新測試時，還要確認目標應用程式與本機網路服務都能正常使用。

07 / 分辨介面與核心程序

用戶端當機：先保留狀況再修復

用戶端無法開啟、視窗一閃即關閉，以及節點核心程序結束，需要分開處理。前兩者主要影響圖形介面，後者則可能出現介面仍在、所有請求卻都失敗的狀況。先記錄作業系統、處理器架構、下載的套件類型，以及故障發生於啟動、匯入還是連線階段。不要直接刪除整個使用者資料目錄，訂閱群組、路由規則與問題日誌可能都儲存在其中；刪除後反而更難找出原因。

確認安裝套件與系統環境

先前往用戶端下載頁面確認平台與處理器架構。Windows 的 v2rayN 桌面版與傳統 WPF 版採用不同的介面實作，執行需求與系統相容條件應依所選套件的說明確認；macOS 應分清 Apple Silicon 與 Intel；Linux 則還要確認處理器架構與發行版套件格式。套件下載完成，不代表它適用於目前的裝置；架構不符可能導致程式在啟動時立即結束。

Windows 若出現明確的執行階段元件缺失提示，請依錯誤訊息指出的元件與架構處理，不要下載來源不明的零散動態連結程式庫。可攜式版本應完整解壓縮後再執行，不要只把主程式從壓縮檔中拖出來。路徑權限、暫存目錄清理，以及檔案遭安全軟體隔離，都可能造成啟動不完整；請依系統提示逐項確認，不要把所有問題都歸因於系統版本。

macOS 若提示無法驗證開發者，先確認檔案來源與下載套件類型，再依「系統設定 → 隱私權與安全性」中的相關提示處理。不要為了開啟單一應用程式，就全面關閉系統安全機制。如果提示檔案損毀、元件缺失或架構不符，也不要一概當成權限問題；可參考macOS 首次開啟與權限說明，分辨系統攔截提示與實際程式異常。

查看日誌，不要一再重新啟動

介面仍可開啟時，先確認是否分別有用戶端日誌與核心日誌。如果匯入後立即出現設定錯誤，優先查看第一筆解析失敗或欄位不受支援的紀錄；後續大量連線失敗可能只是連帶結果。如果每次按下連線都提示連接埠被占用，應確認是否已有另一個執行個體在運作，而不是不斷更換連接埠，導致系統代理與監聽設定越來越不一致。

Windows 可使用以下指令查詢示範連接埠的監聽程序編號。取得編號後，請在工作管理員中確認程式身分；不要只因為編號陌生就直接結束系統程序。如果是重複啟動的用戶端，先從系統匣正常結束多餘的執行個體，再重新啟動一個。如果該連接埠確實由其他服務使用，請為用戶端選擇空閒連接埠，並同步更新所有使用該連接埠的應用程式設定。

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

Linux 圖形程式一啟動就結束時，可從終端機啟動已安裝的程式，查看是否出現相依項目缺失、顯示環境或權限相關錯誤。軟體套件安裝程式的錯誤也應先排除，再測試應用程式；手動複製單一執行檔未必能補齊相依項目。如果程式以一般權限即可執行，就不應為了方便而長期使用管理員身分啟動；只有確實需要網路接管功能時，才另外處理權限。

使用最精簡的設定找出問題範圍

懷疑使用者設定檔損毀時，先退出程式，再依用戶端支援的方式備份設定目錄，保留原始檔案不動。若要建立新的設定環境，應使用新的使用者資料目錄或依說明重設；不要認定只要更換安裝目錄，就一定會產生獨立設定。先在空白環境確認介面可以開啟，再只加入一個已知有效的設定，暫時不要匯入所有路由、訂閱與自訂參數。

如果最精簡的環境運作正常，再依序恢復訂閱、路由與特殊網路功能；每恢復一項就重新測試。若恢復某項後再次當機，就能將問題範圍縮小至該部分，不必丟棄所有設定。如果兩種介面版本的表現不同，可閱讀桌面版與 WPF 版的差異，依系統相容性選擇；但不要把更換介面當成節點或 DNS 問題的通用修復方式。

08 / Android 網路與背景限制

行動裝置專項：權限與網路切換

Android 首選 v2rayNG；需要 V2Fly 核心相容路徑時，可考慮 v2flyNG。兩者的圖形介面操作相近，但核心支援範圍與部分設定不一定完全一致。手機連線後仍無法瀏覽、鎖定螢幕後中斷，或切換網路後失效時，應先檢查 VPN 授權、應用程式路由與背景執行狀態，再回頭檢查節點與 DNS，避免將行動系統限制誤判為伺服器故障。

先確認 VPN 服務確實已啟動

首次啟動連線時，系統會要求授權建立 VPN 連線；同意後，用戶端才有條件建立相應的本機虛擬網路介面。狀態列出現 VPN 圖示只代表服務已建立，不表示遠端節點已連線成功。啟動後應立即查看應用程式日誌，確認沒有設定解析失敗、權限遭拒或服務隨即停止，再使用已知目標實際測試連線。

同一個使用者環境中的 VPN 服務通常無法由多個應用程式同時接管。如果已有其他網路工具、工作環境政策或系統服務占用入口，新連線可能取代原有服務，也可能無法建立。先停止其他流量接管應用程式，再啟動單一用戶端。若裝置受組織管理，也應確認管理政策是否限制 VPN 設定；不能靠反覆安裝不同用戶端，繞過裝置本身的授權要求。

如果已設定「一律開啟 VPN」或「封鎖未經 VPN 的連線」，用戶端未啟動或連線失敗時，系統可能依政策封鎖其他網路。排查前先記下這些選項，必要時可暫時關閉以比較基礎網路，完成後再視需要恢復。不要只在應用程式內停止連線，卻忽略系統仍要求所有流量經過已停用的服務。

檢查依應用程式代理與背景執行狀態

只有部分應用程式異常時，請檢查用戶端是否啟用了依應用程式代理或排除清單，並確認目前模式是「只代理選取的應用程式」還是「略過選取的應用程式」。同一份應用程式清單在兩種模式下的作用正好相反。修改後請重新建立連線，並完全結束後再開啟目標應用程式，避免舊連線仍沿用先前的路徑。如果工作資料與個人資料分開，也要確認正在測試的應用程式屬於哪個環境。

鎖定螢幕後中斷、亮起螢幕後又恢復，通常與系統電池最佳化、背景資料或裝置廠商的自動啟動管理有關。請在系統的應用程式資訊中檢查電池策略與背景網路權限；若需要持續連線，再授予適當權限，不必關閉整台裝置的省電功能。觀察中斷時 VPN 圖示是否消失、應用程式服務是否重新啟動，以及日誌中是否有重新啟動紀錄，以分辨程序遭回收與遠端連線逾時。

前景服務通知有助於確認執行狀態，有些系統也會另外管理通知顯示。通知消失不一定代表核心已停止，應搭配系統 VPN 狀態與日誌判斷；反過來說，通知仍在也不代表遠端連線可用。如果恢復背景權限後，仍在相同條件下中斷，請記錄螢幕鎖定時間、供電狀態與網路類型，再逐項比較，避免一次變更多個系統選項。

切換網路後，重新驗證解析與出口

從 Wi-Fi 切換至行動數據後，原有連線可能已失效，DNS、IPv6 與預設路由也可能有所變更。先等網路恢復正常，再中斷並重新連線用戶端，接著送出新的請求測試。如果只有特定 Wi-Fi 無法連線，請檢查是否需要網頁認證或啟用了裝置隔離；如果只有行動數據下無法使用，則比較節點連接埠的可達性與解析結果，不要直接重設所有應用程式資料。

手機連線至電腦分享的代理時，請在 Wi-Fi 的代理設定中填入電腦的區域網路位址，以及實際提供的 HTTP 或混合連接埠。不能填入手機自己的回送位址，也不能將只提供 SOCKS 的連接埠當成 HTTP 連接埠使用。此設定通常只會影響遵循 Wi-Fi 代理設定的應用程式。測試前先確認電腦保持開機且用戶端正在監聽，再依系統代理章節檢查區域網路連線與防火牆。

如果設定匯入成功，啟動時卻出現錯誤，請重新確認設定所需的核心功能。v2rayNG 與 v2flyNG 應使用各自支援的設定格式與功能組合，不要靠修改節點名稱判斷相容性。需要重新安裝時，請從Android 下載入口依處理器架構選擇套件；多數較新的裝置適用 arm64，不確定時可參考通用套件說明，不要只依檔案大小猜測。