本文适合已经在 Shadowrocket（小火箭）中添加自有节点、连接能够建立但网页加载或文件传输明显变慢的用户。排查时先建立本地网络基线，再依次检查节点延迟、线路时段、Global Routing、协议参数和 Log；每次只改变一个条件，最终可以判断瓶颈位于设备网络、远端线路、规则配置还是传输参数。
先固定测试条件，避免测速结果互相干扰
速度排查最容易出现的问题，是同时更换 Wi‑Fi、节点、协议和测速目标。即使结果变快，也无法知道究竟是哪一项起作用。正确方法是固定设备、网络、测试目标和测试时段，每一轮只改变一个变量，并至少重复三次。
先记录未启用 Shadowrocket 连接时的本地网络表现，包括网页首开时间、下载速率和基础延迟。随后打开 Shadowrocket，保持同一个 Wi‑Fi、同一个测试目标，再记录一组结果。若本地基线本身已经明显波动，应先处理路由器、信号或接入网络，而不是立即修改客户端配置。
记录本地基线
关闭 Shadowrocket 的连接开关，在同一 Wi‑Fi 下连续测试三次。记录延迟、下载速率和网页首次打开时间，不要只保留最高值。
固定一个节点
回到 Home，选中用户已有服务中的一个节点。测试期间不要刷新订阅或自动切换节点，以免测试对象发生变化。
使用 Config
在 Home → Global Routing 选择 Config，让请求按照当前配置文件中的规则处理。排查过程中同时记录配置名称，防止把规则变化误判为线路变化。
重复三轮测试
打开连接后，对同一目标连续测试三轮，每轮间隔约 30 秒。若结果分别为 18 Mbps、76 Mbps、24 Mbps，应优先判断为波动，而不是稳定限速。
一次改一项
更换节点后重新测试；确认节点差异后，再比较协议或传输参数。不要在同一轮中同时修改 DNS、MTU、Global Routing 和节点。
第一层：检查本地网络与设备接入
请求从应用发出后，需要先经过设备当前网络，再进入系统建立的 VPN 隧道。Wi‑Fi 信号弱、路由器繁忙、接入网络切换或局域网丢包，都会在流量抵达远端节点之前造成延迟。此时更换协议通常不能解决根因。
在 iPhone 或 iPad 上，可以先靠近无线路由器测试，再切换到另一个已知稳定的 Wi‑Fi 复测。也可以在条件允许时比较蜂窝网络，但两组测试必须使用相同节点和相同目标。若某个 Wi‑Fi 下所有节点都慢，而另一网络恢复正常，问题更可能位于本地接入层。
还要留意“刚连接很快，数分钟后逐渐变慢”的现象。它可能来自无线信号干扰、路由器负载变化或设备在不同接入点之间切换。可先保持屏幕开启完成一轮短测试，再进行五至十分钟持续传输，比较短连接与长连接的差异。
- 所有节点同时变慢：优先检查 Wi‑Fi 信号、路由器负载和当前接入网络。
- 只有一个节点变慢：本地网络通常不是首要嫌疑，应继续检查节点与线路。
- 网页首开慢、打开后正常：重点检查 DNS、连接建立和 TLS 握手阶段。
- 小文件正常、大文件持续变慢：重点观察线路吞吐、丢包、MTU 与拥塞控制。
- 切换网络后立即恢复：保留原有 Shadowrocket 配置，先处理原网络环境。
第二层：用 Ping 与分时测试定位节点和线路
在 Home 的节点列表中执行可用的延迟或 Ping 测试时，不要只看一次结果。单次 60 ms 并不能证明线路稳定；连续结果为 58 ms、62 ms、61 ms，通常比 35 ms、240 ms、90 ms 更可预测。后者虽然最低值更好，但抖动明显，网页和视频仍可能出现停顿。
Ping 还可能受到远端响应策略影响，因此它只能作为入口指标。若延迟测试正常而实际访问慢，应继续做真实传输测试，并查看 Log 中连接建立、超时和重试的时间分布。远端没有响应 Ping，也不等于对应服务一定不可用。
线路时段同样重要。可以在早间、晚间和出现问题的固定时段，对同一节点执行相同测试。如果只有晚间吞吐下降，而本地基线和其他节点正常，现象更符合特定线路或远端资源在该时段拥塞。
报错: timeout
原因与解法:连接在限定时间内没有完成，可能是本地丢包、远端节点繁忙或中间线路不稳定。先在同一网络测试另一个自有节点，再换一个网络复测，以两次对照确定范围。
报错: connection refused
原因与解法:目标地址可以到达，但指定端口拒绝连接。核对节点地址、端口和协议是否与用户自己的服务商资料一致；端口 443 只是常见示例，并不表示所有配置都应改成 443。
报错: Network is unreachable
原因与解法:当前网络没有可用路径，或网络在 Wi‑Fi 与蜂窝连接切换时短暂中断。等待系统网络稳定后重新连接，再检查该错误是否持续出现。
第三层：核对 Global Routing、规则与 DNS
节点本身正常，但部分网站慢或只有某些应用慢时，应检查 Global Routing。Proxy 表示请求统一使用当前代理策略，Direct 表示直接连接，Config 按配置文件规则处理，Scene 则按已设置的场景选择行为。排查日常配置时，通常先确认当前是否处于预期的 Config，而不是误停留在 Direct 或 Proxy。
Config 模式下，一条请求会从上到下匹配规则。DOMAIN-SUFFIX 按域名后缀匹配，GEOIP 按目标 IP 的地理数据库结果匹配，IP-CIDR 按地址段匹配，FINAL 处理前面规则均未命中的请求。顺序错误可能让本应 Direct 的请求进入代理，也可能让需要代理的请求提前命中 Direct。
DOMAIN-SUFFIX,example.com,PROXY
IP-CIDR,192.168.0.0/16,DIRECT
GEOIP,CN,DIRECT
FINAL,PROXY以上语法仅用于解释匹配顺序，不代表适合所有配置。第一条把指定示例域名交给 PROXY，第二条让局域网地址 Direct，第三条根据 GEOIP 结果 Direct，最后由 FINAL 接住其余请求。实际策略名必须与当前 Config 中存在的策略一致。
如果现象是“Ping 正常但网页长时间空白”，还应检查 DNS。域名解析发生在建立目标连接之前；解析超时、返回不可达地址或不同网络下缓存结果不一致，都可能表现为首屏慢。不要同时替换多项 DNS 设置，先恢复到已知可用的配置，再逐项比较。
- 先在 Home 确认当前节点与 Config 名称。
- 确认 Global Routing 没有意外停在 Direct 或全局 Proxy。
- 在 Config 中检查目标域名最先命中的规则，而不是只查看 FINAL。
- 对“域名打不开但 IP 可连接”的现象，优先查看 DNS 解析过程。
- 修改规则后重新发起连接，避免把既有连接的缓存结果当成新规则结果。
第四层：比较协议与传输参数
Shadowrocket 支持 Shadowsocks、VMess、VLESS、Trojan、Hysteria2、WireGuard 等协议。协议名称本身不能直接决定速度；真实表现还取决于服务端配置、加密方式、传输层、线路丢包、CPU 负载和参数是否匹配。只有在同一网络、同一路径条件接近时，协议对照才有意义。
修改前应保存用户自己的服务商给出的原始参数。地址、端口、密码、UUID、公钥、SNI、Transport、TLS 与路径需要成组匹配。只复制地址和端口、遗漏其余字段，可能出现可以建立连接但不断重试、握手失败或传输效率异常的情况。
- Shadowsocks：核对加密方式、密码与端口。客户端与服务端参数不一致时，通常无法正常完成数据交换。
- VMess 与 VLESS：核对 UUID、Transport、TLS、Host、Path 与 SNI。WebSocket 路径或 Host 错误会影响握手。
- Trojan：重点核对密码、TLS 与 SNI。证书名称和目标名称不匹配时，可在 Log 中看到 TLS 相关错误。
- Hysteria2：在高丢包网络中的表现与带宽、拥塞控制及服务端限制有关。不要脱离服务端配置单独填写带宽参数。
- WireGuard：核对公钥、私钥、Address、Endpoint 和 Allowed IPs。若小请求正常而较大传输停滞，可在服务商说明允许的范围内比较 MTU，例如依次测试 1280、1380 与 1420，每次只改一个值。
MTU 不是越小越好。过大时，部分路径可能发生分片或丢弃；过小时，每个数据包承载的有效数据减少，额外开销上升。测试 MTU 时应使用同一节点和同一传输任务，并在每轮修改后重新连接。若服务商明确指定数值，应优先保持指定值。
On Demand 主要用于按网络条件自动建立连接，不是测速加速开关。若排查期间出现连接自动断开或切换，可进入 Settings → On Demand 暂时检查现有规则是否按 SSID、域名或网络状态触发。记录原设置后再调整，测试结束后按实际使用需求恢复。
第五层：从 Log 判断慢在连接的哪个阶段
Log 的价值不是显示一个笼统的“快”或“慢”，而是把请求经过的阶段展开。进入 Settings → Log 后，在清空已有记录的条件下复现一次问题，再按时间查看 DNS、连接、TLS、规则命中和重试信息。只保留一次复现过程，通常比在大量历史记录中搜索更容易定位。
如果同一个域名在短时间内反复解析，随后才建立连接，应检查 DNS。若 TCP 建立后长时间停在 TLS handshake，重点核对系统时间、SNI、TLS 参数和远端响应。若连接迅速建立但传输过程中连续出现 timeout 或 retry，则更接近丢包、拥塞或远端负载问题。
报错: TLS handshake failed
原因与解法:TLS 协商未完成。核对节点中的 SNI、Host、TLS 开关与用户自己的服务资料，确认设备时间自动同步，再重新连接测试。
报错: DNS lookup failed
原因与解法:域名解析没有得到可用结果。先比较其他域名是否正常，再检查 Settings 中的 DNS 配置及当前网络能否访问所设解析服务。
报错: connection reset by peer
原因与解法:远端主动重置了已建立的连接，可能与参数不匹配、远端策略或线路中断有关。保持本地网络不变，使用另一个自有节点对照，再向自己的服务商核对原节点状态。
阅读 Log 时应关注时间关系，而不是只截取最后一行。例如 DNS 用时 20 ms、连接建立用时 70 ms，但 TLS 阶段等待数秒，瓶颈就不在域名解析。相反，如果连接之前已反复出现 DNS timeout，更换节点未必能解决问题。
清理旧记录
打开 Settings → Log，先清理与本轮测试无关的历史内容。
复现一次问题
返回目标应用或网页，只执行一次能够稳定触发变慢的操作。
找到首条请求
按域名、目标地址或时间定位请求起点，确认它命中了哪条规则与哪个策略。
查看等待阶段
比较 DNS、连接建立、TLS 与数据传输之间的时间间隔，找出最长停顿。
做单变量复测
只更换网络、节点或一个参数，再复现一次。若对应错误消失，即可缩小故障范围。
常见速度问题的直接判断
完成以上分层后，可以用现象组合快速归类。归类的目的不是立即给出统一参数，而是决定下一步应该修改哪里。用户已有服务的具体节点状态、端口和传输配置，应以自己的服务商资料为准。
为什么 Ping 很低，下载还是慢？
Ping 测量的是响应延迟，不是持续吞吐。固定同一节点执行至少三次真实下载测试，同时观察 Log 是否出现 timeout、retry 或连接重置。若延迟稳定但吞吐持续低，应检查线路容量、远端负载和传输参数。
为什么只有晚上明显变慢？
先在早晚分别记录本地基线和同一节点结果。若本地网络正常，而该节点只在固定时段下降，再对照另一个自有节点；只有特定节点下降时，更接近线路时段性拥塞。
为什么网页慢，但应用里的小请求正常？
网页通常包含多个域名、TLS 连接和较大的静态资源。检查 Config 中各域名的规则命中情况，再从 Settings → Log 查看 DNS 与 TLS 阶段是否反复等待。
切换 Proxy 后变快，Config 就一定有问题吗？
这说明两种姿态产生了不同路径，但还不能直接确定具体规则错误。回到 Config，查看目标域名首先命中的 DOMAIN-SUFFIX、GEOIP、IP-CIDR 或 FINAL，并核对其策略是否符合预期。
需要把所有协议参数都调一遍吗？
不需要。先保留服务资料中的原始值，只在已经确认本地网络、节点状态和规则都正常后，针对 Log 中的现象修改一项参数。每次修改后重新连接并记录结果。