适用于已经拥有自己的服务商与订阅、能够连接但访问缓慢的用户。先记录 Home 中的节点与 Global Routing，再固定测试目标，依次对照节点、线路、协议和本地网络。每次只改一个变量，用首屏等待、持续传输和失败日志区分问题，避免把延迟数字当成下载速度。
一、先确认连接路径与“慢”的具体表现
Shadowrocket（小火箭）是 Apple 平台上的付费客户端，主要用于 iPhone 与 iPad，唯一获取入口是 App Store；商店页可核对开发者 Shadow Launch Technology Limited 与应用 ID 932747118。应用采用一次性买断，系统要求和通用购买以 App Store 页面标注为准。客户端买断 ≠ 线路套餐，本文只说明如何排查用户已有连接，不提供、不销售、不推荐节点或订阅。
“连接成功”只说明隧道已建立，并不表示目标请求一定使用当前选中的节点。Home → Global Routing 的 Proxy、Direct、Config 与 Scene 会影响实际路径：Proxy 用于代理路由，Direct 用于直接连接，Config 按当前配置处理，Scene 按已设定场景处理。排查前先记录当前选项；使用 Config 时，还要记录 Config 中启用的配置文件和相关策略选择。
将现象拆开记录，比直接切换协议更有效。首次打开等待很久但随后传输稳定，可能涉及 DNS、连接建立或目标首字节响应；持续下载越来越慢，应检查线路拥塞、服务端负载与本地无线质量；只有一个站点慢，则需要先确认该请求命中的规则与目标服务状态。
- 首屏等待：用同一个页面，记录从发起访问到主要内容出现的时间；区分首次访问与重复访问，缓存会改变结果。
- 持续传输：用自己有权访问的同一文件，观察至少 30 秒，不用瞬时峰值代替稳定速率。
- 连接失败：记录发生时间、目标域名和日志原文；对外反馈前删除订阅凭据、密码及个人访问内容。
二、节点层：低延迟不等于高吞吐
Home 中的连通性或延迟测试适合筛查不可达项目，但不能单独证明带宽充足。短请求完成得快，不代表服务端出口、长连接传输和目标网站之间的路径都正常。一次超时也不足以断定节点失效，应在相同条件下复测。
- 在 Home 记录当前节点名称、类型及连接状态。若使用策略组，在可用的请求记录中确认实际选中的出站，不能只看 Home 的选中标记。
- 保持网络、目标文件与 Global Routing 不变，先测当前节点三次，再换用自己已有订阅中的另一个可用节点重复测试。
- 把延迟、首屏等待、稳定速率分别记录。速率单位要统一：
1 MB/s = 8 Mbps，界面单位不同不能直接比较数字大小。 - 若只有一个节点持续异常，先核对该节点的服务器地址、端口和认证信息；订阅管理的记录应先确认订阅是否已更新，避免长期保留临时手工修改。
结论：延迟接近时，用同一目标的持续传输作对照
如果两个已有节点的延迟相近，但只有其中一个在三轮传输中持续卡顿，优先整理该节点的测试记录，而不是同时修改 DNS、规则和协议。
三、线路层：用时间与目标对照识别路径差异
同一个节点在不同时段表现不同，可能与接入网络到服务器之间的链路拥塞、服务器出口负载或目标侧限速有关。仅凭节点名称中的地区无法确定实际路由，也不能把一个网站的速度推广成整条线路的能力。客户端能够记录现象，但无法直接修复远端带宽或运营网络路径。
| 对照方式 | 需要记录的现象 | 下一步 |
|---|---|---|
| 同节点、同目标、不同时段 | 是否仅在固定时段持续降速 | 在另一个时段复测，并向自己的服务商提交时间与结果 |
| 同节点、同网络、不同目标 | 是否只有单个站点或文件源缓慢 | 先核对规则命中，再检查目标服务是否正常 |
| 同目标、同网络、不同已有节点 | 是否只有一个出口出现长时间停顿 | 保留正常与异常两组对照，核对节点状态 |
| 同节点、同目标、不同接入网络 | Wi-Fi 与蜂窝网络是否表现明显不同 | 转入本地网络与接入路径排查 |
例如，记录中若出现“同一目标在 Wi-Fi 下连续三轮停顿，切到蜂窝网络后能持续传输”，这只是一个定位线索，并非对远端服务质量的结论。Wi-Fi、路由器、宽带出口与到服务器的路径都发生了变化，仍需进一步缩小范围。上述现象是记录方法示例，不是本站实测数据。
四、协议层：核对传输条件，不盲改参数
协议不是独立的加速开关。Shadowsocks、VMess、VLESS、Trojan、Hysteria2 与 WireGuard 的连接条件不同，实际速度还受服务端实现、加密处理、底层传输、拥塞控制和网络限制影响。即使服务商提供多种协议，若出口和线路同时变化，也不能把速度差异全部归因于协议。
| 协议或传输 | 应核对的条件 | 排查边界 |
|---|---|---|
| Shadowsocks | 服务器、端口、密码与加密方法保持一致；UDP 能力取决于服务端与配置 | 认证或方法错误先修正连接，不以反复测速替代核对 |
| VMess / VLESS | 用户标识、传输类型、TLS 与相关传输参数对应服务端 | 不能只改协议名称而沿用不匹配的字段 |
| Trojan | 密码、端口、TLS 服务名及证书验证条件 | TLS 失败属于握手问题，不应通过关闭验证掩盖 |
| Hysteria2 | 基于 QUIC，依赖 UDP 路径可用；核对认证与服务端要求 | 网络限制 UDP 时，可能无法连接，不能保证比其他协议更快 |
| WireGuard | UDP 端点、密钥、地址与路由范围 | 握手正常仍需检查目标路由，不随意套用其他配置的 MTU |
如果使用 TLS，443 是常见端口，但不是所有节点的固定值；必须使用用户已有服务商提供的端口。Hysteria2 的带宽参数也不是设备网速的承诺值，随意填大可能使拥塞更明显。除非服务端说明或测试证据要求调整，否则保留订阅给出的参数。
日志片段：connection refused
原因与解法：连接被目标端点或中间设备主动拒绝；先核对服务器地址、端口和服务状态，再复测，不把它当成普通带宽不足。
日志片段：i/o timeout
原因与解法：对应操作在限定时间内未完成；结合日志上下文区分 DNS、拨号或读取阶段，再用同节点切换接入网络作对照。
以上是网络错误中可能出现的原文片段，不代表每次失败都会显示完全相同的文字。应保留实际日志的完整上下文，尤其是失败阶段；仅凭“超时”二字，无法判断是否必须更换协议。
五、本地网络层：分开检查 Wi-Fi、蜂窝网络与 DNS
本地链路问题会同时影响订阅更新、节点测试与网页访问。在设备仍连接 Wi-Fi 时关闭蜂窝数据，并不等于切换到蜂窝网络测试；对照时应在系统 Settings → Wi-Fi 断开当前 Wi-Fi，确认实际使用蜂窝网络，同时留意测试文件带来的流量消耗。
- 建立本地基线：保持设备位置不变，暂停其他大流量任务。用可直接访问的同一目标检查普通访问是否也慢；若同样缓慢，先检查路由器与宽带状态。
- 排除无线干扰：靠近路由器复测，并在条件允许时对比 2.4 GHz 与 5 GHz。频段不是速度保证，距离、遮挡和信道拥挤都会影响结果。
- 切换接入网络：保留同节点、同模式、同目标，改用蜂窝网络重复三次。若差异稳定存在，继续检查接入网络到服务器的路径，而不是立即重建配置。
- 区分 DNS 与传输：若只在首次打开域名时等待很久，检查 Config 中当前配置的
[dns]设置及解析日志；若连接建立后仍持续低速，仅更换 DNS 通常不能解决吞吐问题。 - 检查自动连接：在 Settings → On Demand 记录已启用的条件。测试中若连接被自动重新触发，确认是否由这些条件造成；需要临时关闭时记下原值，测试后恢复。
结论：先固定实际接入网络，再比较配置
当设备在 Wi-Fi 与蜂窝网络之间自动切换时，两轮测试并不具有可比性。先确认系统当前使用的网络，再决定是否调整 Shadowrocket 设置。
六、规则与复核：确认请求确实走了预期出口
Config 模式下，规则通常按顺序匹配。DOMAIN-SUFFIX 匹配域名后缀，IP-CIDR 匹配地址段，GEOIP 按 IP 地理数据库匹配，FINAL 处理此前未命中的请求。域名解析、规则顺序与策略组选择都可能改变最终路径。更改 Home 中选中的节点，不一定改变一个固定指向其他策略的请求。
[Rule]
DOMAIN-SUFFIX,example.com,PROXY
IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
GEOIP,CN,DIRECT
FINAL,PROXY这段代码只展示规则语法，example.com 是示例域名，不应直接覆盖现有配置。no-resolve 用于避免仅为该 IP 规则触发域名解析；它不是通用提速选项。保留当前配置副本后，再针对异常目标检查规则命中与实际出站。若短暂切到 Proxy 后现象改变，说明应进一步检查原配置路径，但仍不能直接证明规则本身错误。
为什么延迟很低，视频还是一直缓冲？
短请求延迟与持续吞吐不是同一指标。保持同一视频或文件源，在同一接入网络下测试三轮，再用已有的另一节点对照；同时确认目标请求的实际出站没有被规则固定到其他策略。
改成 Proxy 就快了，要一直保持吗？
先记录差异，再回到 Config 检查目标命中的规则和策略组。Proxy 可用于受控对照，但会改变其他请求的路由方式；完成测试后恢复原模式，再按目标修正配置。
更新订阅能解决速度慢吗？
只有服务端地址、端口或配置已经变化时，更新才可能修正旧记录。回到 Home 更新自己已有的订阅，并核对目标记录是否改变；更新成功不等于线路拥塞已经消除。
所有协议都慢，是否需要重置应用？
先用同节点对比 Wi-Fi 与蜂窝网络，并检查可直接访问的目标。只有明确发现本地配置异常时才考虑恢复配置；重置前保留配置与必要记录，避免丢失定位依据。
提交问题前保留最小复现记录
- 写明设备、接入网络、测试时间，以及 Home → Global Routing 的选项。
- 写明节点类型、目标访问类型、三轮结果和速率单位；不发送密码、密钥或完整订阅链接。
- 附上异常前后的单项变更，例如“同节点由 Wi-Fi 改为蜂窝网络”，避免只写“已经全部试过”。
- 恢复临时调整的模式、On Demand 条件与测试配置，随后重新验证日常目标。
分层排查的终点不是找到一个通用参数，而是确定问题发生在本地接入、到服务器的路径、服务端传输条件，还是规则与目标响应。证据明确后，再对对应层做最小修改；涉及远端服务状态时，将脱敏记录交给自己的服务商核对。