Shadowrocket 故障排查大全
先区分故障层，再修改一个变量。
本页是系统查阅手册，适用于已经持有自己的订阅或服务器信息、需要定位连接异常的用户。尚未完成首次配置时，先按快速上手教程建立基准；已能连接但出现特定症状，再从下列目录进入对应章节。教程负责操作主线，本页解释失败分支、对照方法与恢复边界。
客户端一次性买断 ≠ 线路套餐。应用购买、用户已有的连接服务和当前网络分别检查。正版获取与购买恢复见App Store 下载指南；本站不提供、不销售、不推荐节点或订阅。
开关打不开：先检查 VPN 配置与系统限制
开关一打开就退回、一直停留在连接过程、系统没有出现预期授权提示，是三种不同现象。前者优先检查系统是否接受 VPN 配置，中间状态要结合错误记录判断服务器连接是否已经开始，没有提示则可能是此前已经允许，也可能受设备管理策略限制。先记住触发后的表现，不要连续快速拨动开关；反复尝试会混淆前一次失败与后一次重连的记录，也不能替代权限检查。
区分首次授权与已有配置
首次在 Home 打开连接时，系统可能请求添加 VPN 配置。确认操作来自刚刚打开的 Shadowrocket，再按系统提示允许，并完成设备要求的身份验证。这个授权允许客户端建立系统网络隧道，不表示服务器信息已经有效，也不表示应用购买包含连接服务。如果取消了授权，回到应用重新发起连接；不要为了让提示出现而先删除其他网络设置。权限正常但仍连接失败，应继续检查本章后半部分的配置与网络状态。
已经使用过的设备，可在系统设置中搜索 VPN，查看是否存在对应配置，以及当前由哪项配置建立连接。系统设置的分组位置可能随系统变化，优先使用搜索而不是照搬固定路径。若另一项 VPN 正在工作，先停止它，再单独测试 Shadowrocket；涉及工作或学校管理的配置，不要擅自移除。设备管理、内容过滤与网络扩展可能共同影响连接，管理策略造成的限制需要由设备管理员确认。
按顺序排除连接争用
先关闭 Shadowrocket 的连接，临时暂停 On Demand，再确认系统没有自动启用另一项 VPN。随后退出当前设置页面，回到 Home，核对实际选中的 SERVER 是否仍是预期条目，再发起一次连接。若开关能够保持但网页失败，说明症状已经转到访问层，应进入下一章；若马上退回，查看失败时间附近的错误描述，重点区分权限拒绝、配置创建失败和服务器握手失败，而不是只根据开关颜色判断原因。
如果系统配置明显残留异常，先保存应用内服务器与配置文件，再关闭连接和自动触发条件。只移除能够确认属于 Shadowrocket 的 VPN 配置，然后回到应用重新触发系统授权。移除系统 VPN 配置和删除应用内配置不是同一操作；前者重建系统连接入口，后者可能丢失规则与参数。对于受管理设备，出现无法删除或无法新增的提示时，应停止重复操作，先核实管理要求。
网络未就绪时不要先重装
在需要网页登录的 Wi-Fi 上，先断开 VPN，完成网络登录，并确认普通网页能够访问，再尝试连接。网络显示已连接不等于已经取得可用出口，路由器未分配地址、登录状态过期或当前网络限制访问，都可能让连接过程停住。换到另一条自己可用的网络复测，若只有原网络失败，应保留当前应用配置，继续检查该网络；若所有网络都失败，再检查系统权限、服务器参数与设备时间。
本章完成的标准是系统接受 VPN 配置，连接操作产生可识别的结果，并能区分“隧道未建立”和“隧道建立后访问失败”。需要重新核对应用来源、系统要求或已购恢复时，查看正版核验说明；系统要求以 App Store 页面标注为准。首次打开各区块的用途可对照Home 与 VPN 配置授权说明，避免将系统授权问题误判为订阅故障。
已经连接却无法上网：用三姿态缩小范围
连接状态成立，只能说明系统隧道已经建立，不能证明域名解析、服务器转发和目标网站都正常。先断开连接访问一个平常可用的网站，确认底层网络能够工作；再连接并访问同一地址，保留前后差异。如果断开后也失败，先处理当前网络或目标网站，不要在规则文件里寻找所有原因。若只有某一个应用或网站失败，单独记录它的具体域名、错误提示和发生步骤，避免把局部问题写成全部断网。
先理解 Global Routing 的检查用途
在 Home 查看 Global Routing，配置姿态 Config 按当前生效配置处理流量，代理姿态 Proxy 和直连姿态 Direct 可用于建立对照。姿态名称与规则中的 PROXY、DIRECT 关键字相关，但不是同一个设置位置。诊断时先固定网络与所选服务器，再依次改变姿态，每次重新发起目标访问。这里只比较测试结果，不把临时测试姿态直接保留为日常配置；涉及本地地址、特殊规则或系统流量时，还需结合实际记录判断。
| 界面姿态 | 检查目标 | 结果指向 |
|---|---|---|
| Config | 当前配置与策略命中 | 仅此姿态失败，优先查规则与 DNS |
| Proxy | 所选服务器的转发路径 | 失败时检查服务器、握手与目标访问 |
| Direct | 直连路径的对照表现 | 与断开连接后的测试一起解释 |
如果 Proxy 能访问而 Config 不能，说明该目标通过所选服务器存在可用路径，重点转向当前配置是否把它交给 DIRECT、REJECT 或其他策略。反过来，Direct 正常而 Proxy 失败，优先检查所选服务器的参数、状态和出口路径。三个姿态都失败时，先确认测试目标本身可用，再看 DNS 与当前网络。单次成功不能证明全部流量正常，单次失败也不能证明某类规则一定有错，需要结合访问记录和重复测试。
检查当前生效配置，而不只看编辑内容
进入 Config，确认当前实际使用的是刚刚检查的配置文件。编辑了一个文件但仍启用另一个文件，是“规则写对却没有效果”的常见原因。保留原文件后创建单独测试配置，先用少量规则验证目标，再逐步加入原有规则。规则按顺序匹配，首条命中即生效；宽泛规则如果位于前面，会使后面的具体规则失去机会。检查时同时看匹配类型、域名范围、策略名称和 FINAL 的位置。
[Rule]
DOMAIN-SUFFIX,example.com,PROXY
IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
FINAL,DIRECT上例用于解释结构：示例域名及其子域名交给 PROXY，指定私有网段使用 DIRECT，其余请求由 FINAL 处理。它不是适合所有网络的完整配置，也不能替代已有配置的 DNS 与其他参数。测试真实故障时，应将目标域名换成自己需要检查的域名，并先确认服务器可用。若原来使用策略组，不要在未核实策略组定义的情况下直接改名，否则会把规则问题变成策略引用问题。
用一条访问记录闭环
重新打开目标页面，查看应用可用的连接或诊断记录，定位相同时间发生的请求，核对实际域名、命中规则、策略和错误信息。一个页面可能涉及登录、图片、接口等多个域名，首页能显示而登录失败，往往需要检查第二个请求，而非只添加首页域名。验证后恢复正常 Config，关闭临时测试设置。姿态解释见Global Routing 三姿态说明，规则范围见规则类型详解。
若访问记录显示请求已经通过预期策略发出，但仍由目标返回拒绝或登录错误，应进一步检查目标账户、浏览器会话与服务器出口条件。不要通过不断扩大代理规则来处理所有网站业务错误；先保存明确证据，再决定进入服务器超时或 DNS 章节。
节点超时：分开检查地址、握手与转发
Connectivity Test 显示超时，不代表已经确定服务器宕机。测试方法、目标、当前网络和服务器配置都会影响结果。先查看采用的测试方式，再核对实际网页访问；端口可以建立连接，不等于协议认证成功，测试目标能够响应，也不等于所有网站都可访问。把测试结果当作线索，而不是把某一个数值或超时标签当作完整结论。固定同一服务器、同一网络和同一测试目标，才有可比较的基准。
先查服务器信息是否完整一致
打开当前 SERVER 条目的编辑信息，与用户已有的服务器资料逐项核对。地址、端口、协议类型、认证字段和传输设置必须是一组相互匹配的参数。手动复制时留意前后空格、漏字和换行，不要把说明文字一并粘入字段。服务器地址填域名时，还要确认该域名能够解析；填入地址后连接仍失败，也不能据此跳过证书与服务端名称检查。不要把某个字段“看起来相似”当作已核对完成。
| 协议或参数组 | 重点核对 | 常见误判 |
|---|---|---|
| Shadowsocks | 方法、密码、地址、端口 | 端口可达便认为认证有效 |
| VMess / VLESS | 身份字段、传输类型、TLS 与路径 | 只检查地址，忽略传输要求 |
| Trojan | 密码、TLS、服务端名称 | 用连接地址替代全部名称字段 |
| Hysteria2 / WireGuard | 按原资料核对认证及协议专属参数 | 将其他协议的配置方式套入 |
按错误阶段判断下一步
如果记录显示域名解析失败，先转到 DNS 章节；如果是连接被拒绝，说明目标路径与单纯等待超时不同，应确认地址、端口及服务端监听状态；如果建立连接后出现认证错误，重点核对密码或身份信息。TLS 相关错误还应检查设备日期与时间、服务端名称和证书状态。错误文字可能因协议不同而变化，报告时保留原文比只写“连不上”更有帮助，同时遮盖其中可能包含的私密字段。
带有 TLS 的连接中，连接地址、服务端名称与传输层的 Host 不一定相同。它们应按已有服务器资料填写，不能为了减少字段而统一改成一个值。使用 WebSocket 等传输方式时，还需核对路径、大小写和相关请求头设置。路径里的一个字符差异也可能导致连接到正确主机却无法进入预期服务。不要用关闭证书验证来掩盖名称错误；那既不能解释根因，也会改变正常的验证边界。
通过网络对照区分客户端与路径问题
保持同一条服务器配置，分别在两条自己可用的网络上测试。如果一条正常、一条始终超时，优先检查原网络的出口限制、登录状态及对协议传输的支持；如果两条都失败，再比较同一订阅中自己原本持有的其他条目。只有某个条目失败时，问题更接近该服务器或其配置；全部条目一起失败时，需继续核对订阅是否整体变更、认证是否失效，以及设备公共设置是否发生修改。
不要连续改动端口、协议和认证字段碰运气。若服务器资料由自己的服务商维护，应提交测试时间、网络类型、错误阶段与已遮盖的配置差异，询问该条目当前要求是否变化。若服务器由自己管理，检查对应时间的服务端记录，确认连接是否到达、认证是否被接受以及后续请求是否发出。客户端没有收到响应与服务端明确拒绝认证，是两条不同的处理路径。
调整完成后保存条目，重新选择它并建立一次新连接，避免继续观察旧连接的结果。确认能够稳定访问后，再恢复日常的自动触发与规则设置；协议字段的含义可在术语手册继续查阅。
订阅失败：先区分获取失败与内容无法导入
Subscribe 更新失败时，先保留当前还能使用的条目，不要立即删除整个订阅。订阅更新包含获取地址、接收响应、解析内容和更新条目几个阶段；其中任何一段失败，最终都可能表现为更新不成功。先记录具体提示及更新时间，再确认旧条目是否仍能连接。更新失败而旧条目可用，通常说明需要重点检查订阅获取路径或内容，而不是先更改全部服务器参数。
核对地址来源与完整性
订阅地址应来自用户自己的服务资料，复制时保留完整查询参数，检查是否混入空格、引号、换行或说明文字。有些服务会同时提供管理页面、说明页面和订阅地址，浏览器能够打开的页面不一定是可导入的订阅内容。不要把登录页面地址当作 Subscribe 地址，也不要因为链接很长就删除末尾参数。订阅地址可能包含身份凭据，分享截图和诊断记录前应遮盖完整敏感部分。
如果服务资料中的地址已经变更，应先在原有管理渠道确认，再修改客户端记录；不要依赖转发消息里的旧地址。浏览器访问能辅助判断是否出现登录页面、错误页面或重定向，但浏览器和应用的请求环境可能不同，因此浏览器能打开不等于应用必能导入。尤其是浏览器已有登录状态时，看到的内容可能依赖会话，而订阅请求需要的是能够独立获取、格式受支持的数据。
按响应结果选择排查分支
若能看到 HTTP 状态，认证相关错误应先核对订阅凭据和账户状态，资源不存在应检查路径是否变化，请求过于频繁则应停止连续更新并按服务要求等待，服务端错误则需要由订阅维护方核实。连接超时并不属于内容格式错误，先检查当前网络与订阅域名的解析。每次复测应使用相同地址，避免同时更换网络和链接，使结果失去判断价值。
当提示更接近解析失败时，重点检查返回内容是否是协议条目、配置文件，还是网页文本。订阅与 Config 中使用的完整配置文件不是同一种对象，不能只因它们都表现为一个链接就放进同一入口。部分条目可能包含客户端当前不支持的字段组合，出现少量导入成功、少量失败时，应按失败条目的协议与参数进行核对，而不是认为整个地址都不可用。具体支持范围以当前应用说明为准。
保留旧条目，避免更新造成连接依赖
订阅地址有时依赖当前已有的连接路径才能获取。若先删除全部服务器，再更新订阅，可能失去原本可用的获取条件。应先保存现有配置与可用条目，再检查更新请求是否确实经过预期路径；不要假定它一定与刚刚打开的网页使用相同连接。若当前选中的服务器已经失效，只在用户原有可用条目与可用网络之间做对照，不引入来源不明的数据来绕过排查。
更新成功后，检查条目数量变化只是初步步骤，还需确认当前选中项是否仍存在、其关键参数是否被覆盖、重复名称是否导致选错对象。对自己手工调整过的条目，应了解下一次订阅更新是否会重写字段，必要时保留独立副本用于比较。不要把“更新完成”与“服务器可以连接”画等号，数据获取和实际服务器连接需要分别验证。
本章结束时应能明确属于地址错误、获取路径失败、响应异常还是格式不匹配。导入入口的基本步骤见快速上手教程；若导入的是规则配置，可继续阅读配置文件各段说明，不要将服务器订阅与规则文件混用。恢复后只执行一次必要的更新与连接验证，避免频繁刷新增加新的限制因素。
速度慢：拆开首屏等待、持续传输与局部卡顿
“速度慢”至少包含三类现象：打开页面前等待很久，页面开始加载后传输缓慢，以及只有特定应用或网站卡顿。先描述慢在哪一段，再选择测试。首屏等待可能涉及 DNS、握手与重定向，持续传输更受路径容量和拥塞影响，局部卡顿则可能属于某个域名、协议或目标服务。Connectivity Test 的响应时间只是特定测试的结果，不能直接代表持续下载能力，也不能代替真实业务验证。
建立可重复的测试条件
先固定设备、网络、服务器、姿态与测试目标，暂停大型同步、系统下载和其他持续传输任务，等待当前请求结束后再复测。记录测试发生的时间以及是否处在低电量、热点共享或信号较弱状态。不要拿不同时间、不同目标的一次结果作比较，也不要同时打开多个测速任务；并发测试本身会争用带宽，使原本正常的路径看起来不稳定。短时间重复几次观察趋势，比追求一次最高结果更有意义。
在同一网络下，先断开连接观察目标的直连表现，再连接并用 Proxy 检查服务器路径，最后用 Config 验证日常分流。若 Proxy 正常而 Config 慢，应检查目标的部分资源是否被交给了不同策略；若两个姿态都慢，而其他已有服务器正常，问题更接近当前服务器路径。若所有方式都慢，优先检查 Wi-Fi 信号、网络拥塞和目标服务，不要先大规模修改配置。
识别页面里的慢请求
一个页面可同时请求文本、图片、脚本、视频和登录接口，主页面加载完成不表示全部依赖域名正常。出现图片慢、登录转圈或播放开始后停顿时，应在相同时间段查看连接记录，找出持续失败或反复重试的请求。只为首页域名添加规则，可能无法覆盖实际卡住的资源；反过来，为图省事扩大到很宽的域名范围，又可能改变本来正常的访问路径。规则调整应以实际请求为依据。
如果每次第一次访问慢、随后访问明显改善，应重点观察解析、连接建立与缓存因素；如果长时间传输中周期性停顿，则考虑网络切换、丢包、路径拥塞或服务器资源竞争。缓存会影响对照，浏览器刷新也可能继续使用已有连接。复测时尽量建立新的访问过程，并说明是否为首次请求；不需要为了测试清空全部应用数据，更不要把清理数据作为通用提速手段。
协议调整与 MTU 要有证据
传输方式不是越复杂越快，协议是否合适取决于服务器配置与当前网络条件。若怀疑某类传输受限，先比较自己已有且参数正确的条目，不要在客户端单方面改协议名称。MTU 等参数也不应按网络文章里的固定数值随意照抄；只有出现小请求正常、大请求停住，并有重复对照支持时，才进入该方向排查。调整前保留原值，每次只改一项，并用相同目标复测，效果不明确就恢复。
目标服务也可能针对登录状态、资源类型或出口条件表现不同。如果其他网站正常，只有某个目标持续缓慢，应分别检查目标状态和服务器到目标的路径，不能据此认定客户端整体性能不足。设备过热、后台任务集中运行和弱信号重传也会改变体感速度；先让设备恢复正常工作状态，再重新测试，避免把短暂的系统负载归因到规则配置。
确认根因后，只保留能解释并改善问题的修改，删除临时测试规则，回到日常 Config 再检查一次。只代理指定网站的配置方法见指定域名分流说明；若慢在解析阶段，则继续下一章，不要用更换所有服务器代替 DNS 定位。
DNS 问题：区分服务器域名与目标域名解析
DNS 故障不只有“所有域名打不开”一种表现，也可能是服务器地址无法解析、某个子域名失败、首次打开很慢，或者切换网络后访问异常。先确定失败发生在服务器连接之前还是连接之后：服务器域名解析失败会阻止协议连接，目标域名解析失败则可能发生在隧道已经建立之后。这两个阶段使用的路径和依赖条件不一定相同，不能只修改一处 DNS 就认为覆盖了全部问题。
用错误记录确认解析阶段
对照故障时间，查看错误中出现的是服务器地址还是访问目标。若服务器域名没有得到可用结果，先确认底层网络正常，再核对域名拼写、当前配置的解析设置和系统网络状态。若服务器已连接，只有特定目标失败，则比较该域名在不同姿态下的表现，并查看实际请求是否被规则交给预期策略。域名解析成功只说明取得了地址，不代表地址对应服务一定可达，后续连接仍需单独检查。
不要用“直接输入网站地址能打开”作为唯一验证。许多网站依赖域名选择站点、证书验证和请求头，直接用地址访问失败并不能证明网络不通；某个地址能够响应，也不能证明原域名解析正确。更可靠的方式是保留原域名，在相同目标和相同网络下比较解析与连接记录。若应用提供相关诊断信息，记录结果类型、耗时与错误阶段，不要只截取一个看似异常的地址。
检查解析路径是否形成依赖循环
使用加密解析时，解析服务自身的域名也需要被解析并建立连接。如果解析路径依赖尚未建立的代理，而代理服务器域名又依赖该解析服务，就可能形成相互等待。修改前先画清三步：谁解析服务器域名、谁连接解析服务、谁解析目标域名。优先恢复到已经验证可用的解析配置，再逐项加入自定义设置；不要同时叠加多个解析服务后只凭感觉判断哪个正在生效。
配置文件中的 DNS 参数、系统网络的解析设置以及其他网络扩展可能共同影响结果。应先确认当前生效的 Config，再检查是否有 [Host] 本地映射或其他覆盖项。旧的本地映射会绕过正常解析，把域名固定到已经不适用的地址。若必须保留映射，说明用途并定期复核；若来源不明，先保存副本，再单独停用该映射复测，而不是删除整份配置。
[Host]
example.com = 192.0.2.10
[Rule]
DOMAIN-SUFFIX,example.com,PROXY
IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
FINAL,PROXY以上为结构示例，文档示例地址不应作为实际访问目标。[Host] 可影响域名到地址的映射，域名规则与地址规则则决定后续分流。示例中的 no-resolve 用于避免为了这一地址规则主动触发域名解析，不表示所有请求都不再使用 DNS，也不保证域名会在服务器端解析。不能把这一个选项当作通用 DNS 修复开关，应结合当前规则顺序与实际连接路径解释。
留意双栈网络与缓存变化
同一域名可能返回不同地址类型，当前网络对这些地址的可达性也可能不同。出现某条网络正常、另一条失败时，应对照实际使用的地址类型与连接错误，而不是直接关闭某类网络能力。若只有部分地址不可达，问题可能在路径或服务端，修改解析只是在改变被选择的地址，未必消除了根因。网络切换后短暂异常还可能涉及旧缓存或旧连接，应结束受影响请求后建立新连接再判断。
恢复验证至少包括服务器连接、故障域名和一个原本正常的域名，防止修复局部时破坏其他访问。记录哪项解析设置或映射产生了差异，再恢复临时测试项。配置段作用可查阅[General]、[Rule] 与 [Host] 说明；需要理解域名规则和地址规则的范围时，查看术语手册。解析结果中的地址与访问历史也可能涉及隐私，分享时保留诊断必要信息即可。
耗电异常与更新后异常：围绕最近变更复测
耗电增加和更新后连接变化，都应从时间线开始排查。记录异常何时出现、此前修改了什么、当时使用哪种网络以及是否进行了持续传输。不要因为系统电量列表出现 Shadowrocket，就认定所有耗电都由某项设置导致；VPN 扩展处理其他应用的流量，系统归属方式与使用场景会影响统计。应结合屏幕使用时间、网络活动和可重复的对照观察，避免只比较两个时长不同的百分比。
耗电增加先查重试与持续活动
在相近使用条件下，分别观察稳定连接和故障重连期间的表现。服务器持续失败、网络信号较弱、频繁切换网络，以及其他应用不断请求失败资源，都可能增加网络活动。先检查是否存在重复连接错误，再找反复失败的域名或后台请求。若某个应用在持续同步，暂停其任务后观察变化，比直接关闭全部规则更容易定位。测试不需要耗尽电量，关键是比较相近时段与相近负载。
检查 On Demand 是否与预期一致，尤其是网络条件变化后是否反复触发连接。临时关闭自动触发，手动建立稳定连接并观察，如果异常明显减少，再逐项恢复条件。On Demand 控制连接触发，不等同于流量分流；修改它不能替代规则修复。若连接总在断开后重新打开，先确定是自动触发行为还是失败重连，不要在系统设置与应用之间反复关闭开关却不检查触发来源。
诊断期间保留足够记录即可，结束后恢复日常日志设置，避免长时间保留不必要的详细诊断。设备温度、移动网络信号、热点共享和后台备份都要一并考虑。如果断开连接后设备仍持续发热或耗电异常，应继续检查系统与其他应用。不要以牺牲证书验证、随机修改协议参数或删除系统配置作为省电办法，这些操作没有建立耗电原因与改善结果之间的证据。
更新后异常先确认实际变更范围
应用更新、系统更新、订阅更新和远程配置更新可能发生在接近的时间，但它们改变的内容不同。先确认是界面位置变化、某个条目失效、全部连接失败，还是规则命中发生变化。查看 App Store 的应用说明与更新记录，并核对自己的订阅和配置是否同期变更。应用与系统的兼容性要求以 App Store 页面标注为准，不应根据其他设备的旧截图推断当前设备一定适用。
保留更新前可用配置的副本，与当前内容比较协议参数、策略名称、DNS、本地映射和规则顺序。若同一配置曾被远程更新覆盖，应先核实文件内容，而不是把变化全部归因于应用本身。发现旧字段不再适用时，依据当前应用说明调整；不要为了恢复旧行为，把多个不明参数一次性加回。使用简单测试配置建立基准，有助于判断问题来自配置还是共同运行环境。
恢复顺序从可逆操作开始
先关闭连接并重新打开应用，再使用已核实的服务器与最小配置测试；必要时保存记录后重启设备。若仅原配置失败，逐段恢复并定位触发项；若所有配置都失败，继续检查系统 VPN 状态与网络条件。删除应用会影响本地数据，且重新获取应用不等于自动恢复原有服务器与规则，因此只能在完成备份、确认恢复条件并排除其他原因后考虑。购买恢复说明见已购与重装指引。
验证恢复后，再逐项打开原来的 On Demand、日常配置和后台任务。如果只有恢复某一项后异常重现，就保留这个明确触发条件继续排查；若无法复现，应标记为暂时恢复，继续观察，而不是宣称已经找到根因。
iPad 专项：对照网络、配置与休眠恢复
iPad 与 iPhone 使用同一类排查逻辑，但设备所处网络、系统权限、应用布局和后台使用场景可能不同。不要因为一台设备正常就直接复制全部系统设置，也不要把另一台设备的订阅凭据公开用于比较。先确认两台设备使用的是同一份有效服务资料、同一目标和相近网络条件，再对照结果。应用购买范围、兼容性和系统要求以 App Store 页面标注为准，获取入口说明见iPad 下载与首次打开。
排除“看似相同”的配置差异
逐项核对实际选中的 SERVER、Global Routing 姿态和当前 Config。相同的显示名称不保证内容一致，旧订阅条目可能仍保留相同名称但使用不同地址或参数。比较时应看关键字段与生效文件，而不是只看列表标题。iPad 较宽的布局可能将列表与编辑内容同时展示，保存某项修改后，还要确认它确实成为当前使用对象；不要把编辑视图中的选择误认为连接已经切换。
系统 VPN 授权需要在每台设备上分别确认，另一台设备已经允许并不会替代本机授权。若 iPad 开关立即退回，按第一章检查系统 VPN 配置、其他连接与设备管理策略。学校或工作场景中的 iPad 可能受管理要求约束，出现无法新增、修改或删除配置时，应先联系管理员核实。不要将受管理设备与个人设备的差异直接判断为客户端故障，也不要擅自移除管理项。
Wi-Fi 与热点环境分别测试
仅有 Wi-Fi 连接能力的设备，可以在自己可用的另一条 Wi-Fi 或个人热点上做对照；热点测试会改变底层网络路径，不等于只改变设备。两台设备即使连接同一路由器，也可能处于不同频段、隔离策略或登录状态。先断开 VPN，确认 iPad 已完成网络登录且普通访问正常，再启用连接。如果只有某个 Wi-Fi 失败，保留服务器参数，转查该网络，不要先重建所有条目。
访问打印机、局域网网页或家庭设备失败时，应区分系统本地网络权限与分流规则。若系统要求相关权限，按实际用途检查；规则则需要把真实本地网段交给合适路径。不要假定所有路由器都使用同一个私有网段，应从当前网络信息确认地址范围。域名形式的本地服务还可能依赖局域网解析与发现机制，外部 DNS 返回的结果不一定适合本地访问，不能只靠添加一条宽泛规则处理。
[Rule]
DOMAIN,localhost,DIRECT
IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
IP-CIDR,10.0.0.0/8,DIRECT,no-resolve
IP-CIDR,172.16.0.0/12,DIRECT,no-resolve
FINAL,PROXY上述片段展示私有地址范围与兜底策略的关系，不是要求把它直接覆盖进日常配置。使用前核对当前网络、已有策略和远程服务是否也使用私有地址；若存在需要通过代理访问的私有网络，简单地全部直连会破坏该场景。具体规则应放在更宽泛规则之前，并通过一次真实本地访问验证命中结果。关于首条命中和 FINAL 的含义，可回看规则类型说明。
锁屏唤醒后只检查新增变化
如果连接在锁屏前正常、唤醒后异常，先记录唤醒时网络是否已改变，再查看 On Demand 与连接记录。系统休眠恢复可能使旧连接失效，打开新页面验证比继续等待原页面更可靠。多窗口中某个应用停住，也不代表所有网络都失败；先比较同一设备上的其他访问，再决定是否重建连接。不要把应用从最近任务中反复移除当作维持后台连接的固定步骤。
完成排查后，应能给出明确结论：本机授权问题、配置差异、某条网络限制、局域网分流，或休眠后的连接恢复问题。仍需协助时，整理两台设备的对照条件与遮盖后的错误记录，避免发送整份订阅。恢复日常使用后，回到教程主线重新完成一次连接和分流验证；功能边界与 On Demand 用途可在功能介绍查阅。保留已经验证可用的配置副本，下一次异常即可从同一基准开始。