Shadowrocket 速度慢怎么排查:从节点、线路、协议到本地网络逐层定位

一、先建立基线：延迟不等于下载速度

先在 Home 点选要使用的服务器，确认选中标记，再打开连接开关并运行 Connectivity Test。测试成功表示相应测试请求能够完成，不表示所有网站、所有协议或大文件传输都正常。一次较低的延迟也不能说明线路带宽充足；连接建立之后，仍可能受到服务器负载、出口拥塞和目标站限制。

把“慢”描述成可以重复的现象：是点击网页后长时间空白，还是页面文字很快出现但图片持续加载，或是下载开始后速率不断下降。下面的数字是单位换算与记录方法，不是对任何线路的实测承诺。

1. 暂停云盘同步、系统更新和其他设备的大流量任务，记录测试时间与接入方式。
2. 固定同一个目标页面或你有权访问的测试文件，每组连续测试三次；首开与再次打开分别记录，避免缓存混入结果。
3. 分别记录 Connectivity Test 结果、网页首开等待、持续传输速率和是否中断，不把这些指标合并成一个“快慢”判断。
4. 每次只改变一个条件。换服务器时不要同时换 Wi-Fi，换协议时不要同时改 DNS。

例如界面显示 5 MB/s，换算约为 40 Mbps，而不是 5 Mbps。应用展示的瞬时流量也不一定是当前文件的平均速度，应与下载工具的平均值、测试持续时间一起看。

二、节点层：确认选中项、有效配置与服务状态

这里的节点指已有服务配置中的服务器条目，不是配置文件本身。在 Home 中看到多个条目，只能说明配置已经列出；实际连接仍取决于当前选中项，以及所用配置是否通过策略选择了其他出站。切换条目后重新建立连接，并尽量新建测试请求，避免原来的长连接继续使用旧路径。

• 先核对条目：检查服务器地址、端口、协议与认证信息是否与自己的服务商提供的内容一致。端口必须使用服务配置给出的值，不能因为常见 HTTPS 使用 443 就统一改为 443。
• 再检查更新：使用已有订阅的更新操作后，重新确认当前选中项。条目名称相同不保证服务器地址和参数没有变化；订阅更新也不等于当前 Config 中的规则同时更新。
• 最后做对照：如果已有另一条有效服务器，在同一网络、同一时间段、同一目标下切换比较。仅一条持续异常，优先核对该条目的状态与服务限制。

上述是网络日志中可能出现的错误片段，具体界面展示可能不同。分享记录时隐藏服务器地址、认证信息和订阅凭据；本文只讨论用户已有配置的排查，本站不提供、不销售、不推荐节点或订阅。

三、线路层：用路由姿态与时间对照缩小范围

一次访问可能依次经历本地接入、代理服务器入口、服务器出口与目标服务。连接到服务器很快，不代表服务器到目标站也很快。若只有某个网站慢，应先排除目标站负载、内容分发位置和目标对出口地址的限制，而不是直接修改所有服务器。

在 Home → Global Routing 检查当前姿态。用于速度对照时，先明确流量走哪条路径；临时切换只用于验证，完成后恢复原来的工作配置。

保持本地网络不变，在不同时间段重复同一测试。如果多条已有服务器都只在相似时段变慢，可能涉及共享链路拥塞；如果只有一个目标持续慢，更应检查目标路径。它们是定位线索，不是仅凭一轮测试就能确认的结论。

四、协议层：核对传输条件，不按协议名称判断快慢

Shadowsocks、VMess、VLESS、Trojan、Hysteria2、WireGuard 都需要与服务器端相匹配的参数。协议名称不是速度等级；不同入口、不同服务器和不同出口的对照，不能直接用来证明某种协议更快。只有服务商已经提供相应配置时，才有可用的切换条件。

• Shadowsocks：核对加密方法、密码以及服务要求的其他参数；认证不匹配应先解决连接问题，不属于速度调优。
• VMess / VLESS：核对认证标识、传输类型，以及服务要求的 Host、path、TLS 等参数。不要把某个条目的路径复制给另一个入口。
• Trojan：核对密码和 TLS 相关配置，服务器要求的名称必须与服务配置一致。不要通过关闭证书验证来处理“慢”。
• Hysteria2：依赖 QUIC 与 UDP 传输条件。本地网络限制 UDP 时，可能出现连接失败或明显波动，应换网络交叉验证。
• WireGuard：检查服务给出的密钥、端点和路由范围；底层通常使用 UDP，不能仅凭其他 TCP 请求正常就认定它的链路也正常。

如果小请求成功、大文件却反复停顿，可能涉及丢包、重传、服务器限速或路径 MTU。先通过相同目标与另一网络复现，再依据服务器说明调整相关参数。没有依据时反复降低 MTU、拉高并发或填写夸大的带宽值，会使问题更难定位。

五、本地网络层：检查 Wi-Fi、蜂窝网络与自动连接

若多个有效服务器、多个目标都在同一 Wi-Fi 下变慢，而蜂窝网络下恢复，应优先检查接入环境。无线干扰、路由器负载和家庭上行被占满，都可能造成延迟上升。蜂窝网络也会随信号和基站负载波动，切换后最好在同一位置连续测量，而不是只取一次最高值。

1. 靠近接入点复测：在条件允许时比较 5 GHz 与 2.4 GHz Wi-Fi，保持服务器和目标不变。信号强度改善后若波动下降，先处理无线覆盖。
2. 暂停后台上传：暂停照片备份、文件同步或其他设备的上传任务，再比较网页首开和下载表现。上行拥塞也会拖累下载确认与交互请求。
3. 完成网络认证：公共 Wi-Fi 若要求网页登录，先完成认证。网络尚未放通时，连接超时不能作为服务器性能依据。
4. 排除配置冲突：检查系统是否同时启用了其他 VPN 配置或网络过滤功能，一次只保留当前测试所需的连接条件。
5. 检查自动重连：在 Settings → On Demand 查看触发条件。若正在验证关闭连接后的直连基线，可临时停用相关自动连接条件，测试结束后恢复原设置。

设备持续发热、低电量运行或后台任务繁忙也可能影响测量。保持相近的设备状态，并分别记录“Wi-Fi 慢、蜂窝正常”与“所有接入都慢”；这比单独提交一张瞬时流量截图更有排查价值。

六、首开慢与部分网站慢：检查 DNS 和规则

网页第一次打开等待很久、随后访问明显改善，可能与 DNS 查询或连接建立有关，也可能只是缓存生效。DNS 影响的是解析和地址选择，并不会直接提高已经建立连接的大文件传输带宽。先在 Config 确认当前使用的配置，再检查其中的 DNS 与规则内容，避免修改了没有生效的文件。

规则通常按顺序匹配，具体规则应放在兜底规则之前。下面只是语法说明，不是要求整段替换现有配置；PROXY 必须对应实际可用的代理策略，保留原配置后再做局部测试。

[Rule]
DOMAIN-SUFFIX,example.com,PROXY
IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
GEOIP,CN,DIRECT
FINAL,PROXY

• DOMAIN-SUFFIX 匹配域名后缀。示例中的 example.com 仅用于说明语法，不表示服务推荐。
• IP-CIDR 匹配 IP 网段；no-resolve 表示这条规则不主动触发域名解析，并不是全局关闭 DNS。
• GEOIP 按目标 IP 在地理数据库中的归属匹配；排查时应核对实际解析地址与数据库结果，而非只看域名后缀。
• FINAL 处理前面未命中的请求，不能用它掩盖前面规则指向错误的问题。

系统 DNS、自定义 DNS 与 DNS over HTTPS 应分别测试，不要同时更换解析器和服务器。DNS over HTTPS 还依赖解析服务自身可达，增加加密并不必然缩短首开时间。若更改后只是首开改善、持续下载仍慢，应继续回到线路与服务器层，而不是反复清理 DNS 设置。

七、常见问题与排查记录

完成排查后，恢复临时改动的 Global Routing 与 On Demand 设置。提交给自己的服务商或支持人员的记录，应足以复现问题，但不应包含认证密码、完整订阅链接或密钥。