Shadowrocket 订阅与服务器管理

第一章 · 导入对象

Subscribe：添加已有订阅

订阅是一个用于取得服务器列表的地址，不是某一台服务器本身。Shadowrocket 请求该地址后，解析返回内容，再把可识别的服务器条目放入列表。订阅地址负责描述“从哪里更新”，条目负责描述“如何连接”。区分这两个对象，才能理解为什么重新输入单个服务器不能修复整个订阅的更新失败，也能避免把登录网页当成订阅地址。

先确认拿到的是订阅地址

导入前检查已有资料的用途说明。订阅地址通常是完整网址，可能附有较长的路径和查询参数；管理网页则可能要求登录后才能查看内容。两者外观看起来相似，返回的数据却不同。不要仅凭地址里含有某个英文单词就判断用途，也不要删除看似随机的参数。参数可能用于识别访问权限，少一个字符就可能取得错误内容。

复制时从地址开头一直选到结尾，留意聊天软件或文档是否把长地址折成多行。视觉换行未必属于原始文本，但手动拼接容易插入空格。优先使用原资料中的复制操作，随后在输入框核对协议、域名和末尾参数。不要把订阅地址粘贴到搜索框，也不要把它作为公开提问的附件；持有完整地址的人可能取得相同服务器资料。

从 Add Server 建立 Subscribe 条目

进入 Home，打开 Add Server，在 Type 中选择 Subscribe，再把已有订阅地址填入 URL。界面布局可能随设备和应用内文案调整，核心判断是当前类型为 Subscribe，而不是某种单服务器协议。填写便于辨认的备注后保存，等待列表获取完成。首次操作建议一次只添加一份订阅，这样出现问题时能明确对应哪一个地址。

保存后回到 Home，检查是否出现预期的订阅分组和服务器条目。显示订阅名称只代表管理对象已经建立，不能单凭名称断定远端内容已成功解析。继续检查条目数量是否符合已有资料的大致范围、协议类型是否可识别，以及是否出现错误提示。列表为空时先保留订阅对象，记录提示，再检查地址与网络，不必立即重复添加多份相同订阅。

如果导入成功，点选一台已知参数正确的服务器作为当前选择，再按教程完成连接与验证。订阅更新成功、服务器被选中、连接开关开启、实际请求可用是四个不同状态。只完成第一个状态时，应用不会因此自动证明整条链路可用。关于选中服务器与开关的先后关系，可参阅首次连接检查说明。

按失败发生的位置排查

出现地址错误或无法请求时，先检查复制是否完整，以及当前网络是否能完成域名解析和正常联网。出现认证或权限相关提示时，核对已有地址是否仍有效，不要连续改动协议、端口等无关字段。若返回内容实际是网页、登录提示或普通文本，客户端即使能访问该网址，也未必能把它解析为服务器列表。此时应确认原资料的导出用途。

同一地址在不同网络下结果不一致时，先记录两次测试的网络条件，再判断是否与 DNS、访问路径或连接状态有关。不要一边切换网络，一边修改地址参数，再同时更换当前服务器；多个变量一起改变，会让一次成功或失败失去解释价值。也不必预先规定更新必须通过代理，实际可用路径取决于当前网络和地址的可达性。

订阅能导入并不说明其中每个条目都可用，也不表示它包含规则配置。服务器列表与 Config 中的分流规则需要分别确认。进入下一章前，建议记下这份订阅的本地名称、最后一次实际更新结果和当前选中条目，后续手动添加、更新及排序时就有明确的参照对象。

第三章 · 输入方式

Scan QR Code 与剪贴板导入

二维码和剪贴板是输入通道，不是独立的服务器协议。它们可能承载单个服务器分享链接，也可能承载订阅地址，甚至只是普通文字。导入前应先知道已有资料预期添加什么对象，导入后再检查实际结果。能够识别二维码，只能说明图像内容被读取；能够读取剪贴板，也不能单独证明内容适用于当前导入入口。

扫描前检查可读性与来源对象

使用 Scan QR Code 时，让二维码完整进入取景区域，保留四周必要的空白，避免强反光或模糊。若二维码显示在另一台设备上，可适当提高显示亮度并调整距离。不要只截取中心图案，边缘定位区域缺失会影响识别。对已压缩多次的图片，放大只会放大模糊像素，优先回到已有资料的清晰原图。

首次使用相机扫描时，系统可能请求相机权限。只在准备扫描时授予所需权限；如果之前拒绝，可到系统设置检查 Shadowrocket 对应的权限，再返回尝试。权限只决定应用是否能读取摄像头，不决定二维码内容是否有效。允许权限后仍无结果，应分别排查画面清晰度与编码内容，而不是重复切换所有系统权限。

识别后先看应用准备创建的条目类型及可见参数。如果预期导入一份 Subscribe，结果却只得到一个普通网址或单台服务器，应暂停保存并核对原资料。不要因为弹出了识别结果就直接替换现有订阅。若二维码本来用于登录网页或管理用途，它不会因为由 Shadowrocket 扫描，就自动变成可用的服务器资料。

剪贴板导入要保留完整文本

在已有资料中复制完整分享文本，再返回 Shadowrocket 使用相应的剪贴板导入提示或入口。系统可能询问是否允许粘贴，应根据当前主动操作决定。若文本包含多行，先确认每行的边界与原始格式，避免把说明句、列表序号或引用符号一起带入。长字符串中间多一个不可见空格，也可能使解码结果不同。

某些资料在聊天窗口中会自动生成预览卡，点击卡片和复制原始文字得到的内容不一定相同。需要导入时，应复制真正的分享链接，而不是卡片标题。遇到“格式无法识别”一类提示，可先在本地确认开头标识是否完整，以及末尾是否被省略。不要把认证文本上传到在线转换页面来试错，以免扩大敏感资料的暴露范围。

如果一次复制了多个条目，应在导入后逐个检查是否遗漏、是否重复，以及协议类型是否与预期一致。少数条目成功并不意味着整段文字全部通过解析。建议先用一条完整资料确认输入方式，再处理较长列表。批量操作前保留当前可用条目的记录，导入后按备注核对新增范围，避免随后清理时分不清新旧对象。

识别结果仍需完成连接验证

保存后回到 Home，核对新增条目的备注、类型、地址和端口，再选中一台进行连接。若只出现名称而缺少关键参数，应回到原资料确认分享内容是否完整。若字段齐全但无法建立连接，排查应转向认证、TLS、传输与当前网络，继续更换扫码距离通常不会改变已保存参数，也不会修复服务器侧的拒绝。

重复扫描同一二维码可能建立重复条目，不会自动修复已有条目。再次扫描前先确认是否已有对应记录。两个同名条目也未必完全相同，应比较协议、地址、端口及所属分组后再决定保留哪一个。暂时无法确认时，用不同备注标识测试对象，而不是立即删除原本可用的记录。

导入完成后，剪贴板里可能仍保留原始资料。可以用普通文本覆盖剪贴板，并检查是否存在会把剪贴板内容同步到其他设备的设置。对于自己保存的二维码图片，也应纳入备份保护范围。扫码只是减少手工输入，不会降低原始凭据的重要性；后续更新与撤销仍应按条目实际所属的订阅或服务器来处理。

第五章 · 数据刷新

订阅更新策略与失败处理

更新订阅是重新请求远端内容，并据此刷新本地服务器集合。它不是更新 Shadowrocket 应用，也不等同于重新连接当前服务器。应用本身的购买安装与更新通过 App Store 进行，相关入口见获取应用说明。管理服务器时，首先要明确当前操作针对的是订阅对象、某个条目还是连接状态，避免在错误层级反复重试。

手动更新建立可追踪的检查点

首次导入后先完成一次手动更新观察。更新前记下分组名称、当前选中条目和关键参数，更新后检查提示、列表变化以及当前选择是否仍存在。远端可能增删服务器、修改名称或调整认证信息，因此条目数量变化不一定表示异常。相反，提示成功但内容没有变化，也可能只是远端这次没有调整，不能仅凭列表外观判断请求没有发生。

如果之前对订阅所属条目做过本地编辑，应提前保存改动记录。不要假设每类本地修改都能跨更新保留；刷新可能重新生成条目或覆盖远端管理的字段。需要长期保留的独立测试参数，可单独建立注明用途的手动副本，同时记录它与原订阅的关系。副本不会自然跟随原订阅变化，后续仍需人工核对。

更新时尽量避免同时修改规则、切换网络和删除服务器。先在稳定网络下执行一次，等待明确结果，再决定下一步。若更新后当前选中服务器消失，应重新选择列表中参数有效的条目并验证连接。连接开关仍显示开启，并不能保证之前的选择已经由新的服务器无缝替代；实际请求结果才是判断依据。

自动更新要结合设备与网络条件

如果应用内提供自动更新或相关周期设置，可按实际需要启用，并以当前界面可用选项为准。更新频率并非越高越好，频繁请求可能增加无效流量，也会让临时错误反复出现。选择策略时考虑远端内容通常多久改变、设备何时联网，以及是否需要在使用前主动检查。重要操作前的一次手动核对，往往比假定后台已更新更可靠。

移动设备的后台执行受到系统调度、网络状态与电量条件影响。设置了自动更新，不应解释为任何时刻都能严格按计划执行。长时间未打开应用、网络刚恢复或设备处于受限状态时，先进入应用确认实际列表。不要把未观察到后台刷新直接认定为订阅失效，也不要以设备日历时间推断上一次请求一定成功。

若远端地址需要通过特定可达路径访问，更新结果可能随当前网络与连接状态变化。排错时记录执行更新时是否连接、选中了哪台服务器，以及网络属于 Wi-Fi 还是蜂窝网络。只改变一个条件再试一次，才能判断失败是否与路径有关。不要为让更新成功而长期保留不清楚用途的路由改动。

按请求、认证、解析三层处理错误

请求阶段失败时，重点检查联网、DNS、地址拼写及连接超时。认证阶段失败时，核对地址中的访问参数是否完整、是否已被更换，以及已有权限状态。解析阶段失败时，检查返回用途是否正确，是否变成登录页面或错误说明。不同阶段的处理方向不同，连续点击更新不会自动补齐丢失的参数，也不会改变远端返回的数据格式。

某次更新失败后，如果原列表仍然保留，不要为了“刷新干净”立即删除订阅。原记录可能仍有可用条目，删除后反而增加恢复难度。先保存错误提示和原有参数，确认地址后再重试。若更新成功却所有服务器同时异常，应比较更新前后的共同字段，例如认证或传输设置，而不是逐个更改所有条目的备注。

订阅状态与业务请求状态需要分别记录：更新时间反映列表刷新，Connectivity Test 反映某种测试条件，实际访问反映当前请求。三者结合才能判断问题范围。订阅长期无法更新时，带着已遮挡敏感参数的错误阶段与网络条件去核对已有资料，比提交整条订阅地址更有利于保护信息。

第七章 · 诊断读数

Connectivity Test、延迟测试与排序

延迟测试用于观察某种测试请求在当时条件下的响应情况，不等于持续吞吐、所有网站的可达性或未来稳定性。不同测试方法覆盖的链路阶段可能不同，读数应结合实际测试方式理解。先看当前界面使用的测试类型，再比较同一网络、同一方法下的结果。不要把不同时间、不同网络测得的数字放在一起，直接选出所谓长期最优服务器。

先建立一致的测试条件

测试前确认设备已经正常联网，暂时停止会明显占用带宽的任务，并记下网络是 Wi-Fi 还是蜂窝网络。若刚从一个网络切到另一个网络，等待连接状态稳定后再测。设备与接入点之间的无线质量、当前网络负载以及远端服务状态都可能影响结果，单次波动不能单独说明服务器参数错误。

对一组服务器做比较时，保持测试方法一致。某种方法可能主要反映端口建立连接的耗时，另一种方法可能还包含 TLS 或应用层响应，数字不能直接横比。若界面没有给出足够方法细节，就把结果视为同一轮筛选线索，而不是精确的网络测量报告。测试目标不同，也可能导致同一服务器显示不同结果。

先选一台已知参数正确的服务器作为参照，再检查疑似异常条目。若所有条目同时超时，优先排查设备网络、DNS 和公共测试目标的可达性；若仅某个条目异常，再核对其地址、端口、认证与传输参数。按照共同故障和个别故障分支处理，比无差别重填所有密码更有效，也能保留原有的可用状态。

读数成功后仍要验证实际连接

使用 Connectivity Test 后，再选择目标服务器并发起实际请求。测试成功说明测试链路在该条件下得到预期响应，不代表 Config 中每条规则都会选择相同路径。如果测试正常而某个域名失败，应检查该请求的规则匹配、解析与目标服务状态。不能只因列表显示较低延迟，就排除 DNS 或规则造成的问题。

测试失败同样需要看发生阶段。解析不到地址、连接超时、认证被拒绝和 TLS 错误的处理方向不同。能看到错误信息时，记录原文并遮挡敏感参数；没有明确错误时，先用同一网络重复一次，再换一个条件验证。连续高频测试会引入额外请求，通常不如有计划地缩小问题范围更有帮助。

若常用请求无法访问，但其他请求正常，可以先比较它们在当前配置中匹配的策略。必要时短暂切换 Global Routing 辅助验证，并在结束后恢复原姿态。若切换后现象变化，只能说明路径选择值得检查，不能直接证明所有规则都错误。DNS 的选择与解析异常可结合DNS 设置说明进一步核对。

排序只改变查找，不替代选择

按延迟排序可以把本轮结果较快的条目集中显示，方便进一步试用。排序后应重新确认当前选中的服务器，不要假设排在第一行的条目已经自动成为当前选择。排序规则与是否自动选择是不同功能，应以应用内实际状态为准。列表位置也可能在下次更新或测试后变化，日常记录应使用可辨认的名称与归属。

将超时条目排在后面有助于减少误选，但不建议仅凭一次超时立即删除。临时网络故障、测试目标异常或远端维护都可能造成相似结果。先复测一台，确认故障是否持续，再决定是否清理。如果整组服务器都来自订阅，本地删掉个别条目后，后续更新还可能再次出现；长期变化应从订阅管理关系理解。

测试后选一台适合当前请求且参数明确的服务器，恢复日常 Config，并用实际使用确认结果。若测试期间临时改过 DNS、路由姿态或传输参数，应逐项恢复或记录最终保留的改动。没有这一步，测试得到的“可用”状态可能只在临时设置组合下成立，下一次切换网络时就难以复现。

对反复出现的故障，保留少量可比较的记录即可，不必长期堆积包含认证内容的日志与截图。关注同一条件下故障是否稳定重现，以及改变某一项后是否稳定消失。这样的记录可以帮助区分偶发波动与配置错误，也便于日后在更新服务器资料时重新验证。