適合已有服務商與訂閱，且連線成功但瀏覽速度緩慢的使用者。先記錄 Home 中的節點與 Global Routing，再固定測試目標，依序比對節點、線路、協定與本地網路。每次只變更一個條件，透過首屏載入時間、持續傳輸狀況與錯誤日誌判斷問題；不要把延遲數值當成下載速度。
一、先確認連線路徑與「慢」的具體情況
Shadowrocket（小火箭）是 Apple 平台上的付費用戶端，主要供 iPhone 與 iPad 使用，唯一取得管道為 App Store；可在商店頁確認開發者 Shadow Launch Technology Limited 與 App ID 932747118。本 App 採一次買斷制，系統需求與通用購買以 App Store 頁面標示為準。買斷用戶端不等於購買線路方案；本文僅說明如何排查使用者已有的連線，不提供、販售或推薦節點與訂閱。
「連線成功」只代表通道已建立，不表示目標連線一定經過目前選取的節點。Home → Global Routing 中的 Proxy、Direct、Config 與 Scene 都會影響實際路徑：Proxy 用於代理路由，Direct 用於直接連線，Config 依目前設定檔處理，Scene 則依已設定的情境處理。排查前先記下目前選項；若使用 Config，也要記錄已啟用的設定檔及相關策略選擇。
將問題現象分開記錄，比直接切換協定更有效。首次開啟時等待很久、之後傳輸卻穩定，可能與 DNS、建立連線或目標回應首位元組的時間有關；下載速度持續變慢，應檢查線路壅塞、伺服器負載與本地無線網路品質；若只有單一網站速度慢，先確認請求符合哪條規則，以及目標服務是否正常。
- 首屏載入：使用同一個頁面，記錄從發出請求到主要內容顯示的時間；分別測試首次與再次造訪，因為快取會影響結果。
- 持續傳輸：使用自己有權存取的同一個檔案，觀察至少 30 秒；不要以瞬間峰值代表穩定速度。
- 連線失敗：記錄發生時間、目標網域與完整日誌原文；對外回報前，請移除訂閱憑證、密碼及個人存取內容。
二、節點層：低延遲不代表高吞吐量
Home 中的連線能力或延遲測試適合用來篩查無法連線的項目，但不能單憑測試結果判定頻寬足夠。短請求很快完成，不代表伺服器出口、長連線傳輸及通往目標網站的路徑都正常。單次逾時也不足以判定節點失效，應在相同條件下重測。
- 在 Home 記錄目前節點名稱、類型與連線狀態。若使用策略群組，請在可用的請求記錄中確認實際選用的對外連線，不要只看 Home 上的選取標記。
- 維持網路、目標檔案與 Global Routing 不變，先對目前節點測試三次，再改用自己現有訂閱中的另一個可用節點重複測試。
- 分別記錄延遲、首屏載入時間與穩定傳輸速度。速度單位應統一：
1 MB/s = 8 Mbps，介面單位不同時，不能直接比較數值大小。 - 若只有單一節點持續異常，先確認該節點的伺服器位址、連接埠與驗證資訊；管理訂閱時，應先確認訂閱是否已更新，避免長期保留臨時手動修改。
結論：延遲相近時，以相同目標的持續傳輸結果進行比較
若兩個既有節點的延遲相近，但其中一個在三輪傳輸中都持續卡頓，應先整理該節點的測試記錄，不要同時修改 DNS、規則與協定。
三、線路層：比對時間與目標，找出路徑差異
同一個節點在不同時段的表現可能不同，原因包括接入網路至伺服器之間的鏈路壅塞、伺服器出口負載或目標端限速。單憑節點名稱中的地區，無法判斷實際路由；單一網站的速度也不能代表整條線路的效能。用戶端可以記錄現象，但無法直接改善遠端頻寬或電信網路路徑。
| 比對方式 | 需記錄的現象 | 下一步 |
|---|---|---|
| 同一節點、同一目標，不同時段 | 是否只有在固定時段持續降速 | 改在其他時段重測，並將時間與結果提供給自己的服務商 |
| 同一節點、同一網路，不同目標 | 是否只有單一網站或檔案來源速度緩慢 | 先確認規則比對結果，再檢查目標服務是否正常 |
| 同一目標、同一網路，不同既有節點 | 是否只有一個出口長時間停滯 | 保留正常與異常兩組結果供比對，並確認節點狀態 |
| 同一節點、同一目標，不同接入網路 | Wi-Fi 與行動網路的表現是否明顯不同 | 接著排查本地網路與接入路徑 |
例如，若記錄顯示「同一目標在 Wi-Fi 下連續三輪停滯，切換至行動網路後可以持續傳輸」，這只是協助定位的線索，不能據此判定遠端服務品質。Wi-Fi、路由器、寬頻出口及通往伺服器的路徑都已改變，仍需進一步縮小排查範圍。以上僅為記錄方式範例，並非本站實測數據。
四、協定層：確認傳輸條件，不要盲目修改參數
協定不是獨立的加速開關。Shadowsocks、VMess、VLESS、Trojan、Hysteria2 與 WireGuard 的連線條件各有不同，實際速度還會受到伺服器實作、加密處理、底層傳輸、壅塞控制及網路限制影響。即使服務商提供多種協定，若出口與線路也同時改變，就不能把速度差異全歸因於協定。
| 協定或傳輸方式 | 應確認的條件 | 排查範圍 |
|---|---|---|
| Shadowsocks | 伺服器、連接埠、密碼與加密方式應保持一致；UDP 是否可用取決於伺服器與設定 | 若驗證或加密方式有誤，應先修正連線設定，不要以反覆測速取代檢查 |
| VMess / VLESS | 使用者識別碼、傳輸類型、TLS 與相關傳輸參數須符合伺服器設定 | 不能只更改協定名稱，卻沿用不相符的欄位 |
| Trojan | 密碼、連接埠、TLS 服務名稱與憑證驗證條件 | TLS 失敗屬於交握問題，不應藉由關閉驗證來掩蓋 |
| Hysteria2 | 以 QUIC 為基礎，須確認 UDP 路徑可用；並核對驗證方式與伺服器要求 | 網路限制 UDP 時可能無法連線，也不能保證速度優於其他協定 |
| WireGuard | UDP 端點、金鑰、位址與路由範圍 | 即使交握正常，仍須檢查目標路由；不要任意套用其他設定中的 MTU |
若使用 TLS，443 是常見連接埠，但並非所有節點都固定使用此連接埠；請以自己使用的服務商所提供的連接埠為準。Hysteria2 的頻寬參數也不代表裝置網速，任意調高可能使壅塞更加嚴重。除非伺服器說明或測試證據要求調整，否則應保留訂閱提供的參數。
日誌片段：connection refused
原因與處理方式：目標端點或中間設備主動拒絕連線；先確認伺服器位址、連接埠與服務狀態，再重新測試，不要將此情況當成一般頻寬不足。
日誌片段：i/o timeout
原因與處理方式：相關操作未能在指定時間內完成；依日誌上下文判斷發生於 DNS、連線建立或讀取階段，再以相同節點切換接入網路進行比對。
以上是網路錯誤中可能出現的原文片段，並非每次失敗都會顯示完全相同的文字。請保留實際日誌的完整上下文，尤其是失敗階段；只看「逾時」兩字，無法判斷是否必須更換協定。
五、本地網路層：分別檢查 Wi-Fi、行動網路與 DNS
本地連線問題可能同時影響訂閱更新、節點測試與網頁瀏覽。裝置仍連上 Wi-Fi 時關閉行動數據，不代表已切換至行動網路測試；比對時應在系統 Settings → Wi-Fi 中中斷目前的 Wi-Fi 連線，確認實際使用行動網路，並留意測試檔案所耗用的流量。
- 建立本地基準：保持裝置位置不變，暫停其他大量使用流量的工作。使用可直接存取的同一個目標，確認一般連線是否也很慢；若同樣緩慢，先檢查路由器與寬頻狀態。
- 排除無線干擾：靠近路由器重新測試，並在條件允許時比較 2.4 GHz 與 5 GHz。頻段不代表速度保證，距離、遮蔽物與頻道壅塞都會影響結果。
- 切換接入網路：維持同一節點、模式與目標，改用行動網路重複測試三次。若差異持續且一致，接著檢查接入網路至伺服器的路徑，不要立刻重建設定。
- 區分 DNS 與傳輸問題：若只有首次開啟網域時等待很久，請檢查 Config 中目前設定的
[dns]項目及解析日誌；若連線建立後仍持續低速，單純更換 DNS 通常無法改善吞吐量。 - 檢查自動連線：在 Settings → On Demand 記錄已啟用的條件。若測試期間連線被自動重新觸發，確認是否由這些條件造成；如需暫時停用，請先記下原本設定，測試後再還原。
結論：先固定實際使用的網路，再比較設定
裝置若在 Wi-Fi 與行動網路之間自動切換，兩次測試就不具可比性。先確認系統目前實際使用的網路，再決定是否調整 Shadowrocket 設定。
六、規則與複查：確認請求確實使用預期出口
在 Config 模式下，規則通常依序比對。DOMAIN-SUFFIX 比對網域後綴，IP-CIDR 比對 IP 網段，GEOIP 依 IP 地理資料庫比對，FINAL 則處理先前未符合規則的請求。網域解析、規則順序與策略群組選擇都可能改變最終路徑。在 Home 中更改選取的節點，不一定會改變固定指向其他策略的請求。
[Rule]
DOMAIN-SUFFIX,example.com,PROXY
IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
GEOIP,CN,DIRECT
FINAL,PROXY這段程式碼僅示範規則語法；example.com 是範例網域，不應直接覆蓋現有設定。no-resolve 用來避免只為此 IP 規則觸發網域解析，並非通用的加速選項。先保留目前設定的副本，再針對異常目標檢查規則比對結果與實際出口。若短暫切換至 Proxy 後現象有所改變，表示應進一步檢查原本的設定路徑，但仍不能直接證明規則本身有誤。
為什麼延遲很低，影片卻一直緩衝？
短請求延遲與持續吞吐量是不同指標。固定使用同一部影片或同一個檔案來源，在相同接入網路下測試三輪，再用另一個既有節點比對；同時確認目標請求的實際出口沒有被規則固定至其他策略。
切換成 Proxy 就變快了，需要一直保持嗎？
先記錄差異，再切回 Config 檢查目標符合的規則與策略群組。Proxy 可用於控制變因的比對測試，但會改變其他請求的路由方式；測試完成後請還原原本模式，再依目標修正設定。
更新訂閱能改善速度慢的問題嗎？
只有在伺服器位址、連接埠或設定已變更時，更新才可能修正舊資料。回到 Home 更新自己現有的訂閱，並確認目標記錄是否有變動；更新成功不代表線路壅塞已經排除。
所有協定都很慢，需要重置 App 嗎？
先使用同一節點比較 Wi-Fi 與行動網路，並檢查可直接存取的目標。只有確認本地設定異常時，才考慮還原設定；重置前請保留設定與必要記錄，以免失去排查依據。
回報問題前，先保留最小重現記錄
- 寫明裝置、接入網路、測試時間，以及 Home → Global Routing 的選項。
- 寫明節點類型、目標存取方式、三輪測試結果與速度單位；不要傳送密碼、金鑰或完整訂閱連結。
- 附上異常發生前後的單一變更，例如「同一節點由 Wi-Fi 改用行動網路」，不要只寫「全部都試過了」。
- 還原暫時調整的模式、On Demand 條件與測試設定，接著重新確認日常使用的目標。
分層排查的目的不是找出一組通用參數，而是確認問題發生於本地接入、通往伺服器的路徑、伺服器端傳輸條件，或規則與目標回應。掌握明確證據後，再針對相應層面進行最小幅度的調整；若涉及遠端服務狀態，請將已移除敏感資訊的記錄交由自己的服務商確認。