小火箭速度慢怎么排查：节点、线路、协议、本地网络分四层定位

开始前：先把“速度慢”转成可重复现象

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；客户端购买与用户自己的线路服务是两项独立内容。