Shadowrocket（小火箭）连接后的速度取决于整条请求路径，连通性测试的低延迟不等于高下载速度。本文面向已经有自己的服务商与订阅、能够连接但访问变慢的用户，按本地网络、路由与协议、线路质量、节点负载逐层对照。每次只改一个条件，记录结果，再决定保留设置还是恢复原值；本站不提供、不销售、不推荐节点或订阅。
一、先区分延迟、吞吐量与连接失败
“网速慢”至少包含三类现象：点开网页后等待很久、文件下载持续速度低、连接时好时坏。第一类可能涉及 DNS 查询、连接建立或远端响应；第二类更接近持续吞吐量问题；第三类则要关注丢包、网络切换和连接中断。先描述现象，比直接更换协议更有效。
这条流程是诊断用的逻辑分层，不是固定的数据包处理时序。DNS 查询可能发生在不同环节。Home 中的 Connectivity Test 用于判断测试目标是否可达，并参考对应测试方式的耗时；它不能代替文件下载测试，也不能证明所有网站、所有传输方式都正常。
- 首屏等待长：记录首次访问与再次访问是否有明显差异，同时检查域名解析和连接建立。
- 下载持续慢：固定同一个文件、同一个目标站点，观察至少 30 秒，避免只看起始瞬间的速度。
- 频繁卡住：记录发生时是否刚从 Wi-Fi 切换到蜂窝网络，或屏幕刚从锁定状态恢复。
- 只有一个站点慢：优先检查该站点的路由、资源服务器与账户限速，不直接归因于客户端。
注意单位：8 Mbps 约等于 1 MB/s，这是比特与字节的换算关系，尚未扣除协议开销。把测速页面的 Mbps 与下载界面的 MB/s 直接比较，会把正常差异误判为速度下降。
二、建立本地 Wi-Fi 与蜂窝网络基线
先证明设备到互联网的基础连接正常，再判断代理路径。选择一个在当前网络可以直接访问的站点作为基线目标，不要使用本来就需要代理才能访问的目标做直连对照。测试期间暂停其他设备的大文件传输，并避免同时运行多个测速任务。
-
记录原值
在 Home 记下当前选中的节点与 Global Routing 姿态，在 Config 记下当前使用的配置文件。后续只修改一个条件，测试后能够回到同一基线。
-
暂停自动连接
检查 Settings → On Demand。若已启用自动触发条件，先记录并暂时关闭相关开关，再回到 Home 关闭连接开关，确认测试期间没有被重新建立连接。
-
测量直连
在 Wi-Fi 下访问基线目标，记录打开时间、下载持续速度与是否中断。连续做三次，保留三个结果，而不是只选择最快的一次。
-
切换网络
关闭 Wi-Fi，确认设备已使用蜂窝网络，再重复相同目标与相同操作。注意流量消耗；不要一边切换网络一边计时。
-
恢复连接
回到 Home，选择原来的节点并开启连接。先执行 Connectivity Test，再进行同一目标的访问测试；完成全部对照后恢复原先的 On Demand 设置。
如果关闭连接后 Wi-Fi 仍慢、蜂窝正常，优先检查无线信号、路由器上行占用和本地网络质量。如果两种网络直连都正常，而开启同一个节点后只有其中一种变慢，说明接入网络到该节点的路径差异值得继续排查，但尚不能据此认定是节点负载。
三、确认 Global Routing 与实际命中的规则
连上后慢，不一定表示流量确实经过了所选节点。Home → Global Routing 决定路由姿态；Config 中的规则只有在相应姿态下才参与分流。先核对模式，再阅读规则，避免修改一份当前没有生效的配置。
| 姿态 | 排查意义 | 需要注意 |
|---|---|---|
| Proxy | 用于对照代理路径，减少分流规则造成的变量。 | 只作短时测试，完成后恢复原姿态。 |
| Direct | 用于观察直接连接的访问结果。 | 不等于关闭系统中的 VPN 连接，不能替代断开连接的基线测试。 |
| Config | 按当前配置中的规则决定策略。 | 检查当前配置、命中顺序与最终策略。 |
| Scene | 按已设置的场景决定相关路由行为。 | 先核对实际触发的场景，避免测试条件随网络变化。 |
下面只演示规则语法，不是建议覆盖现有配置。DOMAIN-SUFFIX 匹配域名及其子域；IP-CIDR 匹配 IPv4 网段；GEOIP 按地址归属数据库判断；FINAL 处理前面没有命中的请求。规则按顺序匹配，宽泛规则放在前面可能使后面的细分规则没有机会命中。
[Rule]
DOMAIN-SUFFIX,example.com,PROXY
IP-CIDR,192.168.0.0/16,DIRECT
GEOIP,CN,DIRECT
FINAL,PROXY- 示例中的
example.com是说明用域名，不是测速目标；192.168.0.0/16是私有地址范围，不包含所有私有网段。 GEOIP,CN,DIRECT不表示“所有中文网站直连”，域名语言与服务器 IP 归属不是同一概念。- 在请求记录中核对目标域名与实际策略。如果改为 Proxy 后正常、恢复 Config 后异常，应优先检查规则和策略指向。
- 同一网页可能向多个域名请求图片、视频和脚本。主域名正常，不代表所有资源都走相同路径。
四、协议参数先核对，不用猜测值提速
在 Home 打开已有节点的编辑页面，核对 Type、服务器地址、端口与认证信息。Shadowsocks、VMess、VLESS、Trojan、Hysteria2、WireGuard 的参数不能互换；协议必须与远端配置一致，不能仅修改 Type 来做协议速度对比。
例如，已有配置指定端口 443 时，应先确认远端实际监听的传输方式。TCP 443 可达，并不证明 UDP 443 可达；端口号相同也不说明使用了相同协议。Hysteria2 基于 QUIC，依赖 UDP；WireGuard 也使用 UDP，网络对 UDP 的限制可能影响连接和持续传输。
- TLS 与服务器名称：使用 TLS 的配置要核对远端要求的服务器名称与证书条件。不要通过关闭证书验证来掩盖参数错误。
- 传输路径：已有配置涉及 WebSocket 等传输时，路径与 Host 必须与远端一致。普通网页能打开不等于代理传输入口可用。
- Hysteria2 带宽参数：若配置包含上下行带宽设置，应按当前网络和远端说明填写。盲目提高数值不保证更快，过高的发送预期可能加重排队或丢包。
- WireGuard MTU：先保留已知可用值。小请求正常、大请求停滞时才考虑路径 MTU 问题；例如将原有 1420 临时改为 1380 可作为一次对照，不能视为通用最佳值。
- DNS：域名访问失败而已有 IP 连接可用时，检查 Config 中实际使用的 DNS 设置。不要同时修改 DNS、规则和协议，否则无法知道哪一项产生了变化。
五、用对照结果区分线路质量与节点负载
线路质量与节点负载都可能表现为“晚间变慢”，单靠时间段无法下结论。保持目标站点不变，先固定节点切换接入网络，再固定接入网络切换用户已有的另一个节点。每组测试至少重复三次，并留出间隔，避免并发测试互相争用带宽。
| 观察结果 | 优先怀疑 | 下一项验证 |
|---|---|---|
| 同一节点仅在 Wi-Fi 下慢 | 本地无线环境或该接入网络的远端路径。 | 靠近路由器重测，再与蜂窝网络对照。 |
| 同一节点在两种网络都慢，其他已有节点正常 | 该节点的入口、出口或资源限制。 | 换两个目标站点，并比较不同时段。 |
| 所有节点访问同一站点都慢 | 目标站点、资源服务器或共同经过的路径。 | 保持节点不变，测试另一独立目标。 |
| Connectivity Test 正常，持续下载慢 | 吞吐受限、丢包、远端限速或目标响应能力。 | 记录持续速度，不只比较测试耗时。 |
| 频繁超时且结果波动明显 | 无线干扰、拥塞、丢包或远端不稳定。 | 先完成本地直连对照，再检查节点路径。 |
延迟低只说明短请求的往返或建立连接耗时较低，带宽、丢包率和并发限制仍可能拖慢大文件。反过来，远距离节点的延迟较高，也不必然意味着持续下载速度低。没有控制目标、时间和网络条件的两张测速图，不能证明某种协议一定更快。
如果只有高峰期出现明显退化，且本地直连基线正常，可以将现象、时间段、接入网络与脱敏后的测试结果交给自己的服务商确认。节点 CPU、出口带宽和连接数属于远端指标，不能仅凭客户端看到的延迟直接推算。
- 保留每组的最低、最高与中间结果，关注波动范围，而不只记录单个最好成绩。
- 视频应用可能缓存内容或自动降低画质，短时间播放流畅不能证明持续吞吐量恢复。
- 测速目标与日常目标可能使用不同路径，最终应回到实际出现问题的应用复测。
六、出现错误时先按报错类型处理
以下是网络连接诊断中可能出现的标准错误字符串，具体呈现以实际请求记录为准，不保证每种测试都会显示相同文本。报错描述的是失败阶段，不是远端根因的最终结论。记录原文和出现时间，比反复开关连接更有诊断价值。
报错:i/o timeout
原因与解法:指定时间内未完成相关网络读写，可能涉及路径不通、丢包或远端无响应。先固定节点切换 Wi-Fi／蜂窝网络，再核对远端地址、端口与对应传输方式，不把超时直接当成带宽不足。
报错:connection refused
原因与解法:连接请求被明确拒绝，常见于目标端口没有相应服务监听或中间设备主动拒绝。核对已有配置的地址与端口，并向自己的服务商确认监听状态，调整 MTU 通常不能修复此类错误。
报错:no such host
原因与解法:当前解析过程未能获得所需域名记录，可能是域名填写错误或解析环境异常。核对服务器域名拼写，切换接入网络复测，再检查当前配置的 DNS 设置；不要把未经确认的 IP 长期写死。
如果没有错误，只有速率偏低，应继续做持续吞吐量对照，而不是寻找并不存在的报错。提交记录前遮盖密码、Private Key、认证 token 和订阅地址；保留协议类型、脱敏后的目标、端口、网络类型和时间，通常足够描述现象。
七、常见追问与排查收尾
延迟只有几十毫秒，为什么下载还是慢？
Connectivity Test 与持续下载测量的对象不同。回到 Home 保持同一节点，固定目标文件观察至少 30 秒，并检查 Mbps 与 MB/s 是否混用；再用另一目标复测，区分单站限速与路径吞吐问题。
改成 Proxy 就正常，Config 为什么卡？
先在 Home → Global Routing 确认两次测试的姿态，再到 Config 检查当前配置的 DOMAIN-SUFFIX、IP-CIDR、GEOIP 与 FINAL 顺序。结合请求记录确认实际策略，不要直接删掉全部规则。
切换网络后卡住，需要一直重启设备吗？
先等待新网络稳定，再在 Home 关闭并重新开启连接，让连接在新路径上建立；检查 Settings → On Demand 是否触发了预期之外的自动连接。只有复现条件明确后，才判断是否与网络切换有关。
换成 Hysteria2 就一定能提速吗？
不能保证。先确认自己的远端支持该协议且参数完整，再确认当前网络可传输相应 UDP 流量。不同入口与出口会引入额外变量，应尽量控制目标、接入网络和测试时段，不能只按协议名称判断。
排查结束要恢复哪些设置？
恢复原有 Global Routing、当前配置与 On Demand 设置，撤销没有改善的 MTU 或 DNS 改动。最后用日常应用复测一次，把有效修改与对应结果记下，避免留下临时测试姿态。
排查的终点应是一个能复现、能验证的结论，例如“本地直连正常，同一节点仅在某接入网络持续下载变慢”，而不是笼统地说“客户端慢”。保留这一结论，再处理对应层级，才能减少无效修改。