Subscribe 导入：先分清地址与返回内容
订阅记录与服务器条目的关系
订阅地址是一项可重复请求的资源入口，服务器条目则是客户端解析结果中的具体连接对象。一个订阅可以返回多个条目，但订阅名称、条目名称和当前选中的服务器并不是同一项设置。管理时先保留订阅归属，再查看其中各条目的协议与参数。地址本身能够保存，不代表远端内容已经成功取得；列表中出现名称，也不代表服务器已经通过实际连接验证。
开始前请在原始信息中确认，这是一条用于订阅更新的完整地址，而不是账户页面、说明页面或单个服务器分享链接。尤其要保留地址问号后的查询参数，它们可能承担身份验证与内容选择作用。复制时不要附带中文引号、换行、聊天前缀或末尾标点，也不要为了让地址看起来整齐而自行删减参数。订阅地址按敏感凭据处理，不用于公开截图。
从 Add Server 中建立 Subscribe 记录
在 Home 打开 Add Server，进入 Type 选择并找到 Subscribe，再按当前表单填写地址与便于辨认的备注。不同显示语言下的位置可能有所差别，应以应用内实际出现的 Subscribe 项和字段提示为准。保存前逐字核对协议头、主机名、路径和参数；保存后观察是否出现对应订阅分组、是否生成服务器条目，以及应用是否报告请求或解析错误。三个结果需要分别记录。
首次导入建议只处理一条订阅。先确认返回内容能够解析、条目归属正确，再添加下一条，这样出错时可以直接定位本次输入。导入完成后在 Home 点选准备使用的服务器，确认选中标记落在该条目上；不要把展开订阅分组的动作当成选择服务器。随后按照快速上手连接并运行 Connectivity Test，验证导入结果是否真正参与了当前连接。
空列表与请求失败的核对顺序
如果保存后没有服务器，先看应用给出的错误属于访问失败还是内容无法解析。访问失败应检查当前网络是否能建立请求、地址是否完整、凭据是否仍有效；内容无法解析则要确认远端返回的是服务器资料，而不是需要登录的网页、错误说明或空响应。浏览器能显示一段文字，只能证明浏览器取得了内容，不能直接证明该内容适合 Subscribe，也不能代替客户端内的导入结果。
不要用连续新增相同记录解决空列表。重复导入会让后续更新与删除更难判断，却不会修复地址错误。保留一条订阅记录，重新核对输入并执行一次更新；如果远端信息已变化，应使用自己现有服务所提供的最新地址。排查时只记录失败发生在哪一步，不把完整地址复制给无关人员。需要说明问题时，描述错误类别、当前网络以及是否产生条目即可。
若同一地址以前可用、现在失败，先保留现有服务器列表，避免在原因未明时清空数据。记录最后一次成功更新后的可见条目与本次提示，再区分远端暂时不可达、返回内容变化和本地输入被改动这三种情况。管理目标是恢复可重复更新的来源关系，而不是只让列表暂时出现几个名称。
Add Server 手填字段：按协议核对，不靠名称推断
先选择 Type，再填写连接信息
手动添加适合已经持有完整服务器参数、需要逐项检查的情况。在 Home 打开 Add Server 后，首先选择实际协议 Type，再填写 Address、Port 与相应认证字段。选择 Type 会改变表单需要的参数，因此不能先把所有内容填进一种协议，再只改名称来假定转换完成。备注用于辨认，不参与认证；名称包含某个协议词，也不能证明条目实际采用了该协议。
Address 通常填写主机名或地址本身，Port 单独填写数值。不要把完整网页地址、路径和端口一起塞进 Address，除非当前字段明确要求完整地址。复制后检查首尾空格，以及数字是否被输入法替换为全角字符。地址、端口、认证与传输参数应来自同一份现有服务器资料，不要从多个相似条目中拼接，因为其中任意一项对应不同入口都可能导致失败。
| Type | 认证信息 | 附加核对 |
|---|---|---|
| Shadowsocks | Method、Password | 是否另有传输要求 |
| VMess / VLESS | UUID 及协议相关选项 | 传输类型、路径、TLS |
| Trojan / Hysteria2 | 对应的认证字段 | 服务器名、TLS 与附加参数 |
| WireGuard | 密钥及对端信息 | 接口地址、Endpoint 与路由范围 |
| HTTP / SOCKS5 | 按要求填写用户名与密码 | 地址、端口及认证要求 |
认证字段不能互相替代
Shadowsocks 的 Method 与 Password 必须成对匹配服务器设置；VMess、VLESS 的 UUID 不是任意备注，也不能用账户登录密码替代。Trojan、Hysteria2 应按各自表单和已有资料核对认证值。WireGuard 需要理解本地私钥与对端公钥的角色，不能交换位置。表格只是检查方向，不是可通用于全部服务器的参数模板；实际必填项以所选 Type 的表单为准。
密码与密钥通常区分大小写，复制时不要进行自动纠错。遇到看起来为空的认证字段，应先确认资料是否真的要求留空，而不是凭连接结果反复猜测。若参数来自一段分享链接，可先导入为独立条目，再进入编辑页与文字资料对照。这样既能保留原始解析结果，也能发现手填时遗漏的传输选项，但仍需确认链接确实属于同一服务器。
TLS、服务器名与传输路径分别检查
启用 TLS 后，连接地址与用于证书验证的服务器名可能不同。传输中的 Host、Path 与 TLS 的服务器名也有各自用途，不能因为都是域名或字符串就互相复制。应按照现有资料检查传输类型、路径中的斜杠、大小写以及服务器名。不要通过关闭证书验证来掩盖字段不匹配；出现证书问题时，同时核对设备日期时间是否正确，以及资料中的域名是否仍然有效。
保存后重新打开编辑页，确认输入没有被漏填或落入错误字段。为每次修改保留清晰边界：先只改一个有依据的项目，再测试结果，不要同时更换协议、端口、认证和 TLS。若已知一份完整参数可以工作，可建立独立测试副本对照，但应明确区分原条目与测试条目，避免把尚未验证的副本设为日常默认服务器。
手填条目通常需要自行维护，不能假设 Subscribe 更新会替它修正参数。属于订阅生成的条目则应优先在来源资料层面核对，因为后续刷新可能重新生成字段。对具体英文界面词不熟悉时，可结合界面词说明查阅，避免把连接参数与 Global Routing 的策略选项混在一起。
扫码与剪贴板导入：识别内容后再保存
Scan QR Code 只改变输入方式
二维码是承载文本的方式，不是独立的服务器协议。它可能装着单个服务器分享链接、订阅地址，也可能只是普通网页。使用 Scan QR Code 前先确认内容来自自己现有的服务器资料，识别后检查客户端显示的类型和待导入对象，再决定保存。不要把“扫描成功”理解成服务器可用；扫描只能说明图像中的文本被读取，后面仍有格式解析与连接验证两道检查。
在应用提供的扫描入口打开 Scan QR Code，按系统提示决定是否允许相机访问，然后把完整二维码置于取景范围内。若暂时不准备授权相机，可采用已有文本的导入方式，不必为了继续操作而调整无关系统权限。图片反光、裁切缺角、分辨率不足或屏幕缩放都可能影响识别；应优先取得清晰的原始二维码，而不是反复截取越来越小的局部图。
识别结果需要核对三个层次
第一层看对象类型：打开的是 Add Server 编辑信息，还是 Subscribe 地址记录；第二层看连接字段：地址、端口、协议与认证是否完整；第三层看管理归属：新条目是否属于预期订阅，还是单独保存的手动条目。扫码完成后如果跳转到普通页面，说明二维码可能承载的是网页入口，不应继续把整段网页地址当作服务器参数尝试填写。
同一设备上保存的二维码图片，是否可直接从相册识别，应以当前扫描界面实际提供的功能为准。没有相应入口时，不需要假设某个隐藏手势存在。可以使用自己保存的原始文本，或在另一台受控设备上显示已有二维码再扫描。整个过程都应避免让包含认证资料的图像进入公开共享相册、群聊或录屏，尤其不要只遮住备注却保留完整编码区域。
剪贴板导入前先去掉无关文字
复制时尽量只选择完整的一条分享链接或订阅地址，而不是整段聊天记录。系统询问粘贴权限时，确认当前操作确实由自己发起，再允许应用读取。如果应用出现导入提示，先检查解析出的数量与类型；若没有提示，应使用界面实际提供的导入入口，不把未出现的提示误判成协议不支持。复制一次、核对一次，比连续覆盖剪贴板更容易追踪问题。
富文本内容容易附带项目符号、引号、不可见空格与人为换行。可以在受控的纯文本环境中查看首尾，但不要为此把凭据粘贴到在线转换页面。多个条目批量导入时，检查每条记录的边界，避免两段链接被拼成一行，或一段编码内容被拆成两条。应用报告数量与预期不同，应先回到原始文本确认，而不是把不完整结果留在列表中继续连接。
如果扫码与文本导入得到不同结果，应对照两者是否真的是同一份内容。二维码可能来自较早保存的资料，而剪贴板已经复制了新地址；也可能文本中带有额外转义。保留原始资料并比较对象类型、地址和端口，不依赖名称一致作结论。确认导入完成后，把剪贴板替换为普通文本，并清理不再需要的敏感截图，减少后续误分享的机会。
订阅更新策略：区分请求成功与内容变化
手动更新应形成完整检查过程
订阅更新是再次访问已保存地址并处理返回内容，不是对已有服务器做连通性测试。执行前先确认正在更新哪一条订阅，记下当前选中的服务器及分组情况；执行后分别检查应用提示、条目变化和默认选择是否仍符合预期。请求成功但条目没有变化，可能只是远端内容与本地相同；列表发生变化，也不代表新条目已经完成连接验证，两种情况都需要进一步核对。
对订阅记录执行界面提供的更新操作后，等待本次结果再继续，不要在请求尚未结束时反复点击。频繁刷新不会使错误地址变正确，还可能使多次请求的先后结果难以分辨。若一次失败，应先根据提示区分网络不可达、认证问题与内容解析问题，再决定下一步。需要更新地址时直接核对订阅记录本身，不要只在某个生成条目里修改服务器地址。
自动更新不能当成即时保证
如果当前 Settings 或订阅编辑界面提供自动更新相关选项，应阅读其实际含义与可设置范围，再根据使用需要启用。不要假设应用在任意后台状态都能按精确时刻完成请求。设备网络、系统调度与应用状态都会影响执行条件；准备依赖新参数连接前，仍应在前台检查最近一次可观察的更新结果，必要时主动完成一次更新与连接验证。
更新频率应服务于资料变化，而不是越短越好。长期稳定的订阅不需要因一次连接失败就连续刷新；如果现有服务明确调整了参数，则应更新并检查变化后的字段。自动更新与自动选择服务器也不是一回事：前者维护数据，后者涉及实际连接对象。不能因为列表刚刚刷新，就假定客户端已经替自己切换到某个更合适的条目。
本地编辑与远端内容的边界
订阅生成的字段可能在后续更新时重新写入，因此本地改过备注、端口或其他参数后，要考虑这些修改是否会被覆盖。具体保留行为以当前界面与实际更新结果为准。需要长期保留自定义参数时，可在功能允许的情况下建立独立手动条目，并清楚标注其维护责任；不要把订阅条目直接当作长期不变的本地记录，也不要依赖未验证的覆盖规则。
如果更新后出现新增、减少或重名条目，先对照远端资料是否确有变化，再检查当前选择。旧服务器可能被移除，新名称也可能对应不同参数。为了避免连接过程中混淆，重要更新可以选择在不进行关键传输时操作；更新完成后重新确认选中标记，再进行测试。对旧条目的依赖应落实到参数与归属，而不是只记住列表中的位置。
排查更新失败时，可以换用自己可控的另一种网络做对照，同时保持地址与客户端设置不变。若网络改变后成功，优先分析请求路径；若始终失败，再核对地址与返回格式。不要把订阅更新问题直接归因于某个服务器延迟值，更不要同时清空列表、改地址和切换多项网络设置。一次只改变一个条件，结果才具有比较意义。
形成简单维护记录会比记忆可靠：写下操作对象、操作原因、是否产生条目变化与验证结果即可，不需要保存完整认证信息。下一次遇到相同提示时，就能判断问题发生在访问订阅、解析内容还是连接服务器阶段。这样的记录也能减少在正常列表上重复导入、重复删除的误操作。
多订阅整理：保留归属与选择依据
给订阅命名，而不是暴露地址
管理多个已有订阅时，首要任务是能回答“这个条目从哪一条记录更新而来”。为订阅使用简短、稳定且可辨认的备注，例如按个人设备用途或维护范围命名，不把完整订阅地址、账户标识和密钥放进名称。备注应帮助区分对象，不应承担参数存储功能。服务器名称则尽量保留必要辨认信息，避免全都改成相同短名，导致后续无法对照。
新建第二条订阅前，先确认第一条已经完成导入与一次实际验证。随后逐条添加，观察新增分组与条目范围。若应用支持折叠分组，可以把暂时不用的分组收起以减少视觉干扰，但折叠只影响展示，不等于停用、删除或改变当前连接。查看列表时要把展开状态与选中状态分开理解，真正的连接对象应以客户端显示的选择标记为准。
重复项要比较参数与维护来源
名称相同不一定重复，名称不同也不一定独立。判断前先比较 Type、Address、Port 与关键认证和传输字段，再看它们是否分别来自两条订阅。两个订阅返回相似服务器时，保留不同来源有助于维持各自更新关系；直接删掉某个生成条目，可能在下一次更新时再次出现。因此，整理前应先明确是要减少显示重复，还是要停止维护某一条来源记录。
| 对象 | 主要用途 | 整理时核对 |
|---|---|---|
| 订阅记录 | 保存更新入口与归属 | 地址、备注、更新结果 |
| 服务器条目 | 保存具体连接参数 | 协议、参数、选中状态 |
| Config | 保存规则与策略引用 | 当前文件、规则顺序、引用名称 |
| Global Routing | 确定请求采用的路由方式 | Config / Proxy / Direct |
整理列表不等于修改路由
Global Routing 使用 Config 时，请求按当前配置中的规则处理；使用 Proxy 时，需要核对当前代理服务器或相关策略；使用 Direct 时，流量按该模式直接处理。列表里有多少订阅，并不能决定请求一定经过哪一个服务器。若配置中还有按名称引用的策略，应继续检查引用是否有效，不能只看 Home 中选中了一条服务器就断定所有请求都使用它。
更改备注前尤其要注意配置引用。若规则或策略依赖某个名称，改名后可能需要同步核对引用关系；如果只是为了展示整齐而批量改名，反而可能增加维护成本。建议先理解当前 Config 是否引用具体名称，再决定改动范围。对不熟悉的配置，保留一份原文件并小范围验证，比一次重命名全部条目更容易恢复，也更容易定位出错环节。
建立可重复的维护次序
日常整理可以采用固定顺序：先更新一条订阅，核对变化，再测试准备使用的条目，最后处理重复或失效记录。处理完一组再进入下一组，避免多条订阅同时刷新后无法判断变更来源。若某一订阅临时失败，不要立即把其他正常记录也删除重建；应保留已经验证的状态，把排查限制在出现问题的那条记录内。
当条目数量较多时，先按归属缩小范围，再使用界面实际提供的搜索或排序方式查找。搜索不到可能是名称变化、分组折叠或筛选条件影响，不一定意味着记录已被删除。切换测试对象前记下当前可用条目，测试结束后回到预期选择。多订阅管理的重点是让来源、参数、路由和当前选择保持清楚，而不是追求列表越短或名称越统一。
需要检查某个界面词时，可查术语表；需要从零完成一条连接时，则回到快速上手。本页的整理方法用于减少管理混淆，不改变已有服务本身的权限、参数有效期或可用范围。
延迟测试与排序：把响应、握手与请求分开判断
一个测试数值不能代表所有使用结果
测试结果首先取决于采用了什么检测方式。针对端口的检查、需要协议参与的检测和实际网页请求，验证范围并不相同。某种方式有响应，可能只说明对应路径能够建立联系；它不一定验证认证、TLS、规则与目标服务的完整链路。比较数值前，先查看当前测试设置和说明，确保结果来自同一种方法，而不是把不同检测范围的值直接排列。
批量测试适合初步缩小检查范围，不适合直接得出“排在第一的条目始终最好”的结论。当前网络、测试目标、设备负载与测试时点都会影响结果。应在同一网络条件下完成一组测试，并对准备使用的少数条目再做实际验证。刚切换网络时看到的旧结果只代表之前的条件，不应在没有重新测试的情况下继续作为选择依据。
Connectivity Test 要对应当前连接
在 Home 选择准备使用的服务器，确认选中标记后打开连接开关；系统要求添加 VPN 配置时，阅读提示并按自己的操作意图确认。随后运行 Connectivity Test，并同时核对 Global Routing。若正在使用 Direct，测试成功不能用来证明某个代理服务器认证正确；若使用 Config，则还要考虑测试目标可能匹配的规则，以及该规则最终采用的策略。
实际验证应包括自己确实需要访问的目标。Connectivity Test 成功而某个应用失败时，应继续检查该应用请求是否命中了不同规则、域名解析是否正常，以及目标服务是否存在独立问题。不要因为系统出现 VPN 状态就停止验证：系统状态说明连接配置在工作，不等于每个目标都已经完成请求。首次连接的具体顺序可参阅首次连接检查说明。
超时先按层次定位
出现超时时先检查当前基础网络，再核对服务器地址与端口，然后核对认证、传输和 TLS；有域名相关错误时，再检查解析与服务器名。端口无法访问与认证被拒绝属于不同阶段，应根据实际提示分开处理。若错误信息不足，可以在保留其他参数的前提下换用另一种可控网络比较；不要在没有依据时连续修改多项字段，否则测试结果无法对应具体原因。
设备系统日期时间也影响证书与部分认证流程。检查日期、时区和自动设置是否符合实际情况，不要通过长期关闭验证绕过错误。如果只有一条服务器失败，而同一网络下其他已知条目正常，应把排查集中在该条目的参数和远端状态；如果多条不同记录同时失败，则先检查共同条件。更详细的分支见超时与连接失败排查。
排序只改变查看顺序，不替代选择
按延迟排序便于浏览，但排序本身不保证自动切换当前连接。排序后仍应明确点选准备使用的条目，核对选择标记并再次验证。空白结果、未测试结果与失败结果也不能随意当成同一数值比较；应看清当前界面对这些状态的表示方式。多订阅环境下还要确认排序作用范围，是当前分组还是更大的列表，避免误以为某条记录已经消失。
测试结束后保留足够但不过量的记录：使用哪种方法、在哪个网络、是否通过实际请求即可。分享排查信息时遮去服务器认证、订阅地址和个人数据。测试记录的价值在于说明条件与现象，而不是展示一串无法复现的数值；只有条件一致，前后比较才能帮助区分网络变化、参数变化和规则变化。
删除与备份：先确认范围，再验证恢复
删除前辨认操作对象
删除单个服务器、删除订阅记录与删除 Config 文件影响不同。操作前先看当前位于哪一个页面、选中了什么对象，以及确认提示描述的范围。单个服务器从列表移除，不代表远端订阅内容被改变；订阅记录删除，也不能代替对外部服务权限的处理。不要仅凭按钮附近的名称判断影响，应结合页面位置和实际提示确认本次删除针对条目、分组还是配置。
如果准备删除当前选中的服务器，应先确定替代对象并验证连接，再处理旧记录。若配置策略依赖即将删除的名称，还要同步检查引用是否仍可解析。删除后回到 Home 核对选中状态，并检查 Global Routing 与当前 Config。不能假设客户端一定会自动选中符合自己预期的下一条记录；即使系统连接状态仍存在，也应重新验证实际请求。
订阅条目可能在更新后重新出现
对订阅生成的服务器进行本地删除后，下一次刷新可能依据远端内容重新生成它。出现这种情况不一定是删除失败，而是本地列表再次与来源内容同步。若目标是停止维护整条订阅，应处理对应的订阅记录，并在确认提示中检查关联条目的范围；若只是暂时不使用某个服务器，保持清楚的选择与分组展示通常比反复删除、刷新更容易维护。
批量删除前不要依赖列表位置，因为排序、分组展开与更新都会改变位置。逐一核对名称和来源，必要时先缩小到一个分组操作。若不确定某个条目是否仍被规则引用，应先保留它并查明引用，而不是删除后靠连接失败反推关系。删除是管理动作，不是常规排错的第一步；保留可比较的旧状态往往更有助于定位问题。
备份要覆盖不同类型的数据
完整恢复所需资料可能包括原始订阅地址、独立手填服务器参数、Config 文件及需要重新设置的应用选项。备份某个服务器分享链接，通常不能替代整条订阅的更新入口；备份 Config，也不能证明服务器认证资料包含其中。使用应用实际提供的导出或备份功能时，应阅读项目说明并确认范围，不把某个文件名称或文件大小当成内容完整的证据。
备份文件可能包含密码、UUID、密钥或订阅凭据，应保存在自己控制且具备访问保护的位置。不要把它当成普通文档公开分享，也不要为了便于辨认把认证值写进文件名。设备送修、转交或更换前，应先检查本地文件、相册二维码与剪贴板是否还保留相关信息。保护备份不仅是保留副本，也包括限制副本可以被哪些账户和设备访问。
恢复验证与应用重新安装分开处理
换机或重装前，先确认已经持有可恢复的资料，再处理原设备。应用重新获取应从 App Store 完成，已购恢复与购买适用范围见已购恢复说明，系统要求以 App Store 页面标注为准。重新安装应用与恢复服务器数据是两项独立工作，不应假设购买记录会同时恢复全部本地设置，也不应把系统备份的存在当作实际恢复成功的证明。
在目标设备恢复后，按数据类型逐项检查：订阅地址是否存在且能更新，手填条目字段是否完整，Config 是否已经选择，相关策略名称是否有效。最后选择一个预期服务器，检查 Global Routing，运行 Connectivity Test 并验证实际目标。只有这一整条过程完成，才说明备份可用于当前需求；能够打开备份文件或看到若干名称，只能算恢复过程中的中间结果。
若怀疑某份备份或分享资料已经泄露，应在自己的既有服务管理范围内处理相应凭据，并更新客户端记录。仅删除本地副本不会改变已经暴露的认证值。恢复验证通过后，再按需要清理过期副本，同时保留一份已确认范围与用途的可用备份。日常维护遵循“先保存依据、再改变状态、最后验证结果”，比出现故障后重新拼凑信息更可靠。