Shadowrocket 疑难解答

先从本站下载页打开 App Store 产品页，确认应用 ID 为 932747118，再看当前账号所在店面是否提供该应用。搜索名称本身不足以确认可用性。需要核对地区时，进入系统 Settings，打开 Apple Account 的 Media & Purchases，再进入 View Account 查看 Country/Region；名称随系统语言可能不同。调整地区前，先阅读 Apple 对余额、订阅及付款方式的提示。

同时核对三项：开发者为 Shadow Launch Technology Limited，图标与本站页头的官方图标一致，产品页地址含 id932747118。不要只看相似名称或搜索结果的位置。进入详情页后，再核对价格与兼容性；系统要求以 App Store 页面标注为准。本站下载页集中列出这些信息，确认后再通过 App Store 完成购买。

先用原购买账号登录 App Store，在账户中的已购应用记录里查找 Shadowrocket，符合恢复资格时可重新下载。若仍显示价格，先核对购买记录、当前登录账号和店面地区，不要急着重复付款。界面中的列表名称可能随系统版本变化。重新取得应用与恢复原配置是两件事，已有订阅、服务器信息和配置文件应另外备份，恢复资格以 App Store 页面标注为准。

客户端一次性买断 ≠ 线路套餐。购买取得的是 Shadowrocket 客户端的使用资格，连接仍以用户已有自己的订阅或服务器信息为前提。导入后还需核对参数、选择服务器并完成系统授权。美区定价为 $2.99，以商店页面为准；其他店面按当地货币显示。本站不提供、不销售、不推荐节点或订阅，应用购买与已有线路服务分别管理。

Shadowrocket 可在 iPad 上通过同一 App Store 产品页获取。先登录购买时使用的账号，再检查商店显示的是下载按钮还是价格；设备兼容性、系统要求及通用购买资格以 App Store 页面标注为准。iPad 的可用显示空间与 iPhone 不同，但仍需分别核对当前服务器、Config 和连接授权。购买资格不等于配置自动同步，换设备后应检查已有信息是否完整。

先确认设备在关闭连接时能正常访问网络，再准备用户已有自己的订阅或服务器信息。在 Home 导入信息或通过 Add Server 填写参数，确认条目已出现并选中需要使用的服务器，然后检查 Global Routing。首次开启连接时按系统提示添加 VPN 配置，最后访问一个明确的目标页面验证结果。先完成单个服务器的验证，再调整规则，便于确定问题发生在哪一步。

这是系统允许应用创建 VPN 配置的授权步骤，与购买是否成功是不同事项。确认提示来自刚刚打开的 Shadowrocket 后，按屏幕要求完成允许及设备身份验证，再返回应用检查连接状态。若此前取消，可再次尝试开启连接。如果设备受组织管理，配置权限可能受到限制，应检查系统中的管理设置，并向设备管理员核对，不要反复删除其他用途的配置。

先看应用或系统是否显示具体错误，再确认已选择有效服务器并完成 VPN 配置授权。检查是否有其他 VPN 连接正在使用，以及设备管理是否限制配置。接着关闭连接，重新打开应用，只尝试当前选中的一个服务器。如果仍失败，记录错误文字、发生步骤与当前网络类型；不要同时重置网络、删除配置和改动多个参数，否则难以判断是哪项变化影响了结果。

配置（Config）按当前配置文件的规则决定策略，代理（Proxy）让相关流量使用所选代理策略，直连（Direct）用于直接连接。需要规则分流时选 Config，并确认 Config 中实际启用的文件。排查时可对同一目标分别测试不同姿态，记录结果后恢复日常设置。Global Routing 与规则中的 PROXY、DIRECT 不是同一层级，不能仅凭某条规则推断所有流量的去向。

先按英文界面词定位：Home 查看服务器与连接，Add Server 添加服务器，Config 管理配置文件，Settings 查看设置，Global Routing 选择连接姿态。官方手册保留这些词的英文原文，中文只解释用途。不同设备和系统设置可能影响文字显示，不必为了语言差异重装应用；找不到项目时，先确认当前页面和应用内实际提供的选项，再对照教程继续操作。

先确认粘贴的是用户已有的完整订阅地址，而不是账户管理页面或说明页面，并检查首尾空格、换行和参数是否遗漏。再确认当前网络能够访问该地址，以及订阅是否仍有效、返回格式是否适用于应用的导入入口。若报错，记录状态或错误文字，不要连续重复提交。订阅地址可能包含访问凭据，排查时应遮盖完整地址中的敏感部分，不要把它放进公开截图。

先核对协议类型，再逐项检查服务器地址、端口及该协议要求的认证信息。若已有信息还包含 TLS、Server Name、传输方式或路径，应按原始资料逐字填写，不要根据名称猜测。显示名称只用于辨认，不决定连接能力；地址栏也不应混入说明文字。每次只修正一个字段并保存测试，确认设备日期时间正常，同时保留原始资料供对照，不要公开密码或其他认证内容。

先确认二维码承载的是用户已有的服务器或订阅信息，而非普通网页入口。使用 Scan QR Code 时检查相机权限、画面清晰度和二维码边缘是否完整。识别成功后仍应打开条目核对协议与必填字段，不能把识别成功等同于配置正确。若原资料同时提供文本信息，可改用对应导入方式或 Add Server 逐项填写，再比较关键字段，避免反复扫描同一张不完整图片。

更新前先记下当前选中的服务器和订阅分组，必要时备份配置。更新后核对条目是否仍属于原订阅，再检查原选中项是否被移除、改名或替换；名称变化不一定表示连接信息相同。若更新失败，先看错误提示并检查地址有效性，而不是不断删除重加。订阅内容更新与 Config 文件更新分别管理，完成更新后应重新选择有效条目并测试，不要假定原选择始终保留。

服务器条目保存某个连接所需的协议和认证参数，订阅用于批量取得或更新用户已有的服务器信息，Config 文件则描述规则、DNS 等配置行为。导入订阅成功，不代表已经启用合适的 Config；切换 Config，也不等于更新服务器凭据。排查时先确定问题属于连接参数还是规则行为，再进入对应位置修改。重要配置应单独备份，并在恢复后核对实际启用的文件与服务器。

先关闭连接验证本地网络，再开启连接访问同一个目标，区分基础网络与代理路径问题。随后核对当前服务器、Global Routing 和实际启用的 Config，再查看目标请求对应的规则与错误信息。若只有部分域名失败，优先检查规则和 DNS；若多个目标都失败，再检查服务器参数及网络环境。每次只改一项，并记录改动前后结果，不要直接把配置全部替换掉。

Connectivity Test 的结果只说明所选测试方式在当时完成了相应探测，不能同时证明域名解析、认证、规则选择和目标访问都正确。先确认测试对象与当前选中的服务器一致，再查看失败网页对应的实际请求。若连接探测有结果而域名访问失败，应继续核对 DNS；若只有特定目标异常，则检查规则策略及目标本身的可用性。延迟数值适合做线索，不应作为唯一判断依据。

先确认 Global Routing 为 Config，并核对正在使用的配置文件，而不是只编辑了另一个文件。规则从上到下逐条匹配，命中后使用对应策略；具体条件应放在较前位置，FINAL 放在 [Rule] 段最后。检查目标是否先被更宽泛的 DOMAIN-SUFFIX、GEOIP 或 IP-CIDR 条件命中，再确认 PROXY、DIRECT、REJECT 是否符合预期。修改后重新发起请求验证，避免沿用已有连接判断。

先确认是多个域名都失败，还是单个域名异常，再核对当前 Config 的 [General] 段及应用内实际生效的 DNS 设置。查看是否存在不可达的自定义解析地址、Host 覆盖或影响解析请求的规则。备份原设置后，只调整 DNS 相关的一项并重新测试；使用 DNS over HTTPS 也需要解析服务地址本身可达。不要把连接成功或单次延迟正常直接当作 DNS 正常的证明。

先在系统电池设置中查看对应时段的用量，同时比较屏幕使用、网络环境和实际传输情况；耗电占比不等于应用独自造成的额外耗电。再检查 On Demand 条件是否频繁触发连接，以及网络切换时是否反复重连。可在相似使用场景下比较开启与关闭后的表现，再保留符合需要的条件。On Demand 用于控制按需连接，不保证必然省电，也不能替代对异常网络活动的检查。