本文适用于 Shadowrocket（小火箭）已经能够连接、但网页加载慢、视频缓冲或下载速率不稳定的情况。以你已有的服务商与订阅为前提，先固定测试目标并核对分流，再依次对照节点、线路、协议和本地网络；每次只改一个条件，最终得到可以复现的现象与处理方向，而不是仅凭一次延迟测试更换全部配置。
一、先区分慢在哪里
连接开关开启，不等于每个请求都经过代理，也不等于代理出口带宽充足。网页首屏慢、视频播放中反复缓冲、下载长期低速，可能分别涉及 DNS、连接建立、持续吞吐量。先写清具体症状，后续对照才有意义。
这条流程链表示排查位置，不是所有协议固定的底层处理顺序。DNS 可能参与规则判定和目标解析，缓存也会改变首次访问与再次访问的耗时。不要把单一网站的响应慢直接等同于整条代理线路慢。
- 选一个你有权访问、内容相对稳定的网页或下载对象，所有对照使用同一目标；不要用不同网站的测速结果互相比较。
- 记录当前时间、本地网络类型、节点名称、协议、Global Routing 状态以及症状，节点名称在记录中可用 A、B 代称。
- 暂停系统更新、云盘同步与其他大流量任务，连续做三次相同操作，分别记录首屏等待、传输速度与是否中断。
- 区分冷启动与重复访问。第一次解析和握手较慢、第二次明显加快，与持续传输始终低速不是同一个问题。
例如，80 Mbps 理论上约等于 10 MB/s；这只是单位换算示例，不是 Shadowrocket 的实测速率或性能承诺。延迟表示等待时间，下载速率表示单位时间传输的数据量，两者不能直接换算。
二、先核对分流与连接状态
在 Home 核对当前选中的节点和连接开关，再查看 Global Routing。Proxy 用于让可代理流量走代理策略，Direct 用于直连，Config 按配置规则分流，Scene 按场景配置决定行为。排查时必须知道目标请求实际走向，不能仅凭状态栏图标判断。
- Config：打开 Config 中当前使用的配置，检查规则顺序及命中的策略；节点已选中，不代表该域名一定使用该节点。
- Proxy：可作为短时对照，观察目标在代理路径下是否改善。测试完成后恢复原来的 Global Routing，避免改变其他应用的访问路径。
- Direct：用于对照本地网络直达目标的表现。若目标本身无法直连，失败不能证明本地宽带速度低。
- Scene：先核对正在生效的场景条件和路由行为。为减少变量，可以临时采用明确的 Config 或 Proxy 状态进行对照。
下面是规则语法示例，不是可直接替换现有配置的完整文件。这里的 example.com 是示例域名，PROXY 必须对应实际可用的代理策略。规则通常按顺序匹配，FINAL 放在末尾承担兜底作用。
[Rule]
DOMAIN-SUFFIX,example.com,PROXY
IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
GEOIP,CN,DIRECT
FINAL,PROXYDOMAIN-SUFFIX 按域名后缀匹配，IP-CIDR 匹配地址段，GEOIP 按 IP 地理归属数据匹配。若目标误中 DIRECT，应先修正规则而不是切换协议；若 Proxy 正常、Config 慢，优先核对规则、DNS 和策略选择。更多路由说明见代理模式。
三、节点层：核对可用性与负载迹象
节点指你已有配置中的具体服务端入口。节点延迟低，只说明测试请求在特定条件下往返较快；它没有测出服务端出口拥塞、账号限速或目标网站对出口的限制。对同一个节点，短请求成功而持续下载变慢，也可能是负载或限速表现。
- 在 Home 确认选中的节点没有误选，检查地址、端口、协议类型与服务商提供的信息是否一致。不要把端口统一改成 443；只有服务端确实监听该端口时才能使用。
- 若你已有多个节点，保持同一本地网络、同一 Global Routing 和同一测试目标，只切换节点 A 与 B，记录三轮结果。
- 检查已有订阅的流量与有效期信息；在 Home 对订阅执行更新后，再确认节点参数是否变化。订阅和节点从你的服务商处获取。
- 只有某一个入口持续异常时，向你的服务商反馈节点代称、故障时间和报错。若多个入口共享出口或中转，不要将它们当作完全独立的对照组。
结论：先定位单点，再调整配置
同一网络与目标下，只有节点 A 持续异常、节点 B 正常时，先保存 A 的错误记录并确认其服务状态；此时全局修改 DNS、MTU 或所有协议参数，会破坏已经可用的对照条件。
四、线路层：比较时段与网络路径
线路是设备到入口、入口到出口以及出口到目标之间的传输路径。节点名称里的地区不等于整条路径，也不能直接推出低延迟或高带宽。相同入口在晚间变慢、非高峰恢复，可能涉及共享链路拥塞，但仅凭这一现象不能断言具体哪段网络负责。
| 对照条件 | 具体操作 | 可以缩小的范围 |
|---|---|---|
| 同节点、不同时段 | 保存上午与晚间各三次结果，目标与本地网络不变 | 判断是否存在重复出现的时段相关拥塞 |
| 同节点、不同接入 | 在 Wi-Fi 与蜂窝网络之间切换，重新建立连接 | 识别本地接入或运营商路径差异 |
| 同网络、不同目标 | 分别访问两个已有测试目标，保持节点不变 | 区分普遍传输异常与单个目标响应异常 |
| 同目标、已有不同入口 | 仅切换节点，不同时修改协议与路由 | 判断异常是否与某个入口或共享路径相关 |
若有可信的丢包测试条件，要区分 ICMP 探测和真实业务传输。中间路由设备可能限制探测回复，某一跳显示高丢包而最终目标正常，并不能证明业务流量在那里同等丢失。更有价值的是：末端持续失败、传输反复停顿，以及这些现象能否在相同条件下重现。
不要在一次测试中同时切节点、换 DNS、换协议和重启路由器。每完成一组对照，先恢复基线，再改下一项；否则即使速度恢复，也无法判断起作用的步骤。
五、协议层：确认传输条件而非只看名称
Shadowsocks、VMess、VLESS、Trojan、Hysteria2、WireGuard 的服务端参数和传输条件不同。更换协议不是把现有节点的类型字段改成另一个名称；只有你已有的服务端明确提供对应配置，才能进行有效对照。
- Shadowsocks：核对服务端地址、端口、加密方法与密码，不能用修改加密方法来修复参数不匹配。
- VMess / VLESS：除身份参数外，还要检查传输方式及其配套字段；若使用 WebSocket，Path 和 Host 应与服务端要求一致。
- Trojan：核对密码与 TLS 服务名等参数。TLS 握手失败属于连接建立问题，不应通过降低证书验证要求来掩盖。
- Hysteria2：基于 QUIC，依赖 UDP 通路。某些高延迟、丢包场景下可能更合适，但网络限制 UDP 时，可能直接无法建立有效连接。
- WireGuard：基于 UDP，检查 Endpoint、密钥与服务端配置。隧道能够建立但部分大请求停滞时，才进一步调查路径 MTU，不要把任意 MTU 数值当作通用加速设置。
例如，服务端配置为 UDP 443 时，仅确认 TCP 443 可访问不能证明 Hysteria2 可用；端口号相同，传输层仍然不同。使用 TCP 承载的业务和使用 UDP 的业务，也可能在同一网络下得到不同结果。
报错：connection refused
原因与解法：目标端口的连接被主动拒绝，可能是端口错误、服务未运行或中间设备拒绝连接。先核对服务商给出的地址与端口，再确认服务状态；反复测速不能修复拒绝连接。
报错：i/o timeout
原因与解法：某一步网络操作未在时限内完成，可能发生在解析、连接或读取阶段。查看错误上下文，再以同节点切换本地接入的方式缩小范围，不要直接认定是密码错误。
报错：TLS handshake timeout
原因与解法：TLS 握手未按时完成，可能与路径、服务端负载或握手参数有关。先确认系统时间、TLS 服务名及服务端配置，再比较另一种本地网络下是否仍然失败。
上述是网络诊断中可能出现的错误原文，实际日志可能带有前缀、目标地址或更详细的原因。它们用于判断失败阶段，不代表 Shadowrocket 在所有平台都会显示完全相同的提示。
六、本地网络：检查 Wi-Fi、DNS 与自动连接
本地网络的异常会影响所有节点。先在同一设备上比较 Wi-Fi 与蜂窝网络，再决定是否深入检查路由器；如果只有一台设备异常，再检查该设备上的其他 VPN、过滤工具、节能设置与后台下载，而不是先重置整个网络。
- 确认 Wi-Fi 信号与拥塞：靠近路由器重复测试，条件允许时比较不同频段。高频段并非任何距离都更快，应以同一位置的实际稳定性判断。
- 核对 DNS 表现：若主要是首次打开网页等待很久，后续下载正常，检查 DNS 设置与解析失败记录。先保存原配置，再对照系统 DNS 或你已有的自定义 DNS；不要同时更改多个解析选项。
- 检查时间与网络登录：确认系统日期时间正确，公共 Wi-Fi 已完成其网络登录。未完成网络登录时，节点可能集体超时，TLS 连接也可能失败。
- 检查自动重连：在 Settings → On Demand 查看是否有自动连接条件。手动断开用于对照时，确认它没有立即重新触发连接；测试结束恢复原设置。
- 重新建立基线：切换 Wi-Fi 或蜂窝网络后重新连接，再开始三次对照，避免把旧连接中断的恢复时间算进稳定速率。
结论：跨网络对照优先于反复重装
同一设备、同一节点、同一目标在蜂窝网络正常而 Wi-Fi 持续异常时，优先检查 Wi-Fi 接入与其上游路径。先保留这组差异证据，再修改路由器或客户端设置。
七、常见疑问与反馈记录
延迟只有几十毫秒，为什么视频还是卡？
延迟测试不等于持续带宽测试。固定一个视频和清晰度，比较同节点下的持续播放，再换你已有的另一个节点。若短请求稳定、长时间传输反复停顿，重点记录吞吐量波动与发生时段。
换成 Hysteria2 就一定会更快吗？
不一定。先确认服务端提供 Hysteria2 参数、本地网络允许相应 UDP 通路，再在相同目标与时段对照。若只有 UDP 协议失败而已有 TCP 传输配置正常，应先调查 UDP 路径，不要持续增加带宽参数。
更新订阅以后仍然慢，要继续刷新吗？
订阅更新用于同步配置，不会直接增加服务端带宽。更新一次后核对节点地址、端口与协议是否变化，再做固定目标测试；若参数没变且连接可用，继续检查节点负载、线路与本地网络。
只有 Config 慢，Proxy 正常，该改哪里？
先在 Config 检查目标命中的规则及策略，特别是靠前的 DOMAIN-SUFFIX、GEOIP 和末尾 FINAL；再检查域名解析是否影响匹配。不要直接删除全部规则，先备份并只修正明确有误的一项。
向你的服务商反馈时，提供最小复现条件通常比描述“所有节点都慢”更有帮助。订阅链接、身份密钥和密码不应出现在公开记录中；截图或日志分享前，遮盖这些信息。
- 发生条件：日期、具体时间与时区，本地网络为 Wi-Fi 或蜂窝网络，以及是否只在某一时段出现。
- 配置范围：节点代称、协议、Global Routing 状态和所用配置，不提交完整订阅链接或密钥。
- 复现步骤：打开哪个类型的目标、等待多久、在哪一步停顿，附三次重复操作的记录。
- 对照结论：切节点是否改善、切本地网络是否改善、Direct 是否具备可比条件，以及准确错误原文。
完成排查后，恢复临时改动的 Global Routing 与 On Demand 设置，保留能够稳定复现问题的记录。如果仍无法定位，可继续按照排查手册检查连接与配置；本站不提供、不销售、不推荐节点或订阅，相关配置从你的服务商处获取。