先分辨是連線失敗、網頁初次載入慢，還是下載速度持續偏慢；接著固定測試節點與網路，再檢查本機代理入口、DNS、路由及 Mux。本文適合已匯入訂閱、能連線但速度不穩定的 v2rayN 使用者。依序記錄測試結果，有助縮小問題範圍，避免一次改動多項設定而無法判斷原因。
一、建立測速基準：別只看延遲數字
TCP 延遲只反映建立連線所需的部分時間，不能代表節點能持續傳輸多少資料。真實連線延遲較接近一次經過代理的請求，但仍會受測試網址、DNS 和目標網站回應速度影響。低延遲節點的頻寬可能不足，高延遲節點也可能有較穩定的持續傳輸速度。
先暫停下載、雲端硬碟同步和系統更新，選定一個有權存取的 HTTPS 下載資源，並維持相同裝置、網路與時段。以下數字是建議的測試條件與連接埠範例，不代表本站實測結果，也不是用戶端效能保證。
-
記錄目前設定
在「說明」→「關於」記下用戶端版本；在「設定」→「參數設定」記下目前核心、監聽連接埠和 Mux 狀態，也記錄主畫面的路由模式。不同版本的設定頁籤可能有所差異，請依實際介面確認，不必為了符合本文而修改連接埠。
-
固定代理入口
先停用 TUN，使用系統代理進行基本排查。在系統匣選單的「系統代理」→「自動設定系統代理」啟用代理，並關閉其他會變更系統代理設定的程式。後續比較時都維持相同的代理模式。
-
篩選候選節點
在伺服器清單選取候選節點，按右鍵執行「測試伺服器真實連線延遲」。接著將待測節點設為作用中伺服器，逐一測試相同資源；批次延遲測試結果不能當作下載頻寬。
-
記錄三種耗時
分別記錄是否連得上、網頁初次載入情況，以及持續下載速度。每次切換節點後重新送出請求，避免瀏覽器沿用舊連線；記錄時註明單位，1 MB/s 約等於 8 Mbps。
二、節點層：分辨單一節點壅塞與目標網站限速
先在相同網路下切換節點，不要同時更改 DNS、協定和路由。選擇兩個不同出口的可用節點，比較相同下載資源；接著保留其中一個節點，改測另一個目標網站。如此可判斷問題是跟著節點出現，還是只發生在特定資源。
| 觀察結果 | 優先懷疑 | 下一步 |
|---|---|---|
| 只有一個節點持續偏慢 | 該節點負載、限速或特定線路 | 維持本機設定，改用另一個出口重新測試 |
| 多個節點只有晚上變慢 | 共用線路壅塞或伺服器尖峰負載 | 記錄相同資源在不同時段的測試結果 |
| 只有一個網站下載慢 | 目標網站限速、出口互連或內容傳遞差異 | 改測其他目標，並確認帳戶或單一連線限制 |
| 所有節點都慢，直接連線也慢 | 本機網路、無線干擾或頻寬占用 | 先測試有線網路，並查看區域網路中的其他裝置 |
更新訂閱只會重新整理伺服器設定，不會增加節點頻寬。節點名稱中的地區、倍率或線路等字樣，也不能取代實際測試。若訂閱服務商設有帳戶速率、流量或同時上線數限制，請查閱服務說明；這些限制無法只靠用戶端解除。
結論：保留有效的對照結果
如果只要切換節點就能反覆恢復速度，先使用表現穩定的節點並保存比較紀錄；不必馬上重設整個用戶端，也別把節點差異歸因於某個協定名稱。
三、線路層：交叉測試有線網路與手機熱點
網路線路涵蓋裝置到路由器、電信業者接取網路、跨網連線和節點出口。無線訊號滿格不代表傳輸穩定；同一存取點上的其他裝置若占滿上傳頻寬，也可能讓網頁請求排隊。測試時查看工作管理員的網路使用量，先排除本機背景流量。
- 改用有線網路：維持節點和目標不變，從無線網路切換為網路線連線。若有線連線穩定，優先檢查無線干擾、頻段和路由器負載。
- 改用手機熱點：讓同一台電腦改連手機熱點。若速度明顯改善，值得繼續排查原本的接取線路，但不能只憑一次測試就認定電信業者有所限制。
- 觀察持續傳輸：觀察完整的 60 秒。若一開始很快、之後逐漸下降，可能是快取、突發頻寬、限速或壅塞所致，不能只截取瞬間峰值。
- 檢查封包遺失：在 Windows 執行
ping -n 30 192.168.1.1檢查本機閘道；只有當實際閘道位址是這個位址時才使用，否則請替換成本機預設閘道。
四、本機代理、DNS 與路由：排查初次載入慢和路由錯誤
若網頁第一次載入要等很久，但開始下載後速度正常，優先檢查名稱解析和建立連線的過程。若下載速度也持續偏慢，再檢查線路和資源使用量。系統代理只會影響遵循該設定的應用程式；瀏覽器擴充功能、應用程式內建代理和 TUN 也可能改變實際連線路徑。
- 開啟「設定」→「參數設定」，確認本機監聽連接埠。以下命令假設
127.0.0.1:10808接受 SOCKS 連線；若目前連接埠只接受 HTTP，請勿直接套用 SOCKS 參數。 - 在 Windows 終端機執行以下命令。這些命令只會取得回應標頭，用於排查請求階段，不適合測量下載頻寬；範例目標為
https://example.com/。 - 第一條使用
socks5h，將目標網域交由代理端透過 SOCKS 解析；第二條使用socks5，由本機解析目標網域。交替重複測試，避免把快取或網站波動誤判為 DNS 問題。
curl.exe --proxy socks5h://127.0.0.1:10808 --connect-timeout 10 --max-time 30 -I https://example.com/
curl.exe --proxy socks5://127.0.0.1:10808 --connect-timeout 10 --max-time 30 -I https://example.com/若兩者的差異穩定出現，請前往「設定」→「DNS 設定」，檢查目前核心對應的解析策略。遠端解析仍會受到核心 DNS 與路由設定影響，不能把某個公共 DNS 位址填入所有欄位就當作解決問題。節點伺服器位址本身也需要可用的解析路徑，避免陷入「必須先連上代理才能解析代理伺服器」的循環依賴。
在主畫面確認目前的路由模式，並前往「設定」→「路由設定」檢查自訂規則。針對單一問題網站，暫時以全域代理進行比較；測試後恢復原模式。若此時恢復正常，請檢查該網站是否誤中直連規則，以及 DNS 回傳的位址是否影響 IP 規則比對。規則通常依序比對，過於寬泛的前置規則可能遮蔽後續規則。
五、傳輸協定與 Mux：一次只調整一個變因
VMess、VLESS 是代理協定；TCP、WebSocket、gRPC 等則屬於傳輸相關設定，TLS 又是另一層。用戶端不能任意將伺服器提供的 WebSocket 節點改成其他傳輸方式；路徑、Host、SNI、連接埠和伺服器監聽設定都必須相符，否則通常只會連線失敗，不會提升效能。
- 先沿用訂閱原始設定：保留伺服器提供的傳輸參數。只有在伺服器明確提供多個入口時，才在相同測試條件下比較不同入口。
- 單獨比較 Mux：在「設定」→「參數設定」查看目前核心的 Mux 選項。記下原本的值，關閉後重新啟動核心或切換作用中的伺服器，再重新建立測試連線。
- 區分使用情境：Mux 可讓多個邏輯連線共用底層連線，可能減少短連線的額外負擔；對長時間下載不一定有明顯幫助。某些以可靠位元組串流為基礎的多工情境，還可能讓多個請求一起受到封包遺失與等待的影響。
- 別盲目調高並行數：並行數不是越高越快。節點、核心和傳輸方式的支援情況各有不同；看不到明確效益就恢復原值，也不要同時調整 Mux、分片和 DNS。
同時觀察 CPU 和記憶體使用量。若傳輸期間有單一核心持續滿載，且更換網路或節點都沒有明顯改善，請檢查核心版本、過量記錄、其他網路篩選軟體和背景處理程序。更新用戶端或核心前請先備份設定，並閱讀相應版本說明；不要為了追求速度而關閉防火牆或略過憑證驗證。
六、查看錯誤記錄：區分連線故障與速度問題
反覆重新連線也會讓網頁看起來很慢。開啟用戶端記錄，先依發生時間查找連續出現的失敗原因。以下是記錄中可能出現的錯誤片段，完整前綴會因核心和作業系統而異；單次錯誤不能取代對前後文的判斷。
錯誤：context deadline exceeded
原因與處理方式：作業未能在限定時間內完成，可能發生在名稱解析、連線或等待回應的階段。先查看前後記錄確認目標，再以相同節點測試不同目標、相同目標測試不同節點來定位問題，不要只延長逾時時間。
錯誤：connection refused
原因與處理方式：目標端或中間設備主動拒絕連線。確認記錄中的位址和連接埠；若是本機代理位址，檢查核心是否正在執行，以及應用程式設定的連接埠是否正確；若是伺服器位址，核對訂閱參數和伺服器監聽設定。
錯誤：lookup ...: no such host
原因與處理方式：網域名稱解析未取得有效結果。確認解析失敗的是節點伺服器還是存取目標，檢查拼字、DNS 設定和解析路徑，再重新送出請求。
七、常見問題：依症狀逐步縮小範圍
延遲很低，為什麼下載還是很慢？
延遲不等於傳輸量。將該節點設為作用中伺服器，對相同資源連續觀察 60 秒，再換第二個節點和第二個目標。若只有一個目標慢，先查目標網站限速；若多個目標都慢，再檢查節點頻寬和線路。
開啟全域代理後變快，需要一直開著嗎？
先把它當作路由對照，不要直接視為最終解法。恢復原本模式，在「設定」→「路由設定」檢查目標網域符合哪條規則，並搭配記錄確認流量的出口。修正錯誤分流後，再測試原本的使用模式。
測速很快，瀏覽器開啟網頁卻很慢？
先停用瀏覽器中個別設定的代理擴充功能，再透過終端機明確指定本機代理來測試。如果終端機正常，請檢查瀏覽器的安全 DNS、快取和連線重用；若終端機也慢，繼續檢查核心 DNS 與路由。
換了 DNS 和 Mux，還是分不清原因怎麼辦？
還原成已記錄的基準設定，依序測試節點、接取網路、DNS 和 Mux，每次只改一項。每輪保留三次結果及測試時間；只有能重複出現的改善才值得保留，偶爾一次的峰值不能當作有效結論。