Shadowrocket 订阅与服务器管理

先确认输入内容的用途

导入前，准备好自己已有的完整订阅地址，并确认它由你的服务商标明用于 Shadowrocket。地址中的路径、查询参数和令牌可能共同决定返回哪一份列表；仅复制域名通常不够。不要根据页面标题或链接长短判断用途，也不要把账户说明页、登录页或续费页面的地址填进订阅字段。可访问的网页与可解析的订阅内容是两回事。

服务器条目保存连接所需的协议和参数，订阅负责从远端获取这些条目，Config 则控制规则、DNS 等行为。三个对象可以同时存在，却不能互相替代。导入订阅后列表出现服务器，只能说明获取与解析已经完成，尚未证明当前选中的服务器能够连接，也未证明已有规则会按预期处理流量。

从 Home 建立 Subscribe 条目

在 Home 打开新增入口，进入 Add Server，并在 Type 中选择 Subscribe；实际入口位置以应用内显示为准。在 URL 中粘贴完整地址，为订阅填写便于辨认的备注，再保存。若应用询问是否获取或更新订阅，按提示执行。操作期间留意系统网络是否可用，不要在等待过程中连续新增相同地址，否则容易留下多个外观相似的订阅分组。

保存前先检查首尾是否混入空格、换行、引号或中文标点。聊天消息中自动换行的长地址，复制后不一定缺失，但截图转文字可能把字符识别错误。尤其要核对问号之后的内容、大小写敏感的令牌和百分号编码。地址属于访问凭据，应直接粘贴到应用，不要为了检查格式而提交到陌生网页。

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

以上只是格式示例，不是可用订阅。真实地址从你的服务商处获取。示例中问号后的 token 表示查询参数，不能据此推断所有订阅都使用相同参数名。某些地址把识别信息放在路径里；检查时应保持原样，不要为了让地址看起来整齐而删除一段，也不要自行补上示例中的参数。

保存之后核对四项结果

第一次获取完成后，依次检查订阅分组是否出现、服务器条目是否存在、条目协议是否符合已有信息、备注是否能区分该分组。若列表为空，先保留原地址，检查应用提示，再确认服务商是否调整过订阅入口。不要立即修改每一台服务器，也不要先删除旧列表；导入失败与服务器连接失败应分开处理。

如果列表正常出现，却包含不认识的名称，应先对照已有订阅说明，而不是把名称当成连接质量或地理位置的保证。备注由订阅内容决定，可能在后续更新中改变。只要需要追踪某个条目，就应同时记录它所属的订阅与协议类型，不能只记住列表中的显示顺序。

[Check]

订阅导入成功、服务器测试成功、实际请求成功，是三个不同检查点。请按顺序核对，不要用其中一项代替其余两项。

遇到解析失败时，先检查完整地址和当前网络，再核对返回内容是否仍是订阅数据。远端若返回登录提示、错误页面或空内容，即使请求本身得到响应，也无法形成服务器列表。详细分支可参阅订阅为空或解析失败自查。保留错误文字即可，向他人求助时不要附上完整令牌。

已存在相同订阅时，优先在原条目上更新，而不是重复导入。需要试验新地址，可先用不同备注建立临时分组，并保留原分组作为对照。确认新列表完整且能够完成实际请求后，再决定是否移除旧条目。这样的顺序能把远端内容变化与本地操作影响分开，减少误删后无法判断原因的情况。

Scan QR Code 不等于识别所有页面

使用 Scan QR Code 前，先确认二维码来自自己已有的服务器信息或订阅说明。二维码可能装着单条分享链接，也可能只是一个网页地址；扫描器读取了内容，不代表应用一定能将其转换为服务器。若扫描后进入普通页面或提示无法解析，应回到原始说明确认用途，不要仅因为二维码旁写了服务器名称就认定它是导入码。

从另一块屏幕扫描时，让二维码完整进入取景区域，避免反光、裁掉边角或把多个码同时放进画面。内容较长的二维码往往更密，缩得太小可能影响识别。优先使用原始清晰图，而不是经过多次压缩的聊天缩略图。识别失败首先是图像或内容问题，不能据此判断该服务器已经失效。

系统请求相机权限时，按实际操作需要授权。如果此前拒绝，应在系统设置中核对 Shadowrocket 的相机访问权限，再重试扫描。权限问题与服务器认证无关，不必为此修改订阅地址。对于应用内提供的其他图像识别入口，也应以当前界面为准，不要假定所有系统或设备上的按钮位置完全相同。

剪贴板导入保留原始字符串

复制分享链接时，应从协议前缀开始，直到参数和备注结束。消息中的解释文字、序号、项目符号和代码围栏不属于链接。若应用提供剪贴板导入入口，复制后在应用内主动执行，并根据系统提示允许所需访问。不要把系统没有弹出提示误认为复制失败，也不要连续复制其他内容覆盖刚准备好的链接。

多条链接一次复制是否能够批量导入，要看该入口对内容的识别情况。为了便于核对，首次操作建议先导入一条，确认解析结果，再处理剩余内容。多行文本里夹有说明段、空白行或网页标记时，部分行可能被忽略。导入后应按实际条目逐项检查，不能只依据“已导入”的提示推断全部信息都被保存。

如果系统询问是否允许粘贴，拒绝后应重新在应用提供的入口操作，并留意权限提示。复制功能与订阅网络请求是两条独立链路：剪贴板没有读到内容，属于输入阶段；已生成订阅但获取失败，属于请求阶段。先判断失败发生在哪一步，才能避免反复修改本来正确的地址或服务器参数。

导入后比较字段而不是只看名称

单条分享链接导入后，核对 Type、地址、端口以及必要的 TLS、传输字段。备注正确只能说明名称部分被读取，不能证明其他参数完整。有些格式会将备注进行百分号编码；名称出现编码字符或显示不同，不一定影响连接，但应检查是否误把链接参数写进了备注，或把备注残留在地址字段中。

订阅二维码导入后，还要确认它建立的是可更新的订阅条目，而不是只留下当次列表中的一台服务器。判断依据是应用保存的条目类型和更新入口，不是二维码图片的标题。如果后续需要持续更新，保留正确的订阅对象比复制其中某一条服务器更合适；单条导入通常不会自动继承订阅的更新关系。

[Privacy]

二维码、分享链接和剪贴板内容可能包含完整凭据。不要把它们上传到公共识别页面；截图求助前先移除二维码、密码和查询令牌。

重复扫码容易生成多个相似条目。清理前先比较所属分组、协议和地址，再确认当前选中的是哪一条。名称相同但参数不同，不应直接当作重复项删除；名称不同但地址相同，也可能承载不同认证或传输设置。无法确认时先保留两份，使用清楚的临时备注区分，并按照测试章节进行单项比较。

完成导入后，可把剪贴板替换为普通文本，减少后续误粘贴凭据的机会；这不等于撤销已经分享出去的信息。若完整链接曾进入公开场合，应通过你已有服务的管理入口处理凭据变更，再更新应用内保存的内容。输入方式的便利不能替代凭据管理，原始分享信息仍需要按敏感数据保存。

更新前保留能够比较的状态

订阅更新可能新增、删除、重命名服务器，也可能替换地址、端口或认证信息。执行前先确认正在操作的分组，记下当前选中的条目及其所属订阅。如果刚好正在排查连接问题，建议先记录错误现象，再进行刷新；否则列表变化后，旧问题与新参数会混在一起，难以判断到底是哪一步改变了结果。

不要默认更新一定会保留本地手动修改。订阅管理的条目来自远端内容，本地备注、排序或字段是否保留，应以实际更新结果为准。需要长期维护的独立参数应另建手填条目，并注明用途。更新前也不必先清空旧分组；保留旧状态有助于判断获取失败时应用是否仍保留先前数据。

手动更新与自动更新各自负责什么

手动更新适合在服务商明确通知参数调整、列表明显过时或首次导入后需要重新核对时使用。在对应订阅上执行更新，等待操作结束，再检查提示与分组内容。短时间连续点击通常不能解决远端返回错误，反而会让多个结果难以对应。一次操作失败后，先看错误属于网络、认证还是解析，再决定下一步。

如果当前应用提供自动更新相关设置，可以根据自己的使用频率启用并核对选项。系统后台调度受网络、设备状态及系统限制影响，不应把设置了更新周期理解为每次都会在准确时刻完成请求。需要确认关键变更时，仍应回到应用检查实际列表，必要时主动刷新，而不是只依赖后台任务的预期执行时间。

订阅更新走哪一条网络路径，可能受当前连接状态、路由模式和应用设置影响。若连接开启时更新失败、关闭后能够完成，说明值得检查路径差异，但不能立刻断言某台服务器失效。先在同一基础网络下比较，保留一次只改一个条件的原则，避免同时切换网络、替换地址并重新导入整个订阅。

按失败阶段处理，不以重建替代诊断

请求阶段失败，常见表现是无法建立连接、超时或名称解析问题；此时先确认设备能正常使用当前网络。认证或访问阶段失败，需要核对地址中的凭据是否完整、远端是否撤销旧地址。解析阶段失败，则应检查返回内容是否仍符合订阅格式。不同阶段有不同处理对象，不宜都归结为“节点不能用”。

如果远端已更换订阅地址，应在原订阅的相应字段中修改，并核对更新结果。只重命名分组不会改变请求地址，只修改某一台服务器也不会修复整个订阅入口。地址变更前后可短暂保留两组对照，但应明确哪组是旧记录，避免之后在旧分组继续操作，误以为新地址仍然没有生效。

[Update boundary]

更新提示成功不等于列表必须增加，也不等于每台服务器都能连接。远端内容没有变化时，更新后的列表可以保持原样。

更新后先看分组是否存在，再看条目内容是否变化，最后确认当前选中项。某条服务器从远端列表移除后，本地原先的选择可能需要重新确认；不要只看连接开关仍然开启，就认为流量仍经过更新前的同一条记录。如果规则指向某个命名对象，也应检查相关引用是否仍能对应到预期条目。

列表数量变化也不能直接解释为服务质量变化。可能只是远端拆分、合并或重命名了项目，应结合实际参数和说明核对。反复刷新仍无法得到预期内容时，整理错误文字、操作顺序和已做过的检查，再向你已有服务的管理方核实返回内容。提供问题描述即可，不应在公开交流中提交完整订阅地址。

Shadowrocket 本身的更新应通过 App Store 查看与安装，不能靠刷新订阅完成。应用是否需要更新、兼容性和系统要求，以 App Store 页面标注为准。有关正版入口和应用 ID 的核对方法见正版核验说明；涉及列表为空的具体排查，则回到订阅请求与解析这条链路处理。

先辨认测量对象与测试方法

使用 Connectivity Test 或列表中的测试功能前，先核对应用当前采用的测试方式和目标。不同方式可能测量到服务器端口的建立过程，也可能包含经由代理访问测试目标的过程，结果含义并不相同。只有方法、目标、基础网络和时间条件接近时，数值才适合横向比较；不要把不同模式下的结果直接排成优劣顺序。

测试数值反映的是一次或一组测量，不代表今后的每次请求都会相同。当前网络负载、无线信号、服务端状态、名称解析以及目标响应都可能影响结果。一次偏高不必立即删除条目，一次偏低也不应直接认定它适合所有用途。先保持网络不变，重复少量测试，观察结果是否具有一致性，再决定是否切换。

超时或失败同样需要结合测试方法理解。如果测试目标不可达，可能出现多台服务器同时失败；如果某个协议字段错误，则可能只有对应条目异常。测试失败并不总等于服务器地址完全无法访问，测试成功也不证明特定业务请求一定成功。先把测试功能当作定位线索，再用实际请求确认。

建立一条可复现的核对顺序

第一步确认基础网络正常，排除尚未完成网络登录、信号不稳定等情况。第二步核对选中条目及其协议参数，避免正在测的是名字相近的旧记录。第三步在固定方法下执行测试，等待结果后再操作。第四步核对 Global Routing 与当前 Config，最后再访问自己需要验证的目标。每一步都应能说明检查了什么。

如果所有条目一起失败，优先检查基础网络、统一测试目标和公共设置；如果只有某一订阅失败，再检查该订阅是否刚刚更新、认证是否变化；如果只有一台失败，回到其地址、端口、TLS 和传输参数。这样的范围收缩，比先重装应用或清空所有订阅更容易保留证据，也不必重复建立已经正确的配置。

为比较实际请求而临时改变姿态时，应先记下原状态，验证结束后恢复。不能为了得到一次成功结果就长期保留不理解的模式。尤其在 Config 下，目标请求可能命中 DIRECT 或其他策略；这时即使服务器列表显示很低的延迟，也无法证明该请求正在使用相应服务器。

排序只是展示，选择仍需确认

按延迟排序便于找到当前测试中响应较快的条目，但排序不是自动选择的同义词，也不等于持续健康检查。排序后再确认当前选中标记，避免把列表首项当成正在使用的条目。若本轮只有部分条目完成测试，也不要把未测、超时和已测结果混为同一类；应先确认结果覆盖范围。

批量测试期间尽量不要同时刷新订阅或移动条目。列表发生变化后，测试对象、名称和位置可能无法直接对应。先完成测试并记下需要比较的条目，再执行更新或整理。重新测试时采用同样的网络与方法，才能判断变化是否来自新参数，而不是设备刚好从一种网络切到另一种网络。

[Evidence]

记录测试方式、基础网络、所选条目和实际错误，比只记录一个延迟数字更有排查价值。分享记录时移除所有凭据。

实际使用中还要区分延迟与速度：较短的响应时间并不保证大文件传输更快，也不能说明长连接一定稳定。本页不设置统一的合格数值，因为测试目标、网络和业务需求不同。若结果持续波动，先在固定条件下复现，避免高频批量测试制造额外请求；再根据错误发生的阶段，回到参数、订阅或规则章节逐项核对。