v2rayN 問題診斷與故障排除大全

一、已連線但無法上網

先確認故障位於哪一層

「客戶端顯示執行中」只代表本機核心程序已啟動，不代表遠端節點可達，也不代表瀏覽器正在使用該代理。完整鏈路依序經過應用程式、系統代理或 VPN 介面、本地監聽連接埠、路由規則、DNS、遠端節點與目標網站。排查第一步不是反覆點擊連線，而是判斷斷點位於本機之前還是節點之後。先關閉客戶端的系統代理或 VPN 開關，確認一般網路能否開啟常用網站；如果直接連線本身不可用，應先修復 Wi-Fi、網路線、閘道器或電信業者連線。基本網路正常後，再重新啟動客戶端。

接著在 v2rayN 中選擇一個設定完整且已知可用的節點，將路由暫時切換至全域模式，並啟用系統代理。全域模式僅用於診斷，可暫時繞過複雜的分流規則。如果此時恢復存取，表示節點與核心基本正常，問題集中在路由規則、DNS 或繞過清單；如果仍然無法存取，則繼續檢查本地監聽、節點連通性與應用程式代理範圍。診斷完成後應恢復適合日常使用的路由模式，避免長期保留臨時測試狀態。

檢查本地監聽與應用程式代理

桌面客戶端通常會在本機回送位址上提供 HTTP、SOCKS 或混合代理連接埠。連接埠遭其他程式佔用時，核心可能啟動失敗，也可能啟動後無法接受連線。開啟 v2rayN 記錄，尋找「address already in use」「bind failed」「failed to listen」等意思明確的錯誤。發現連接埠衝突後，可以結束佔用該連接埠的程式，或在 v2rayN 設定中改用未被佔用的連接埠，然後重新啟動核心。不要只修改瀏覽器代理而忽略客戶端監聽連接埠，兩端連接埠必須一致。

Windows 可在 PowerShell 中檢查連接埠是否處於監聽狀態。以下範例中的連接埠應替換為客戶端介面顯示的實際本地連接埠：

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

Test-NetConnection 127.0.0.1 -Port 10809

如果連接埠正常監聽，但只有某個應用程式無法連線，需要確認該應用程式是否遵循系統代理。有些程式內建代理設定，有些程式只會在啟動時讀取系統代理，還有些程式會直接建立連線。對於提供自訂代理選項的應用程式，可明確填入 127.0.0.1 與對應的 HTTP 或 SOCKS 連接埠進行對照測試。若明確指定代理可用而系統代理無效，問題不在節點，應前往「系統代理無效」章節。

用最小設定隔離路由與 DNS

複雜設定中常見的斷點包括：網域規則提前命中直連、目標 IP 被錯誤攔截、DNS 查詢經由不可達的出口、訂閱合併後留下無效的出站標籤。診斷時可暫時停用自訂路由，只保留一個代理出站與一個直連出站。若最小設定可用，再逐組恢復規則，每恢復一組就測試同一批網址。不要一次匯入多套規則後再猜測是哪一條造成故障。

記錄是判斷出站路徑的主要依據。正常請求通常會看到目標網域或 IP、選定的出站標籤以及連線結果。若記錄完全沒有新增請求，表示應用程式流量沒有進入客戶端；若有請求但立即出現解析失敗，應檢查 DNS；若連線遠端節點時逾時，應進入下一章；若只有部分網域失敗，優先檢查分流與網域解析。透過「是否進入本地連接埠、是否完成解析、是否建立遠端連線」三個判斷點，可以將模糊的「無法上網」縮小為可操作的問題。

還要檢查系統時間。TLS 交握依賴正確的日期、時間與時區，裝置時間偏差過大時會出現憑證尚未生效或已失效的錯誤。啟用作業系統自動校時後，完全退出客戶端，再重新開啟並測試。企業網路、校園網路或公共熱點可能還要求先透過入口頁面完成驗證，此時應先關閉代理，在瀏覽器中完成網路驗證，再啟用客戶端。若驗證頁面被代理攔截，表面現象同樣會是所有網頁都無法開啟。

二、節點逾時、連線遭拒與交握失敗

區分三類連線錯誤

節點測試中的「逾時」「連線遭拒」與「交握失敗」代表不同階段。逾時通常表示資料封包未在規定時間內得到回應，可能是伺服器不可達、連接埠遭過濾、線路丟包或位址解析錯誤；連線遭拒表示目標主機可達，但對應連接埠沒有服務監聽，常見於連接埠填寫錯誤或伺服器端尚未啟動；交握失敗則表示 TCP 已建立，協定參數、TLS、傳輸方式或驗證資訊不相符。只有先區分階段，後續操作才不會停留在無效的重複測速。

不要只依賴客戶端清單中的單次延遲測試。部分測試方式只檢查 TCP 建立連線，無法涵蓋協定交握；另一些測試會請求特定網址，結果又會受到 DNS 與路由影響。應同時查看執行記錄，並在桌面系統上測試伺服器位址與連接埠的基本可達性。Windows 可使用以下命令：

Resolve-DnsName node.example.com
Test-NetConnection node.example.com -Port 443

其中 node.example.com 是文件範例位址，實際操作應填入設定中的伺服器網域。若網域無法解析，先處理 DNS；若解析結果存在但 TCP 測試失敗，檢查網路路徑、連接埠與伺服器狀態；若 TCP 成功而客戶端交握失敗，重點核對 UUID、密碼、協定類型、傳輸方式、TLS 開關、SNI、Host、路徑與 REALITY 參數。

逐項核對協定參數

VMess、VLESS、Trojan 等設定不能只比較伺服器位址與連接埠。協定欄位必須整體相符。以 VLESS 為例，使用者識別碼、流控方式、安全層、傳輸類型與伺服器名稱彼此相關；REALITY 設定還需要對應的公鑰、短識別碼與伺服器名稱。WebSocket 設定通常需要正確的路徑與 Host；gRPC 需要匹配服務名稱；TLS 連線中的 SNI 應與伺服器憑證及入口設定一致。任何欄位遭訂閱轉換工具截斷，都可能在 TCP 成功後立即交握失敗。

手動編輯節點時，應優先與提供方給出的完整原始設定逐項比對，而不是憑經驗補齊。大小寫、前導斜線、空格與不可見字元都可能造成差異。複製 UUID 或金鑰後，可以先貼到純文字編輯器檢查首尾空格，再寫入客戶端。匯入 QR Code 與分享連結後也應開啟節點詳細資訊複核，因為舊格式可能無法攜帶較新的傳輸欄位。若同一節點在一台裝置可用、另一台不可用，將兩端的協定詳細資訊並排比較，通常比重新匯入更有效。

辨識線路、網路與伺服器端問題

同一設定在行動網路可連線、在家用寬頻逾時，通常表示客戶端設定本身有效，應檢查本地網路、路由器、DNS 或上游路徑。反過來，若所有網路環境都在相同階段失敗，伺服器端異常或參數不符的機率更高。可使用手機熱點讓桌面裝置進行一次對照測試，也可以在 Android 裝置上切換 Wi-Fi 與行動數據。測試時保持節點、客戶端路由模式與 DNS 設定不變，只替換接入網路。

節點位址若使用網域，還要留意解析出的 IP 是否在不同網路中發生變化。CDN、雙堆疊解析或本地 DNS 快取可能讓兩台裝置連線到不同位址。使用 nslookup 或 Resolve-DnsName 記錄結果，再與客戶端記錄中的實際目標 IP 比對。若網域同時回傳 IPv4 與 IPv6，而目前網路的 IPv6 路由不完整，連線可能等待很久後才回退。此時可暫時優先使用 IPv4 進行驗證，但不應在沒有證據時永久關閉系統的 IPv6 功能。

若記錄出現憑證名稱不符、未知憑證簽發者或交握協定不一致，不要把「略過憑證驗證」當作一般解決方法。先檢查裝置時間、SNI、伺服器名稱與 TLS 設定。暫時關閉驗證只能用於確認問題是否位於憑證鏈，確認後仍應恢復並修正設定。對於來自訂閱的節點，應優先重新取得完整設定；如果多個客戶端同時出現相同交握錯誤，則需要由設定提供方核對伺服器端入口，而不是在客戶端反覆更換無關選項。

節點逾時也可能是本地安全軟體攔截核心程序或阻止建立新的出站連線。判斷方法不是直接關閉所有防護，而是查看攔截記錄，並確認 v2rayN 使用的核心程式是否獲准存取目前網路。若客戶端目錄被移動、核心檔案路徑變更，舊規則可能不再匹配。重新授權目前實際路徑後重新啟動客戶端。完成排查後，再以真實網頁與檔案傳輸驗證，單純顯示「延遲可用」不足以證明完整鏈路正常。

三、訂閱更新失敗、節點為空或內容未變更

先判斷是請求失敗還是解析失敗

訂閱更新包含下載與解析兩個階段。請求失敗時，客戶端無法取得訂閱正文，記錄通常會出現逾時、名稱解析失敗、連線遭拒或 HTTP 狀態異常；解析失敗時，請求可能已成功，但回傳內容不是客戶端支援的訂閱格式，最終表現為節點數量不變、節點清單為空或提示格式錯誤。排查時應先閱讀更新記錄，不要只根據清單結果判斷。兩類問題的處理方向完全不同。

先檢查訂閱網址是否完整。網址中的查詢參數、大小寫與特殊字元可能是驗證的一部分，複製時缺少結尾字元就會失效。以下網址僅用於說明結構，不能實際用作訂閱：

https://example.com/subscription?token=xxxx&client=v2rayN

如果網址經由聊天工具或文件轉貼，可能被自動換行或附加標點。建議在訂閱群組設定中重新貼上，並檢查首尾是否有空格。不要把網頁管理網址、節點分享頁或登入頁當作訂閱網址。在瀏覽器中能開啟頁面，也不代表回傳內容適合客戶端解析；反之，瀏覽器直接顯示一長串編碼文字通常是正常的訂閱回應，不代表內容損壞。

決定更新請求是否經過代理

訂閱伺服器的可達路徑可能與節點流量不同。客戶端通常允許選擇更新訂閱時使用直連、目前代理或系統代理。若直連請求逾時，而已有節點仍可連線，可將訂閱更新切換為經由目前代理；若代理節點本身已失效，強制透過代理更新又會形成閉環，此時應改用直連或先匯入一個可用節點。判斷原則是根據記錄確認請求實際使用哪個出口，而不是在多個選項之間隨機切換。

首次安裝且清單為空時，沒有現成代理可供訂閱更新使用，因此應先確認訂閱網址能透過目前基本網路存取。已有節點的使用者可先選取一個實際可用的節點，再執行更新。更新完成後，檢查訂閱群組的最後更新時間、節點清單變化與錯誤記錄。如果手動更新成功而自動更新失敗，重點檢查自動更新間隔、裝置休眠、客戶端是否常駐，以及更新工作啟動時代理核心是否已就緒。

關於更新請求未經代理、連結失效、逾時與格式異常等分支，可繼續閱讀v2rayN 訂閱更新失敗的六種原因與自動更新設定方法。該文著重自動更新設定，本章則著重根據記錄區分故障階段。

處理格式、快取與群組覆蓋

常見訂閱內容包括 base64 編碼的分享連結集合、逐行排列的分享連結與原生 JSON 設定。不同客戶端及核心支援的欄位範圍並不完全相同。v2rayN 訂閱可以包含多種常見節點類型；v2rayNG 與 v2flyNG 在核心能力和匯入欄位上可能存在差異。如果伺服器回傳的是網頁 HTML、登入提示、錯誤 JSON 或空白文字，客戶端就無法按節點訂閱格式解析。此時應檢查回應內容的實際類型，並確認帳戶狀態與訂閱入口。

若記錄顯示下載與解析都成功，但清單看起來沒有變化，應檢查訂閱群組篩選、別名覆蓋與去重策略。部分使用者啟用了僅顯示目前群組、依關鍵字篩選或依備註去重，新節點可能已匯入但被介面過濾。先清空搜尋框，切換至完整伺服器清單，再查看目標群組。不要立即刪除所有舊節點；先匯出目前設定或複製群組，再執行一次覆蓋更新，這樣可以判斷是訂閱內容沒有變化，還是客戶端合併策略隱藏了差異。

訂閱快取也會造成「更新成功但仍是舊內容」。可以完全退出客戶端，重新開啟後手動更新；若客戶端提供清除訂閱快取或不使用快取的選項，可在備份後執行。系統代理指向目前客戶端時，不建議在核心停止期間用瀏覽器判斷訂閱是否可達，因為瀏覽器請求可能仍指向已關閉的本地連接埠。應先關閉系統代理，確認直連狀態後再進行對照。

自動更新間隔不宜設定得過短。高頻請求無法提升節點品質，反而可能遇到伺服器頻率限制，並在網路切換或裝置喚醒時產生重疊工作。根據訂閱實際變化頻率設定合理週期，需要時手動更新即可。更新後若只有部分新協定節點無法使用，應回到節點詳細資訊核對欄位，並確認所選客戶端核心支援對應設定。需要了解格式差異時，可閱讀V2Ray 訂閱格式介紹與轉換說明。

四、連線成功但網頁慢、下載慢或速度波動

分開測量延遲、吞吐量與穩定性

低延遲不等於高下載速度。延遲反映一次往返所需時間，吞吐量取決於線路容量、壅塞、丟包、伺服器負載與 TCP 行為；穩定性則反映連續連線中是否頻繁抖動或重傳。客戶端節點清單中的測試結果只能作為初步篩選，不能取代實際存取。診斷速度問題時，應固定同一裝置、同一接入網路、同一測試時段與同一目標，分別比較直連、單一節點與另一個節點，避免將目標網站本身的負載誤判為客戶端故障。

先關閉其他下載、雲端硬碟同步、系統更新與影片播放，再測試一般網頁首次開啟、連續載入圖片及一個合法檔案下載。若同一網路上的所有節點都很慢，而切換手機熱點後恢復，應優先檢查本地寬頻、Wi-Fi 干擾、路由器效能與上游路徑；若只有一個節點很慢，通常是節點線路或負載問題；若瀏覽器很快但特定應用程式很慢，應檢查該應用程式是否使用相同代理、是否採用 UDP、是否有獨立 DNS 或連線並行限制。

檢查路由是否讓流量繞路

分流規則錯誤會讓原本適合直連的流量經過遠端節點，或讓需要代理的請求先嘗試直連後逾時回退。兩種情況都會增加頁面首次開啟時間。開啟記錄觀察慢速請求最後命中的出站標籤，尤其注意網域規則、IP 規則與預設規則的順序。路由通常按由上至下或依核心規定的優先順序匹配，一條範圍過大的規則可能遮蔽後續細分規則。調整時先複製現有規則集，再用少量網域驗證，不要直接重寫全部設定。

以下是一個用於理解分流結構的簡化規則。此片段展示 geosite 與預設出站的關係，實際標籤名稱需要與客戶端現有出站保持一致：

{
  "routing": {
    "domainStrategy": "AsIs",
    "rules": [
      {
        "type": "field",
        "domain": ["geosite:cn"],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "network": "tcp,udp",
        "outboundTag": "proxy"
      }
    ]
  }
}

domainStrategy 決定網域匹配與解析之間的關係。使用 AsIs 時會優先依原始網域規則處理，避免不必要的提前解析；需要依 IP 規則分流時，核心可能在後續進行解析。沒有一套設定適用於所有網路，應根據規則結構選擇。修改後必須重新載入設定，並在記錄中確認新規則已生效。

排查 MTU、UDP 與多路複用

網頁能開啟但大檔案卡住、影片間歇性緩衝或部分請求長時間停頓，可能與路徑 MTU 有關。VPN 介面、通道與某些接入網路會增加封裝開銷，過大的封包若無法正確分片，會表現為小請求正常、大量傳輸異常。桌面端可先比較系統代理模式與虛擬網卡模式：如果系統代理正常而虛擬網卡模式異常，請檢查該模式的 MTU、驅動程式與路由表。不要憑經驗將 MTU 降得過低，應逐步調整並觀察大檔案傳輸是否穩定。

UDP 對 DNS、即時通訊與部分新型傳輸很重要，但不同節點與網路對 UDP 的支援可能不同。若啟用 UDP 後出現間歇性問題，可先在應用層確認是否確實需要，再查看核心記錄是否有 UDP 逾時。只關閉某個應用程式的 UDP 與全域停用 UDP 是兩種不同操作，後者可能改變 DNS 與其他程式的行為。對於使用 QUIC 的網頁，瀏覽器也可能在 UDP 不穩定時回退，造成首次載入變慢、之後恢復正常。

多路複用可以減少部分情境下的重複建立連線，但並非數值越高越快。線路明顯丟包時，過多請求共用連線可能互相影響；伺服器未以相同方式設定時也可能交握失敗。排查速度波動時，可以暫時關閉多路複用進行對照，而不是同時調整並行數、快取、DNS 與傳輸協定。若關閉後穩定性提升，再根據節點伺服器端能力決定是否恢復。

檢查本機資源與無線網路

核心需要進行加密、解密、路由匹配與記錄寫入。老舊裝置、省電模式或大量詳細記錄都可能限制吞吐量。傳輸時觀察 CPU、記憶體與磁碟使用量：若單一核心持續高負載，瓶頸可能位於本機處理；若資源使用量較低但網路吞吐量週期性歸零，則更像是線路丟包、無線干擾或伺服器壅塞。Android 裝置還會受到省電策略與背景限制影響，相關處理請見行動端章節。

Wi-Fi 訊號格數無法完整反映鏈路品質。同頻干擾、路由器過熱、裝置距離與自動頻段切換都會造成抖動。條件允許時先使用有線網路測試；只能使用無線網路時，靠近路由器並暫停其他裝置的大流量工作。若每天在固定時段變慢，而客戶端設定沒有變化，通常應記錄時段、接入網路與節點差異，避免反覆重新安裝客戶端。穩定性問題需要多次、低干擾的對照資料，而不是一次峰值結果。

五、DNS 解析失敗、網域污染現象與位址不一致

判斷是網域問題還是連線問題

DNS 故障常表現為網頁提示找不到伺服器、記錄出現解析失敗、同一節點使用 IP 可以連線而使用網域逾時，或部分網域開啟至錯誤位址。首先區分「沒有解析結果」和「解析到不可用位址」。前者通常與 DNS 伺服器不可達、代理 DNS 設定錯誤或系統快取異常有關；後者可能來自快取、分流策略、IPv4 與 IPv6 優先順序或不同 DNS 的回傳差異。直接更換一串 DNS 位址並不能說明原因，應先記錄目前解析結果。

Windows 可使用以下命令查看系統解析結果與指定類型的回傳內容：

nslookup node.example.com
Resolve-DnsName node.example.com -Type A
Resolve-DnsName node.example.com -Type AAAA
ipconfig /displaydns

macOS 與 Linux 可使用 nslookup，也可依系統環境使用 dig。對照客戶端記錄中的目標 IP，判斷請求使用的是系統 DNS、客戶端內建 DNS 還是遠端解析。若命令列結果正常而客戶端記錄解析失敗，重點檢查客戶端 DNS 設定與出站標籤；若系統與客戶端都失敗，應先檢查網路提供的 DNS、路由器轉送與本機防火牆。

理解本地解析與遠端解析

系統代理主要轉送應用程式的 HTTP 或 SOCKS 流量，應用程式發起的 DNS 查詢不一定會自動經過代理。某些瀏覽器會使用自身的安全 DNS，某些程式直接呼叫系統解析，SOCKS 客戶端也可能選擇先在本地解析網域，再只將 IP 交給代理。因此同一台裝置上的不同應用程式可能取得不同位址。排查時要確認應用程式傳給代理的是網域還是已解析的 IP，並檢查瀏覽器內建 DNS 設定是否覆蓋系統策略。

虛擬網卡模式通常能接管更廣泛的流量，但仍需要正確的 DNS 劫持、路由與排除規則。若啟用後所有網域都失敗，而直接存取 IP 有回應，表示虛擬介面已接管流量，但 DNS 請求沒有到達可用的解析器。檢查客戶端產生的 DNS 入站、虛擬位址範圍與路由表，確認 DNS 伺服器本身不會再次經過錯誤出站而形成迴圈。修改虛擬網卡相關設定後，應停止核心、等待介面釋放，再重新啟動。

遠端解析適合需要由代理出口決定網域位址的情境，本地解析則更適合依本地網路取得就近位址的服務。兩者不能簡單視為優劣關係。若路由規則先依網域決定出站，通常應保留原始網域資訊；若規則依賴 IP 集合，則需要在適當階段解析。設定中同時存在多個 DNS 伺服器時，還應明確每個伺服器的匹配網域、查詢出口與失敗回退，避免查詢在直連與代理之間循環。

處理快取、IPv6 與 Fake DNS

更換 DNS 後，舊記錄可能仍保留在作業系統、瀏覽器與客戶端快取中。Windows 可執行 ipconfig /flushdns 清除系統快取，之後完全退出瀏覽器與客戶端再測試。清除只會移除快取，不會修復錯誤的路由或 DNS 設定；如果記錄很快再次出錯，應繼續檢查實際查詢路徑。瀏覽器自身快取與安全 DNS 也要單獨核對，不能只依賴系統命令。

雙堆疊網路中，網域可能同時回傳 A 與 AAAA 記錄。系統會根據網路狀態與位址選擇策略決定連線順序。如果路由器廣播了 IPv6 但上游連線不完整，應用程式可能先等待 IPv6 逾時，再回退至 IPv4，表現為頁面首次開啟緩慢。可以分別查詢 A 與 AAAA，並在記錄中觀察實際嘗試的位址。暫時優先使用 IPv4 可用於驗證，但最終應修復路由器 IPv6、代理出站或客戶端網域策略，而不是永久掩蓋問題。

Fake DNS 會向應用程式回傳保留位址，再由客戶端還原原始網域進行路由。它適合虛擬網卡接管，但要求保留位址池不與區域網路、公司網路或其他 VPN 衝突。若啟用後區域網路裝置無法連線、特定應用程式識別到異常位址或重新啟動後舊映射失效，應檢查位址池、排除網域與快取生命週期。區域網路印表機、路由器管理網域與內部業務網域通常需要依實際網路設定為本地解析或直連。

完成 DNS 修復後，應同時測試節點網域、一般網頁網域與區域網路網域。只測試一個公開網站，無法涵蓋訂閱更新、節點入口與本地裝置存取。若問題只發生在某個應用程式，檢查該應用程式是否啟用了獨立 DNS；若多個裝置在同一路由器上表現一致，則優先檢查路由器的 DNS 轉送與 IPv6；若僅在客戶端開啟時異常，則回到核心 DNS、路由出站與虛擬介面設定逐項驗證。

六、系統代理已啟用但瀏覽器或應用程式無效

確認作業系統中的代理值

v2rayN 的「系統代理」開關負責將作業系統代理位址指向本地監聽連接埠。核心執行與系統代理是兩個獨立狀態：核心已啟動但系統代理關閉時，只有明確設定代理的應用程式會經過客戶端；系統代理已寫入但核心停止時，應用程式會連線到沒有服務的本地連接埠。排查時應同時確認核心執行狀態、本地連接埠監聽與系統代理位址，三項缺一不可。

Windows 中可在系統網路代理設定裡查看手動代理位址與連接埠，也可以透過 PowerShell 查看目前使用者的相關設定。重點不是記住登錄檔位置，而是確認介面顯示的連接埠與 v2rayN 實際監聽的連接埠一致。若切換設定後連接埠發生變化，舊系統代理可能仍指向之前的連接埠。先關閉系統代理，再由客戶端重新啟用，通常比手動修改多個位置更可靠。

macOS 上的代理設定會依網路服務儲存，Wi-Fi 與有線網路可能各有一套設定。切換接入方式後，如果客戶端只更新了舊網路服務，新連線就不會使用代理。Linux 桌面環境對系統代理的支援存在差異，有些應用程式讀取桌面設定，有些讀取環境變數，還有些完全使用自身的網路設定。因此「系統代理已啟用」不代表所有桌面應用程式都會自動遵循。

處理瀏覽器快取與獨立代理設定

瀏覽器通常會讀取系統代理，但擴充功能、企業政策、安全 DNS 與啟動參數可能覆蓋系統設定。如果瀏覽器無效，先建立一個不載入額外擴充功能的臨時設定進行對照，或檢查瀏覽器網路設定是否明確寫入了其他代理。修改系統代理後完全退出瀏覽器，再重新開啟，因為部分程式只會在啟動時讀取代理。若新設定可用，問題位於原瀏覽器設定，而不是 v2rayN 節點。

可以使用命令列明確指定本地代理，驗證核心是否接受請求。以下連接埠僅為範例，應替換為客戶端實際的 HTTP 連接埠：

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

如果明確指定代理成功而瀏覽器失敗，表示節點、核心與本地監聽都正常，應繼續檢查系統代理讀取鏈路。如果兩個命令都失敗，查看客戶端記錄中是否收到請求；完全沒有記錄通常是連接埠或安全軟體問題，有請求但連線失敗則回到節點、DNS 或路由章節。使用 --socks5-hostname 時，網域由 SOCKS 代理端處理，可用於與本地解析進行對照。

理解繞過清單與 PAC 行為

系統代理通常包含繞過本地位址、區域網路網段或特定網域的清單。範圍過大的繞過規則會讓目標請求直接連線，看起來像代理沒有生效。檢查是否存在通配符過寬、網域後綴寫錯，或將測試網站包含在直連清單中的情況。區域網路位址通常需要繞過代理，但具體範圍應與實際網路一致。刪除所有繞過項目不是長期方案，因為可能影響路由器管理頁面、印表機與內部服務。

PAC 模式透過腳本決定每個請求使用代理還是直連。瀏覽器可能快取 PAC 檔案，腳本位址不可達時也可能回退為直連。診斷時可以暫時切換至固定系統代理，若立即恢復，問題集中在 PAC 取得、快取或匹配規則。修復後再恢復 PAC，並驗證代理網域、直連網域與區域網路位址三類請求。關於系統代理、全域模式與繞過規則的關係，可閱讀系統代理、全域模式與繞過中國大陸模式差異詳解。

權限、殘留狀態與代理迴圈

客戶端異常退出後，系統代理可能殘留。下次啟動若使用不同連接埠，瀏覽器就會繼續連線至舊位址。遇到「退出後無法上網」時，先在系統設定中關閉手動代理，再檢查自動設定指令碼是否仍然啟用。接著啟動客戶端，確認核心正常後由客戶端重新寫入。不要同時讓多個代理客戶端管理系統代理，否則它們可能交替覆蓋位址，造成狀態與介面不一致。

代理迴圈常見於客戶端更新訂閱、檢查網路或下載規則時，錯誤地再次經過自身已失效的系統代理。記錄會出現本地連接埠重複連線、請求無回應，或核心停止後所有網路操作都失敗。解決思路是明確每類內部請求使用直連還是目前代理，並確保客戶端啟動前不依賴尚未建立的出口。切換節點時也應等待新核心完成監聽，再觸發需要代理的操作。

部分應用程式不支援系統代理，或只代理 HTTP 流量。此類程式需要在自身設定中填寫 SOCKS 或 HTTP 位址，或在適合的桌面環境中使用虛擬網卡模式接管流量。切換至虛擬網卡模式前應了解其權限、DNS 與路由影響，不要把它當作系統代理問題的通用開關。若只有一個程式異常，優先查閱該程式文件中的代理能力；若所有程式都異常，再檢查系統層與客戶端層。

七、客戶端無法啟動、核心退出或頻繁當機

區分介面程序與核心程序

v2rayN 由圖形介面負責設定管理，再呼叫 Xray 或 V2Fly 核心處理流量。介面能開啟但連線後立即停止，通常是核心啟動失敗；介面本身無法開啟、視窗閃退或設定頁面當機，則應檢查執行環境、設定檔、權限與介面相關元件。兩者的記錄位置與修復路徑不同。首先記錄當機發生在「開啟客戶端」「啟動核心」「載入訂閱」還是「開始傳輸」階段。

如果介面仍可操作，先開啟記錄目錄，保留本次啟動前後的錯誤內容。核心常見的啟動錯誤包括 JSON 語法錯誤、出站標籤不存在、連接埠衝突、規則檔案無法讀取及設定欄位不受支援。不要只截取最後一行，因為根因往往出現在前面的設定解析階段。若記錄過於詳細，可暫時將等級調整為 warning 或 info，重新重現一次，避免大量正常連線記錄掩蓋關鍵錯誤。

驗證產生的設定是否完整

手動新增路由或從舊設定遷移後，逗號、引號與括號錯誤會導致核心拒絕啟動。標準 JSON 不允許註解，也不允許在最後一個陣列項目後保留多餘逗號。以下是結構完整的最小示意，可用於理解層級，不應直接取代既有節點設定：

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

若客戶端支援查看產生的設定，應重點檢查記錄指出的欄位路徑。自訂片段不要重複定義客戶端已產生的頂層物件，也不要引用不存在的 outboundTag。從另一款客戶端複製設定時，應確認目標核心支援相同欄位。Xray 與 V2Fly 有共同基礎，也各自具備不同能力；關於核心差異，可閱讀Xray 核心與 V2Fly 核心差異比較。

處理權限、路徑與安全軟體攔截

客戶端目錄缺少寫入權限時，可能無法儲存設定、更新核心檔案或寫入記錄。桌面系統中應將客戶端放在目前使用者具有正常讀寫權限的位置，路徑避免指向暫存目錄或會被自動清理的位置。不要長期依賴管理員權限啟動；如果一般權限失敗，應先確認具體遭拒的檔案或操作，再修正目錄權限。以高權限執行可能改變設定檔擁有者，導致之後以一般權限啟動時持續失敗。

安全軟體可能阻止新下載的核心程序執行，或在更新後將新檔案視為未授權程式。應查看系統安全記錄與隔離記錄，確認遭攔截的實際檔案路徑。僅為目前可信的安裝目錄設定必要的執行與網路權限，不要關閉整套防護。若 v2rayN 介面啟動正常但核心檔案立即消失，通常需要先處理隔離規則，再從Windows 下載入口重新取得客戶端。

路徑包含特殊字元、同步磁碟佔位檔案或目錄層級過長時，外部核心與規則檔案可能無法正常讀取。可將客戶端移至簡短、穩定且可寫入的使用者目錄進行對照。移動前先退出程式，移動後重新選擇核心路徑，並檢查訂閱、記錄與規則目錄是否仍指向舊位置。不要在程式執行時搬移目錄，這會讓介面儲存位置與核心目前工作目錄不一致。

恢復損壞設定而不遺失全部資料

如果更新訂閱或修改路由後介面立即當機，可以先複製整個設定目錄作為備份，再嘗試移走最近修改的自訂規則、介面狀態檔案或單一訂閱群組。恢復過程應從最小變更開始，不要直接刪除全部設定。重新開啟後，逐項匯入伺服器與路由設定，每次匯入後重新啟動驗證。如此可以定位具體損壞檔案，並保留其他正常資料。

客戶端頻繁當機也可能由記憶體不足、規則集過大或記錄持續增長引起。觀察當機前的記憶體、磁碟空間與記錄大小。大量重複規則會增加啟動解析時間，自訂網域清單中一行異常冗長的內容也可能帶來額外負擔。刪除重複項目、按用途拆分規則，並保留必要記錄即可。若只在傳輸大量連線時當機，降低應用程式並行數進行對照，同時查看系統是否記錄程序因資源限制而終止。

完成恢復後，應按「介面啟動、核心監聽、單一節點連線、訂閱更新、自訂路由」的順序逐層加回功能。每一步保持可用後再繼續。如果錯誤只在某個自訂片段出現，應依據目前核心支援的欄位重寫，而不是繼續沿用舊客戶端匯出的完整設定。需要重新安裝時，從下載中心選擇目前平台的軟體套件，並在匯入舊資料前先驗證空白設定能正常啟動。

八、Android 上的連線中斷、背景失效與應用程式分流

確認 VPN 權限與系統衝突

v2rayNG 與 v2flyNG 通常透過 Android 的 VPN 介面接管應用程式流量。首次連線時系統會顯示 VPN 授權，未授權、授權遭撤銷或已有其他 VPN 佔用時，客戶端無法建立介面。狀態列出現 VPN 標誌只能表示介面存在，仍需配合客戶端記錄確認核心已啟動並載入選定節點。若點擊連線後立即中斷，先檢查系統是否提示另一個 VPN 正在執行，再確認工作設定檔、企業管理或安全應用程式是否限制 VPN 權限。

Android 通常同一時間只允許一個主要 VPN 服務。廣告過濾器、企業 VPN、網路加速工具與其他代理客戶端可能與 v2rayNG 或 v2flyNG 衝突。排查時應完全停止其他佔用 VPN 介面的應用程式，而不是只從最近使用的工作中劃掉介面。系統設定中的「一律開啟 VPN」與「封鎖未使用 VPN 的連線」也會影響切換客戶端；如果「一律開啟 VPN」綁定了另一個應用程式，新客戶端可能無法取得權限。

選擇客戶端時，v2rayNG 使用 Xray 核心，v2flyNG 以 V2Fly 核心為基礎。兩者在常見設定上有交集，但部分協定與傳輸欄位的支援不同。匯入訂閱後若只有特定節點無法連線，應先核對節點是否依賴對應核心能力，不要將同一設定無條件複製到兩款客戶端之間。需要安裝或更換軟體套件時，可前往Android 下載入口。

處理省電與背景限制

鎖定螢幕後連線中斷、切換應用程式後很快失效，通常與電池最佳化和背景限制有關。系統可能暫停客戶端程序、限制背景網路或回收 VPN 服務。應在應用程式電池設定中允許背景活動，並依裝置系統提供的選項取消對客戶端的嚴格省電限制。部分裝置還有自動啟動、背景彈出或工作鎖定設定，應以「允許 VPN 服務持續執行」為目標，不必開啟與網路無關的權限。

修改省電設定後，應重新啟動客戶端並進行完整測試：保持螢幕開啟存取一次，鎖定螢幕數分鐘後再次存取，再在 Wi-Fi 與行動數據之間切換。若只在鎖定螢幕後失敗，重點仍是背景策略；若網路切換後失敗，則可能是 VPN 介面沒有重新建立、舊 DNS 快取未更新或節點連線未重新撥號。記錄中若出現網路遺失後沒有新的預設網路，表示客戶端未及時取得系統網路變化。

系統記憶體緊張時，背景程序也可能被回收。大量常駐應用程式、遊戲與瀏覽器分頁會增加這種機率。觀察客戶端通知是否在中斷時消失；通知消失通常表示服務已停止，通知仍在但無法存取，則更可能是通道、DNS 或節點連線中斷。啟用持續通知有助於系統將 VPN 服務視為前景工作，也方便區分服務停止與鏈路失效。

檢查應用程式分流與繞過設定

Android 客戶端可按應用程式決定經過 VPN、繞過 VPN，或僅代理選定的應用程式。清單設定錯誤時，會出現瀏覽器可用但其他應用程式直連，或只有少數應用程式無法連線。排查時先暫時關閉按應用程式分流，讓所有一般應用程式進入 VPN，確認基本連線正常；接著再恢復白名單或黑名單，逐一驗證目標應用程式。不要同時啟用「僅代理選取的應用程式」與相反的繞過邏輯。

系統元件、下載管理器與嵌入式網頁可能由不同程序發起請求。某個應用程式介面中的下載動作不一定由該應用程式套件名稱直接執行，因此只選取主應用程式可能導致登入正常但下載失敗。遇到這種差異，應查看客戶端按應用程式統計或記錄，確認實際流量是否進入 VPN。對於依賴區域網路裝置的應用程式，還要視需要允許繞過本地網路，否則投放、印表機與路由器管理功能可能失效。

按應用程式代理與核心路由屬於兩個層級。前者決定應用程式流量是否進入 VPN，後者決定進入後的流量走代理還是直連。如果應用程式根本沒有進入 VPN，修改 geosite 或 IP 規則不會產生效果；如果應用程式已進入但目標網域命中錯誤出站，才需要調整核心路由。記錄中完全沒有該應用程式請求時，先查應用程式分流；有請求但出口不符時，再查路由規則。

網路切換、私人 DNS 與熱點共享

從 Wi-Fi 切換至行動數據時，本地位址、DNS 與 MTU 都可能變化。客戶端需要重新繫結預設網路並恢復通道。若切換後狀態顯示已連線但網頁停滯，可以先暫停再連線，而不是刪除節點。若經常發生，檢查客戶端是否允許網路變更後自動重新連線，並確認系統沒有封鎖背景網路。雙卡裝置還應確認目前數據卡與系統預設網路一致。

Android 的私人 DNS 設定可能與客戶端內建 DNS 並行或衝突。出現網域失敗但 IP 可連線時，可記錄目前私人 DNS 模式，暫時切換為系統自動進行對照。如果自動模式恢復，繼續檢查私人 DNS 主機的可達性與客戶端 DNS 路由；如果沒有變化，問題更可能位於 VPN 內的解析路徑。不要把關閉私人 DNS 當作最終結論，測試後應根據實際解析結構選擇合適設定。

裝置開啟熱點時，下游裝置的流量是否經過手機 VPN，取決於系統能力與客戶端轉送方式，不能只根據手機本機連線狀態推斷。若手機可存取而連線熱點的電腦無法存取，先確認下游裝置能否正常上網，再檢查客戶端是否明確支援熱點流量轉送。沒有對應轉送能力時，應在下游裝置獨立安裝桌面客戶端，而不是反覆調整手機節點。

最後使用固定順序驗證：取消嚴格省電限制，停止其他 VPN，關閉應用程式分流，選擇一個已確認可用的節點，保持預設路由完成網頁測試；接著鎖定螢幕、切換網路並逐項恢復分流。若基本狀態仍然失敗，查看記錄屬於解析、連線還是交握問題，並返回前面對應章節。若基本狀態正常而恢復某項設定後失敗，該設定就是明確的排查入口。透過逐層恢復，比反覆清除應用程式資料更容易保留訂閱與路由設定。