小火箭速度慢怎麼排查：節點、線路、協定、本地網路四層定位

開始前：先把「速度慢」轉化為可重現的現象

Shadowrocket（小火箭）顯示已連線，只能代表系統 VPN 通道已建立，不代表每個請求都能獲得相同的傳輸量。網頁首屏等待、影片緩衝、檔案傳輸緩慢與應用程式偶爾轉圈，可能分別對應 DNS 回應、連線交握、持續頻寬與封包遺失抖動。排查前應先確認是哪一種現象，不要只記下「感覺很慢」。

建議選定一個可重複存取的網頁、一個由自己控制或長期穩定的檔案來源，以及同一項應用程式操作作為測試對象。每輪測試至少持續 60 秒，連續執行 3 輪，並記錄首次結果與後兩次結果是否接近。第一次慢、之後恢復，通常較接近 DNS、TLS 交握或快取差異；三輪都持續偏慢，才較像傳輸量或線路問題。

固定測試條件

1. 在 Home 選擇一個現有節點，測試期間不要反覆切換。
2. 確認 Global Routing 目前的狀態並記下結果。排查規則影響時使用 Proxy 作為對照，日常設定則保留 Config。
3. 關閉正在進行的大型檔案同步、系統更新及其他持續占用頻寬的工作。
4. 記錄目前使用 Wi-Fi 或行動網路、測試時間、節點名稱、協定類型，以及連續 3 輪的現象。
5. 測試後恢復原本的 Global Routing，避免把臨時對照設定當成長期設定。

請求實際上會經過多個環節。Home 中的延遲測試主要反映探測請求的往返時間，不是完整下載速度。某個節點可能顯示較低延遲，但持續傳輸時受到負載、壅塞或封包遺失影響；反之，延遲略高的節點也可能有更穩定的持續傳輸量。因此，延遲數字只能用於初步篩選，不能單獨作為結論。

第一層：判斷是否為單一節點負載

節點層問題通常表現為：在相同網路、相同時間與相同測試目標下，某一個現有節點連續 3 輪偏慢，而同一份設定中的其他節點明顯穩定。這裡要比較的是使用者已持有的節點項目，不要根據名稱、地區標籤或單次延遲結果直接下結論。

先在 Home 對目前節點執行延遲測試，再選擇另一個現有節點重複相同操作。切換後等待連線狀態穩定，然後重新開啟測試目標，不要沿用已載入快取的頁面。若兩個節點使用相同協定，結果較容易歸因於節點負載；若協定也不同，應先記為「節點或協定待分離」，留到第三層繼續驗證。

節點層的實際操作順序

• 將 Global Routing → Proxy 保持為短時間對照，排除規則將不同測試請求送往不同策略的情況。
• 選取 2 至 3 個使用者已有的節點，每個節點完成 3 輪相同測試，測試期間不要重新整理訂閱。
• 同時記錄「首次開啟耗時」與「持續傳輸是否穩定」，不要把兩者合併成單一評價。
• 完成後切回 Config，確認規則模式下是否出現不同結果。

第二層：辨識線路時段與路徑壅塞

線路層問題通常具有明顯的時間特徵。例如白天穩定、晚間固定時段下降，或平日與週末表現不同。節點本身沒有變化，但從本地網路到節點入口之間的路徑可能在特定時段壅塞。此類問題若只在當下不斷切換設定，很容易把短暫恢復誤認為某個選項有效。

建立一份最簡單的記錄即可：早上、中午、晚上各測試一次，每次使用相同網路、相同節點、相同目標與相同 Global Routing。連續記錄兩天後，若慢速集中在相近時段，且 Wi-Fi 與行動網路的結果不同，表示應優先檢查本地接取路徑；若兩種接取方式都在相同時間下降，則較接近共同路徑或節點入口負載。

依現象區分時段問題

• 每天在相近時段變慢：保留測試記錄，不要在每一輪變更協定與規則。
• Wi-Fi 緩慢、行動網路正常：優先檢查路由器距離、無線頻段、訊號遮蔽及同網路裝置占用。
• 兩種網路都慢：使用另一個現有節點進行一次對照，判斷是否為共同節點入口。
• 測速正常但特定網站緩慢：檢查規則命中、DNS 結果與目標網站自身回應，不要直接歸因於整條線路。

還應區分峰值與穩定值。開始數秒出現高峰，之後持續下降，可能是壅塞控制、封包遺失或伺服器限速造成；全程穩定但上限較低，則較像固定頻寬條件。記錄曲線趨勢比只抄下最高數字更有價值。

第三層：區分協定特性與設定不匹配

Shadowrocket 可處理 Shadowsocks、VMess、VLESS、Trojan、Hysteria2、WireGuard 等協定，但「協定名稱」本身不能直接決定速度。實際結果還會受到傳輸層、加密方式、TLS、UDP 可用性、MTU、伺服器設定及本地網路品質影響。比較協定時，應使用服務商已提供且正確設定的自有項目。

Shadowsocks 的表現與所用加密方式、伺服器處理能力，以及 TCP 或 UDP 流量有關。VMess 與 VLESS 可能搭配不同傳輸方式，額外封裝與 TLS 交握會影響首次連線耗時。Trojan 常見於 TLS over TCP 情境，封包遺失時可能出現明顯重傳。Hysteria2 基於 QUIC 與 UDP，其效果取決於網路對 UDP 的支援及封包遺失情況。WireGuard 同樣依賴 UDP，MTU 不合適時可能出現小型請求正常、大流量卡頓的現象。

不要隨意變更伺服器端相關參數

協定參數需要與伺服器端匹配。連接埠、密碼、UUID、金鑰、Server Name、Public Key 或傳輸路徑中的任何一項不一致，都可能導致連線失敗或反覆重試。速度排查不應從隨機修改這些欄位開始，而應先確認匯入項目與服務商提供的原始設定一致。

若使用者已有同一服務下、不同協定但目標位置相近的項目，可以固定本地網路與測試目標進行對照。每種協定執行相同的 3 輪測試，並分別記錄首次回應與持續傳輸量。只有協定是主要變數時，這組比較才有意義。

第四層：檢查本地 Wi-Fi、行動網路與系統連線條件

本地網路是最容易被忽略的一層。Wi-Fi 訊號格數較多，不代表無線環境沒有干擾；同一房間內其他裝置持續上傳，也可能提高延遲並降低下載速度。最直接的判斷方法是在保持節點、協定與測試目標不變的情況下，只切換 Wi-Fi 與行動網路。

若行動網路穩定而 Wi-Fi 明顯波動，先靠近路由器重新測試，再暫停同網路的大流量工作。若靠近後恢復，問題較接近訊號衰減或無線干擾；若距離變化沒有影響，但其他裝置停止傳輸後恢復，則較接近區域網路頻寬占用。反之，若 Wi-Fi 正常而行動網路偏慢，應考慮目前位置的訊號品質與行動網路壅塞。

1. 在 Home 保持同一個節點，不要重新整理或切換設定。
2. 使用 Wi-Fi 完成 3 輪測試，記錄每輪首次回應與持續表現。
3. 關閉 Wi-Fi，等待行動網路狀態穩定後，以相同目標再完成 3 輪。
4. 若差異明顯，再回到原本的網路重新測試一次，排除短時間波動。
5. 若兩種網路都慢，返回節點層或線路層繼續定位。

檢查 On Demand 是否造成連線切換

進入 Settings → On Demand，查看是否啟用了依網路條件自動連線的規則。On Demand 主要決定何時建立連線，不會直接增加頻寬，但條件反覆命中可能導致連線在網路切換時重新建立。若緩慢只發生在離開 Wi-Fi、進入行動網路或重新加入某個 Wi-Fi 後，可暫時關閉 On Demand 做一次對照，再恢復原本設定。

Global Routing 也應納入記錄。Proxy 讓請求統一經過目前的代理策略，適合短時間對照；Direct 用於直接連線測試；Config 依規則匹配；Scene 依已設定的場景處理。若 Proxy 與 Config 結果不同，應轉向檢查規則與 DNS，而不是繼續修改協定。

規則、DNS 與訂閱更新：排除容易混淆的現象

完成四層檢查後，若速度問題只出現在特定網域或應用程式，應檢查 Config 中的規則匹配。Shadowrocket 依設定順序處理規則，前面的規則會先命中。DOMAIN-SUFFIX 用於匹配網域後綴，GEOIP 依 IP 地理資訊匹配，IP-CIDR 匹配位址範圍，FINAL 處理先前未命中的請求。

DOMAIN-SUFFIX,example.com,PROXY
IP-CIDR,192.168.0.0/16,DIRECT
GEOIP,CN,DIRECT
FINAL,PROXY

以上片段說明匹配順序，不代表適合直接替換現有設定。若某個網域在 Config 下緩慢，切換到 Proxy 後恢復，應先查看它是否命中了 DIRECT、不合適的策略或過早出現的廣泛規則。若兩種狀態都慢，規則就不是主要變數。

DNS 問題常表現為「輸入位址後等待較久，但頁面一開始載入就很快」。這種現象與持續頻寬不同。檢查設定中的 DNS 設定時，應以既有設定說明為準，不要同時替換多個解析項目。還要注意，網域規則與 IP 規則的結果可能受解析位址影響，因此 DNS 與規則需要結合觀察。

訂閱更新與速度測試應分開處理

訂閱更新負責取得服務商提供的節點清單與設定內容，本身不是速度最佳化操作。測試過程中重新整理訂閱可能改變節點項目或參數，使前後結果無法直接比較。應先完成一組固定設定的測試，再單獨處理更新問題。

若需要手動核對訂閱格式，範例位址應類似 https://example.com/sub?token=xxxx，其中網域與令牌均為虛構值。實際連結由使用者自己的服務商提供，請注意連結通常包含存取憑證，不要公開展示或轉發。

形成結論：以最小變更完成一次閉環

有效排查的目標不是找出瞬間最快的組合，而是確定緩慢發生在哪一層。節點層觀察單一項目是否異常，線路層觀察時段與路徑，協定層觀察傳輸特性及參數匹配，本地網路層觀察 Wi-Fi、行動網路與系統連線條件。四層彼此相關，但透過控制變數可以逐步縮小範圍。

1. 固定基準：相同目標、相同節點、相同協定、相同 Global Routing，連續測試 3 輪。
2. 只更換節點：判斷是否為單一節點負載，不要用單次延遲取代持續測試。
3. 只更換時段：早上、中午、晚上記錄相同條件，觀察是否存在穩定的時間規律。
4. 只更換協定：使用現有且參數正確的項目，分別記錄首次回應與持續傳輸量。
5. 只更換接取方式：在 Wi-Fi 與行動網路之間進行對照，確認本地網路是否為主要變數。
6. 回到 Config：若 Proxy 正常而 Config 異常，再檢查規則順序、DNS 與策略命中。

完成測試後，只保留能解釋現象的調整，並恢復為進行對照而暫時變更的設定。若問題集中在訂閱內容、伺服器參數或節點狀態，應攜帶測試時間、網路類型、協定與重複結果向自己的服務商查詢；若問題只出現在本地 Wi-Fi，則繼續檢查路由器環境與區域網路占用。

Shadowrocket 是 Apple 平台上的付費商業客戶端，iPhone 與 iPad 為主要使用裝置，Mac、Apple TV 與 Apple Vision 的相容性及系統要求以 App Store 頁面標示為準。應用程式採一次買斷，開發者為 Shadow Launch Technology Limited，應用程式 ID 為 932747118；客戶端購買與使用者自己的線路服務是兩項獨立內容。