Shadowrocket
完整使用手册

01 / ACQUIRE

获取与安装：先确认平台和来源

开始配置之前，先把“客户端安装”与“连接服务准备”分开处理。Shadowrocket 是闭源商业应用，安装完成只代表设备具备处理代理连接和规则的客户端，并不自动生成可用服务器。iPhone / iPad 版在 App Store $2.99 一次性付费，Mac / Windows / 安卓 / Linux 版免费；已有订阅的有效期、账号状态和流量限制由原服务决定，与客户端的获取方式是两件事。

iPhone / iPad：核对商店条目

从下载页的 iPhone / iPad 入口进入 App Store，核对产品名 Shadowrocket、开发者 Shadow Launch Technology Limited、官方图标与应用 ID 932747118。不要只凭搜索结果中的名称判断，名称相近不代表同一应用。系统要求以 App Store 页面标注为准；商店页面的兼容性提示应优先于旧文章中的系统描述。

如果商店搜索不到，先检查当前 Apple ID 所属地区以及该地区的产品可用情况。中国大陆商店没有此应用，切换设备的显示语言或系统地区不会直接改变购买账号的店面。需要调整账号地区时，应通过账号设置中的国家或地区流程了解余额、已有订阅和付款方式限制。不要在未理解影响时反复切换账号，也不要把搜索不到误判为安装文件损坏。

电脑与安卓：选择匹配的安装包

其他平台统一从全平台下载页获取，安装包经本站 /dl/shadowrocket/ 路径提供。Mac 先打开“关于本机”，显示 Apple 芯片时选 Apple 芯片版 dmg，显示 Intel 处理器时选 Intel 版 dmg。Windows 选择页面提供的 64 位安装包；安卓选择 arm64 安装包，并确认设备允许安装来自当前浏览器或文件管理器的应用。不要用文件扩展名相似来代替架构判断。

桌面与安卓安装包没有代码签名，首次打开可能受到系统拦截。Mac 遇到“无法验证开发者”，应在确认包来自本站后，到系统设置的“隐私与安全性”中使用“仍要打开”；Windows 出现 SmartScreen 提示时，同样先确认来源，再通过“更多信息”查看是否提供“仍要运行”。这些操作是针对本次文件的判断，不需要关闭整套系统防护；受组织管理的设备应遵循管理员策略。

Mac 如果显示“已损坏”，先删除未完成的下载并重新获取正确架构。确认应用已经放在 Applications 且来源可靠后，才考虑对该应用执行下列命令清除隔离属性。命令会改变系统对这个应用的隔离处理，不能用于来源不明的文件，也不要把路径改成整个磁盘。更多分支见Mac 与 Windows 安装说明。

xattr -cr /Applications/Shadowrocket.app

Linux：发行版格式与执行权限

Debian / Ubuntu 通常使用 deb 并交给 apt 处理依赖，Fedora 系使用 rpm 配合 dnf；AppImage 需要先授予执行权限再运行。命令中的本地文件名必须与实际下载的文件一致，不能从示例推断安装包名称。下载不完整、架构不符、缺少运行依赖是不同问题，应分别查看终端输出。操作细节可查Linux 安装说明。

安装结束后再继续下一章，不要在尚未成功打开客户端时批量导入资料。若换机或重装，iPhone / iPad 使用原购买账号检查已购项目；其他平台重新从本站下载对应安装包即可。保留原有配置的备份比保留某个旧安装包更重要，因为服务器凭据、规则和本地设置不会因重新下载客户端而自动恢复。

02 / PERMISSIONS

首次启动与权限：建立可检查的起点

首次打开 Shadowrocket 后，先观察 Home 中是否已经存在服务器、当前 Global Routing 选择了什么，以及连接开关是否处于关闭状态。此时不必立刻修改所有 Settings。一个容易复现的起点是：系统网络可以正常访问普通网页、客户端尚未连接、没有其他正在工作的 VPN 配置。这样后续出现问题时，能够区分原网络故障与客户端配置问题。

VPN 配置授权的含义

iPhone / iPad 首次建立连接时，系统会请求添加 VPN 配置，并可能要求设备密码或生物识别确认。该授权允许客户端通过系统网络扩展接管相应流量，不等于购买了连接服务，也不表示每一个请求一定通过远端服务器。请求最终走 PROXY 还是 DIRECT，还要由 Global Routing 和当前配置决定。应确认系统提示中的应用名称，再完成设备本地授权。

如果曾经拒绝授权，回到客户端重新尝试连接并观察系统提示。若系统没有弹窗，应检查系统设置中的 VPN 状态以及设备是否受管理策略限制。不要一开始就删除所有网络设置：这可能一并清除已保存的 Wi-Fi 和其他连接资料。先确认客户端是否能请求权限、配置是否能写入，再决定是否需要移除旧的 Shadowrocket VPN 配置后重新授权。

识别网络扩展之间的影响

设备上可能还有其他 VPN、企业接入、网络过滤或系统管理功能。排错时应先停止会接管相同流量的功能，再单独测试 Shadowrocket；是否能够并存取决于系统机制和实际配置，不能仅根据图标判断。删除企业配置或描述文件可能影响工作网络，受管理设备应先联系管理员，不应为了测试直接移除组织策略。

系统状态栏出现 VPN 标记，只能证明系统存在相应隧道状态，不能证明服务器认证、DNS、目标网站和规则全部正常。相反，回到桌面后看不到客户端前台界面，也不表示连接已结束。应同时查看 Home 的连接状态与后续的实际请求记录，而不是把单一图标当作连接成功的全部证据。

相机、照片与本地网络权限按需处理

使用 Scan QR Code 时，相机权限用于读取二维码；若从图片读取资料，还可能需要照片访问。只有采用对应导入方式时才处理这些权限，不使用扫码并不妨碍手动填写 Add Server。授予照片访问时，应优先选择足够完成导入的范围；二维码本身可能包含完整凭据，保存到相册或分享给他人都需要谨慎。

如果系统询问本地网络访问，先判断是否确实需要访问局域网设备或相关网络功能。权限与路由策略不是同一个层面：允许本地网络访问，并不会自动让所有局域网地址走 DIRECT；规则正确，也不能绕过操作系统明确拒绝的访问权限。遇到局域网设备不可达时，应分别检查权限、IP 地址、网段以及当前 Wi-Fi 是否启用了客户端隔离。

保留网络基线，再做一次改动

首次配置前可以记录当前使用 Wi-Fi 还是蜂窝网络、是否需要网页认证，以及普通网页是否能直接打开。公共 Wi-Fi 的认证页面往往需要在连接客户端之前完成，否则系统虽然显示连上无线网络，实际仍没有互联网访问权限。蜂窝网络还要检查应用的网络访问是否受到系统限制，以及当前数据连接是否真的可用。

建议在首次成功前保持 On Demand 关闭，不主动更改复杂 DNS 或其他高级设置。一次只处理一个问题：先让应用获得系统权限，再导入一组已知有效的资料，最后执行连接测试。如果应用在进入后台后状态变化，记录发生时的网络切换和系统提示，再到维护章节查找原因，而不是同时修改多个开关造成新的不确定性。

完成这一章的判断标准是：客户端可以正常打开，系统允许添加 VPN 配置，基础网络能够工作，并且用户知道如何手动关闭连接。若权限仍被阻止，可前往FAQ按“各平台安装与首次打开”分类继续排查；不要带着未完成的权限问题进入规则调试，因为两者的症状可能相似，处理方法却完全不同。

03 / CONNECTION MATERIAL

添加服务器与 Subscribe：区分资料类型

本章以用户已经拥有自己的订阅或服务器信息为前提。先判断拿到的是单条服务器参数、单条分享链接、二维码，还是能够更新服务器列表的 Subscribe 地址。它们可能都以一段文字呈现，但用途不同。把订阅地址填进服务器地址栏，或者把完整分享链接当作密码填写，都不会因为格式看起来像网址而自动转换成正确配置。

Add Server：逐项对应已有参数

手动添加时，从 Home 的添加入口进入 Add Server，先选择与服务端一致的协议，再填写地址和端口。地址可以是主机名或 IP，不应自行附加网页路径；端口必须使用服务端提供的数值。备注只用于本地辨认，不参与认证。密码、UUID、密钥等认证资料要保持原样，注意复制时多出的空格、换行和中文标点。

协议名一致只是第一步。同一个协议还可能使用不同的传输方式、TLS、SNI 或路径，不能凭“服务器能响应”就省略这些字段。SNI 是 TLS 握手中使用的名称，通常不是随意填写的备注；WebSocket 的 path 与 Host 也有各自用途。没有获得相应参数时，应回到原服务资料核对，不要通过关闭证书检查来掩盖字段错误。

分享链接与二维码：导入后仍要检查

使用剪贴板导入或 Scan QR Code，可以减少手动输入错误，但导入成功仅说明客户端能够解析资料，并不证明远端服务仍然有效。导入后打开条目详情，检查协议、服务器地址和端口是否与原资料一致。二维码若被压缩、遮挡或包含多个内容，可能无法识别；这时应重新取得清晰原图或改用原始文字，而不是反复扫描同一张模糊图片。

如果扫描结果是订阅地址，应按 Subscribe 的方式保存，而不是当作独立服务器。扫码入口和字段的具体位置可能随界面调整，但判断依据始终是资料内容。不要把含凭据的二维码上传到公共识别服务，也不要把完整分享链接贴进公开反馈；需要排错时，只描述协议和字段名称，并隐藏认证信息。

Subscribe：更新的是服务器列表

添加已有 Subscribe 时，填写原服务提供的完整地址，保存后执行更新并观察结果。地址中的路径和查询参数可能承担认证功能，删去尾部参数可能使请求失效。更新返回为空、认证失败、格式无法解析和网络超时是不同结果：先确认地址是否完整、是否仍有效，再判断当前基础网络能否访问该地址，最后检查内容是否属于客户端可识别的订阅格式。

首次更新后，记录列表中出现的分组名称和可识别的服务器备注。订阅更新可能增加、删除或重命名条目，因此不宜把更新后的变化全部视为客户端异常。若手动修改了订阅生成的服务器，后续更新可能覆盖修改；确实需要固定参数时，应先建立明确命名的独立条目，同时保留原订阅，避免两份相似资料混在一起无法判断当前选择的是哪一个。

服务器、订阅与 Config 不是同一层

服务器条目描述连接到哪里，Subscribe 管理一组条目的来源，Config 则决定流量怎样匹配规则以及使用哪些策略。只添加服务器并不会自动得到适合所有场景的规则；下载一个 Config 也不一定包含可用的服务器凭据。导入后应分别确认 Home 中的服务器选择与 Config 中的当前配置，而不是看到任意一个列表有内容就认为准备工作全部完成。

最终应得到一个清楚的最小集合：一组有效连接资料、一个能够识别的当前服务器，以及一份知道用途的配置。先不要连续导入多份相似订阅或 Config。重复内容会增加选错条目的概率，也会让失败时难以判断资料来源。若只需要完成首次导入，可回到快速上手按主线操作，保留本章用于核对字段与更新行为。

04 / GLOBAL ROUTING

Global Routing：理解三种处理姿态

Global Routing 决定客户端以哪一种总原则处理流量。配置、代理、直连分别对应界面中的 Config、Proxy、Direct。它们不是三套服务器，也不代表三个服务等级；改变这里的选择，会改变请求是否参考规则以及是否使用代理。开始调规则前，应先确认当前姿态，否则同一份 Config 在不同姿态下可能表现不同，看起来就像规则没有生效。

Config、Proxy、Direct 的边界

Config 是需要精细分流时的常用选择。规则中的 PROXY 一般指向配置定义或客户端当前使用的代理策略，DIRECT 表示直接连接，REJECT 用于拒绝匹配请求。规则里的策略名要能在实际配置中找到对应关系，不能把一个任意备注直接当成有效策略。Proxy 可用于排除规则匹配的影响，但并不能修复密码、TLS 或远端服务错误。

Direct 也不能完全替代关闭客户端的基线测试，因为客户端仍可能参与 DNS 等网络处理。需要判断是不是系统网络本身异常时，应先完整断开，再访问同一目标。对照时应保持同一网络、同一网址和接近的测试时间，不要一边切换 Wi-Fi，一边改变姿态，否则难以知道究竟是哪项变化带来了结果。

规则从上到下检查，先匹配的先决定

规则文件中的顺序具有实际意义。较具体的域名条件通常放在较宽泛的条件之前，FINAL 放在末尾作为兜底。下面示例用于说明语法与顺序：指定域名后缀走 PROXY，局域网地址直接连接，GEOIP,CN 对应的地址直接连接，其余交给 PROXY。示例不是适用于每个网络的完整配置，使用时仍需检查自己的服务与策略定义。

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

DOMAIN 匹配一个明确域名；DOMAIN-SUFFIX 用于该域名及其子域名；DOMAIN-KEYWORD 根据域名中的关键词匹配，覆盖范围更宽，可能命中原本不想包含的站点。IP-CIDR 与 IP-CIDR6 对应地址网段，GEOIP 依赖地址归属数据而非网页语言或网站品牌。选择规则类型时，应先问“现有证据是域名还是地址”，而不是只选择看起来最短的写法。

域名规则、解析与连接记录要一起看

同一个页面可能加载多个域名，正文、图片、登录与接口不一定共用同一主机。只为首页域名添加规则后，部分资源仍走其他策略并不罕见。应通过当前请求记录确认缺失资源的目标，再决定是否补充精确规则；直接用很宽的关键词兜住整个页面，虽然改动少，却可能把无关域名也纳入代理范围。

地址规则有时需要解析结果才能匹配；示例中的 no-resolve 用于限制该地址规则主动触发域名解析的行为，不代表关闭全部 DNS。DNS 缓存、应用复用旧连接和目标使用多个地址，都可能影响观察结果。修改规则后应重新发起测试请求，必要时关闭目标应用再打开，避免用修改前建立的连接判断修改后的配置。

如果目标是“少量网站走 PROXY，其余 DIRECT”，应把指定域名条件放在前面，并使用 FINAL,DIRECT 作为末尾规则；这与上面的兜底示例方向不同，不能同时照抄两种结尾。完整案例见DOMAIN-SUFFIX 与 FINAL 规则写法。配置保存后保留一份可工作的旧副本，发生误匹配时先回退，再逐条缩小条件。

05 / VERIFICATION

连接与验证：从系统状态到实际请求

服务器资料和路由方式确定后，再开始第一次连接。先在 Home 选择一个能明确辨认的服务器，确认 Global Routing 与测试目标一致，然后打开连接开关。首次连接按系统提示完成授权。不要在开关刚变化时立即判断失败；应给连接建立和首个请求留出合理时间，同时观察客户端是否出现明确错误，而不是不停开关制造更多重连。

把验证拆成三层

第一层是系统是否成功启动 VPN 配置；第二层是客户端是否能够和选定的服务端建立有效通信；第三层是目标网站的实际请求是否按预期完成。前一层成功不会自动保证后一层成功。VPN 状态存在但网页打不开，可能是认证、DNS、TLS、远端出口或规则问题；开关马上关闭，则应先检查系统权限、配置可加载性与应用给出的错误。

测试时先选择一个自己熟悉、可以反复访问的普通网页，再选择当前规则应走 PROXY 的目标。使用 Config 时，还应验证一个预期 DIRECT 的目标，以确认不是所有请求都被同一种策略处理。页面曾经打开过可能来自缓存，建议刷新并观察新请求；仅看到已缓存的标题或图片，不能作为当前网络已经连通的证据。

Connectivity Test 能说明什么

Connectivity Test 的结果依赖实际测试方式。能够测得响应，通常说明相应测试请求在当时有结果，但不意味着所有协议特性、目标站点或长时间传输都正常。延迟小也不等于吞吐量高；链路带宽、拥塞、远端负载和应用访问的具体路径都可能影响使用体验。不同测试方式的数值不应直接混在一起排名。

应先在自己的已有服务器中选少量条目，使用相同方式重复测试，再打开实际需要的网站观察。若某条目测试失败而网页正常，检查测试目标和方法是否被限制；若测试成功但网页失败，则继续检查 DNS、规则与目标站点。关于数值的边界，可查延迟测试与节点选择说明，不要把单个数字当作唯一依据。

按错误所在层逐步排除

如果所有目标都失败，先断开客户端确认基础网络可以工作，再核对服务器地址、端口和认证信息。遇到 TLS 错误，应核对系统时间、证书对应名称和 SNI，而不是直接跳过验证。使用依赖 UDP 的协议时，还需要考虑当前网络对 UDP 的可用性；某个网络失败不能直接证明资料错误，可以在允许的另一种网络上保持相同参数进行对照。

如果仅有一个网站异常，优先查看该目标的规则与请求结果，不要先更换整份 Config。网页返回的服务端错误、账号登录限制和地区内容差异，也不一定是客户端连接失败。应把“连接无法建立”“请求超时”“收到网站拒绝响应”分开记录；这三类现象分别指向不同的排查方向。

网络切换后的复测

从 Wi-Fi 切换到蜂窝网络时，旧连接可能需要重新建立，正在传输的请求也可能中断。先等系统网络稳定，再刷新目标；仍失败时手动断开并重连一次，然后重新观察。不要在网络刚切换的几秒内同时修改服务器、规则和 DNS，否则无法确认恢复究竟由哪项操作引起，也无法稳定复现。

一次有效验证应能复述为：在某种网络下，使用某个服务器与某种 Global Routing，某个目标按预期策略建立新请求并完成响应。保留这样的描述比一句“能用”更有价值。若排查后仍无法定位，可到FAQ按故障类型继续查阅，同时准备经过脱敏的错误文本、网络类型和复现步骤，不公开订阅地址或完整服务器凭据。

06 / DATA

Data：用流量与请求记录解释现象

Data 的用途是帮助观察客户端处理过的流量与连接，而不是替代服务端账单。进入 Data 后，应先看当前界面展示的是实时连接、请求记录还是汇总数据，并留意统计范围。上传、下载、连接数量和一次请求的持续时间描述的是不同维度；如果不先确认单位与范围，容易把一段时间的累计值误读成当前瞬时速度。

客户端统计与订阅用量可能不同

本地统计可能受到重连、清理、应用重启和统计起点影响，服务端则按自己的周期与计费口径记录。协议额外开销、失败重试和其他设备使用同一服务，也可能造成两边数字不完全一致。因此，不能简单用本地下载量推断订阅剩余流量；剩余用量应以原服务提供的记录为准，客户端中的统计主要用于理解本机处理行为。

上传与下载的方向通常以设备为观察点：设备向外发送为上传，接收内容为下载。打开网页不只有下载，DNS、TLS 握手、请求头和确认数据都会产生发送量；视频播放也可能包含缓存预取。停止在页面上操作后还有少量流量，并不直接说明异常，需要先看是否仍有后台应用、同步或持续连接。

从目标、策略和结果建立证据链

排查规则时，先在记录中找到刚刚发起的目标，再看可用的目标域名或地址、命中规则、最终策略与连接结果。不同界面能提供的字段可能不同，以当前记录实际内容为准。目标字段出现 IP 不意味着网站没有域名；应用可能直接使用地址、复用缓存，或在客户端可观察的环节没有保留域名信息。

一个网页通常包含多条连接，不能只看最上方的一条就判断整个站点的策略。可以在测试前关闭无关应用，清楚记下开始时间，然后只刷新一次目标页面。若需要清理记录，应先保存关键现象；清理用于减少干扰，不会自动修复服务器或 DNS。记录量减少后，再检查失败资源是否与主页面采用不同域名和策略。

常见现象的解释方法

同一域名出现多个地址可能来自负载均衡、不同解析结果或多个资源连接，不应立即逐个写死 IP 规则。固定地址可能随服务变化而失效，也可能影响共用地址的其他站点。优先使用能够准确描述目标的域名规则，只有在明确理解地址范围用途时再用 IP-CIDR，并在修改后重新观察命中结果。

连接持续很久但流量很少，可能是等待事件的长连接；流量突然增多，也可能来自系统同步或应用预取。判断异常应结合发起应用、目标和操作时间，而不是仅凭连接持续时间或总量。若停止某个应用后现象消失，再重新打开该应用能够复现，就比盲目删除规则更接近原因。

超时记录说明请求没有在相应等待条件内完成，但原因可能在本地网络、服务端、目标站点或返回路径。认证错误、解析失败与超时也应分开看。可使用上一章的分层方法，先验证基础网络，再保持参数不变对照另一服务器或网络；Data 提供的是现象证据，不会自动替用户决定是哪一方出了问题。

记录隐私与反馈范围

请求记录可能暴露访问域名、局域网地址、使用时间及应用行为。分享之前只截取与故障直接相关的部分，并隐藏订阅地址、认证资料和私人目标。即使没有显示密码，完整访问记录也可能包含敏感信息。不要为了求助直接导出整段历史；通常目标类型、策略、错误文本和复现步骤已经足够开始定位。

日志或详细记录需要的存储与处理资源会随数量增加。完成一次排错后，应回到适合日常使用的记录级别，并根据当前界面提供的方式清理不再需要的历史。清理前若想比较修改效果，应先把两次测试条件记下来；否则仅凭后来较小的统计数字，无法证明新配置更有效。

本章的目标不是让每条请求都被人工检查，而是在遇到问题时能够抽取少量可复现证据。完成“发起一个明确请求—找到对应记录—解释策略与结果”的闭环，就可以回到日常使用。若目标本应走 PROXY 却命中 DIRECT，应回到 Global Routing 章节；若策略正确仍失败，应回到连接验证章节。

07 / SETTINGS

Settings：按问题调整，不批量套用

Settings 中的选项影响范围不同，有些属于应用偏好，有些会改变网络行为，还有些设置也可能出现在 Config 文件中。开始修改前，先记录原值，确认当前启用的配置以及该设置是否被配置覆盖。不要把一张他人的设置截图当成通用答案：网络环境、服务端参数和规则目标不同，相同开关组合可能产生相反结果。

DNS：先弄清谁在解析

DNS 将域名映射为地址，它的结果会影响后续连接和地址规则。排错时应区分“域名没有得到可用结果”和“得到地址后连接失败”。若直接使用 IP 能建立相应测试，而域名请求失败，才更有理由继续检查解析链路；同时还要考虑 HTTPS 的证书名称要求，不能把访问任意 IP 的结果直接等同于原网站访问结果。

本地解析与经代理访问解析服务有不同路径，具体采用哪种行为要结合当前 Config 和设置判断。修改 DNS 后应重新发起请求，并留意缓存与旧连接。不要一次加入很多解析服务器期望自动解决问题；先确认每个地址的用途、网络可达性和配置语法，再保留能够说明原因的最少改动。

加密 DNS 保护的是相应解析链路，不意味着所有应用连接都会变成代理，也不替代 TLS 对目标连接的保护。局域网中的内部域名可能依赖当前网络提供的解析服务，随意改成外部解析会导致内部资源失效。公司、校园或家庭存储场景应分别验证内部域名与普通网站，避免只测试一个公网目标。

On Demand：自动触发与路由分开理解

On Demand 用于根据条件触发连接行为，而 Global Routing 决定连接后怎样处理请求。设置自动连接不会自动生成分流规则，关闭某条规则也不一定关闭 On Demand。首次使用时先完成手动连接验证，再添加一个容易理解的触发条件，例如针对指定 Wi-Fi 环境的处理；不要同时叠加多组条件后再猜测哪一组生效。

如果手动关闭后又自动连接，首先检查 On Demand 及系统相关自动连接状态，不要立刻重装应用。多个网络条件存在时，应逐项阅读条件的匹配范围与顺序；Wi-Fi 名称要与当前网络一致，蜂窝条件要在实际切换后验证。更多例子见On Demand 按需连接设置。

TLS、UDP 与 IPv6 的调整边界

TLS 相关问题应优先核对系统时间、SNI、服务端证书及传输参数。关闭证书验证会改变安全边界，不应作为常规提速或通用修复步骤。服务器更换域名后，旧的 SNI 或证书名称可能不再合适，应回到原资料更新，而不是保留旧参数再不断放宽检查。配置中的服务器地址与 TLS 名称不一定相同，但必须符合服务端的明确要求。

UDP 是否可用同时受到协议能力、服务端配置与当前网络影响；客户端某个选项打开并不能让所有网络自动具备 UDP 通路。IPv6 也不只是一个孤立开关：设备、解析结果、网络出口与规则都可能参与。若只有返回 IPv6 地址的目标异常，应先保存对应记录并做受控对照，避免直接把所有连接问题都归因于 IPv6。

MTU 一类参数会影响分组大小与传输路径，通常不应在首次配置时随意调整。只有在特定网络出现稳定复现的传输问题、并有相应依据时才逐步测试。每次只改变一个值，并记录修改前后的网络与目标；随意采用网络上的固定数字，可能暂时改变现象，却使其他连接受到影响。

应用偏好与网络设置分别记录

显示、排序和测试偏好主要影响操作体验，DNS、路由和连接相关设置则直接影响请求。建议分别记录这两类改动。为整理列表而修改备注，与修改服务器地址是不同性质的操作；排错时先检查最近改变的网络项，再考虑界面偏好，不要因为列表顺序变化就认定服务器资料被重置。

若某项在当前界面中不存在，不要在其他页面中强行寻找同名开关，先查看它是否属于当前 Config 的参数或服务器详情。不同平台和界面可能有不同组织方式，本手册不把固定位置作为唯一依据。能够说明设置作用、影响范围和回退方法，才算完成该项调整，而不是仅仅把开关改成与他人相同的状态。

08 / MAINTENANCE

日常维护：保留有效配置与故障记录

稳定使用后的维护重点不是频繁修改设置，而是知道哪些资料会变化、哪些内容需要备份、故障发生时怎样回到已知可用状态。服务器列表、Config、应用偏好与系统 VPN 权限属于不同层次，任何一层发生变化都可能影响体验。建立简单的维护习惯，可以避免把服务到期、订阅更新和规则改动混在一起处理。

订阅更新与配置更新分别确认

更新 Subscribe 后，先看是否成功取得内容，以及常用服务器是否被删除或重命名。不要只根据列表条目数量判断更新质量：原服务可能调整节点安排，而本地保留的旧条目也可能仍然显示。若更新后连接异常，先核对当前选中项是否还是有效服务器，再检查认证参数和服务状态，不必马上重置整个应用。

Config 更新可能改变规则、DNS、策略名称或其他设置，影响比单纯更新服务器列表更广。更新前保存当前可工作的副本，更新后先用几个固定目标验证 PROXY、DIRECT 和局域网行为。若策略名称变化，原先关联的选择也可能需要重新确认。自动更新可以减少手动操作，但不能替代对重大配置变化的了解。

备份需要包含用途与敏感范围

至少应知道自己使用哪一份 Config、常用服务器来自哪个已有订阅，以及做过哪些本地修改。按当前界面提供的导出方式保存时，应确认文件是否含服务器密码、订阅地址、密钥或其他认证资料；配置文件即使只是纯文本，也可能具有与账号密码相近的敏感性，不应放入公开目录或公开分享。

备份名称宜表达用途，例如“日常分流”“调试前副本”，而不是仅用容易混淆的数字。恢复时先导入副本，检查其是否仍引用存在的策略与服务器，再手动建立连接。旧备份中的服务端参数可能已经失效，因此“成功导入”不等于“恢复后必定可用”；仍要按连接验证章节重新测试。

应用更新、换机与重装

iPhone / iPad 的应用更新通过 App Store 处理，重新获取时先检查原购买账号的已购项目。iPhone / iPad 版在 App Store $2.99 一次性付费，Mac / Windows / 安卓 / Linux 版免费；这两档客户端获取方式不改变连接服务的独立性。换机前先保存自己的配置与订阅资料，不能假设安装应用后所有本地内容都会自动出现。

电脑与安卓需要更新时，从下载页重新获取对应平台安装包，并按照安装放行说明处理系统提示。Mac 更新仍要区分 Apple 芯片与 Intel；Linux 继续选择适合当前发行版的包格式。更新前关闭客户端并保存本地修改，更新后先确认旧配置是否保留，再进行必要的导入，避免重复创建多份相同内容。

建立一份可复现的故障描述

故障记录可以按五项组织：发生时使用的网络、选中的服务器、Global Routing、受影响的目标类型、客户端给出的错误。再补充最近是否更新 Subscribe、Config 或应用，以及关闭客户端后基础网络是否正常。这样的记录能够明确排查入口，比“突然不能用”更容易区分权限、资料、路由与远端问题。

按固定顺序检查：先基础网络，再服务器有效性，再当前配置与命中策略，最后才是高级设置。临时切换 Proxy 可以帮助隔离规则，但验证结束后应恢复自己的日常姿态。若必须多次切换网络才能偶尔成功，记录每次条件而不是只保留成功的一次；间歇性故障尤其需要对照样本。

• 可复现：同一条件下重复出现，优先缩小到最少的改动与目标。
• 仅某网络出现：保留参数不变，对照其他允许使用的网络。
• 仅更新后出现：恢复上一份有效配置，再逐项比较变化。
• 仅某目标出现：查看目标请求与策略，不先重置全部资料。

清理与回退的完成标准

长期不用的独立服务器和重复配置可以清理，但应先确认它们是否仍被某个策略引用。删除前保留必要备份，删除后重新验证常用场景。订阅生成的条目若会再次更新出现，应从来源管理角度处理，而不是反复手动删除。退出使用某项服务时，也应清理其中的凭据副本和不再需要的二维码图片。

回退成功的标准不是列表恢复原样，而是能够在明确网络下重新完成目标请求，并解释其路由方式。确认正常后关闭临时详细记录，恢复日常需要的 On Demand 条件，保留最终有效 Config。后续遇到同类问题时先复用这套检查顺序；需要短流程时查快速上手，需要具体问答时查FAQ，不要每次都从删除全部配置开始。