Shadowrocket 故障排查大全

确认开关失败发生在哪一步

iPhone / iPad 上，Home 的 Not Connected 表示尚未建立连接，不等于订阅一定有错。先关闭自动重连条件，手动操作一次开关，观察系统是否请求添加 VPN 配置。若权限窗口尚未确认，回到系统提示完成验证；若开关短暂打开后恢复，记录持续时间和紧接着出现的错误，不要连续反复点击。

接着断开客户端，在浏览器打开一个平常可以访问的页面。基础网络也失败时，先完成 Wi-Fi 登录、检查蜂窝数据或重连网络。需要网页认证的公共 Wi-Fi 应先在断开状态完成认证，再测试连接。设备能连上无线接入点，只能说明局域网连接成立，不能证明已经获得互联网访问能力。

检查 VPN 配置与系统管理限制

iPhone / iPad 可在系统设置中搜索 VPN，查看是否存在对应配置，以及是否有其他正在连接的 VPN。先停止冲突连接，再返回 Shadowrocket 重试。不要凭名称删除公司、学校或设备管理下发的配置；受管理设备可能限制添加 VPN，需要由设备管理员确认允许的连接方式，应用内重新导入服务器不能解除系统限制。

若此前拒绝过授权，重新发起连接并留意系统提示；若系统中存在失效的 Shadowrocket VPN 配置，可在保存应用内资料后，移除明确属于本应用的旧配置，再由应用重新申请。系统配置与服务器条目不是同一份数据，删除前应确认对象，避免把订阅和规则一并清理。完成后先测试手动连接，不急于恢复自动条件。

分开处理权限不足与配置错误

Mac、Windows、安卓和 Linux 上，先检查应用是否正常启动，以及建立网络隧道需要的系统授权是否完成。安卓应核对 VPN 连接确认和应用电池限制；桌面系统应核对当前账户权限与安全软件的阻止记录。只修改与 Shadowrocket 对应的授权，不应为了排查而长期关闭系统防护或放宽所有应用的权限。

如果系统已经允许连接，而开关仍立即回退，改用保存好的最小配置，保留一个已有且参数完整的服务器条目。暂时停用自定义脚本、Rewrite 和复杂策略组，再重新连接。这样是在判断错误是否来自配置加载，不是在证明服务器可用。若最小配置可以维持连接，再逐项恢复扩展内容，直到找到导致回退的那一项。

检查 On Demand 与竞争连接

On Demand 会依据系统条件发起连接，容易让手动关闭后的状态看起来像“自动弹回”。排查时先记下原条件，再暂时关闭 On Demand，确保只有一次手动连接请求。与此同时停止其他 VPN、网络过滤或隧道功能，测试结束后再分别恢复；同时运行多个接管网络的组件，会使权限和路由归属难以判断。

如果只有锁屏后或切换网络时退出，应转到耗电和 iPad 章节，而不是继续删除服务器。若每次启动都出现明确配置解析错误，则检查配置中的分段名、标点和引用策略是否存在。把错误原文与最后一次成功连接的配置作对照，比重装应用更容易保留线索，也能避免重复输入敏感认证信息。

建立可重复的访问对照

全平台遇到“已连接但打不开”时，先固定一个测试页面和一个浏览器。依次记录断开连接时、连接后、切换服务器后的结果，不要同时更换网络和配置。若断开后也打不开，该目标本身或基础网络就可能有问题；若仅某个应用异常，应另外检查该应用的缓存、登录状态和系统网络权限，不能直接归因于所有流量。

在 Home 核对实际选中的 SERVER，不要只看订阅列表是否已经刷新。订阅包含多个条目时，列表更新不一定意味着当前选择同步变化。再查看 Global Routing，确认当前是 Config、Proxy 还是 Direct。连接按钮只说明网络扩展已启动，不说明每个请求都会经过同一服务器，也不说明规则已经命中预期策略。

用 Global Routing 隔离规则影响

短时切到 Proxy 后，用同一目标复测。如果 Proxy 成功而 Config 失败，重点检查配置、匹配顺序和策略引用；如果两者都失败，继续看服务器参数、DNS 和目标服务。Direct 可用于观察直连路径，但它仍是客户端中的路由状态，不等同于完全停用客户端，因此必要时还要补一次断开连接的基础网络对照。

核对规则顺序与末尾策略

Config 下的规则应从上向下检查，先命中的匹配会影响后续处理。宽泛的 DOMAIN-KEYWORD 或提前出现的兜底规则，可能让预期的精确规则没有机会执行。检查规则所引用的策略是否确实存在，并确认当前启用的是刚编辑的配置，而不是同名副本。修改后重新建立连接，再发起新请求，避免旧连接继续沿用原路径。

下面片段只演示规则分段与顺序，不能直接代替已有完整配置。PROXY 是策略引用，必须与当前配置可用的策略对应；本地网段示例按实际网络调整。FINAL 放在末尾承担剩余请求的兜底，不能把它放在需要继续匹配的细分规则之前。测试时一次只调整一条规则，并保存原来的顺序。

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

从日志判断故障停在哪一层

如果应用提供连接记录，先看请求是否出现，再看匹配策略、目标和错误。没有记录可能是请求未进入当前路径、应用使用已有连接，或记录功能没有开启，不能仅凭空列表认定软件没有工作。关闭测试页面后重新打开，发起一次新请求；日志中的域名和认证信息应在分享前隐藏，保留错误类别和时间即可。

若记录显示已经建立到服务器的连接，但目标仍返回错误，应检查目标服务、账户限制或目标侧的响应，而不是继续修改本机 VPN 权限。如果只有一个域名失败，转到 DNS 章节；如果所有经代理的请求都超时，转到节点超时章节。恢复日常使用前，把临时的 Proxy 状态改回原计划，并再次确认 Config 下的实际行为。

分清超时、拒绝连接与认证错误

全平台出现节点超时，先保留错误原文。超时表示在等待窗口内没有获得预期响应，可能发生于域名解析、建立连接、握手或目标访问；拒绝连接通常说明目标地址已响应但端口不接受该连接；认证失败则应优先核对用户字段。三者处理顺序不同，不能看到失败就统一重填密码，更不能把每次失败都解释为网络速度不足。

先确认服务器地址没有协议前缀、空格或复制时带入的换行，端口是订阅或服务器配置给出的值。不要因为名称相似就把另一条目的端口和认证拼到一起。订阅显示名称只是备注，不参与协议识别；某条目改名后，实际使用的协议、地址和传输参数不会因此自动改变，需要在详情中逐项核对。

按协议核对成组参数

Shadowsocks 应核对加密方法与密码；VMess、VLESS 应核对用户标识以及服务器要求的附加参数；Trojan 应核对密码和 TLS 相关设置。WireGuard 的密钥、地址和对端信息也不能与其他协议的字段互换。以用户已有的服务器资料为准，不应把不同教程中的“常用值”当成通用配置覆盖现有条目。

区分 TLS 名称与连接地址

启用 TLS 的条目中，连接地址、用于握手的服务器名称和传输层 Host 可能承担不同作用。把域名换成 IP 后，即使端口能连通，也可能因为证书名称不匹配而失败。先恢复服务端要求的名称，再检查设备日期和时间是否准确；时间明显错误会影响证书有效期判断，表现可能与参数错误相似。

不要把关闭证书验证作为长期解决办法。出现证书错误时，优先确认地址、名称、系统时间以及服务器证书状态。若资料只给出订阅，先更新并重新导入一个独立测试条目，比较字段差异，不要在原条目上连续试填多个猜测值。无法确认的服务端参数应由已有服务的管理方核实，而不是通过随机组合寻找可连接状态。

用交叉测试定位网络与服务器

固定同一个条目，分别在 Wi-Fi 与蜂窝数据下测试；再固定同一网络，换另一个已有且可用的条目。只有一个网络失败时，应检查该网络的认证、端口或 UDP 可达情况；多个网络都只对同一条目失败时，更应关注服务器状态和参数。测试 Hysteria2 等涉及 UDP 的路径时，普通网页可访问并不能证明对应传输同样可用。

Connectivity Test 的结果取决于测试方法，显示可达不等于真实业务已经成功。端口建立、握手完成和打开目标页面分别验证了不同阶段，应该补一次实际请求。若服务端允许查看日志，可按同一测试时间核对是否收到连接、是否拒绝认证以及是否成功访问目标，避免仅凭客户端的统一超时提示判断全部原因。

先判断是地址问题还是网络问题

全平台更新已有订阅失败时，先检查链接是否完整，尤其是问号之后的查询参数。聊天工具、邮件换行和手动选择文字都可能截断地址。不要根据订阅备注名重新拼接链接，也不要把服务商的登录页面当作订阅入口。复制后只在本机核对，订阅地址常带访问凭据，不应放进公开截图或错误反馈标题。

记录更新时的网络和连接状态。如果当前所选服务器已经失效，而订阅更新又经过该服务器，就可能形成无法取得新条目的循环。先在基础网络可用的条件下尝试更新，必要时改用另一个已有且可用的连接路径。不要频繁连续点击，远端可能限制请求频率；等待后用相同条件重试，才能判断是否只是临时响应失败。

检查返回内容而不是只看成功提示

能够取得响应，不代表取得了可解析的服务器列表。远端可能返回账户登录页、到期提示、访问验证页面或一段错误文本。若应用提示格式错误，应结合响应状态和错误说明确认内容类型，不要直接把整段响应复制进 Add Server。链接能在浏览器里显示文字，也不意味着该文字符合当前导入入口所支持的格式。

若返回未授权或访问被拒绝，先核对自己的账户状态、链接是否已重置以及查询参数是否缺失。若显示地址不存在，检查是否复制了旧入口；若属于远端服务器错误，可稍后重试并联系已有服务的管理方。客户端更新无法修复远端账户限制，反复删除本机配置也不会改变服务器对该订阅请求的授权结果。

选择与资料匹配的导入入口

Subscribe 用于订阅地址，Add Server 用于逐项填写服务器信息；Scan QR Code 与剪贴板识别则取决于实际内容。二维码可能包含单个条目，也可能只是网页地址，扫描成功不等于已经导入可连接的配置。Import from Cloud JSON 也不是所有链接的通用入口，必须与提供的资料格式一致，不能只看名称相近就尝试互换。

订阅、服务器列表与完整配置文件有不同用途：订阅主要更新条目，配置文件还可能定义规则、DNS 和策略。把规则文件当成节点订阅，可能得到空列表；导入了节点，也不表示已经启用新的分流配置。入口对照可查Subscribe、Add Server、扫码与剪贴板说明，再按实际资料选择方式。

# 仅演示订阅地址结构，不可用于连接
https://example.com/sub?token=xxxx

保留原条目并验证更新结果

修改订阅前保留旧配置和仍然可用的条目，另建测试分组或副本观察更新。更新后核对条目数量变化、所选 SERVER 是否还存在，以及原先手动调整的参数是否被覆盖。某些更新会重新生成条目；本地编辑应有单独记录，不能假定每次远端刷新都保留这些改动，也不要在没有备份的情况下整体清空。

导入后列表为空，还要检查搜索条件、分组折叠和筛选是否隐藏了条目。若只有部分条目缺失，比较它们的协议与字段完整性，判断是来源本身没有返回，还是解析时被跳过。先选一个新条目打开详情并发起实际请求，确认导入、选择与连接三步都完成，再把测试结果合并到日常配置中。

把“慢”转换成可观察的现象

全平台排查速度问题，应先描述具体场景：网页开始加载前等待很久、下载持续缓慢、视频播放中断，还是只有首次访问慢。开始前的等待可能涉及 DNS、握手与服务器建连，持续传输则更依赖路径容量和目标响应。不同现象不能用同一个测试数字解释，也不应仅凭节点名称或地理备注推断线路质量。

固定同一个目标和相近的内容大小，先在断开状态记录基础网络表现，再测试同一条目。避免一边下载大文件一边测网页，也要留意系统更新、云端同步和其他设备占用网络。测试结果应写明网络、时间段与服务器，单次偶然变快或变慢不足以证明某个参数长期有效，更不适合作为频繁调整全部配置的依据。

理解延迟与吞吐量并不相同

Connectivity Test 反映的是指定测试过程的结果，不能直接等同于下载速度。一个响应较快的条目，仍可能在持续传输时受到容量或拥塞影响；一个首次响应稍慢的连接，也可能在建立后保持稳定吞吐。应补充实际网页和持续传输两类测试，再判断是首包等待还是传输阶段的问题，而不是只按列表中的数字排序。

若只有个别目标慢，先比较同一服务器访问其他目标的情况。目标站点负载、内容分发路径、登录状态和应用自身重试也会影响体验。若所有目标同时变慢，再检查本地网络与服务器侧资源。不要为单一目标把全部规则改成同一种策略，这可能改变原本正常的请求路径，增加新的故障而没有解释旧问题。

检查 Wi-Fi、蜂窝与传输路径

在 Wi-Fi 下，可先靠近接入点并停止大流量任务，观察卡顿是否随信号和局域网拥塞变化；蜂窝下则留意信号变化和移动过程。用同一条目换网络，比在同一网络里不断切条目更能判断本地路径。公共网络可能对部分端口或 UDP 处理不同，普通浏览可用不代表所有协议的持续传输都同样稳定。

如果仅涉及 UDP 的协议或应用异常，结合网络切换结果核对 UDP 路径，不要盲目增加带宽参数。服务器配置与客户端参数应成对匹配，填入更大的数值并不会创造实际容量。涉及 MTU 的调整应有分片、特定大小请求失败等证据，并保留原值；没有可重复症状时，不建议把网上的固定数值直接套用到所有网络。

减少规则、重试与诊断的附加开销

若简单配置正常而复杂配置明显变慢，逐项恢复策略组、DNS、自定义脚本和 Rewrite，观察哪一步开始变化。频繁的健康检查、失败重试和大量诊断记录可能增加额外请求，也可能让短时间观察失真。先保留业务必需内容，暂停高频测试，再用同一目标验证；删除规则之前应确认是否有其他功能依赖它。

长时间使用后才卡顿，还应观察设备温度、剩余存储和后台任务，而不是只判断线路。设备发热可能同时影响浏览器、解码与网络处理，暂停高负载任务并恢复正常温度后再复测。问题解决后恢复原来的诊断级别，并记录真正有效的改变；若无法稳定复现，就保留日志与条件，避免把巧合当成可靠修复方法。

识别域名解析与连接失败的边界

全平台遇到只有域名打不开、首次访问等待明显或日志出现解析错误时，先检查 DNS。域名解析负责把名称转换为地址，连接则使用所得地址继续建立通信。解析成功并不证明目标端口可用，连接超时也不一定是 DNS 错误；应在记录中分辨失败发生于解析前、连接时还是 TLS 握手阶段，避免把所有问题归为同一类。

不要简单用“换成 IP 能打开”作为唯一证据。许多 HTTPS 服务依赖域名完成证书验证和站点选择，直接在浏览器输入 IP 可能得到不同页面或证书错误。更可靠的方法是对照应用记录中的查询结果与后续连接错误，并检查同一域名在基础网络和当前配置下是否表现不同，测试期间始终保留原来的目标名称。

从系统 DNS 基线逐项恢复

先保存当前 DNS 设置，检查配置是否同时指定多个来源、是否存在自定义 Host，以及是否有旧的域名映射。下面的片段仅演示使用系统 DNS 的排查基线；它不保证适合所有网络，也不替代已有完整配置。如果切回基线后问题消失，再逐个恢复自定义解析项，确定是哪一项引入异常，不要一次性把所有地址替换掉。

[General]
bypass-system = true
dns-server = system

[Rule]
DOMAIN-SUFFIX,example.com,PROXY
FINAL,PROXY

使用加密 DNS 时，还需要考虑解析服务本身如何建立连接：它的域名可能先依赖其他解析路径，其请求也可能受路由策略影响。若解析必须经由当前尚未建立的服务器，而服务器域名又依赖该解析，就可能形成依赖循环。先恢复能启动的最小链路，再按当前应用支持的设置明确解析与连接关系，不宜随意叠加多个兜底。

检查规则类型与解析时机

DOMAIN、DOMAIN-SUFFIX、IP-CIDR 和 GEOIP 处理的对象不同。域名规则直接针对名称，IP 类规则则可能需要已有解析结果才能判断。使用 no-resolve 的 IP 规则可避免为了该条规则主动解析，但这不代表后续真实连接永远不需要 DNS。排查时既要看规则文字，也要看请求此时是否已经有目标地址，不能只根据域名猜测匹配结果。

处理缓存、IPv6 与局域网名称

修改 DNS 后，旧请求可能继续使用缓存或已有连接。关闭测试页面、重建客户端连接，再发起新请求；只有在应用提供明确的缓存清理入口时才使用该入口，不要为刷新 DNS 清空所有配置。若出现 IPv4 正常而 IPv6 异常，应检查服务器、系统和实际网络是否具备一致的 IPv6 路径，而不是仅在规则里补一个名称。

打印机、局域网服务和内部域名可能依赖当前 Wi-Fi 提供的 DNS，统一改成远端解析后不一定还能找到。遇到外部域名恢复而内部名称失效，应分别核对局域网地址、系统权限和内部解析路径。保留只在本地网络生效的边界条件，不要把内部名称发送到无关解析路径；恢复后同时验证外部页面与实际需要的本地服务。

正确阅读系统电池统计

iPhone / iPad 和安卓出现耗电疑问时，先查看系统电池页面的统计时间范围、屏幕使用时长和后台活动。电池占比是该时段各应用相对消耗的比例，不等于客户端持续占用了同等比例的全部电量。前后两次若分别处在 Wi-Fi 与弱信号蜂窝环境，或一个时段大量传输，不能直接根据百分比断言配置异常。

网络隧道会处理经过它的数据，系统统计可能把部分网络处理消耗归到相关进程，但并不能由此精确拆分每个应用的流量成本。先选两个使用习惯接近的时段，记录网络、连接持续时间和主要任务，再比较差异。排查时不要同时改协议、换网络并关闭后台权限，否则即便电量改善，也很难知道真正有效的因素。

检查是否存在持续失败与重试

反复连接失败比稳定空闲连接更值得检查。打开应用观察连接是否频繁切换，订阅是否在短时间反复更新，策略组是否高频测试不可用条目。若连接日志持续产生同类错误，先修复基础网络、认证或解析问题，再评估耗电。仅仅降低诊断记录详细程度，不能解决底层不断失败的请求，也可能把重要证据隐藏起来。

On Demand 的条件应与实际需求一致。移动过程中频繁切换 Wi-Fi 与蜂窝、在覆盖边缘不断重连，可能让系统反复重新建立连接。先暂时关闭自动条件，在稳定网络手动保持一次连接，观察错误是否停止；测试结束后按需要恢复条件，而不是长期取消所有自动行为。若只有某个无线网络异常，优先检查该网络本身。

处理后台限制而不是一律强行常驻

安卓应检查系统是否限制 Shadowrocket 的后台网络和电池使用，尤其是只有锁屏后断开的情况。按系统提供的应用级选项调整，不必把所有应用都设为不受限制。iPhone / iPad 上的 VPN 连接由系统网络机制管理，不能简单把主应用切到后台等同于连接应该退出；应结合系统 VPN 状态、日志和网络切换时间判断。

Mac、Windows 和 Linux 则应区分屏幕关闭、睡眠和系统唤醒。设备进入睡眠后网络路径可能中断，唤醒后的旧连接也未必可以继续使用。先确认系统已经恢复正常联网，再重建客户端连接；不要为维持测试而长期关闭整机节能。若只在电池供电时异常，核对系统电源模式以及对网络适配器的节能设置是否改变。

隔离脚本、记录和其他后台任务

复杂脚本、Rewrite、频繁检测和长时间详细日志会增加处理工作，但不能在没有对照时认定某一功能就是原因。复制配置后暂停非必需部分，用相同业务场景测试，再逐项恢复。与此同时检查云同步、大文件上传、系统更新和媒体处理，因为这些任务既会增加流量，也会让客户端承担更多网络处理，表现为同时发热和耗电。

如果设备温度明显升高，应先暂停高负载任务，等待恢复正常再测。异常发热与网络中断同时出现时，不要连续运行压力测试或保持充电高负载来追求稳定结果。若最小配置下仍在相近条件持续异常，整理电池页面、系统状态和脱敏日志，保留发生时间；重装前先确认是否能够用另一网络复现同样现象。

区分应用、系统和订阅更新

全平台遇到“更新后连不上”，先确认更新的是 Shadowrocket、操作系统、订阅还是配置文件。它们可能恰好发生在同一时段，却影响不同层次。记录最后一次正常使用的网络与配置，再列出之后的变更，不要立即把所有问题归因于应用。订阅条目被替换、系统权限重置和规则内容变化，都可能在应用更新后才第一次显现。

先重启一次应用并重新建立连接，确认系统基础网络可用；如系统更新尚未完成必要的重启，应先完成系统流程。若只有旧连接失效而新请求正常，可能是网络状态没有及时恢复。若每次连接都会稳定出现同一错误，则保留日志继续定位，不要通过反复重启掩盖可复现的线索，也不要在未备份时清除应用数据。

用配置副本检查兼容边界

保存当前配置与可用的旧副本，比较分段、策略名称、DNS 和附加功能。配置解析更严格时，过去未暴露的拼写或引用错误可能被明确提示；应根据实际错误逐项修正，不要整体复制一个来源不明的配置覆盖现有资料。先用单一已有服务器和最小规则建立连接，确认基础功能后，再恢复策略组和扩展设置。

订阅更新也可能改变条目的标识、名称或参数，导致原策略引用失去目标。检查当前 SERVER 是否仍存在、策略组是否为空，以及被引用的名称是否完全一致。若同名条目有多份，应确认选择的是哪一份。恢复旧配置并不一定恢复远端已经更改的服务器状态，因此必须同时验证实际请求，不能只看配置文件可以成功载入。

重新获取应用时保留系统安全边界

需要重新安装时，从获取应用选择对应平台。iPhone / iPad 在 App Store 获取，系统要求以 App Store 页面标注为准；Mac、Windows、安卓和 Linux 安装包由本站 /dl/ 路径提供。Mac 应先在「关于本机」确认 Apple 芯片或 Intel，不能仅凭设备外观选包；平台与架构不匹配并不是服务器配置错误。

桌面与安卓安装包没有代码签名，首次打开可能触发系统拦截。Windows 的 SmartScreen 可在核对来源后查看「更多信息」并选择「仍要运行」；Mac 遇到无法验证开发者时，在「隐私与安全性」检查对应应用的「仍要打开」。只针对明确下载的 Shadowrocket 操作，不应为了安装而关闭全局安全检查或长期降低保护设置。

安卓应在系统设置中为执行安装的浏览器或文件管理工具允许「安装未知应用」，完成后可按需收回权限；微信内无法下载时改用系统浏览器。Linux 应根据发行版选择 deb、rpm 或 AppImage，并按安装说明处理权限。具体流程见Mac 与 Windows 安装笔记及安卓安装笔记。

逐项恢复并保留可追溯记录

重新安装前确认备份能够恢复服务器、规则和必要设置，敏感字段应只保存在自己的安全位置。不要假定卸载后所有数据仍然保留，也不要把系统 VPN 配置当作完整应用备份。恢复时先导入一个条目完成连接，再恢复订阅与规则，最后恢复自动连接条件；每一步都用相同目标验证，便于准确识别异常从何时开始。

如果只在新系统或特定配置组合下复现，整理最短复现步骤、系统信息、错误原文和脱敏后的最小配置。反馈不需要附上完整订阅和真实密码，公开这些字段反而会带来额外风险。问题暂未定位时，保留已经验证可用的配置副本，避免继续叠加修改；恢复的目标是可解释地恢复功能，而不是让每个设置都变得不同。

iPhone 正常而 iPad 失败时如何对照

iPad 遇到同一订阅在 iPhone 可用、自己却无法连接时，先把两台设备放到同一个 Wi-Fi，选择同一个服务器条目，并核对 Global Routing 和启用配置。仅仅订阅名称相同并不足以构成对照，两台设备可能分别选择不同条目，或者一台使用旧规则。核对完再发起同一目标请求，记录实际结果而不是只比较连接图标。

接着检查 iPad 的日期、时间、VPN 授权和基础网络。Wi-Fi 版 iPad 没有蜂窝网络可供切换，不能照搬手机的切换步骤；可以在获得授权的情况下用另一可用网络或个人热点做对照。蜂窝版则应额外检查系统是否允许应用使用蜂窝数据。一次只更改网络来源，保留配置不变，才能判断故障是否跟随网络。

公共 Wi-Fi、热点和局域网访问

公共 Wi-Fi 需要认证时，先断开 Shadowrocket 完成网页登录，再建立连接。若认证页无法自动出现，可在系统 Wi-Fi 页面确认连接状态，按网络提供的正常方式完成验证。热点连接也有独立的上游网络条件，手机本身能访问某目标，不代表分享给 iPad 的路径与手机应用完全相同，应在 iPad 上单独检查基础访问。

访问打印机、投屏设备或局域网服务异常时，先核对系统中的本地网络权限、两台设备是否处在同一网段，以及无线网络是否启用了客户端隔离。再检查配置中是否把本地地址错误交给代理。下面片段仅为常见私有地址的规则示例，实际网段以当前网络为准；使用本地服务还可能需要该网络提供的域名解析。

[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
FINAL,PROXY

锁屏恢复与多任务中的连接判断

iPad 锁屏后再次使用时，先观察系统是否已经重新获得 Wi-Fi，再看客户端状态。网络恢复期间的短暂失败不能直接说明订阅失效；等待基础网络正常后重建连接，用新请求测试。如果每次解锁都稳定复现，应记录锁屏前后的网络、On Demand 条件和错误时间，按耗电章节检查后台与重连，而不是重复导入同一条订阅。

分屏、台前调度或外接键盘改变的是操作方式，不会自动同步另一台设备的服务器选择。排查时把 Shadowrocket 与测试应用依次打开，确认修改后已经保存并应用；不要在多个配置编辑窗口之间混淆副本。某个应用在多任务中保留旧连接时，可先结束该请求再重试，避免把旧会话路径误认成新规则仍未生效。

同步资料、设备限制与反馈方法

把配置从 iPhone 转到 iPad 后，应分别核对服务器详情、策略引用和系统权限。文件复制只能迁移文件内容，不能替另一台设备确认 VPN 授权；依赖当前网络的本地域名和地址也不一定适用于新设备。如果已有服务对同时连接数量有限制，应先断开另一台设备做对照，再向原服务管理方确认规则，客户端不能改变远端账户限制。

如果应用中出现异常但同设备浏览器正常，要进一步核对该应用的网络权限和所访问的目标，不能直接用浏览器成功推断所有业务都应成功。若受学校或企业管理，保留管理配置并咨询管理员，不自行移除限制。整理反馈时注明 iPad 的网络类型、是否锁屏恢复、所选配置和错误原文，同时隐藏订阅、用户标识与密码。