Shadowrocket 订阅与服务器管理

01 / 导入可更新的列表

Subscribe 入口与对象关系

先分清订阅、服务器和配置文件

订阅是一份可重复获取的服务器列表，服务器是一条具体的连接记录，配置文件则决定请求如何匹配规则以及交给什么策略。三者有关联，却不是同一件事。订阅更新成功，只说明列表已经获取和解析，不等于选中的服务器可连接；服务器能够连接，也不表示当前配置已经按预期分流。排查之前先确认正在处理哪个对象，才能避免把规则问题误当成订阅问题。

在 Home 查看当前服务器以及所属订阅，在 Config 管理配置相关对象。按本手册的操作主线，进入 Config 查找 Subscribe 入口；如果当前平台把订阅添加合并到 Home 的加号入口，则在 Add Server 中选择 Subscribe 类型。不同平台的入口层级可能有差别，判断依据应是表单的类型和 URL 字段，而不是照着另一台设备的按钮位置盲点。

添加之前确认链接的用途

订阅地址从你的服务商处获取。先阅读随链接提供的说明，确认它用于 Shadowrocket 的服务器订阅，而不是账号管理页面、说明页面或完整规则配置。浏览器能打开某个网址，并不能证明客户端能把返回内容解析成服务器列表。若链接中含有身份参数，应完整复制，不要删掉问号后的内容，也不要把聊天软件附加的标点一并带入。

https://example.com/sub?token=xxxx

在 Subscribe 表单内填写便于识别的名称和完整 URL，再保存并执行更新。首次导入期间保持当前网络稳定，等待结果后返回 Home，核对是否出现服务器记录、记录数量是否符合你已有信息的范围、名称是否可读。这里不以某个固定数量作为成功标准；只要服务端调整列表，结果就可能变化，因此应以自己的授权内容和服务端说明为准。

用结果区分失败阶段

保存后没有服务器，先判断客户端是否实际请求过地址。名称存在而列表为空，可能是获取失败、返回内容为空或格式无法解析。若提示认证问题，检查链接是否已被替换、到期或复制不完整；若返回网页内容，确认拿到的是订阅接口而不是登录页。不要把同一个失败地址连续添加成多个订阅，这只会产生多个需要清理的空分组，不能改变请求结果。

当部分记录出现、部分记录缺失时，应检查缺失记录的协议与参数是否被当前平台支持，以及订阅是否原本就只返回部分内容。此时先保留能正常读取的结果，记录失败现象，再对照已有服务器资料。不要为了让列表看起来完整而自行补写未知密码、端口或传输参数；这些字段需要与服务端一致，猜测出来的记录即使能保存，也未必能建立连接。

已经有服务器记录但连接结果异常时，不必立即删除订阅重建。先选定其中一条，完成后文的单条测试，再检查 Global Routing。这样可以把“列表获取”和“流量使用”拆开验证。第一次操作需要连续步骤时，可转到使用教程；本页后续章节则按字段、更新和整理分别说明，适合带着具体问题回查。

02 / 核对单条记录

Add Server 手填字段与协议参数

先选 Type，再按原始资料填写

手填适合你已经掌握完整服务器信息、需要隔离一条记录进行排查的情况。在 Home 打开 Add Server，先选择 Type，再填写该类型出现的字段。协议选择会改变后续表单，因此不要先把所有资料填入默认表单，最后才切换类型。保存前逐项对照原始资料，尤其检查复制时是否带入空格、换行、全角冒号，以及端口是否被误写进地址字段。

Address 通常填写服务器域名或地址，Port 单独填写端口，不要在 Address 前面添加网页协议前缀。域名与访问网页时使用的路径不是同一概念，路径应放到对应传输设置中。对于 IPv6，应区分分享链接中的方括号表示法和表单实际要求；如果表单已把地址与端口拆开，就不要再把整段“地址加端口”粘进去。名称只用于识别，不能修正连接参数。

相似字段不代表可以互换

Shadowsocks 的加密方法与密码需要同时匹配，不能仅凭密码相同就认为配置正确。VMess、VLESS 常涉及 UUID，但同一个 UUID 不代表两种协议可以互换；传输方式及其附加字段也必须对应。Trojan 的认证信息应填入对应密码字段，HTTP 与 SOCKS5 则要核对是否启用了账号认证。没有提供的可选项目，应先保持默认，而不是从其他记录中复制一组看似完整的设置。

TLS 开关、SNI、Host 和 Path 各有作用。Address 决定向哪里建立连接，SNI 用于加密握手中的服务端名称，Host 可能属于应用层请求信息，Path 则用于相应传输路径。它们有时看起来一样，但这种一致不能推导成通用规则。若原始资料给出不同值，应分别保留；不要为了表单整齐而强行统一，也不要把网页中显示的跳转域名直接写成 SNI。

Hysteria2、WireGuard 等类型还可能需要特定认证或密钥资料。只有订阅已经正确提供这些参数，或你持有完整的服务端配置时，才适合添加。遇到无法确认的字段，先回到原始资料核对其含义。为了通过保存而填写任意字符，只能生成一条外观完整的记录，并不能证明协议已经配置好。不同协议的基础差异可查阅协议概览。

用最小改动定位字段错误

保存后先选择这一条服务器进行测试，暂时不要同时调整 DNS、规则和连接模式。若测试失败，按地址解析、端口连接、认证、传输参数的顺序排查。地址错误常表现为无法解析，端口或网络问题可能表现为连接超时，认证和握手失败则需要继续看具体提示。错误提示只能缩小范围，不能代替逐字段核对；例如连接被拒绝，既可能是端口填错，也可能是服务端没有监听。

需要修正参数时，每次只修改一个能说明原因的项目，并记下修改前后的值及结果。手填记录最好使用“手动”之类的明确名称，与订阅生成的条目区分。若只是为验证某个参数，先复制记录再改副本；确认有效后再决定是否保留。不要在不清楚更新行为时直接改动订阅条目，否则下一次列表刷新可能恢复原值，让已经完成的排查失去对照。

03 / 从现有内容建立记录

Scan QR Code 与剪贴板导入

先判断二维码实际承载什么

二维码是一种承载文本的方式，不是一种独立协议。它可能包含单条服务器分享链接，也可能包含订阅地址或普通网页。打开 Scan QR Code 后，应先看识别结果和待保存对象，确认它与自己的资料一致。扫描成功只表示图像中的文本被读出，不能证明目标地址可用，更不能证明其中的认证信息仍然有效。不要把扫描提示出现等同于服务器已经连接。

从另一块屏幕扫描时，尽量让完整二维码进入取景区域，避免反光、遮挡和过度缩放。若需要相机权限，只在使用扫描入口时按系统提示授权即可；权限被拒绝时，可以到系统对应应用权限中检查。已经持有二维码图片的用户，应优先使用当前界面提供的图片识别入口；若当前平台没有该入口，使用原始文本导入通常比反复调整图片更直接。

如果识别结果是订阅地址，应将它作为 Subscribe 来源保存，而不是填到服务器 Address。若识别出的是单条服务器，保存后检查 Type、Address、Port 与认证字段。一个二维码通常对应它承载的那段内容，不应因为画面上还有其他文字，就认为客户端已经读取了旁边的全部说明。尤其要留意二维码下方另列的密码、备注或传输要求，它们可能不在编码内容里。

剪贴板导入要保留边界与编码

剪贴板导入适合你已复制完整分享链接的情况。先从原始消息复制链接本身，再使用 Home 或添加菜单中显示的剪贴板导入入口。系统询问是否允许粘贴时，确认内容来自刚才的复制操作后再允许。若没有出现预期记录，先检查剪贴板是否已经被其他复制动作覆盖；不要把导入失败直接归因于协议不受支持，实际内容可能只剩标题或一段说明文字。

聊天软件可能把长链接折行显示，但视觉换行不一定是实际换行。复制后需要区分两者：如果文本中真的插入了换行或空格，协议解析就可能在中间截断。也要检查开头是否少了协议前缀、结尾是否多了中文句号，以及链接是否被富文本包装成了显示名称。面对无法确认的复制结果，应重新从原始文本获取，而不是逐字猜着补齐被截断的部分。

批量文本导入时，先确认当前入口支持多条记录，再使用结构清晰的内容。把一整篇包含标题、解释和多个链接的消息全部复制进去，可能造成误识别或只处理第一条。首次可以只导入一条，核对字段后再处理其余内容。如果已经导入过同一批资料，再次执行前应查看现有列表，避免把重复记录误认为订阅更新增加了服务器，后续测试和排序也会更容易辨认。

导入后做三项复核

第一项核对记录类型，确认 Subscribe 没有变成单条服务器，单条服务器也没有被误存为普通 URL。第二项核对关键字段，尤其是密码、UUID、SNI 和传输路径；第三项核对归属，确认记录是在预期分组中，而不是混进另一个订阅。完成这三项后再测试连接，可以把文本识别与实际通信分成两步，便于判断错误出在导入过程还是服务器本身。

扫码后出现不认识的域名或与原始资料不符的参数，应停止保存并重新核对来源内容。已有订阅链接属于访问凭据的一部分，不适合转发到公共群组或提交到公开识别页面。排查时可以描述“二维码能识别但保存为空”等现象，无须把完整内容交给他人。需要展示图片时遮住二维码本身，仅遮挡旁边文字并不能隐藏编码在图案中的链接。

四种导入方法的适用入口可配合订阅导入方式说明查阅。完成导入后若记录数量不符，回到本页第一章检查订阅对象；如果只有其中一条失败，则进入第二章逐项检查参数，避免反复扫描同一张图片而增加重复项。

04 / 识别文本结构

分享链接格式与 Config 边界

协议前缀只说明起点

分享链接通常以协议前缀开头，后面承载地址、认证、传输参数与备注。不同协议的编码方式不同，即使前缀相同，也可能存在参数表达差异。识别前缀有助于选择入口，但不能只看开头就判断整条链接正确。实际导入后应回看字段，确认客户端理解出的内容与你原有资料相符；如果参数被忽略，外观上仍可能出现一条记录，却无法按预期连接。

链接中的查询参数常用于表达传输方式、加密连接或额外设置，井号后的部分常用于备注。备注里的中文、空格和特殊符号可能经过百分号编码，认证部分也可能使用 Base64。不要为了让文本更容易阅读而手动解码后再粘回，也不要重复编码已经编码的部分。某些字符在不同位置有不同含义，一次不必要的替换就可能改变完整链接的结构。

不要把订阅、分享链接和规则互相替代

订阅 URL 指向一份可更新内容，单条分享链接通常描述一个服务器，Config 则描述连接之外的行为。收到一个以 HTTPS 开头的地址时，应结合原始说明判断它返回什么，而不是一律按 Subscribe 添加。收到带有节名与规则行的文本时，也不要把它当成多条服务器链接导入。它们可以协作，但保存位置和更新机制不同，错误入口无法把内容自动转换成另一种对象。

[General]
bypass-system = true

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

这段内容是用于说明语法的规则片段，不包含服务器认证信息。DOMAIN-SUFFIX 匹配域名后缀，IP-CIDR 匹配地址范围，FINAL 处理前面未匹配的请求。规则通常自上而下判断，先命中的规则决定处理方向，因此更具体的匹配应放在宽泛兜底之前。示例中的 PROXY 需要有可用的代理选择，不能因为写了这一策略名，就认为已经自动添加服务器。

Global Routing 中的配置、代理、直连分别对应 Config、Proxy、Direct。使用 Config 时，当前配置的规则才是排查重点；使用 Proxy 时，应先看所选服务器能否工作；使用 Direct 时，请求不会因为列表中存在服务器就自动交给它。测试订阅是否可用时，要把当前姿态一起记录，否则同一份列表在不同模式下得到的访问结果可能完全不同。

分享前先检查凭据暴露范围

服务器分享链接可能包含完整密码或 UUID，订阅地址可能具有持续获取列表的权限。把内容变成二维码、缩短显示名称或编码，并不会改变其敏感性质。需要在自己的设备之间迁移时，应使用受控的传递方式，并确认接收设备可信；需要求助时则优先提供协议类型、错误提示与脱敏字段，不应把完整可连接记录直接放进公开截图。

当一条链接在不同入口导入后的字段不一致，保留原始文本和两份解析结果进行对照。先检查是否发生截断、转义或编码变化，再确认相关参数是否被当前平台识别。不要把缺失字段一律归结为链接失效，也不要随意删掉不认识的查询参数。能说明每个改动的原因，比凑出一条能够保存的长链接更重要；无法确认时应回到原始资料核对格式。

05 / 控制列表变化

订阅更新策略与失败恢复

把更新看作一次有边界的替换

订阅更新是客户端重新请求来源、解析返回内容并刷新相关记录的过程，不是给所有条目重新测速，也不是更新 Shadowrocket 应用。服务端可能增加、删除、重命名服务器，客户端则按自身的匹配方式处理现有记录。开始前应知道哪些信息来自订阅、哪些是自己修改的，尤其是备注、当前选中项和用于规则引用的名称，避免更新后无法判断变化是否正常。

第一次使用先执行手动更新，确认能稳定获取内容，再考虑当前平台提供的自动更新设置。自动更新间隔不应只是追求越短越好；频繁请求并不能修复错误地址，还可能触发来源端的请求限制。若没有自动更新选项，按需要手动刷新即可。无论使用哪种方式，都应在重要使用场景之前留出检查时间，不要在必须保持连接的过程中同时更换来源和大批量更新。

更新前后的四个检查点

更新前记录来源名称、当前选中服务器、是否存在手动修改以及当前网络状态。更新后先看是否提示成功，再看列表是否出现明显变化，接着确认选中项仍存在，最后执行单条连接测试。记录数量变化不必立即视为错误，但突然变空或大量名称异常时，应暂停继续操作。保留原始来源和已有备份，比立即删除后重建更有利于判断变化发生在服务端还是本地。

如果你曾在订阅条目上直接修改参数，更新可能覆盖这些修改。确有必要长期保留的修正，适合做成独立手动记录并注明用途，同时保留原订阅用于对照。不要依赖某次更新恰好没有覆盖备注的现象，推断所有字段都会被永久保留。不同字段与不同平台的处理方式可能不同，应以一次受控更新的实际结果确认，而不是在大量条目上同时试验。

按获取、认证和解析分层排查

更新超时时，先确认设备当前网络能够工作，再判断订阅请求是否依赖某条已经失效的代理路径。订阅获取所走的路径与普通网页访问路径未必相同，应查看当前平台提供的相关设置。可以在可控环境下切换网络后重试，但不要一次同时更换网络、规则和来源链接，否则即使更新成功，也无法知道是哪一个因素改变了结果，下一次失败仍难以复现。

出现认证失败或访问被拒绝时，检查地址是否完整、身份参数是否被重置、来源是否仍对你的账号有效。遇到请求过于频繁的提示，应停止重复刷新，等待适当时间后再按来源说明操作。若返回登录页、提示页或空内容，客户端可能表现为解析失败；这与服务器列表中的某条节点超时不同，需要回到订阅请求本身处理，不能通过修改单条服务器端口来修复。

同一个来源以前可更新、现在却无法解析时，应核对返回格式是否改变，以及复制的新链接是否指向不同用途的接口。不要把某个网页保存为本地文件后就认作有效列表，也不要从其他格式中任意拼接字段。保留错误原文、发生时的网络环境和是否所有来源都失败这三类信息，通常比反复重装更有帮助。只有一个来源失败时，优先检查该来源，不必清空全部订阅。

更新完成后检查配置引用

服务器名称变化可能影响你依赖名称进行识别或选择的习惯，涉及自定义策略时还应检查引用关系。更新后能看到记录，但访问突然走到另一条线路，应同时核对当前选中项与 Config，而不是仅看列表顶部的名称。对于长期使用的规则，尽量把依赖关系写清楚，并保留可以恢复的配置副本。订阅维护和规则维护分开处理，可以减少一次更新引发多处变化的风险。

06 / 保留清晰归属

多订阅整理与本地修改边界

名称要说明归属，不只说明位置

管理多个已有订阅时，首先给来源取稳定、可区分的名称。名称可以按个人用途或资料归属组织，不必把完整 URL 放进标题，更不要把密码或身份参数写在备注里。服务器备注则用于辨认单条记录，可以保留原始名称并加上简短说明。来源名称与服务器名称承担不同层级的任务，分清它们后，查找失败范围、处理重复和删除整组内容都会更准确。

初次整理不要立刻合并所有来源。先逐个确认能否更新、列表大致范围以及是否有独立手填条目，再决定显示顺序。多个来源中出现相同名称，不代表它们是同一条服务器；名称不同，也不代表地址与认证一定不同。管理上的重复应结合来源归属、协议、地址、端口及关键参数判断，不能只凭列表中的一行文字批量删除，更不应为了名称一致而改动认证信息。

区分远端维护内容和本地维护内容

订阅生成的记录适合交由来源更新维护，手动建立的记录适合承载你明确掌握的独立信息。如果需要临时调整某个订阅条目进行测试，应先复制或建立清楚标识的副本，并记录改动原因。这样既能保留原始记录作参照，也能避免下一次更新覆盖测试参数。测试结束后及时清理无效副本，否则它们容易与真实可用记录混在一起，形成看似丰富却难以维护的列表。

分组、收藏和排序等功能应以当前平台实际提供的选项为准。没有独立收藏功能时，可以通过明确备注与来源归属完成基础整理，不必虚构一个额外管理层。也不要把列表视觉顺序当成策略优先级：把某条服务器拖到最上方，通常不等于 Config 会自动选择它。真正影响请求去向的是当前选择、Global Routing 与配置中的策略关系，需要分别检查。

重复清理先检查差异

同一地址与端口可能对应不同协议、不同认证或不同传输参数，不能仅凭这两项相同就认定完全重复。反过来，同一条分享链接被反复导入，也可能因为备注不同而出现多项。清理时先比较关键字段，再看是否同属一个来源。确认是重复后，优先保留能被正常更新、归属明确的一项；涉及手动修正时，先把修正原因记入自己的维护记录，再决定删除哪一份。

若某个来源暂时无法更新，但已有服务器仍可用，可以先保留并注明当前状态，而不是立即移除。若来源已经停止使用，应检查是否还有配置引用其中的名称，以及当前连接是否正依赖这一组。整理应在有恢复条件的情况下进行，避免把“暂时失败”“重复”和“确实不再需要”三种情况混成同一类。逐组处理比一次全选更慢一些，却能保留可解释的变更过程。

跨设备保持规则，不追求列表外观一致

同一订阅在不同设备上可能因为平台能力、显示方式或本地手动条目不同而呈现不同列表。管理目标应是来源正确、关键参数一致、选择逻辑明确，而不是强求每台设备的行数和顺序完全相同。迁移后先检查原始来源，再检查单条记录，最后检查 Config。若某种协议在目标平台出现字段差异，应对照当前界面和原始资料处理，不要把另一台设备的截图当成唯一表单标准。

07 / 解释测试结果

Connectivity Test、延迟与排序

先知道测试测到了哪一步

延迟结果来自一次具体测试，不是对服务器整体质量的永久评价。不同测试可能只检查端口连接，也可能通过代理访问某个目标；测试协议、目标地址、当前网络和并发数量都会影响结果。使用 Connectivity Test 或列表测试功能前，先查看当前平台提供的测试方式与设置。只有测量条件接近，结果才适合比较，否则把两种不同测试的数值放在一起排序容易得出错误结论。

端口能够连接，并不保证认证成功，也不保证目标网站可以经由代理打开。相反，某个测试目标无法响应，也不必然说明所有访问都不可用。遇到“测试有结果但网页失败”的情况，应继续检查认证、TLS、传输设置、DNS 与规则；遇到“测试失败但实际访问正常”的情况，应先检查测试目标及其访问路径。不要仅凭一个符号就删除记录，先确认测试覆盖了哪个环节。

建立可重复的比较条件

先选一条已知能够工作的记录作为对照，在同一网络、相近时间内测试其余候选。测试期间尽量暂停大流量任务，避免设备正在下载或同步而影响结果。批量测试可以缩小范围，但大量并发会增加本地网络和服务端压力；得到明显异常结果时，再对少量候选单独重测。一次测得较低延迟只能说明当时那个目标响应较快，不能直接推导成持续传输速度更高。

切换 Wi-Fi 与移动网络后，原先排序可能不再适用，因为接入路径和解析环境都变了。与其每天保存一张固定“最快”列表，不如保留少量用途明确的候选，并在实际环境变化后重新检查。记录测试条件时，可以写网络类型、所用测试方式和大致现象，不需要在公开记录中附上完整地址和认证内容。可复现的现象比孤立的一次结果更有排查价值。

排序和实际选择是两件事

按延迟排序只改变展示顺序，不应默认理解为已经切换当前服务器。排序后回到 Home，明确查看当前选中的记录，再开始验证访问。若配置使用策略组或其他选择逻辑，还要检查该策略最终指向哪一项。列表第一行、当前选中项和某条规则所用策略可能是三个不同对象，忽略这种区别，就会出现“明明选了快的却没有变化”的误判。

测试规则分流时，可以先用 Proxy 验证所选服务器的基本连接，再回到 Config 检查规则命中；Direct 则用于区分直连环境与代理环境，但不能把直连成功当成服务器可用的证据。每次切换后确认当前姿态，避免测试完成后忘记恢复原来的配置。有关 Global Routing 与诊断项目的进一步说明，可查阅功能说明，首次连接失败也可回看教程中的排查步骤。

用有限信息保留诊断线索

需要继续排查时，记录失败是所有记录还是个别记录、发生在更新还是连接、是否只在某种网络出现，并保留经过脱敏的错误原文。不要仅写“连不上”，也不要为了证明问题而公开完整分享链接。若相同记录在另一个设备正常，应比较两端实际保存的参数和当前模式，而不是立刻重置全部设置。先比较差异，再做单项修改，通常更容易得到可以解释的结果。

08 / 可恢复的维护流程

删除、备份与跨设备恢复

删除前确认对象与影响范围

删除一条服务器、删除一个订阅来源和删除 Config 的后果不同。服务器记录被删除后，若仍受订阅维护，下一次更新可能重新出现；来源被删除后，相关记录是否一起移除应以确认提示为准；配置被删除则可能改变规则行为，即使服务器列表仍然存在。操作之前先读清对象名称和确认内容，不要把所有清理按钮理解成同一种“移除”，尤其避免在当前连接依赖该对象时直接删除。

仅想暂时不用某个来源时，先检查当前平台有没有适合的停用或显示管理选项；如果没有，可以保留来源并明确标记用途，不必为了列表简短而立即移除。确实需要删除时，先确认你仍持有有效的原始信息和恢复方式。删除不是撤销认证权限，已经泄露的链接即使从本机移除，仍可能被其他设备使用；这种情况需要在原有服务的管理渠道重置相关凭据。

备份至少覆盖三个层次

第一层是可重新获取的订阅来源，第二层是独立手填记录及其完整参数，第三层是 Config、规则与必要的选择关系。仅保存订阅 URL，不能保证恢复手动记录和规则；仅导出规则，也不能补齐服务器密码。使用当前平台提供的导出或备份功能时，应阅读其说明，确认包含哪些对象。导出完成后检查文件是否真实存在、名称是否可辨认，以及是否能由目标平台相应入口读取。

备份文件可能含密码、UUID、密钥或订阅身份参数，应放在自己控制且有适当访问保护的位置。不要因为文件扩展名看起来普通，就把它当作可以公开发送的说明文档。备份也不适合与公开截图、工作资料或临时传输文件混放。需要在自己的设备之间传递时，确认接收目标，传递后检查内容完整性，并清理不再需要的临时副本，减少凭据长期散落的范围。

恢复要按来源、记录、配置依次进行

迁移到另一台设备时，先完成应用获取与首次打开，再导入备份。iPhone / iPad 版 App Store $2.99 一次性付费，Mac / Windows / 安卓 / Linux 版免费；平台选择与安装步骤统一见下载指南。不必为了恢复订阅直接覆盖所有设置，先确认目标设备已有数据是否需要保留，避免把新设备上的独立手填记录覆盖掉，造成另一种信息丢失。

恢复后先查看来源名称，再逐个执行手动更新，确认地址仍有效；接着核对独立服务器的关键参数，最后检查 Config 与策略选择。旧备份可以还原过去的本地状态，但不能保证远端服务仍接受旧凭据，也不能保证已经调整的服务器继续存在。因此恢复成功的标准不是“列表看起来和以前一样”，而是来源可更新、所需记录可连接、规则行为与当前需求一致。

用小范围恢复验证备份

重要调整之前，先保存一个明确标识用途的备份，再只修改一组内容。条件允许时，用不影响现有工作的方式验证导入结果，而不是等设备丢失后才第一次尝试恢复。若当前平台不能方便地做独立验证，至少检查导出范围、文件可读性及原始信息是否齐全，并保留自己能理解的恢复顺序。备份的价值在于能够还原所需对象，而不是文件数量越多越好。

长期维护可固定采用“备份、修改、更新、测试、记录”的顺序。每次只处理一个有明确目的的问题，成功后留下简短说明，失败时恢复上一份已知状态。客户端一次性买断 ≠ 线路套餐，应用获取记录也不能替代服务器资料的备份。回到本页目录时，可以按当前对象选择章节：来源问题看 Subscribe 与更新，单条连接看字段与测试，迁移和清理则按本章逐项核对。

返回手册开头 ↑ 查看快速上手教程 →