Shadowrocket（小火箭）速度慢时，先固定测试目标与 Global Routing，再检查已有节点的连通性，随后对照线路、协议参数和 Wi‑Fi／蜂窝网络。本文适合已有自己的服务商与订阅、能够连接但响应慢或传输不稳定的用户；排查结果应是一组可复现的对照记录，而不是单凭一次延迟数值更换全部设置。
开始前：固定测试条件，区分延迟与吞吐量
先给结论：Connectivity Test 的结果不能直接等同于下载速度。延迟反映一次测试请求完成所需的时间，持续传输还受可用带宽、丢包、拥塞、目标服务器限速等因素影响。一个测试响应很快的节点，仍可能在大文件传输时缓慢；某个网页打开慢，也不能直接证明整个连接都慢。
在 Home 记录当前选中的节点以及 Global Routing。在原来使用 Config 的情况下，先保留配置作为基线；需要隔离规则影响时，再短时切到 Proxy，并确认待测请求实际经过所选节点。Scene 涉及场景选择，不应在本轮对照中同时改动；Direct 也不能用来代表代理线路的速度。
- 选定同一个日常访问目标，分别观察首次打开、重复打开和持续传输；不要用不同站点互相替代。
- 暂停其他设备的大流量任务，记录测试时间、网络类型、节点名称、Global Routing 和是否有超时。
- 每种条件重复 3 次，记录各次结果或中位数，不只保留最快的一次。
- 每次只改一个变量，改完重新建立连接；测试结束后恢复原来的 Global Routing。
第一层：节点是否可用，还是只有测试响应正常
在 Home 对当前节点执行 Connectivity Test，再用实际请求验证。测试成功只能说明相应测试条件下可达；测试失败则需要区分服务器不可达、认证错误与测试目标不可达。不要连续刷新订阅来代替节点诊断，更新列表本身不能解决远端负载或线路拥塞。
- 核对节点地址、端口、协议和认证字段是否与用户已有的信息一致。端口必须使用服务商实际提供的值；即使看到常见的
443，也不能自行把其他端口改成它。 - 在同一网络、同一 Global Routing 下，选择已有列表中的另一个节点，重复相同请求。尽量先选协议相同的条目，减少变量。
- 若只有一个节点反复失败，记录其测试时间与错误；若所有节点都慢，继续检查共同线路、本地网络和测试目标。
- 如果怀疑节点信息已变更，按原有 Subscribe 的更新操作刷新一次，并核对当前选择的条目。不要把订阅更新成功误当成节点已经连通。
下面是连接日志中常见的错误片段，具体完整措辞会随协议和底层连接而变化。它们是定位线索，不是对原因的唯一判定；应同时看错误发生在域名解析、建立连接还是传输阶段。
报错：connection refused
原因：目标端口可能未监听，或连接被中间设备主动拒绝。
解法：先核对已有节点的地址与端口，再把发生时间交给自己的服务商确认服务端状态。
报错：i/o timeout
原因：连接或读写在限定时间内未完成，可能涉及丢包、拥塞或远端无响应。
解法：保留相同节点切换网络复测，再与另一个已有节点对照，不要直接把它归因于协议。
报错：no such host
原因：当前解析过程未获得所需主机名的有效结果。
解法：核对主机名拼写和 DNS 设置，并区分失败的是节点域名还是访问目标域名。
第二层：线路拥塞与规则分流如何区分
节点是连接的远端入口，线路则包含本地接入、运营商路径、节点出口以及出口到目标站点的路径。两条名称不同的节点也可能共用部分线路。因此，“换了节点仍然慢”不能单独排除线路问题；同样，测试某一个目标正常，也不能代表所有目标都正常。
| 对照条件 | 观察现象 | 下一步 |
|---|---|---|
| 同节点、同网络，不同时段 | 繁忙时段持续传输明显变慢，其他时段恢复 | 记录多个时段，核对是否存在规律性拥塞 |
| 同节点、同网络，不同目标 | 只有一个站点慢，其他目标正常 | 检查该目标的规则、解析与远端响应 |
| 同节点、同目标，Config 与 Proxy | Proxy 正常，Config 慢或失败 | 在 Config 核对当前配置和实际规则命中 |
| 同节点、同目标，Wi‑Fi 与蜂窝网络 | 只有一种接入方式慢 | 转入本地网络与接入路径排查 |
Config 按当前配置的规则决定请求走向；Proxy 用于代理模式对照，但仍需核对实际请求记录。规则按顺序匹配，前面的规则可能使后面的规则没有机会生效。以下仅展示语法关系，不是可直接替换现有配置的完整文件，也不表示这些策略适合所有目标。
DOMAIN-SUFFIX,example.com,PROXY
IP-CIDR,192.168.0.0/16,DIRECT
GEOIP,CN,DIRECT
FINAL,PROXYDOMAIN-SUFFIX 按域名后缀匹配；IP-CIDR 按 IP 网段匹配；GEOIP 依赖 IP 地理数据进行匹配；FINAL 承接此前未匹配的请求。若某个请求实际走了 DIRECT，继续测试代理节点的延迟并不能解释该请求为什么慢，应先确认命中规则。
结论：先确认走向，再比较线路
当同一目标在 Proxy 下恢复、在 Config 下仍慢时，先检查当前配置的命中规则与 DNS 结果；确认两次请求走同一路径后，再判断节点或线路差异。
第三层：协议参数正确，比直接换协议更重要
Shadowsocks、VMess、VLESS、Trojan、Hysteria2、WireGuard 的传输与认证机制不同，不能只改节点的协议名称就完成切换。每一种连接都需要匹配的服务端支持及完整参数。只在用户已有、已确认可用的配置之间做对照；若两条配置使用不同服务器，测出的差异不能全部归因于协议。
- Shadowsocks：核对加密方式与密码；使用插件时，还要核对服务端要求的插件及其参数。
- VMess／VLESS：核对身份字段、传输方式以及 TLS 等参数。使用 WebSocket 或 gRPC 时，相应路径或服务名也要与服务端一致。
- Trojan：核对密码与 TLS 的服务器名称。连接证书校验失败时应检查时间、域名和证书链，不应以关闭校验作为提速手段。
- Hysteria2：基于 QUIC，依赖 UDP 路径可用；如果当前网络限制 UDP，可能出现握手失败或不稳定，不能预设它在所有网络都更快。
- WireGuard：使用 UDP，需核对密钥、端点及路由相关参数。小请求正常而较大传输停滞时，可将 MTU 列为检查项，但先排除丢包和服务端问题。
这条流程说明“连接开关已打开”与“目标内容能够稳定传输”不是同一状态。握手异常通常优先检查认证、TLS 或底层传输；握手完成后才持续变慢，则继续查看丢包、拥塞、远端负载与目标响应。不要同时修改 MTU、DNS、协议和节点，否则即使恢复，也无法知道是哪项改变产生了作用。
第四层：Wi‑Fi、蜂窝网络与 DNS 的本地检查
保持同一节点和同一目标，依次测试 Wi‑Fi 与蜂窝网络，是区分本地接入差异的直接方法。切换前注意流量消耗；切换后等待网络稳定，再重新建立连接。两种网络结果不同，说明接入环境或路径存在差异，但还不足以判定一定是路由器、运营商或节点中的某一方。
- 核对基础访问：暂时断开 Shadowrocket，访问一个原本可直接打开的常用页面。如果基础访问也慢，先处理本地接入；这一步不能用一个本就无法直接访问的目标来验证。
- 检查 Wi‑Fi 条件：靠近路由器复测，暂停局域网内的大流量任务，并确认公共 Wi‑Fi 的认证页面已经完成。信号格数不是可用带宽的完整指标。
- 区分解析与传输：若首次打开等待很久、随后内容传输正常，检查 DNS 请求是否超时或反复重试。不要仅凭这一现象直接更换所有 DNS 设置。
- 检查自动连接干扰：在 Settings → On Demand 核对现有条件，观察网络切换时是否触发重连。为建立手动测试基线，可记录原设置后暂时关闭 On Demand，测试后恢复。
- 保留 IPv6 信息：如果问题只在特定网络出现，记录解析结果是否包含 IPv6 地址以及相关连接是否失败。不要在没有对照结果时把关闭 IPv6 当作通用方案。
DNS 改动影响的是名称如何解析以及后续可能使用的地址，不会直接增加线路带宽。若持续下载已经建立且稳定缓慢，反复更换 DNS 通常不能回答带宽瓶颈在哪里。相反，若请求卡在解析阶段，就应先看解析结果和请求路径，而不是继续调整协议参数。
常见追问：延迟很低、更新订阅与晚间变慢
延迟只有几十毫秒，为什么下载还是慢？
延迟测试与持续传输测量的对象不同。保持同一节点，对同一目标重复观察持续传输，并记录是否在开始几秒后下降；再换另一个目标对照，区分路径拥塞和目标端限速。
更新 Subscribe 能让原来的节点更快吗？
更新可以同步已有订阅中变更的地址或参数，但不会为当前链路增加带宽。只有怀疑节点信息失效或发生变更时才进行更新，随后仍要在 Home 检查实际选中的节点并重新测试。
为什么只有晚上慢，白天又正常？
先用相同节点、网络和目标记录多个时段，同时排除家庭网络的大流量任务。若差异反复出现，把时段、失败比例和同条件对照结果交给自己的服务商，不要仅凭一次测试断定原因。
所有节点都慢，是不是 Shadowrocket 设置有问题？
不一定。共同因素还包括 Wi‑Fi、接入路径、DNS、规则和测试目标。先比较 Wi‑Fi 与蜂窝网络，再比较 Config 与 Proxy；确认问题跟随哪一个变量后，只检查相关设置。
整理结果：用可复现记录结束排查
四层排查的目标是缩小问题范围，而不是把所有选项重新设置一遍。完成对照后，恢复原来的 Global Routing 和 On Demand；没有得到支持的改动也应恢复。若需要自己的服务商协助，只提交必要的现象与连接信息，不要公开完整订阅链接、密码、私钥或认证令牌。
- 环境：iPhone 或 iPad、Wi‑Fi 或蜂窝网络、发生时间与持续时长。
- 连接：已选节点的辨认名称、协议、Global Routing，以及是否使用同一目标复测。
- 结果：3 次测试的原始记录、实际访问现象、错误片段，以及另一网络或另一已有节点的对照结果。
- 已做操作：逐项列出改变过的设置及是否恢复，让下一次检查从已知状态开始。
结论：把“慢”写成可以重现的条件
记录“同节点在 Wi‑Fi 连续三次超时，切到蜂窝网络后三次成功”，比只写“速度慢”更有助于下一步定位；它指向需要检查的接入路径，但仍保留进一步验证的空间。