Shadowrocket 故障排查大全

建立排查基线：开关打不开或立即回落

先区分“开关失败”与“服务器连接失败”

Shadowrocket 的 Home 开关负责请求系统建立 VPN 配置。开关无法保持打开，通常发生在流量尚未到达服务器之前；节点超时则表示系统通道已经建立，但后续连接服务器的过程没有完成。两者处理路径不同。观察时不要只看网页能否打开，应同时记录 Home 开关状态、系统状态栏中的 VPN 标记、当前所选服务器，以及 Global Routing 显示的姿态。若开关点击后立即复位，先检查系统授权与配置冲突；若开关保持打开但网页失败，再进入下一章检查服务器、DNS 和规则。

首次打开或系统重新确认权限时，设备可能显示添加 VPN 配置的授权窗口。完成设备身份验证后，Shadowrocket 才能让系统创建对应配置。若此前拒绝授权，可进入系统 Settings 查看 VPN 配置是否存在，再返回 Shadowrocket 重试。此处不需要反复删除应用；先确认权限链条，能够避免把系统授权问题误判成服务器问题。设备受到组织管理、内容限制或家长控制时，也可能限制 VPN 配置变更，此时应查看系统给出的明确提示，并由设备管理方确认策略。

清理同一时间的连接竞争

Apple 平台同一时刻只能让符合系统条件的网络扩展接管对应流量。若系统 Settings 中存在其他正在连接或反复自动唤起的 VPN 配置，Shadowrocket 的开关可能停留在“连接中”后回落。排查时先关闭其他 VPN 配置，再暂时关闭 Shadowrocket 的 On Demand，手动操作一次 Home 开关。On Demand 的触发条件若与当前 Wi-Fi、蜂窝网络或域名条件不一致，也会造成用户刚关闭连接、系统又重新发起，或者手动打开后被条件重新评估的现象。

关闭 On Demand 仅用于建立基线，并不表示该功能本身异常。手动连接恢复后，应逐条检查触发条件：当前网络名称是否被归入正确分支，蜂窝网络条件是否与预期一致，条件之间使用的是“同时满足”还是“任一满足”，以及规则是否引用已经删除的配置。每改一项后切换一次网络或等待系统重新评估，不要同时修改多条条件，否则无法知道是哪一项恢复了连接。

使用最小变量法恢复连接

基线测试应只保留一个已知信息完整的服务器，关闭 On Demand，暂时不改协议参数，并先在稳定的 Wi-Fi 下连接。若失败，再切换到蜂窝网络做一次对照。相同配置在两种本地网络上的结果不同，说明问题更可能位于路由器、网络接入或 DNS 环境；两种网络都失败，才继续检查服务器地址、端口、认证信息和协议参数。不要在一次测试里同时更换服务器、DNS、Global Routing 和规则文件，因为多变量变化会掩盖真正原因。

如果 App Store 中的购买记录、应用 ID 或开发者信息需要重新核对，可前往正版核验三要素。Shadowrocket 是一次性买断的客户端，但客户端一次性买断 ≠ 线路套餐；连接所需的订阅或服务器信息应由用户已有的服务来源提供，应用购买状态不会决定某一台服务器是否可用。

开关已打开，但网页与应用无法上网

先用三种 Global Routing 姿态划定范围

Global Routing 的 Config、Proxy、Direct 是定位“连接成功但没有网络”的主要分界。Config 按 Config 中的规则顺序决定每个请求走向；Proxy 让流量统一经过当前服务器；Direct 让流量直接访问。测试时先记住原姿态，再短时间切到 Direct。若 Direct 也无法访问，问题可能位于系统通道、本地网络或 DNS，而不是代理服务器。若 Direct 正常、Proxy 失败，应检查服务器可达性和参数。若 Proxy 正常、Config 失败，重点检查规则顺序、策略名称和 FINAL 结果。

姿态切换只用于诊断，不应把 Proxy 长期当作修复规则问题的方法。若 Config 异常，应回到规则本身处理。规则从上到下匹配，命中第一条后即停止继续判断，因此范围较窄的 DOMAIN、DOMAIN-SUFFIX、IP-CIDR 通常放在较宽泛规则之前，FINAL 放在末尾。一个过早出现的 REJECT、DIRECT 或宽范围 DOMAIN-SUFFIX，都可能让后续预期规则永远没有机会命中。

建立一份可读的最小规则集

以下片段演示规则顺序，不代表真实服务信息。策略名必须与 Config 中现有策略或应用支持的结果名称一致。测试时可使用自己已有配置中的正确策略名替换 PROXY，并确保 FINAL 位于最后。局域网地址使用 DIRECT，可避免访问路由器或本地设备时绕行；明确域名规则放在 GEOIP 和 FINAL 之前，便于从 Data 或请求记录中核对命中结果。

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

若 Config 文件导入后出现策略找不到、规则无效或整组流量失败，应核对逗号分隔字段是否完整、策略名大小写是否一致、是否混入不可见字符，以及引用的策略组是否确实存在。不要仅凭文件能够导入就判断配置有效；导入只说明文本被接受，不能证明其中每个服务器、策略组和规则都可执行。可先保留少量规则验证，再逐段恢复复杂规则。

检查系统时间、网络登录页与 IPv6 差异

设备日期与时间明显不准时，TLS 证书验证可能失败，表现为多数 HTTPS 页面打不开，而少量本地页面仍可访问。应在系统 Settings 中启用自动设置日期与时间，再重新连接。酒店、校园或公共 Wi-Fi 常要求先完成网络登录页验证；连接 Shadowrocket 前可暂时关闭开关，使用浏览器访问普通页面触发登录，完成后再打开。若 Wi-Fi 正常而蜂窝网络失败，或反之，应分别检查两种网络下的 DNS 与 IPv6 可达性，不要把单一接入网络的限制归结为所有服务器不可用。

某些应用会缓存旧连接。修改 Config、DNS 或服务器后，先在 Shadowrocket 中断开再重新连接，然后完全退出出现问题的应用并重新打开。仍失败时，可切换一次飞行模式让系统重建网络接口。重启设备应放在权限、姿态、规则、DNS 和网络对照之后；它能清理临时状态，但不能修复错误的服务器参数或规则顺序。

如果问题只发生在“开关已打开”的场景，可继续阅读服务器状态、Global Routing、DNS 与规则逐项排查，其中提供了更短的现场检查清单。

节点超时、握手失败与 Connectivity Test 异常

把“超时”拆成地址、端口与协议三个阶段

超时不是单一原因。首先需要把服务器地址解析成 IP，其次建立到端口的传输连接，最后按 Shadowsocks、VMess、VLESS、Trojan、HTTP、SOCKS5、WireGuard 或 Hysteria2 等协议完成认证和握手。前一阶段失败，后一阶段不会发生。Connectivity Test 的结果适合用来比较同一时刻、同一本地网络中的多个已有服务器，但一次失败并不能证明服务器永久不可用；本地网络波动、DNS 暂时失败、服务器维护或参数不一致都可能产生相似表现。

先核对 Add Server 或已有条目中的 SERVER、端口、密码或标识、协议类型及传输相关字段。复制信息时常见错误包括地址前后空格、端口遗漏、大小写改变、把备注当成服务器地址，以及二维码或剪贴板内容已经过期。参数应与用户已有服务来源给出的信息逐项一致，不应凭经验替换加密方式、传输类型或 TLS 相关值。协议名称相同也不表示参数能够互换。

用网络对照判断是本地阻断还是远端异常

在 Wi-Fi 下超时时，断开 Shadowrocket 后确认普通网页可访问，再切换蜂窝网络测试同一服务器；随后也可用另一个已确认可用的 Wi-Fi 复测。如果同一服务器只在某个接入网络失败，优先检查路由器 DNS、IPv6、访客网络隔离、单位网络策略或需要登录的网络门户。如果不同接入网络下都超时，而同一订阅中的其他服务器正常，更可能是该服务器地址、端口或远端状态异常。若所有服务器在所有网络中同时失败，则应回头检查订阅内容、系统时间、DNS 和配置是否被整体替换。

测试顺序应固定：先测试当前服务器，再测试同一配置中的另一个服务器，然后更换本地网络，最后才修改协议参数。这样形成两个维度的对照。只更换服务器后恢复，说明系统通道与应用权限基本正常；只更换本地网络后恢复，说明服务器本身至少在另一网络可达；所有组合均失败，则需要检查共同因素，例如错误 DNS、过期配置、系统 VPN 状态或服务来源的整体变更。

理解延迟测试与实际可用性的边界

延迟数值只是特定测试请求在当时网络条件下的往返表现，不等同于网页加载、视频传输或大文件吞吐。某个服务器能够返回测试结果，也不保证所有目标域名都能按当前规则访问；反过来，测试请求被远端限制时，实际业务连接仍可能有响应。因此应把 Connectivity Test 与真实请求记录结合：查看请求是否发出、命中了哪个策略、返回是超时、连接拒绝还是名称解析失败。不同错误提示对应不同层级，不能统一用“换节点”处理。

WireGuard 与 Hysteria2 等协议还可能依赖更具体的密钥、地址、MTU 或传输参数。出现能连接但部分页面卡住时，不要先随意提高或降低所有参数；应先确认服务来源给出的完整字段，再用默认或明确指定值测试。MTU 不合适可能表现为小请求正常、大响应停滞，但相同症状也可能来自 DNS、路径质量或服务端限制，因此需要通过切换本地网络和比较其他服务器来交叉验证。

若确认服务器信息已经由服务来源变更，应按其最新信息更新已有条目或订阅。本说明站只解释客户端中的导入、测试与排查方法，不提供服务器或订阅内容。

Subscribe 导入或更新失败

区分地址不可达、内容无效与更新未生效

订阅失败至少分为三类。第一类是 Subscribe 地址无法访问，常见表现为超时、DNS 失败或 HTTP 状态异常；第二类是地址能够返回内容，但格式不是 Shadowrocket 可识别的数据；第三类是界面提示更新完成，服务器列表却没有预期变化。排查时需要先确认失败发生在哪一步，而不是反复删除和重新添加。用户应使用自己已有服务来源提供的完整订阅地址，并注意链接中的查询参数通常属于地址的一部分，复制时不能截断。

可先在 Subscribe 条目中核对地址首尾是否多出空格、协议头是否完整、字符是否被聊天软件换行，以及链接是否已经由服务来源替换。示例地址只能用于理解结构，不能产生真实服务器：

https://example.com/sub?token=xxxx

若同一地址此前能更新、现在突然失败，应先更换本地网络测试，再确认系统日期与 DNS。公共 Wi-Fi 的登录页、路由器过滤或暂时解析异常都可能影响订阅请求。若地址在不同网络下都返回明确错误，应联系原服务来源确认地址状态；不要通过不明页面转换订阅内容，也不要把包含访问凭据的链接提交给陌生工具。

检查更新策略与本地条目关系

订阅更新可能新增、修改或移除由该订阅管理的服务器。用户手动建立的 Add Server 条目与 Subscribe 管理条目应在排查时分开观察，避免把本地手动条目当成订阅更新结果。更新前记下订阅分组中的服务器数量不是可靠的长期验证方式，因为服务来源可能调整内容；更有效的做法是记录一个明确的服务器名称或更新时间提示，更新后查看该订阅条目的状态，并确认当前选中的服务器是否仍然存在。

如果更新后 Home 仍选中已经被移除或参数变化的旧条目，应重新选择订阅中的有效服务器，再执行 Connectivity Test。若 Config 中的策略组按服务器名称引用条目，名称变化也可能让策略出现空缺。此时不仅要看服务器列表，还要检查 Config 的策略组成员与规则结果。订阅更新成功只证明数据已经写入，不证明原 Config 对新数据的引用仍然成立。

格式错误与局部数据问题的处理

当返回内容中只有个别条目字段异常时，应用可能跳过部分内容或使整个导入结果不符合预期。不要手工猜测缺失字段。先保留原 Subscribe 条目和当前可用配置，向原服务来源核对其提供的格式是否适用于 Shadowrocket。若服务来源同时给出二维码，可使用 Scan QR Code 导入，但二维码只是另一种传递方式，扫描结果仍应核对服务器地址、协议与备注，不能把“能够扫描”视为“参数一定正确”。

Import from Cloud JSON 适合导入用户自己保存的相应数据，但云端文件可能早于当前配置。导入前要区分恢复备份与更新订阅：备份会把某一时点的本地结构带回设备，订阅更新则从原地址取得当前内容。用旧备份覆盖现有数据后，应重新检查 Subscribe 地址、服务器选择、Config 与 On Demand 条件，不要只验证服务器列表是否出现。

订阅不是 Shadowrocket 的购买内容。客户端一次性买断 ≠ 线路套餐；App Store 购买用于取得客户端，Subscribe 中的数据由用户已有的服务来源负责。若要迁移到新设备，可配合阅读配置备份与换机恢复步骤，先恢复应用购买，再核对本地配置与订阅状态。

速度慢、加载停顿与不同应用表现不一致

按本地网络、服务器、线路与协议逐层测量

速度慢需要先定义具体现象：是首次打开页面时等待很久、持续传输速度低、只有图片或视频卡顿，还是仅某个应用异常。不同表现对应 DNS、连接建立、吞吐、丢包和规则命中等不同层级。排查前关闭正在进行的大量同步或下载，固定一个测试目标和时间段，先在 Shadowrocket 关闭状态下测量本地网络，再打开并测试当前服务器。只比较不同时间、不同网站的主观感受，无法得出可靠结论。

第一层是本地 Wi-Fi 或蜂窝网络。若关闭 Shadowrocket 后本地网络本身就有明显丢包、频繁切网或信号弱，后续连接会放大波动。靠近路由器、关闭低质量 Wi-Fi 后改用蜂窝网络、或在另一稳定网络下复测，可以判断基础接入是否为主要原因。第二层是当前服务器与路径。使用 Connectivity Test 比较用户已有配置中的多个服务器，并实际打开同一目标页面；不要只按一次延迟结果选择，因为低延迟不等于持续吞吐稳定。

第三层是协议与参数。不同协议在不同网络条件下的表现可能不同，但参数必须来自已有服务器信息，不能为了追求速度随意改变认证、传输或 TLS 设置。若服务来源给出了多个适用条目，可以在相同网络、相同时间、相同目标下对照。第四层是规则：同一应用的域名可能被分配到不同策略，页面主体走 PROXY，而图片域名走 DIRECT 或 REJECT，就会出现文字先显示、资源长时间空白的现象。

从请求记录识别规则分裂

在 Data 或相应请求记录中观察出现问题时的域名、命中规则和最终策略。重点查看主域名、静态资源域名、登录域名与内容分发域名是否走向一致。若某些域名被 DOMAIN-KEYWORD 过宽匹配，应改为更精确的 DOMAIN 或 DOMAIN-SUFFIX；若 GEOIP 提前命中导致结果与预期不同，可把明确域名规则放到它之前。规则修改后断开并重新连接，同时重新打开目标应用，避免旧连接继续复用先前路径。

速度问题不宜通过把所有流量长期切到 Proxy 来掩盖。Proxy 可用于确认“规则是否参与问题”，一旦确认 Proxy 正常、Config 缓慢，应回到 Config 修正规则。若两者都慢，而 Direct 正常，则检查服务器与路径；若三种姿态都慢，应先检查本地网络、DNS 与设备状态。这个三姿态对照与第二章相同，但本章关注的是可用连接中的性能差异，而不是完全无法访问。

处理大响应停顿与 MTU 线索

小网页正常、大图片或持续传输容易停顿时，可以把 MTU 或路径分片问题列为候选，但不能直接认定。先对比不同本地网络和不同服务器：只有某一网络组合出现，说明路径特征较明显；所有组合都出现，则还要检查协议参数、设备省电状态与目标服务。对于明确提供 MTU 设置的配置，应以用户已有服务信息或协议要求为基准，一次只调整一个值，并记录调整前后的同一测试结果。盲目反复更改会造成更多不稳定。

测试应至少覆盖两个时间点，避免把短暂拥塞当作稳定结论。记录本地网络类型、服务器名称、Global Routing、目标应用和现象发生阶段，再比较结果。若同一服务器在不同时间表现差异很大，可能与远端负载或路径变化有关；若所有服务器只在一个 Wi-Fi 下缓慢，优先处理路由器与接入网络。更完整的四层检查可参阅节点、线路、协议与本地网络逐级排查。

DNS 解析失败、结果异常与部分域名打不开

识别 DNS 故障而不是笼统归为断网

DNS 负责把域名转换为可连接的地址。典型 DNS 故障包括：输入域名无法打开，但直接访问已知 IP 有响应；部分域名持续提示找不到服务器；切换 Wi-Fi 后同一域名恢复；首次请求很慢，随后缓存期内正常。TLS、规则 REJECT、服务器超时也可能产生近似表现，因此需要结合请求记录中的错误类型判断。若记录显示域名解析失败，应先处理 DNS；若已经获得目标 IP 但连接超时，则应转到服务器或路径层排查。

Shadowrocket 中 DNS 的实际行为会受到 Config、系统网络、IPv4、IPv6 以及规则设置影响。排查时先记录当前 DNS 配置，不要直接清空所有字段。暂时使用已确认适合当前配置的 DNS 方案测试，并分别在 Wi-Fi 与蜂窝网络下观察。若只在特定 Wi-Fi 失败，路由器下发的 DNS、网络登录页或局域网劫持可能参与问题；若所有网络都失败，应核对 Config 是否引用了不可达地址、格式错误的配置或与当前规则不一致的解析路径。

理解 no-resolve 与 IP 规则的关系

IP-CIDR、IP-CIDR6 和 GEOIP 根据目标 IP 判断。某些规则带有 no-resolve 时，表示不要为了执行该规则额外触发域名解析；这可减少不必要的查询，但也意味着规则只能在已有 IP 信息时匹配。若误以为所有 IP 规则都会主动解析域名，就可能错误判断规则为何未命中。DOMAIN、DOMAIN-SUFFIX 与 DOMAIN-KEYWORD 直接基于域名匹配，通常应放在需要精确分流的 IP 类规则之前。

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

上述局域网规则用于说明匹配方式。若设备需要访问局域网中的路由器、存储设备或打印服务，DIRECT 通常能避免流量被送往远端，但实际访问仍受 Wi-Fi 隔离和局域网权限影响。局域网 IP 无法访问并不一定是 DNS 问题，因为直接使用 IP 时并未进行域名解析。应先区分访问目标是域名还是 IP，再看失败发生在哪一层。

处理缓存、IPv6 与加密 DNS 的交叉影响

修改 DNS 后，旧结果可能仍存在于应用、系统或连接缓存中。应断开 Shadowrocket，重新连接，再完全关闭目标应用并打开；必要时切换一次飞行模式。不要连续更换多个 DNS 后立即下结论，因为缓存会使前后结果混在一起。若某域名同时提供 IPv4 与 IPv6，而当前网络的 IPv6 路径不稳定，可能出现解析成功但连接缓慢或超时。此时应比较不同接入网络，并查看失败请求使用的地址类型，而不是简单认为 DNS 没有返回结果。

配置加密 DNS 时，还要考虑其服务器域名如何被首次解析，以及访问该 DNS 端点的路径是否受当前规则影响。如果 DNS 端点本身只能通过尚未建立的路径访问，就可能形成启动依赖。排查时可暂时恢复到配置明确支持的基础方案，确认普通解析正常，再逐步加回加密 DNS 设置。每次改变后测试一个此前稳定失败的域名和一个正常域名，才能判断是整体解析故障还是单个域名结果异常。

耗电异常、后台活动与更新后异常

判断耗电来自持续流量还是连接重试

Shadowrocket 处于连接状态时需要处理经过系统网络扩展的流量，耗电会受到设备信号、传输量、协议、规则复杂度、日志记录和连接稳定性共同影响。先进入系统 Settings 的电池用量页面，比较观察时段内 Shadowrocket 的前台与后台活动，同时检查是否有照片同步、云端备份、媒体播放或其他应用持续传输。网络流量由其他应用产生时，Shadowrocket 可能因处理这些连接而显示后台活动，因此不能只看到占比就判断客户端本身异常。

若设备发热并伴随服务器反复超时、Home 状态频繁切换或 On Demand 不断触发，重点检查连接重试。先关闭 On Demand，选择一个已经确认可用的服务器，在稳定 Wi-Fi 下手动连接并观察。恢复正常后，再检查 On Demand 条件是否在 Wi-Fi 与蜂窝网络切换时相互冲突。信号较弱时，蜂窝网络为维持连接会增加耗电；同一配置在稳定 Wi-Fi 下正常、弱信号环境下明显发热，说明接入网络也是重要变量。

缩小日志、规则与后台任务的影响

排查期间可减少不必要的长时间详细记录，并查看 Data 中是否有某个应用持续产生大量请求。异常重试的域名可能每隔很短时间重复出现，既增加流量，也会持续唤醒网络。此时应先确定请求来自哪个应用、命中了哪条规则、返回何种错误，再处理规则或目标应用的后台行为。不要直接用宽泛 REJECT 阻断所有相似域名，因为过宽的 DOMAIN-KEYWORD 可能影响正常功能并制造新的重试。

复杂规则文件本身通常不是唯一耗电原因，但大量重复、互相覆盖或顺序不合理的规则会增加诊断难度。可复制当前 Config，建立精简版本，只保留必要的局域网规则、明确域名规则、GEOIP 与 FINAL，观察相同时段的连接稳定性。如果精简后问题消失，再分段加入原规则，定位引发重复请求或错误分流的部分。此方法比一次删除全部配置更安全，也保留了恢复路径。

更新后先检查状态迁移，而不是立即重建全部配置

通过 App Store 更新后若出现开关失败、服务器不可选、规则行为变化或界面状态异常，先重启 Shadowrocket 的连接：关闭 Home，等待系统 VPN 标记消失，再重新打开。随后确认当前服务器、Global Routing、Config、DNS 与 On Demand 是否仍是更新前使用的项目。系统更新也可能重新评估网络扩展权限，因此应查看系统 Settings 中 VPN 配置是否存在并可用。系统要求与兼容范围以 App Store 页面标注为准。

如果配置内容仍在，但只有某一订阅或服务器失败，应按订阅和超时章节处理，不要把所有问题都归因于应用更新。若所有配置都出现相同问题，可先导出或记录当前重要设置，再重启设备和网络。仅在确认本地数据已有可恢复备份、购买记录可从 App Store 找回、订阅地址也仍由用户保存时，才考虑更大范围的重建。贸然清除数据会把暂时的系统状态问题变成配置恢复问题。

Shadowrocket 的唯一获取入口是 App Store 产品页。可在页面中核对开发者 Shadow Launch Technology Limited 与应用 ID 932747118；应用更新也由 App Store 管理，不应以网络中的版本描述代替商店页面信息。

iPad 专项：分屏、键盘、局域网与换机恢复

先确认 iPad 上的购买与配置来源

iPad 上的 Shadowrocket 与 iPhone 使用相同的 App Store 产品页。同一 Apple ID 已经购买时，可在 App Store 的已购项目中查找并恢复，具体兼容范围与系统要求以 App Store 页面标注为准。首次打开仍需要系统授权添加 VPN 配置。若 iPhone 正常而 iPad 开关打不开，应分别检查 iPad 的 VPN 权限、设备管理策略、On Demand 条件和当前网络，不要假定两台设备的系统网络状态完全相同。

通过 iCloud、Config 导出或 Import from Cloud JSON 恢复配置后，应把“文件已经出现”和“配置可以连接”分开验证。先核对服务器条目与 Subscribe 地址，再选择当前服务器，检查 Global Routing 和 DNS，最后打开 Home。若备份时间较早，订阅管理的条目可能需要重新更新；若策略组引用的服务器名称已经变化，也要同步检查 Config。完整顺序可参阅配置备份与换机迁移说明，其中同样适用于从旧设备迁移到 iPad 的核对过程。

处理分屏、多窗口与键盘带来的界面差异

iPadOS 的分屏和多窗口会改变可用宽度，Home、Config、Settings 或 Data 的列表与详情可能采用不同排列。看不到某个按钮时，先退出较窄的分屏状态或展开侧栏，不要依据 iPhone 的固定位置寻找。连接状态由系统网络扩展维持，关闭某个 Shadowrocket 窗口不等于断开 Home；应回到应用或系统 VPN 状态确认。多个窗口同时打开时，修改 Config 后要确认当前查看的是同一份配置和最新状态。

使用外接键盘粘贴 Subscribe 地址、SERVER、密码或规则时，注意全角标点、智能引号、自动空格和换行。规则语法需要英文逗号，策略名必须与现有名称一致。长按复制的内容若来自带格式文本，可能夹带不可见字符；出现看似完全相同却无法连接的情况，可在纯文本环境中重新核对，再逐字段输入。Scan QR Code 导入后也应检查结果，不应只看扫描过程是否完成。

局域网设备访问与 Wi-Fi 场景

iPad 常用于访问局域网存储、打印设备或家庭服务。若打开 Shadowrocket 后局域网资源失效，先用 IP 地址测试，区分名称解析与网络可达性。确保常见局域网网段存在 DIRECT 规则，并放在 FINAL 之前；若 IP 可访问而本地域名失败，应检查路由器 DNS 或本地名称解析。若 IP 也无法访问，检查 Wi-Fi 是否启用了访客隔离、设备是否在同一子网，以及目标设备是否允许当前网络访问。

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

在学校、会议场所或酒店 Wi-Fi 中，iPad 可能需要先完成登录页验证。先关闭 Home，打开浏览器触发网络登录，确认普通页面可访问后再连接。若分屏中的浏览器没有出现登录页，可暂时全屏打开或在系统 Wi-Fi 详情中重新加入网络。登录状态到期后，表现可能是 Shadowrocket 仍显示连接，但所有请求都失败，此时应再次检查网络门户，而不是立即修改服务器参数。

建立 iPhone 与 iPad 的独立对照

同一配置在 iPhone 正常、iPad 异常时，应让两台设备连接同一个 Wi-Fi，选择同一个服务器、同一份 Config 和相同 Global Routing，再比较结果。若只有 iPad 失败，检查其系统时间、DNS、VPN 配置、设备管理与私有网络相关设置；若两台设备同时失败，更可能是服务器、订阅或当前 Wi-Fi 的共同问题。对照时不要让一台使用蜂窝网络、另一台使用 Wi-Fi，否则结论会同时受到接入网络影响。

若 iPad 具备蜂窝网络能力，还应分别测试 Wi-Fi 与蜂窝网络，并关注 On Demand 条件是否针对两种网络设置了不同动作。切换网络后，等待系统状态稳定再测试，不要在 VPN 标记仍变化时连续点击 Home。只有 Wi-Fi 失败时，检查路由器和登录页；只有蜂窝网络失败时，检查蜂窝信号、数据权限与对应 On Demand 条件；两者都失败时，再回到服务器参数、DNS 和系统 VPN 配置。

若需要重新核对 iPad 的 App Store 获取、已购恢复和首次授权步骤，请查看iPad 获取说明。Mac、Apple TV 与 Apple Vision 的兼容信息也以同一 App Store 页面标注为准；本页的操作重点仍是 iPhone 与 iPad 上的故障定位。