先固定测试目标、Global Routing 和本地网络，再依次替换服务器、接入网络及协议。本文适合已经拥有自己的服务商与订阅、能够连接但访问缓慢的用户；通过逐项对照，区分服务器负载、线路拥塞、协议连接问题与 Wi-Fi 故障，并整理可复核的排查记录。
一、先确认“慢”发生在哪个阶段
Shadowrocket（小火箭）显示连接已开启，只能说明连接状态，不能证明目标网站的整条访问路径畅通。打开网页通常涉及 DNS 解析、建立连接、TLS 握手和内容传输；其中任何一个环节变慢，都可能表现为页面迟迟不出现。先记录现象，再改设置，避免把解析等待误判成带宽不足。
| 可观察现象 | 优先检查 | 对照方式 |
|---|---|---|
| 首次打开等待很久，随后传输正常 | DNS、连接建立、TLS | 同一页面连续打开，再与另一个目标比较；注意缓存影响 |
| 页面能开，大文件持续传输缓慢 | 服务器负载、链路带宽、目标限速 | 固定服务器，换一个允许测试的目标资源 |
| 只有一个网站缓慢 | 目标服务、规则命中、特定出口路径 | 检查该请求的策略，并访问其他目标 |
| Wi-Fi 缓慢，蜂窝网络正常 | 无线信号、路由器、接入线路 | 保持服务器不变，只切换接入网络 |
延迟数字不是下载速度。一次延迟测试反映的是特定探测过程的耗时，不等于实际业务的持续吞吐量；单次测试失败也不能直接推出服务器不可用。视频起播、网页首屏和文件传输应分别观察，不要用一个读数替代全部体验。
二、建立固定基线：先检查 Global Routing
在 Home 检查当前服务器与 Global Routing。Proxy、Direct、Config、Scene 是不同的路由姿态，不是速度档位。排查规则影响时，可临时用 Proxy 与 Config 对照：Proxy 下目标恢复，而 Config 下仍慢，应优先核对规则与策略去向；这并不意味着需要长期保持 Proxy。
-
记录原设置
在 Home 记下所选服务器和 Global Routing；到 Config 确认所选配置。保留原值，测试结束后恢复。
-
固定测试目标
在 Safari 选择一个可重复访问的网页，以及一个允许测试的文件资源。每轮保持目标一致，暂停其他大流量任务。
-
对照路由
在 Home → Global Routing 临时选择 Proxy，保持服务器不变；再切回 Config 重测。记录目标是否走到了预期策略。
-
检查按需连接
到 Settings → On Demand 核对按需连接条件。需要做断开连接的基线测试时，先临时停用相关条件，避免测试中自动重连。
-
恢复并复核
完成对照后恢复原 Global Routing 与 On Demand。再次访问同一目标，确认复现的是相同问题，而不是另一种连接状态。
Direct 适合用来检查当前网络可直接访问的目标，但不能拿一个本来就无法直连的目标作为本地网络故障的证据。Scene 的结果还取决于对应场景配置，不能只看姿态名称判断实际去向。涉及规则时，查看 Config 中的顺序以及实际请求命中结果；DOMAIN-SUFFIX、IP-CIDR、GEOIP 与 FINAL 各有用途，改 DNS 不会自动修正错误的策略选择。
三、节点层：同一网络只替换服务器
这里的节点指服务商提供的具体服务器条目。先保持 Wi-Fi、测试目标与路由模式不变，只在自己的已有服务器中切换两个条目。尽量选择协议及相关参数一致的条目，否则结果同时包含协议差异，不能单独归因于服务器负载。
- 仅一个条目持续缓慢：记录该条目的地址、端口与发生时段，再向自己的服务商核实负载、维护或限速情况。
- 全部条目同时缓慢：继续检查共用线路、本地网络和目标服务；不要立刻批量修改全部参数。
- 同一条目时快时慢：在相近条件下分时段复测。晚间缓慢只是拥塞线索，不足以确定拥塞发生在哪一段。
- 更换条目后恢复：还需要切回原条目复测一次，排除目标缓存、临时恢复或后台任务结束造成的误判。
订阅条目可能被服务商调整。若怀疑地址或端口已变，在 Home 对自己的订阅执行更新，再检查服务器字段是否同步；订阅链接从你的服务商处获取。更新订阅解决的是配置同步问题，不会直接增加服务器带宽，也不能把“更新成功”当成线路正常的证明。
结论：先保留可用对照组
找到能够稳定完成同一任务的服务器后，暂时保留其设置；用它逐项对照其他条目，不要同时更新配置、改协议和换 DNS。
四、线路层：用 Wi-Fi 与蜂窝网络交叉验证
线路包括设备到服务器、服务器到目标服务之间的传输路径。切换本地接入网络只能改变其中一部分，因此“蜂窝网络恢复”说明问题与接入网络或其路径有关，却不能单凭这一项就认定路由器损坏。没有蜂窝网络能力的 iPad，可以使用自己可控的另一处 Wi-Fi 或个人热点进行对照。
| 测试组合 | 保持不变 | 记录内容 |
|---|---|---|
| 原 Wi-Fi + 原服务器 | 目标资源、路由模式 | 首屏等待、能否传输、是否中途停顿 |
| 蜂窝网络 + 原服务器 | 服务器参数、目标资源 | 切换接入网络后现象是否消失 |
| 原 Wi-Fi + 对照服务器 | 原 Wi-Fi、目标资源 | 更换服务器后是否恢复 |
| 蜂窝网络 + 对照服务器 | 对照服务器、目标资源 | 两种接入网络下是否都稳定 |
以上是测试设计，不是实测结果。每个组合建议重复三轮，记录时间与失败次数；大文件测试会消耗流量，蜂窝网络下先确认自己的套餐。若两个服务器只在原 Wi-Fi 下缓慢，检查重点应转向无线环境、路由器与该接入线路；若一个服务器在两种网络下都慢，则继续核对该服务器及其到目标的路径。
如果只有某个网站慢，而其他目标正常，还需考虑目标的 CDN 分配、出口地址限制或应用自身限速。不要用“地理位置更近”替代测试：实际路由、互联质量与负载都会影响结果。
五、协议层：核对参数，再检查传输条件
协议名称不是速度保证。Shadowsocks、VMess、VLESS、Trojan、Hysteria2、WireGuard 使用不同的连接机制；实际效果仍取决于服务器部署与网络条件。只比较服务商已经提供且参数完整的配置，不要把条目的 Type 改成另一种协议来测试，服务器端不会因此自动支持它。
- 地址与端口：以服务商提供的值为准。HTTPS 常见的
443端口不是所有代理服务的通用端口，不能因连接慢就统一改为443。 - TLS 与 SNI：Trojan 等配置应核对证书对应的名称及 SNI。证书验证失败属于连接问题，不应通过开启 Allow Insecure 来作为提速方案。
- 传输参数：服务商使用 WebSocket 等传输时，路径、Host 等参数必须与服务端匹配；能解析服务器地址不代表这些参数正确。
- UDP 条件：Hysteria2 基于 QUIC，WireGuard 使用 UDP。某个接入网络对 UDP 的限制可能造成失败或不稳定，需要与服务商提供的其他可用配置对照。
如果出现日志错误，先处理错误，再做吞吐测试。下面列出的是网络诊断中常见的错误片段；具体前缀与完整文本以实际日志为准，它们不是每个慢速场景都会出现的固定提示。
报错：connection refused
原因：连接被主动拒绝，常见于目标端口未监听或中间设备拒绝。解法：核对服务器地址与端口，并请自己的服务商确认服务状态，不要随意轮换端口。
报错：no such host
原因：域名解析未得到可用结果，需先区分是服务器域名还是目标域名。解法：核对域名拼写与订阅更新结果，再检查当前网络的 DNS 可达性。
报错：context deadline exceeded
原因：某项操作超过等待期限，单凭此文本不能确定丢包位置。解法：结合相邻日志确认失败阶段，再固定服务器切换接入网络复测。
结论：参数正确后才比较协议
只有两种配置都能稳定建立连接、访问同一目标时，速度对照才有意义；握手失败和持续传输缓慢应分开记录、分别处理。
六、本地网络层：检查 Wi-Fi、DNS 与后台流量
如果交叉测试把问题指向本地，先做可逆操作。靠近路由器复测、暂停其他设备的大流量传输，比直接重置全部网络设置更容易保留证据。无线信号强不代表干扰少，也不代表宽带出口没有排队；同一 Wi-Fi 下其他设备的大量上传同样可能增加网页等待。
- 检查接入质量：保持服务器不变，靠近路由器重测；如果路由器提供不同频段，在可控条件下分别测试，并记录所连网络。
- 暂停竞争流量：临时暂停照片同步、系统更新及其他设备的大文件传输，再访问同一目标，完成后恢复原任务。
- 验证直连基线：在确认 On Demand 不会自动重连后，断开连接，访问当前网络正常可达的网页；如果仍慢，先处理本地接入问题。
- 区分 DNS 与吞吐：只有首次连接等待明显时才重点检查解析设置。不要直接用网站 IP 替代域名测试 HTTPS，因为证书、SNI 与虚拟主机都可能依赖域名。
- 观察重新连接：切换 Wi-Fi 与蜂窝网络后，等待当前连接稳定，再重新发起测试。旧连接中断不等于新网络上的服务器不可用。
MTU 不宜作为第一项调整。若小请求正常、较大传输反复停顿，可以把它列为后续排查方向，但同类现象也可能来自丢包或目标限速。只有在配置确实提供相关选项、且有服务商明确参数依据时才调整；每次保留原值，不批量套用网络上的所谓通用数值。
七、怎样整理结果并确认恢复
排查的终点不是某一次测速变快，而是同一任务可以在原使用环境中稳定完成。恢复原来的 Config 与 On Demand 后，再检查常用网页及实际使用的应用；如果恢复 Config 就再次变慢，应回到规则命中与策略选择，而不是继续切换服务器。
- 环境：记录 iPhone 或 iPad、接入网络类型、发生时段，以及是否只有单个目标异常。
- 配置：记录 Global Routing、所用协议、服务器端口及所选配置；密码、密钥、订阅认证信息不应公开。
- 对照：说明“原服务器在两种网络均慢”或“同一服务器仅在原 Wi-Fi 慢”，比只写“速度不行”更便于定位。
- 证据：保留实际错误片段与测试次数。分享日志前检查并遮去认证参数、完整订阅链接及个人访问记录。
- 恢复：撤销临时改动，复测原目标；向自己的服务商反馈仍可重复出现的问题，而不是继续叠加未经验证的设置。
需要进一步核对规则与 DNS 时，可查看Global Routing 与规则分流教程及DNS 排查说明。这些检查针对不同环节，应该按证据逐项使用，不必在一次测试中全部改动。