V2Ray 速度慢怎麼辦？從節點、線路到本機設定逐層排查

一、先分辨首次開啟慢、持續低速與連線失敗

延遲低不代表下載速度快。節點清單中的延遲測試，只反映特定探測方式下的回應時間，不能代表可用頻寬；下載速度還會受到伺服器負載、電信業者路徑、目標網站限速及本機網路影響。先確認速度變慢發生在哪個階段，再決定是否需要調整參數。

v2rayN 是用戶端管理介面，實際處理連線的是所選的核心。Project V、V2Fly 與 Xray 是相關專案，名稱本身不代表效能等級。VMess、VLESS 等協定也不是速度分級；節點位置、傳輸組合與伺服器資源，通常比協定名稱更能解釋速度差異。

二、建立可重複的本機測試基準

先固定節點、目標網址、接取網路及代理入口。以下以 Windows 上的 v2rayN，以及監聽於 127.0.0.1:10808 的混合代理連接埠為例。10808 是範例值，執行前應確認實際設定與核心啟動記錄；不要直接沿用舊教學中的 10809。

1. 記錄環境資訊

   開啟「說明」→「關於」，記下完整的用戶端版本；再記錄啟動記錄中的核心名稱與版本。保留目前的節點、路由模式及 TUN 開關狀態，後續不要同時升級與修改規則。

2. 確認代理入口

   開啟「設定」→「參數設定」，確認本機監聽連接埠；選單分類可能隨版本調整，請以啟動記錄為準。先關閉 TUN，使用明確指定的 HTTP 代理建立基準，避免混用兩種入口。

3. 固定測試條件

   暫停訂閱批次測速、雲端硬碟同步及其他下載。選擇一個可穩定存取的 HTTPS 網址，每次使用相同節點，連續執行下方指令 3 次，採用中間值而非最佳值。

4. 保存測試結果

   記錄測試時間、目標網址、連線時間、第一個位元組的回應時間及完整錯誤訊息。每次調整一項後再測 3 次；若改善不穩定，就恢復原值，避免設定逐漸偏離基準。

curl.exe --proxy http://127.0.0.1:10808 --connect-timeout 10 --max-time 30 -o NUL -sS -w "connect=%{time_connect}s tls=%{time_appconnect}s first=%{time_starttransfer}s total=%{time_total}s\n" https://example.com/

這裡的 example.com 僅用於示範計時指令，不適合測量頻寬上限。透過本機 HTTP 代理存取 HTTPS 時，time_connect 主要反映連線至本機代理的時間，不能當作連線至遠端節點的延遲；TLS 與第一個位元組的回應時間還包含代理鏈路及目標網站的處理時間。若要測量傳輸量，請改用自己有權存取的固定大型檔案，並確認回應內容不是錯誤頁面。

三、節點負載與跨境線路：透過交叉測試找出問題

單次測速無法分辨是節點繁忙還是路徑壅塞。最有參考價值的比對方式是「同一網路換節點」和「同一節點換網路」。測試目標應保持不變，並盡量在相近時間執行，避免目標網站本身的負載變化干擾判斷。

例如，測試紀錄可以是：同一個檔案透過節點 A 下載，白天為 8 MB/s、晚上降至 0.8 MB/s；節點 B 同一時間則維持 6 MB/s。這些數據只能將問題範圍縮小至節點 A 的資源或路徑，不能據此斷定伺服器 CPU 已滿載。確認伺服器負載需要取得伺服器端的 CPU、頻寬、連線數及限速資訊；上述數值僅供判讀示範，並非本站實測。

• 節點地理位置近，不代表電信業者的實際路徑短；跨網互連與繞道可能抵銷距離優勢。
• 一般 ping 出現封包遺失，可能是 ICMP 限速所致。應搭配應用程式連線、持續傳輸及重試情況一起判斷。
• 共用相同入口或出口的兩個節點，並非完全獨立的樣本。必要時應選擇不同線路群組進行比對。
• 不要先用多執行緒下載「補速度」。增加並行連線會加劇連線與頻寬競爭，也可能掩蓋單一連線的封包遺失。

四、DNS 與路由：先確認請求的實際走向

DNS 主要影響解析等待時間、目標位址選擇，以及依 IP 位址比對的規則，不會憑空增加節點頻寬。請分清三個問題：節點網域由誰解析、目標網域由誰解析，以及路由是否為了比對規則而觸發解析。瀏覽器的安全 DNS 設定，也可能與系統及核心使用的 DNS 路徑不同。

• 節點位址解析失敗：代理尚未建立時就需要解析節點網域，不能完全仰賴尚未連通的代理來完成這項工作。
• 目標解析速度慢：觀察是否只有首次造訪時變慢；比較固定目標的首次與重複請求，不要不斷更換網站。
• 解析結果與出口位置不符：部分 CDN 會根據解析來源配置位址，若遠端出口與位址所在位置不相符，可能造成繞路。
• 路由比對結果不符：檢查記錄中的目標與輸出標籤，確認請求沒有意外直連，或讓本機服務繞經遠端。

以下是用來說明規則順序的 V2Ray/Xray 風格 routing 片段，並非完整設定。規則會先將私有位址送至 direct，再把其餘 TCP、UDP 請求交給 proxy。使用前必須確認已有同名的輸出設定，且已提供 geoip 資料；在 v2rayN 中應先備份，避免與介面產生的規則重複疊加。

{
  "routing": {
    "domainStrategy": "AsIs",
    "rules": [
      {
        "type": "field",
        "ip": ["geoip:private"],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "network": "tcp,udp",
        "outboundTag": "proxy"
      }
    ]
  }
}

AsIs 表示路由階段不會主動將網域解析為 IP 位址來比對，因此網域請求不一定會符合 IP 條件；但最終連線仍可能需要解析。不要將它解讀為「關閉 DNS」。使用 IPIfNonMatch 或 IPOnDemand 時，觸發解析的方式不同，應依實際核心與規則判斷。完整欄位說明請參閱JSON 設定手冊。

五、流量嗅探與 MTU：符合症狀時再調整

流量嗅探用來從流量中辨識網域或協定，以協助路由判斷，並非通用的加速開關。開啟後可能改變網域規則的比對結果；關閉後也可能導致依賴網域的分流失效。應在相同節點與目標下進行比對，並同時觀察輸出變化，不要只看網頁是否偶然快了一次。

MTU 是介面允許的最大傳輸單元。若路徑 MTU 探測受阻，可能出現交握成功、較大的資料卻無法傳輸的情況。若問題只在 TUN 模式重現，可在實際提供 TUN MTU 欄位的設定或組態中，將 1500 暫時改為 1400，再測試 1380；這些只是排查時可嘗試的數值，不保證是最佳值。不要為了測試而直接修改所有實體網路卡。

六、從實際記錄分辨故障，別把所有錯誤都歸因於低速

先記下錯誤發生時間，再查詢對應連線的目標、輸出設定與前後記錄。不同核心的前綴及上下文可能不同，以下列出的是常見錯誤片段。這些訊息只能指出排查範圍，不能單憑片段判定問題來源。暫時提高記錄詳細程度後，重現一次問題就恢復日常等級，避免持續寫入磁碟而影響觀察。

七、常見問題與排查完成條件

使用相同目標連續測試 3 次，結果恢復至可接受的水準，而且正常使用時不再中斷，就應停止繼續疊加「最佳化參數」。若問題仍在，請整理用戶端與核心版本、發生時段、節點群組、接取網路、第一個位元組的回應時間及錯誤片段。分享記錄前，請移除訂閱連結、認證資訊與個人瀏覽記錄，讓問題描述足以重現，又不會洩漏連線憑證。

• 已縮小至節點端：同一網路下只有特定節點異常，接著確認服務資源與路徑。
• 已縮小至線路端：相同節點換用其他接取網路後恢復正常，請保留時段與電信業者的比對資料。
• 已縮小至本機端：明確指定代理時正常，但特定應用程式或 TUN 異常，接著調整對應入口。
• 尚未找到問題：恢復測試基準，增加獨立目標與第二個接取網路，不要一次修改 DNS、MTU 和路由。