适用于用户已有自己的服务商与订阅、Shadowrocket 已能连接但打开网页或传输文件缓慢的情况。先区分延迟、吞吐和解析等待，再固定测试条件，依次检查本地网络、节点、线路与协议。每轮只改变一项，最终得到能复现的故障记录，而不是反复更换所有设置。
一、先定义“慢”：延迟、吞吐与首屏等待
Shadowrocket（小火箭）的连接开关处于开启状态，只说明系统隧道已经启动，并不证明每个目标都能正常访问。Home 中的延迟测试也不是持续带宽测试：一次探测成功，不能排除稍后发生的丢包、拥塞、远端限速或目标站点响应缓慢。
先确定问题发生在哪个阶段。点击链接后长时间没有内容，可能是 DNS 解析、连接建立或 TLS 握手等待；页面很快显示文字，但图片一直加载，可能是资源请求或持续传输受限；视频开始正常、随后反复缓冲，则需要观察连续数分钟的吞吐变化。不要仅凭一个毫秒数判断线路质量。
| 可观察现象 | 优先检查 | 对照方法 |
|---|---|---|
| 只有首次打开慢 | DNS、连接建立、TLS | 同一页面连续打开三次，分开记录首次与后续表现 |
| 开始快，随后持续变慢 | 吞吐、拥塞、服务端限速 | 用同一文件连续传输 60 秒，记录中段速率 |
| 只有一个网站慢 | 目标服务、分流结果、节点出口 | 保持节点不变，换两个用户日常使用的目标验证 |
| 所有应用同时变慢 | 本地接入、当前节点、共同链路 | 先比较 Wi-Fi 与 Cellular，再比较已有节点 |
注意单位：Mbps 是每秒兆比特，MB/s 是每秒兆字节。理想换算中，80 Mbps 约等于 10 MB/s；实际应用还存在协议开销。不要把应用显示的 8 MB/s 与套餐描述的 80 Mbps 直接当成十倍差距。
二、建立可重复的测试基线
开始前保存当前使用的配置，并记下 Home 中选中的节点、Global Routing 姿态以及测试时的网络。以下步骤使用你已有的参数，不涉及获取新的连接服务。测试尽量在短时间内完成，避免把不同时段的网络负载误认为设置差异。
-
记录现场
在 Home 记下当前节点与 Global Routing；到 Config 确认当前配置。检查 Settings → On Demand 是否设置了自动连接条件，只记录原状态，不必为了测速先修改它。
-
固定目标
选择一个平时可访问的网页和一个允许测试的固定文件。每轮使用相同目标，暂停云同步、照片上传和其他大流量任务，避免它们抢占带宽。
-
检查分流
在 Home → Global Routing 查看当前选择。Config 按配置规则处理请求，Proxy 用于代理姿态，Direct 用于直连姿态；使用 Scene 时还需确认场景实际采用的设置，不能只看场景名称。
-
重复测量
每种条件测三轮，每轮持续约 60 秒，记录中位表现。不要同时切换节点、协议与网络；测试前重新建立目标连接，避免浏览器复用旧连接或缓存掩盖变化。
-
恢复原配置
完成临时对照后恢复原来的 Global Routing 和配置。如果曾调整 On Demand，也恢复原条件，再用日常应用验证，避免诊断设置影响后续使用。
三、本地网络层：先比较 Wi-Fi 与 Cellular
同一节点在 Wi-Fi 下慢、切到 Cellular 后恢复，说明变化与接入网络有关，但还不能直接断定路由器损坏。两种接入使用不同的运营商路径，差异也可能出现在接入网络到节点之间。先把故障范围缩小，再决定检查路由器还是联系自己的服务商。
- 靠近接入点复测：使用同一台 iPhone 或 iPad，靠近路由器再测一次。Wi-Fi 信号格数不能完整反映干扰和重传；隔墙明显变慢时，优先排除无线覆盖。
- 确认实际网络：在系统 Settings → Wi-Fi 核对连接的网络，切换到 Cellular 时确认 Wi-Fi 已断开。没有蜂窝数据能力的 iPad，可使用另一个已知正常的 Wi-Fi 作对照，并记录接入方式。
- 减少共享占用：暂停其他设备的大文件上传。上行被占满时，网页请求和传输确认也可能排队，表现为下载与交互一起变慢。
- 排除接入限制：需要网页认证的 Wi-Fi 应先完成认证。若正常网页在 Direct 下也慢，先处理接入网络，再继续检查代理参数。
网络切换后应重新开始一次请求，不要仅观察原先仍在下载的任务。已有连接可能因地址变化而中断或等待重试。如果故障只在切换后出现，可手动断开再连接 Shadowrocket 验证；On Demand 主要决定何时自动建立连接，并不是提高带宽的开关。
四、节点与线路层：把服务端差异和时段差异分开
这里的“节点”指 Home 中的一组服务端连接参数；“线路”指设备到该服务端、再到目标服务的网络路径。换节点通常也会改变出口位置与网络路径，因此“换一个就快”只能证明差异与所换路径相关，不能仅凭这一结果认定旧服务器性能不足。
在用户已有的节点中选两个作对照，优先保持协议、目标和本地网络相同。如果只有一个节点持续缓慢，核对其服务状态、用量限制与参数是否变更。如果多个节点只在晚间缓慢，白天恢复，应记录时段，而不是立即重建全部配置。共享链路拥塞、入口负载与目标服务负载都可能产生这种现象。
| 固定条件 | 变更项 | 示例读数 | 可得结论 |
|---|---|---|---|
| 同一 Wi-Fi、同一文件 | 节点 A 换为节点 B | 0.8 MB/s 变为 5.2 MB/s | 继续比较两个节点及其路径，不先改本地 DNS |
| 节点 A、同一文件 | Wi-Fi 换为 Cellular | 0.8 MB/s 变为 4.6 MB/s | 优先查接入网络与到节点的路径 |
| 同一节点、同一 Wi-Fi | 14:00 与 21:00 | 5.0 MB/s 变为 0.7 MB/s | 存在时段相关性，需要多日复测支持判断 |
同时核对自己的服务商后台是否有流量耗尽、到期或速率限制。Shadowrocket 的 Data 读数与服务商计费口径可能不同，不能用本地某一个累计数字直接否定后台限制。若需要更新已有订阅，先保存配置，再按原订阅入口更新，并核对选中节点的参数是否确实发生变化。
五、协议层：先核对参数，再考虑传输差异
在 Home 打开当前服务器的编辑页面，按已有服务商参数核对 Type、地址与端口。端口号本身不代表协议或速度：服务端指定 443 时就填 443，不能因为另一个端口看起来常见便自行更换。修改本地端口不会让服务端自动提供相应服务。
- Shadowsocks：核对加密方法、密码以及服务端要求的附加设置。错误参数更常表现为连接或数据传输失败，而不是一种正常的低速模式。
- VMess / VLESS：核对 UUID、传输方式与 TLS 设置。使用 WebSocket 时，还要逐项对应 Host 与 Path；UUID 相同不意味着其他参数可以省略。
- Trojan：核对密码、TLS 与 Server Name。证书域名、服务端地址和传输入口可能不是同一个值，应按已有参数填写。
- Hysteria2：使用基于 QUIC 的传输，需要网络路径允许相应 UDP 通信。若服务商提供了带宽参数，按说明填写，不把估计值任意放大。
- WireGuard：核对密钥、Endpoint 与服务端提供的其他参数。MTU 不应作为第一步优化项；只有出现特定大小数据停滞等线索时，再依服务商说明逐项验证。
协议对照需要服务端本来就支持对应入口，不能只在 Type 中把 VLESS 改成 Trojan 来测试。即使两个入口都可用，也可能位于不同服务器，测到的差距不一定来自协议。先比较完整参数与网络条件，再讨论协议开销。
报错：i/o timeout
原因与解法：某个网络读写阶段超过等待时间，单靠这行不能确定故障位置。查看同条记录的目标与上下文，核对地址、端口，并用另一种本地网络复测同一节点。
报错：connection refused
原因与解法：目标端口拒绝了连接，可能是服务未监听或中间设备主动拒绝。按已有参数检查端口，并向自己的服务商确认入口状态，不要通过反复测速处理。
报错：certificate verify failed
原因与解法：TLS 证书验证未通过，需结合完整错误确认原因。检查系统日期时间、Server Name 与服务端证书状态，不以关闭证书验证作为提速步骤。
错误文字可能来自不同连接组件，具体呈现以实际记录为准。持续报错应先按连接失败处理；不要把不断重试造成的长时间等待误判为可用带宽偏低。
六、规则与 DNS：确认请求实际走了哪里
如果同一节点在 Proxy 下正常、回到 Config 后变慢，优先检查当前 Config 的规则与 DNS 行为。规则决定请求如何处理，DNS 决定域名如何解析，两者不是同一个开关。不要一次同时替换配置、解析服务器和节点，否则无法判断是哪项改变起了作用。
- 检查命中顺序：
DOMAIN-SUFFIX按域名后缀匹配，IP-CIDR按地址范围匹配，GEOIP按 IP 地理数据库匹配，FINAL处理未命中前序规则的请求。较早命中的规则可能使请求不经过你正在测试的节点。 - 核对实际请求：网页正文、图片与视频可能来自不同域名。一个主域名走代理，并不证明该页面的全部资源都采用相同出站策略。
- 区分解析与传输：首次请求等待很久、之后传输正常时，应检查解析和握手阶段；已经建立连接后持续低速，不能仅靠换 DNS 解释。
- 保留原配置：修改规则前保存原文，每次只调整与目标有关的一项。不要为了测试随意移动 FINAL 或删除整段规则。
不建议直接用 IP 地址替代 HTTPS 域名作通用测速。这样可能改变证书校验、TLS Server Name、虚拟主机与 CDN 路径，测试对象已经不再相同。应使用正常域名请求，结合连接记录判断解析是否完成、最终采用了哪条策略。
七、常见追问与排查收尾
延迟只有几十毫秒，为什么下载还是慢？
延迟反映短时响应，下载需要持续传输。固定节点与文件，连续测 60 秒并重复三轮；若吞吐低但延迟稳定，继续检查限速、负载与出口路径，不要仅按延迟排序下结论。
切到 Proxy 就快了，要一直这样用吗？
先把它视为规则排查线索。记录 Home → Global Routing 的对照结果，回到 Config 检查目标请求的匹配规则；诊断完成后恢复符合日常需求的姿态。
换了网络后卡住，重新连接就好了？
先用新建请求验证，排除旧连接等待重试。再到 Settings → On Demand 核对自动连接条件，记录手动连接与自动连接的差异；不要把重复重连当成固定提速方案。
所有已有节点都慢，下一步提交什么信息？
提供测试时间、接入类型、目标类型、三轮读数和已做过的单变量对照。附上脱敏错误记录，隐藏密码、UUID、密钥及订阅链接中的 token，向自己的服务商确认服务状态。
排查结束后，把结论写成可复现条件，例如“同一节点、同一目标，Wi-Fi 下三轮均低速，Cellular 下恢复”，而不是只写“Shadowrocket 很慢”。若只有单一目标异常，继续检查该目标与出口的关系；若所有目标都异常，再按共同的接入或节点路径检查。没有形成对照前，不急于归因。