Shadowrocket 订阅与服务器管理手册

先区分订阅、服务器与 Config

三类对象解决不同问题

开始操作前，先把 Shadowrocket 中经常同时出现的三类对象分开理解。服务器条目是一组可直接建立连接的参数，通常包含协议类型、服务器地址、端口、认证信息和传输选项。订阅是一条更新入口，客户端读取后可以生成一组服务器条目；它适合维护由同一份已有数据派生出的多个服务器。Config 则负责规则、策略和 DNS 等行为，它决定请求应匹配哪条规则，以及匹配后交给 PROXY、DIRECT 或其他策略处理。服务器能否连接和流量如何分配是两个层面，不能用更换 Config 代替修正错误的端口，也不能用重复刷新订阅修复不适用的规则。

在 Home 中看到的服务器列表，是日常选择连接目标的位置；Subscribe 用于保存与更新订阅；Add Server 用于录入单个服务器；Config 用于选择或编辑规则配置；Global Routing 决定当前采用配置、代理还是直连姿态。界面在 iPhone 与 iPad 上的排列可能不同，但这些英文名称代表的功能关系不变。若某一入口的位置与本文描述略有差异，应按当前应用内可见的同名项目查找，而不是按屏幕坐标机械点击。

录入之前先保留原始资料

无论使用 Subscribe 还是 Add Server，都应先保存一份未改写的原始资料。对于订阅，至少记录用途、完整地址和最近一次确认可用的状态；对于单个服务器，至少记录协议名、主机、端口、认证字段、TLS 状态、传输方式和备注。不要只依赖截图，因为长地址、大小写、路径与查询参数容易在截图中被截断。也不要在录入前自行删除看似多余的字符：URL 中的斜线、问号、井号和百分号可能承担结构意义，改动后仍能保存并不代表含义保持不变。

建议先用少量条目完成验证，再扩展到完整列表。验证顺序是：确认设备时间与网络正常，录入一个服务器或一条订阅，执行连接测试，选择目标条目，最后检查 Global Routing 与 Config。这样出现问题时，变量数量较少，能够判断错误是在原始参数、订阅解析、服务器连接还是规则分流层。若尚未核对应用来源，可先查看App Store 正版核验说明；Shadowrocket 的开发者为 Shadow Launch Technology Limited，应用 ID 为 932747118。

Subscribe 录入与更新策略

新增订阅时先核对地址完整性

在 Shadowrocket 中进入 Subscribe 后新增项目，通常需要填写订阅地址，并可按界面提供的字段设置名称或更新行为。粘贴之前先检查地址首尾是否带有空格或换行。聊天工具、邮件和网页在复制长文本时可能把句末标点一并选中，也可能只复制屏幕上显示的省略版本。正确做法是从用户已经保存的原始资料中复制完整内容，粘贴后将光标移动到开头和结尾核对，不要凭肉眼只看中间的域名部分。

名称应描述用途或范围，而不是写成“订阅一”“新订阅”这类以后难以辨认的文字。名称只用于本地整理，不会修复地址内容。若同一地址被重复添加，更新后可能出现看似相同的服务器组，给选择和排错增加干扰。因此新增前应先查看 Subscribe 列表，确认是否已经存在用途、域名和路径均相同的项目。地址中的认证参数即使只差一个字符，也应视为不同数据，不宜通过手工合并来猜测。

名称：工作日常
地址：https://example.com/sub?token=xxxx
更新前检查：
1. 开头为 https://
2. 结尾没有空格、句号或换行
3. token 参数完整
4. 未重复保存同一地址

手动更新、自动更新与失败保留

订阅更新的实质，是客户端重新读取远端内容并据此调整该订阅关联的服务器条目。日常维护时，先使用手动更新观察结果更稳妥：更新后查看服务器数量是否出现明显异常、原有备注是否变化、当前选中条目是否仍然存在，并对准备使用的条目重新测试。自动更新适合数据维护已经稳定的场景，但不应把更新频率设得过密。过于频繁的请求不会提高连接质量，反而可能让列表在排错过程中持续变化，使同一次问题复现失去一致条件。

当一次更新失败时，不要立即删除订阅或连续反复点击。先区分失败发生在哪一层：如果浏览器访问普通网页也不正常，应先恢复当前网络；如果只有该订阅更新失败，应核对地址是否被截断、设备时间是否正确，以及地址中的认证内容是否发生变化；如果更新提示成功但服务器列表为空，则需要回到原始资料核对返回内容是否仍符合客户端可解析的格式。一次失败不等于本地已有条目全部失效，在删除前应先确认现有条目是否仍可测试和连接。

更新完成后，应把“刷新成功”和“服务器可用”分开判断。刷新成功只说明客户端取得并处理了数据，不代表每个服务器都能建立连接；反过来，某个服务器超时也不一定说明订阅地址错误。先在 Subscribe 确认更新状态，再到服务器列表执行 Connectivity Test，最后在选中条目后进行实际连接验证。分层检查能够避免把连接故障误判成订阅故障。

更新前后的可控变更

订阅管理的一个常见难点是更新会覆盖由该订阅生成的内容。若直接修改订阅条目下的服务器名称或字段，下次刷新后这些本地修改可能被远端数据替换。需要长期保留的个人备注，应优先放在独立记录中；需要实验的参数，应复制为单独的手填服务器后再修改，并在名称中标明“测试副本”。这样订阅仍保持原样，实验结果也不会被下一次更新打断。

若更新后出现大量重复项，先不要逐条删除。应先判断是同一订阅重复添加、多个订阅包含相同服务器，还是远端备注变化导致视觉上相似。前两种情况应从 Subscribe 层整理，后一种情况则要比较协议、主机、端口和认证字段。关于重复条目的系统化处理，可继续阅读多订阅整理章节；若页面提示难以判断，可在疑难解答中按“订阅与节点导入”分类查阅。

Add Server 手填字段与核对顺序

先选择协议，再映射字段

Add Server 适用于用户已经持有单个服务器的完整参数，并且希望逐项录入或建立独立测试副本的情况。第一步不是填写地址，而是选择正确的协议类型。Shadowsocks、VMess、VLESS、Trojan、HTTP、SOCKS5、WireGuard 与 Hysteria2 的认证模型不同；字段名称偶尔相似，含义也不能互换。选择错误类型后，界面仍可能允许保存，但连接阶段会因握手、认证或传输结构不匹配而失败。

填写时建议遵循固定顺序：协议类型、服务器地址、端口、认证字段、TLS 或加密相关选项、传输方式、路径与 Host、备注。每填完一组就回到原始资料逐字核对。服务器地址可为域名或 IP 地址，应原样填写，不添加协议前缀，也不要把端口重复拼到地址字段。端口只填数字；名称或备注可以自定，但不要让备注覆盖对原始参数的记录。

认证、TLS 与传输字段不能独立猜测

认证字段通常区分大小写。UUID 中的连字符、密码里的符号、密钥中的大小写都属于内容本身，不应自动改写。复制后若连接失败，可以先删除字段并重新粘贴一次，以排除不可见空格。对于 TLS、SNI、Host、Path、Transport 等字段，应把它们视为一组相互关联的参数：原始资料明确给出时逐项对应，没有给出时不要凭其他服务器的经验补值。尤其是 Host 与 SNI，虽然某些配置中内容可能相同，但两者作用层次不同，不能因为字符一致就认为可以任意替换。

Transport 选择也必须与原始资料一致。选择 WebSocket 等传输方式后，界面可能出现 Path、Host 等附加字段；这些字段只有在对应传输方式下才有意义。如果原始资料使用另一种传输，照搬其他条目的 Path 不会产生兼容效果。编辑旧条目时，先确认协议与 Transport，再检查附加字段是否因切换选项而被保留。必要时新建测试副本，从空白状态重新填写，能够排除旧字段残留造成的干扰。

保存后的最小验证闭环

完成填写后先保存，但不要立刻批量录入其余条目。回到 Home，找到刚添加的服务器，执行可用的 Connectivity Test 或延迟测试。测试有响应后，点选该条目，使其成为当前服务器，再检查 Global Routing。首次验证建议使用 Config，并确认当前 Config 中存在可理解的规则；若只想排除规则影响，可在明确测试目的后临时比较 Proxy 与 Direct，但测试结束应恢复预期姿态。Global Routing 的三种姿态分别是配置、代理、直连，对应界面词 Config、Proxy、Direct。

测试超时时，按字段顺序反查，不要一次修改多个选项。先核对地址和端口，再核对认证字段，随后检查 TLS、SNI 与 Transport，最后确认设备时间和当前网络。每次只修改一项并重新测试，才能知道哪项变化真正产生影响。如果参数全部逐字一致仍无法连接，应保留原始条目和测试记录，避免为了尝试而覆盖唯一一份准确数据。协议基础字段的进一步说明可参阅Shadowrocket 支持哪些协议。

Scan QR Code、剪贴板与分享链接

扫码导入前先确认二维码内容

当已有服务器信息被编码为二维码时，可以使用 Scan QR Code 读取。二维码只是文本的另一种承载形式，本身不会提高参数正确性。扫描前应确认二维码属于当前要导入的那条服务器资料，并避免把含有认证内容的二维码展示在公开环境。识别完成后，不要仅凭“导入成功”就直接连接，应打开新条目检查协议类型、服务器地址、端口和备注是否符合预期。

若二维码来自另一台个人设备的屏幕，应适当提高屏幕亮度并保持镜头稳定；识别困难时，优先使用原始分享文本，而不是反复对模糊图片进行裁剪。二维码边缘被截断、图片压缩过度或中央被遮挡，都可能导致无法识别。无法扫描属于读取层问题，不代表其中的服务器参数无效。读取成功但测试失败，则应转到参数层核对，尤其关注协议类型、认证内容和 Transport 附加字段。

剪贴板导入要处理空格与多行文本

从剪贴板导入适合处理单条分享链接或应用能够识别的结构化文本。复制时应从方案标识开始选到最后一个字符，避免前后混入说明文字。若一段消息同时包含标题、序号和多条链接，建议逐条复制，不要依赖客户端自动猜测哪一行属于有效数据。导入后立即清理剪贴板也更稳妥，因为分享链接可能携带服务器地址与认证信息。

某些文本工具会把长链接自动换行。视觉上的换行不一定是真实换行，但从富文本中复制时可能插入空格或换行字符。出现“可以识别协议但无法连接”的情况，应将链接粘贴到可信的本地纯文本编辑区域检查结构，再与原始资料对照。不要通过删除中间字符来试错；查询参数和编码字符缺失后，链接可能仍能被识别，却生成不完整的服务器条目。

分享链接是参数容器，不是长期备份格式

常见分享文本会以前缀表示协议类型，后续部分承载地址、端口、认证和备注。不同协议的结构不相同，不能把一个协议的链接前缀改成另一个协议来完成转换。下面仅展示结构辨认方式，内容均为不可用示例。实际操作必须使用用户自己已经持有的完整资料。

ss://[email protected]:443#Example
vmess://ENCODED-DEMO-DATA
vless://[email protected]:443?type=ws&security=tls#Example
trojan://[email protected]:443?security=tls#Example
hysteria2://[email protected]:443?insecure=0#Example

链接末尾的备注通常用于显示名称，经过百分号编码后可能不易阅读；这不影响协议主体，但手工改写时应避免破坏前面的查询参数。若导入结果中备注乱码，可以在确认连接参数完整后只修改本地名称，不要同时改动地址或认证字段。对于 VMess 等采用整体编码的形式，不宜手工拆分后重新拼接；更稳妥的做法是使用原始链接导入，再在服务器详情页核对各字段。

分享链接适合在受控范围内从一台个人设备转移到另一台个人设备，但不适合作为唯一备份。它可能遗漏客户端中的本地备注、排序、Config 和其他管理信息，也可能因复制不完整而失效。长期保存应同时保留原始参数说明、订阅地址记录和 Config 文件，并注明各自用途。若需要把单个条目交给另一台个人设备，生成或显示二维码时应注意周围环境，使用后及时关闭显示页面。

多订阅分组、命名与重复条目整理

先按来源边界管理，再按用途命名

当 Subscribe 中只有一两项时，默认名称似乎也能使用；数量增加后，含义不清的名称会直接影响更新和排错。建议名称至少表达用途、设备场景或数据边界，例如“日常主组”“临时测试”“旧配置核对”。不要把服务器地区、协议和订阅用途全部塞进一个超长名称，详细信息可以保存在独立记录中。名称的目标是让用户在更新前知道这一操作会影响哪一组服务器。

整理时应以订阅为管理边界，不要先在混合服务器列表中逐条移动。先打开 Subscribe，确认每一项的地址、名称与最近一次手动更新结果；再回到服务器列表观察各组生成的条目。若某条订阅已经不再使用，可以先停用其更新行为或记录状态，经过一段确认后再删除。直接删除会让关联条目和历史判断依据同时消失，不利于区分“确实不再需要”与“暂时更新失败”。

重复条目需要比较关键字段

显示名称相同不一定代表服务器完全相同。判断重复时至少比较协议、服务器地址、端口和认证标识；涉及 TLS 或 Transport 时，还应比较 SNI、Host、Path 与相关选项。只有这些关键字段一致，才可以把它们视为连接意义上的重复项。相反，名称不同但关键字段一致，可能只是不同订阅为同一服务器设置了不同备注。

发现重复后，先追溯它们分别属于哪条订阅。若由同一订阅重复添加造成，应保留地址准确、更新正常的一项，再移除重复的 Subscribe 记录；若来自不同订阅，应根据日常维护边界决定保留方式，而不是盲目删除所有同地址条目。不同订阅中的相同服务器可能在后续更新时走向不同，今天重复不代表未来始终重复。若只是想让 Home 更易阅读，可以通过清晰命名、排序和减少失效组来改善，不必为追求零重复而破坏订阅结构。

建立稳定的整理节奏

多订阅管理不需要每天重排。更实用的节奏是：新增时命名并手动更新，更新后抽查主要条目，出现异常时保留测试记录，确认失效后再删除。排序可以帮助日常选择，但排序结果不是服务器质量的永久结论；网络环境、测试目标和时间变化都会改变延迟。若每次测试后都大幅重排，反而会让熟悉的位置不断变化。

建议保留一份简短的本地清单，记录订阅名称、用途、是否自动更新、最近一次人工核对结果和关联 Config。清单不必复制完整认证信息，只用于说明管理关系。对于需要实验的新订阅，可先放在独立名称下，完成更新、抽查与实际连接后再纳入日常组。这样即使实验数据存在重复或字段异常，也不会立即打乱稳定列表。

批量整理前应暂时避免同时修改 Config。服务器列表与规则同时变化后，连接异常很难判断来自哪一层。先让订阅与服务器条目稳定，再检查 Global Routing 和 Config；或者先固定服务器，再单独测试规则。多订阅整理的目标不是让列表看起来最短，而是让每条记录的来源边界、更新方式和用途能够被再次理解。

Connectivity Test、延迟排序与故障定位

测试结果只回答当前测试条件

Connectivity Test 与服务器列表中的延迟测试用于快速判断当前设备、当前网络和当前时刻能否与目标建立相应测试连接。结果适合筛查明显超时的条目，也可辅助排序，但不能代表所有应用流量的长期表现。测试目标、协议握手、网络拥塞和无线信号都会影响结果，因此一次较低的数值不等于永久更稳定，一次超时也不应立即作为删除依据。

进行批量测试前，先确保设备没有处于网络切换状态。若设备正在从移动网络切换到无线网络，或无线网络刚完成重新连接，批量测试容易出现整组超时。等待网络稳定后再测，并尽量让屏幕保持在前台。第一次结果异常时，可以间隔片刻进行第二次测试；若只有少数条目持续超时，再进入单条参数检查。

按范围判断故障层级

测试结果最有价值的信息不是单个数字，而是失败范围。全部服务器同时超时，优先检查当前网络、系统时间和 Shadowrocket 的连接状态；同一订阅下全部超时，而其他订阅正常，应检查该订阅更新后的共同字段或数据状态；只有单个服务器超时，则优先核对该条目的地址、端口、认证和传输参数。若测试有响应但打开目标内容失败，应继续检查当前选中服务器、Global Routing、Config 规则和 DNS，而不是重复编辑订阅地址。

排序用于选择，不用于替代验证

按延迟排序后，列表会把本次测试响应较快的条目放在靠前位置。排序适合从大量已有服务器中缩小候选范围，但连接前仍需确认协议参数和用途。部分条目可能对测试响应较快，却不适合当前 Config 中的使用方式；也可能因短时抖动在两次排序中位置变化。建议先按延迟筛出少量候选，再逐个进行实际连接验证，而不是每次都默认选择第一项。

对多订阅列表执行批量测试时，可以分组进行，避免一次结果过多而难以观察。记录持续超时的条目后，先检查它们是否共享同一地址、协议或订阅；共同特征往往比单条数值更能说明问题。确认某条长期失效前，应至少在网络稳定时复测，并核对最近一次订阅更新是否成功。删除是最后一步，不应作为第一次超时的即时处理。

连接成功但分流结果不符时

如果服务器测试正常，总开关也已连接，但某个域名走向与预期不同，问题通常位于规则层。先确认 Global Routing 当前是否为 Config；若处于 Proxy，规则列表不会按 Config 姿态决定每个请求；若处于 Direct，则服务器条目不会承担当前流量。处于 Config 后，检查规则从上到下的匹配顺序，确认更具体的 DOMAIN、DOMAIN-SUFFIX、IP-CIDR 等规则是否被更早的宽泛规则覆盖，并检查 FINAL 的最终去向。

若所有域名都表现异常，还应检查 Config 是否选中了预期文件，以及配置内引用的策略名称是否存在。规则写着 PROXY，但配置中对应策略没有可用服务器时，规则语法正确也无法得到预期结果。连接失败的完整排查次序可参阅节点超时与连接失败检查清单；首次连接的最短验证流程可参阅首次连接教程。

删除、备份、恢复与设备迁移

删除前判断对象层级

Shadowrocket 中的删除对象可能是单个服务器、整条 Subscribe 记录或一个 Config，它们的影响范围不同。删除单个手填服务器只影响该条本地记录；删除由订阅生成的条目后，后续更新可能再次生成；删除 Subscribe 则会失去该组数据的更新入口；删除 Config 会影响规则选择，但不会自动删除服务器。执行前先确认当前位于哪个列表，并查看名称、地址和关联用途。

对于暂时超时的条目，建议先标记或记录，不要立即删除。对于准备移除的订阅，应先保存完整地址和用途说明，再确认其他订阅未依赖同一管理安排。对于准备删除的 Config，应先检查当前是否正在使用它，以及是否存在本地修改。删除完成后若发现误判，只有在保留原始资料的前提下才能准确恢复；依靠记忆重新填写长地址或复杂规则容易产生新的错误。

备份应覆盖四类资料

完整的管理备份至少包含四类内容：订阅地址记录、手填服务器参数、Config 文件，以及用于解释这些资料关系的简短清单。只保存订阅地址不能覆盖独立手填条目，只导出 Config 也不会自动包含全部服务器认证信息。备份前应清点 Home、Subscribe、Config 和 Settings 中与迁移相关的可见项目，按对象分别处理。

若当前应用界面提供 Data、Import from Cloud JSON 或相应的导入导出入口，应先阅读界面提示，确认它处理的数据范围。不要把“能够导入某种 JSON”理解为所有设置均会自动恢复。完成导出后，应在不覆盖现有数据的前提下检查文件是否生成、名称是否可识别，并记录导出时的用途。备份文件和订阅地址都可能包含敏感内容，应放在受控的个人存储位置。

换设备时按顺序恢复

在新 iPhone 或 iPad 上恢复时，应先通过 App Store 的已购记录取得 Shadowrocket，再逐层恢复数据。购买与已购恢复方式可查看换机与恢复购买说明。系统要求始终以 App Store 页面标注为准。应用准备完成后，先导入一个 Config 或保留默认状态，再恢复一条订阅并手动更新，随后测试一台服务器。确认基本链路正常后，再加入其余订阅和手填条目。

不要在首次打开后一次性导入全部资料并立即覆盖现有内容。分批恢复可以让错误停留在较小范围：订阅无法更新时，只需检查该订阅；服务器无法测试时，只需核对该条参数；分流不符时，再检查 Config。若使用 Import from Cloud JSON，导入完成后也应逐项抽查，不能只看条目数量。名称、排序和当前选中状态可能与旧设备不同，这些差异不一定意味着参数丢失。

恢复完成后进行三轮检查。第一轮检查 Subscribe 是否可以手动更新；第二轮检查主要服务器的 Connectivity Test 与实际连接；第三轮检查 Global Routing 为 Config 时，常用域名是否按规则进入预期策略。随后再检查 On Demand 等自动连接行为，避免在基础连接尚未确认时引入额外变量。旧设备上的资料应保留到新设备完成稳定验证之后，再按个人数据管理计划处理。

建立可恢复而非只可收藏的记录

有效备份的判断标准不是“文件存在”，而是能够说明如何恢复。为每份 Config 写明用途，为每条 Subscribe 记录写明对应名称，为手填服务器保存字段清单，并记录恢复后的验证步骤。若只收藏一个没有说明的长链接，数月后很难判断它应放入 Subscribe 还是作为单个服务器导入，也难以确认是否仍属于当前使用范围。

配置发生重要调整后，应重新保存副本，但不必用大量近似文件覆盖存储。可保留“当前稳定”“修改前”“实验中”三类状态，并避免在文件名中放入认证内容。实验成功后，把确认过的版本设为当前稳定；实验失败则回到修改前副本。这样的版本区分是个人资料管理方式，不依赖客户端显示的应用版本，也不会因为界面调整而失去意义。

Config、Global Routing 与规则分流

理解三种 Global Routing 姿态

服务器管理最终需要与流量策略配合。Global Routing 中的配置、代理、直连分别对应 Config、Proxy、Direct。Config 按当前配置文件中的规则逐条判断；Proxy 让请求统一交给当前代理策略；Direct 让请求直接连接。日常使用规则分流时应选择 Config。Proxy 与 Direct 更适合用于明确目的的对照测试，例如判断异常是否来自规则层，但测试结束后应恢复预期姿态。

规则按照从上到下首次匹配

Config 中的规则通常按书写顺序处理。请求满足某一条规则后，就执行该条指定的策略，不再继续寻找后面的规则。因此更具体的规则应放在更宽泛的规则之前。例如单个 DOMAIN 规则应位于覆盖范围更大的 DOMAIN-SUFFIX 之前，局域网 IP-CIDR 规则应位于 FINAL 之前。FINAL 负责接住前面未匹配的请求，通常放在规则列表末尾。

DOMAIN 精确匹配完整域名；DOMAIN-SUFFIX 按域名后缀匹配；DOMAIN-KEYWORD 按域名中的关键字匹配，范围通常更宽；GEOIP 按目标 IP 的地理数据库结果判断；IP-CIDR 与 IP-CIDR6 分别用于地址网段；USER-AGENT 按请求标识匹配。规则右侧的 PROXY、DIRECT 或 REJECT 是处理策略，不是服务器协议名称。PROXY 需要能够解析到可用策略或服务器，DIRECT 表示直接连接，REJECT 表示拒绝请求。

[Rule]
DOMAIN,api.example.com,DIRECT
DOMAIN-SUFFIX,example.com,PROXY
DOMAIN-SUFFIX,apple.com,DIRECT
DOMAIN-KEYWORD,media,PROXY
IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
IP-CIDR,10.0.0.0/8,DIRECT,no-resolve
IP-CIDR6,fe80::/10,DIRECT,no-resolve
GEOIP,CN,DIRECT
FINAL,PROXY

示例展示的是语法关系，不代表适合所有网络环境。实际 Config 应根据用户自己的使用目标和已有配置进行核对。修改前先复制一份原文件，修改后每次只调整少量规则。若同时移动大量规则、改写策略名并更换 DNS，出现异常时几乎无法定位。可以先增加一条具体 DOMAIN 规则验证匹配，再逐步扩展到 DOMAIN-SUFFIX 或其他范围更大的类型。

服务器名称、策略名称与规则目标要对应

规则末尾写 PROXY 并不意味着任意服务器都会自动可用。Config 中的策略名称需要与实际存在的策略结构对应，策略内部还要能选到有效服务器。若订阅更新后某些服务器名称变化，手工引用具体名称的策略可能需要重新检查。较稳定的做法是让规则指向清晰的策略名称，再由策略管理服务器选择，而不是在大量规则中分散写入具体服务器名称。

遇到“Connectivity Test 正常但规则不生效”时，按以下顺序检查：Global Routing 是否为 Config；当前选中的 Config 是否正确；目标域名是否被更早规则匹配；规则末尾策略名是否存在；该策略内是否有可用服务器；FINAL 是否过早出现。可以临时增加一条范围很小的 DOMAIN 规则进行验证，确认后再决定是否扩展。排查期间不要同时刷新所有订阅，避免服务器列表变化干扰规则测试。

Config 的修改、导入与回退

修改 Config 前应保留原始副本，并为测试副本设置能够辨认的名称。导入新的配置文件后，先检查分区名称、规则段和 FINAL，再选择少量已知域名进行测试。不要仅因为文件能够被导入就认为所有策略引用都有效；语法可读取与策略可执行是两项不同检查。若应用提示某个策略名称无法解析，应回到配置内容确认拼写和对应分组。

规则调试应保留回退路径。每次修改前记录当前稳定副本，修改一组规则后立即测试，并写明修改目的。若结果不符，恢复上一份稳定副本，而不是继续叠加临时规则。对于来源不同的 Config，不建议直接把两个完整文件首尾拼接，因为相同分区、同名策略、重复 FINAL 和不同 DNS 设置可能相互覆盖。需要合并时，应逐段理解后处理，并在每个阶段验证。

完成服务器与 Config 管理后，日常维护可以收敛为固定流程：按需要更新 Subscribe，抽查主要服务器，保持清晰命名，使用 Config 姿态连接，出现异常时按网络、订阅、服务器、规则四层定位，重要调整前保存副本。需要只看首次连接步骤时，返回Shadowrocket 使用教程；需要集中查看问题分类时，进入疑难解答。