SETTINGS REFERENCE · 官方手册

Shadowrocket 设置详解Settings 参数参考

先确认设置作用于哪里，再决定是否修改。按章节查阅参数含义、默认状态核对方法、推荐取值与恢复路径。

本页用于系统查阅，不替代首次连接流程。尚未完成导入与连接时，先阅读使用说明；完成后回到本页检查设置。以下操作以用户已有自己的订阅或服务器信息为前提。

默认值以当前应用显示为准每次只改一类设置 App Store 正版核对

01 / SCOPE

设置范围、默认状态与修改顺序

Shadowrocket 的运行结果由多层信息共同决定：系统网络决定能否到达服务器，服务器条目决定连接参数，Config 决定规则和相关配置，Global Routing 决定当前采用哪一种分流姿态，Settings 则提供应用层面的选项。看到请求失败时，不能只凭某个开关的位置判断原因；应先确定失败发生在哪一层，再进入对应位置检查。

区分应用设置、配置文件与服务器参数

Settings 中的选项不等于当前配置文件的全部内容。某些行为还取决于正在使用的 Config、协议能力以及系统权限。同名或相近选项在不同位置出现时，也不能假定它们始终互相覆盖。先记录当前配置名称、服务器名称和 Global Routing 的选中项，再打开设置详情核对说明；需要比较时，只使用当前应用实际显示的字段作为依据。

服务器信息通常包含地址、端口、认证资料及协议特有字段。这些属于连接端点，不应为了改变分流结果而随意修改。Config 中的规则则用于判断请求交给哪一种策略处理。把服务器端口改成本地 Proxy 端口，或者把订阅地址当作配置文件地址使用，都会混淆数据类型；即使界面允许保存，也不代表能够建立有效连接。

设置页上的名称与排序可能随当前应用界面变化。本手册保留 DNS、On Demand、Ping、Log 等英文原名，但不将未经核实的初始状态写成统一默认值。已经使用过的设备还可能保留历史修改或同步状态，因此“当前显示值”和“首次安装默认值”不是同一概念。排查时记录实际值，比凭记忆恢复所谓默认设置更可靠。

默认值未知时如何选择推荐取值

本页的通用推荐是保留已经验证可工作的设置，仅针对明确问题修改必要字段。对于服务器提供的协议参数，推荐取值是与用户已有资料逐项一致；对于按需连接、同步和本地监听等可选能力，推荐先确认用途与作用范围，再决定是否启用。推荐不是全体用户都应照抄的一组数字，而是能够解释原因、能够重复验证的选择。

设置来源	默认状态核对	推荐处理
Settings	以当前应用显示为准	先记录，再单项修改
Config	检查当前选中的文件	保留可回退的副本
Add Server	由条目与协议决定	与已有服务器资料一致
系统权限	在系统设置中核对	按系统提示确认实际授权

在修改前写一份简短记录，至少包含网络类型、能否连接、失败的目标以及现有设置。记录中不要保存明文密码或完整订阅链接。若问题只发生在特定无线网络，先在另一种可用网络上复测；若仅一个目标失败，先检查匹配规则。这样能够区分全局故障和局部故障，避免用影响全部请求的选项处理一个局部问题。

建立可回退的操作闭环

一次只改变一类变量，并使用同一目标复测。例如测试 DNS 时，暂时保持服务器、路由姿态和规则不变；测试服务器参数时，不同时更新配置文件。每次修改后确认保存是否成功，必要时断开再连接，让新的运行状态重新建立。若效果变差，先恢复刚才记录的值，而不是继续叠加多个尚未验证的改动。

备份应覆盖实际需要恢复的内容。仅保存 Config 并不等于保存服务器认证资料，保留服务器条目也不等于保留全部规则。对于能够导出或复制的内容，先检查当前应用提供的操作及输出范围，再保存到自己能够控制的位置。备份文件可能包含敏感信息，不能为了求助直接公开；同步功能也不能替代独立且经过核对的备份。

恢复顺序同样应由近及远：先撤销最近修改，再核对配置是否选中，然后检查服务器和本地网络。不要把删除所有数据作为第一步。若确实需要重新整理，应先确认备份能读、关键资料齐全，并记下购买账户对应的 App Store 状态。设置手册的目标是让每次改变都有依据，而不是让所有选项都处于某一种看起来整齐的状态。

02 / ROUTING

Global Routing：Config、Proxy 与 Direct

Global Routing 决定当前请求采用哪一种总体处理方式。配置、代理、直连分别对应界面中的 Config、Proxy、Direct。推荐在日常规则分流中使用经过核对的 Config；Proxy 和 Direct 可以帮助进行短时间的对照检查，但它们不能代替服务器参数修正，也不能证明所有应用流量都一定具备相同的网络条件。

先确定姿态，再解释规则结果

Config 的含义是按当前配置文件中的规则处理请求。它要求配置文件本身可用、已经被选中，并且规则引用的策略能够正确解析。仅把文件导入列表，不等于运行时正在使用它。遇到“规则已经写了却没有效果”时，先检查 Global Routing 是否确实为 Config，再检查当前选中的文件名称，最后才检查某一行的拼写和顺序。

Proxy 用于整体采用代理方向的处理，Direct 用于整体采用直连方向的处理。这里的“整体”是路由姿态的解释，不是对系统中每一种流量的绝对保证。系统自身的连接、特殊网络限制以及协议处理仍可能影响观察结果。测试结束后，应恢复原先的 Config 状态，否则之后查看规则日志时可能把姿态差异误判为规则失效。

界面原名	中文含义	推荐用途
Config	配置	按已核对的规则进行日常分流
Proxy	代理	短时比较代理方向是否可用
Direct	直连	短时比较本地直连是否可用

三种姿态的当前选中项以应用显示为准，本手册不推断新装设备的默认选中项。若切换后一个目标恢复访问，只能说明改变处理方向影响了结果；还应结合 DNS、规则匹配和服务器连接继续分析。不要立即把全部请求长期改成另一种姿态，因为这可能同时改变原本正常的本地资源访问、域名解析路径与连接出口。

按顺序理解规则匹配

常见规则从上到下判断，前面已经命中的规则会影响后续规则能否被使用。DOMAIN 用于精确域名匹配，DOMAIN-SUFFIX 用于域名后缀匹配，DOMAIN-KEYWORD 用于域名关键词匹配；IP-CIDR 与 IP-CIDR6 面向地址范围。选择类型时应尽量准确，避免为了匹配一个目标而使用范围过大的关键词，使无关请求也被同一策略接管。

GEOIP 使用地址归属数据进行判断，不等于识别用户所在位置，也不保证对应某个网站的全部资源。一个页面可能同时请求多个域名和不同地区的地址，因此“主页面走直连”不能推导出“所有子资源都走直连”。FINAL 是没有被前面规则处理时的兜底。检查最终行为时，应把兜底策略也纳入记录，而不是只查看显眼的前几行。

[Rule]
DOMAIN-SUFFIX,example.com,PROXY
GEOIP,CN,DIRECT
FINAL,PROXY

上面的片段说明规则顺序与策略写法，不是可以覆盖所有场景的完整配置。example.com 仅作教学域名，PROXY 与 DIRECT 保持规则关键字原样。应在已有配置的副本中核对相应章节，避免重复添加多个同名章节或把片段当成服务器资料导入。保存后重新确认所选文件，并用日志检查目标是否命中预期规则。

从具体请求反推规则问题

排查时先选择一个能够重复出现问题的目标，记下访问动作与时间，然后查看对应请求的域名、地址和策略。若日志显示命中了不符合预期的上游规则，应调整那条规则的范围或顺序；若始终落到 FINAL，则检查目标是否与填写的域名一致。重定向、图片资源和接口域名不同，是“页面地址正确但规则没命中”的常见解释。

REJECT 表示拒绝匹配请求，并不等于能够识别页面上的全部内容。把过宽的域名后缀交给 REJECT 可能同时阻断登录、图片或接口。修改前先记录原规则，修改后分别测试主要操作，而不是只确认页面能够打开。关于匹配范围、误伤与恢复方法，可继续阅读REJECT 规则的写法与边界。

推荐的回退方式是保留原文件，使用副本验证单条规则，再根据日志决定是否合并。规则越多并不自动意味着分流越准确；无法说明用途的重复规则反而增加维护成本。完成测试后，复核 Global Routing、当前配置和选中服务器三者是否仍是预期组合，并把这组组合记入维护记录，作为下一次排查的基线。

03 / NAME RESOLUTION

DNS：解析路径、缓存与地址差异

DNS 用于把域名解析为地址。连接失败可能发生在解析之前、解析过程中，也可能发生在已经得到地址之后；修改 DNS 只会影响其中一部分。推荐先使用当前已经验证正常的设置，并结合 Config 检查解析相关配置。默认值及可选方式以当前应用显示为准，不把某个公共解析地址当作适用于所有网络的统一答案。

先区分解析失败与连接失败

如果请求没有得到可用地址，应关注解析服务是否可达、域名是否有效以及当前网络是否要求先完成接入认证。如果已经有地址但连接仍超时，原因可能在规则方向、服务器状态或目标服务。单凭浏览器显示的“无法打开页面”不能区分这些情况，需要结合 Log 中相近时间的解析与连接信息，把失败发生的位置定位清楚。

域名的解析路径和后续连接路径是两个相关但不同的问题。请求最终使用 PROXY，不意味着所有解析步骤必然采用同样的传输方向；请求使用 DIRECT，也不能只根据策略名称推断解析器来源。具体行为还取决于当前配置和应用选项。检查时分别记录“由哪里解析”和“向哪里连接”，避免把两个问题合并成一个模糊的开关判断。

DNS 设置可能同时涉及应用选项与配置文件内容。先打开当前 Config，核对其中与解析有关的条目，再查看 Settings 中可用的 DNS 选项及说明。不要同时在多个位置填入不同取值后凭结果猜测优先级。如果来源之间存在冲突，应在配置副本中逐项简化、重新连接并测试，直到能够明确哪一项改变了观察结果。

选择解析方式与验证缓存

普通 DNS 与加密解析方式具有不同的传输条件。加密传输能够改变解析请求在链路上的保护方式，但不自动保证解析更快、更准确或在当前网络中可达。若当前应用允许填写解析服务，应核对完整格式、协议支持和实际可达性。推荐优先保留工作正常的方式，只有在有明确需求且能够验证时才进行替换。

缓存会让修改后的结果看起来没有变化。缓存可能存在于应用、系统、浏览器或目标服务相关流程中，因此一次刷新不一定重新触发全部解析。测试时可先关闭旧页面或结束旧连接，再按当前应用提供的缓存操作处理，必要时重新连接。不要为了清理一次缓存就删除整个配置；也不要把偶然一次恢复归因于尚未验证的参数修改。

IPv4 与 IPv6 也会影响观察结果。一个域名可能同时具有两类地址记录，而本地网络对两类连接的支持并不相同。如果只有某些目标异常，应查看实际使用的地址类型和失败阶段。推荐先确认网络与服务器是否支持当前路径，再考虑相关选项；直接关闭某一地址族可能暂时绕过问题，却不能说明根本原因已经解决。

局域网名称与接入认证

访问家庭设备、办公资源或仅在特定网络内存在的名称时，本地解析环境可能不可替代。把所有域名交给同一个外部解析路径，可能导致这些名称失去原本的解析条件。排查这类问题，应先确认设备处于正确的局域网，再比较 Direct 与 Config 的结果，并检查该资源是否需要特定域名、地址范围或访问权限。

需要网页认证的无线网络应先完成接入流程，再测试代理连接。若系统尚未获得正常网络访问能力，修改 DNS 或反复切换服务器通常只会增加变量。可以先确认系统是否弹出认证页面，并用已知可用的普通访问动作检查网络。认证完成后再恢复原配置，重新建立连接，避免把认证前的失败日志与认证后的测试混在一起。

不要为了证明 DNS 正常而直接使用目标地址替代域名访问。使用加密连接的网站往往依赖域名进行证书校验和服务选择，直接访问地址可能产生另一类错误。更可靠的方法是查看解析是否有结果，再在保持原域名的情况下检查连接。测试过程中还应记录是否存在页面重定向，因为后续域名可能走了不同的解析或规则路径。

DNS 排查的收尾是恢复一个能够解释的稳定状态：保留有效设置，撤销没有证据支持的改动，重新测试最初失败的目标以及原本正常的本地资源。如果问题仍只集中在某个目标，应转向规则和目标服务检查；如果所有域名都失败但已有连接暂时可用，则优先继续检查解析链路。这样能够避免在同一选项上重复试错。

04 / CONNECTION LIFECYCLE

On Demand：触发条件与连接生命周期

On Demand 用于根据配置的条件触发连接，不是修改节点质量或规则优先级的选项。推荐先完成一次稳定的手动连接，再根据实际使用场景设置按需行为。默认状态、条件种类和具体动作以当前应用显示为准。启用之前，应能说明什么时候希望建立连接、什么时候希望保持断开，以及网络切换后应怎样恢复。

先建立手动连接基线

先暂时不依赖自动触发，在 Home 中确认所选服务器、Global Routing 与当前 Config，然后手动开启连接。若出现系统要求添加 VPN 配置的提示，应核对来源并按系统流程确认。授权完成只代表系统允许建立相应连接，不代表服务器资料已经正确，也不代表目标网站已经可达；仍需实际访问与日志验证。

当手动连接尚不稳定时，On Demand 只会自动重复一个不稳定的过程。应先解决认证失败、解析失败或路由问题，再设置触发条件。否则看到连接反复建立与断开，很容易误以为按需功能本身故障。检查顺序应是网络可用、服务器资料一致、手动连接可用、规则结果正确，最后才验证自动化条件是否按预期执行。

不要仅依赖系统状态栏中的图标判断连接质量。图标或应用开关能够提示连接状态，但不说明每个请求都成功。验证时应分别检查连接是否建立、一个明确目标是否可用、日志是否出现新的请求以及实际策略是否正确。把这些结果分开记录，才能区别“没有触发连接”和“已经连接但访问失败”。

条件设置与手动断开的关系

若当前界面提供按网络类型或网络条件设置动作，应逐项阅读条件含义，并按自己确实使用的网络填写。无线网络名称相似并不代表属于同一可信环境，不能只凭名称做安全判断。推荐先从少量、明确且容易复测的条件开始，不一次加入大量重叠条件；条件之间的匹配关系则以当前应用显示及实际测试为准。

手动断开后又自动连接，通常需要回到 On Demand 检查是否仍存在有效触发条件。只关闭一次连接开关，不一定等于撤销自动化规则。若需要持续保持断开，应先处理相关按需条件，再确认连接状态。测试后恢复日常设置时，也应同时复核条件与开关，避免只记得恢复其中一项而留下意外行为。

网络切换可能导致原有连接中断并重新建立。正在传输的任务不一定能够在新网络上继续，因此一次短暂失败不能直接判断规则失效。可以等待网络获得正常访问能力后发起新的请求，再查看日志时间线。若每次切换都会持续失败，先用手动方式重建连接，比较自动恢复与手动恢复的差异，再缩小排查范围。

锁屏、后台与系统限制

应用界面没有停留在前台，并不等于连接一定停止；界面仍然打开，也不等于系统网络状态始终不变。锁屏、网络变化和系统资源管理可能影响观察结果。推荐围绕可重复的具体场景测试，例如锁屏后重新打开同一目标，并记录是否需要重新连接。不要把单次后台停留的现象推导为所有设备都相同的固定行为。

耗电应结合使用时长、传输量、信号状况和连接重建频率一起判断。持续传输、信号较弱以及频繁重连都可能改变设备能耗，不能只根据 On Demand 是否打开就作结论。比较时保持网络、服务器与使用任务尽量一致，并观察较完整的使用过程；短时间切换多个设置后得到的电量变化，通常不足以定位原因。

若连接与其他系统网络配置互相影响，应先在系统设置中查看当前实际启用的连接和管理限制。受管理的设备可能存在由组织配置的约束，不能通过随意删除配置来处理。推荐在自己的可控范围内进行对照测试，并保留原有设置记录；不熟悉的系统配置应先确认用途，再决定是否调整，避免影响原本必需的网络访问。

完成按需设置后，至少验证三种状态：正常启动能够连接、网络变化后行为符合预期、需要断开时能够保持预期状态。任何一项不符合预期，都应先简化条件，而不是继续添加补偿规则。对于只在固定时段使用的情况，手动连接也可以作为清晰的操作选择；自动化的价值在于减少重复操作，而不是增加难以解释的状态。

05 / DIAGNOSTICS

Ping、Connectivity Test 与 Log

Ping 和 Connectivity Test 用于观察某种测试条件下的可达性，Log 用于记录具体运行过程。测试结果不是持续可用性的保证，也不是实际吞吐速度的直接测量。推荐把测试作为定位线索：先明确测试对象与方式，再结合真实访问和日志分析。测试方式、目标及默认选项以当前应用显示为准。

读懂测试对象，而不只看数字

一个测试可能关注服务器端口是否可达，也可能关注经由代理访问某个目标的完整过程。两种结果不能直接比较。前者成功，仍可能在后续认证或目标连接阶段失败；后者失败，也可能只是测试目标暂时不可达。操作前应查看当前测试方式及其说明，不把所有标为延迟的数值都理解成相同网络层面的往返时间。

较低的测试耗时不等于下载更快。实际速度还受本地信号、可用带宽、服务器负载、传输协议和目标服务限制影响。推荐在相同网络、相同测试方式与相近时间内进行有限次数的比较，观察结果是否稳定。不要把一次最快结果作为长期选择依据，也不要因为单次超时就删除条目；先确认能否重复出现相同现象。

测试前先确认选中了正确的服务器条目，尤其是备注相似或存在重复条目时。订阅更新可能改变条目集合，因此旧备注不能替代当前参数核对。若列表中的测试成功，而实际开启连接失败，应记录两个动作的时间与对象，检查它们是否使用同一条目、同一路由姿态和同一种网络，而不是直接认定测试功能不准确。

用 Log 串起一次失败请求

Log 的有效阅读单位是一次可重复的操作，而不是整页信息。先记下时间，再发起一个明确请求，随后查找相近时刻的域名、地址、规则与错误信息。界面实际提供哪些字段，以当前应用显示为准。如果日志很长，应缩小测试动作，不在同一时间打开多个页面，否则后台请求与子资源会让关键事件难以对应。

先看失败发生在哪个阶段：域名是否解析、是否找到处理策略、是否建立到服务器的连接、认证是否通过、目标是否响应。错误文字应保留原样，不随意把所有超时都解释成同一原因。超时可能发生在不同层级，连接被拒绝与认证失败也需要不同处理；应根据相邻事件和具体对象解释，而不是只截取最后一行。

观察现象	不能直接推断	下一步
测试耗时较低	实际传输一定较快	保持条件一致，验证真实任务
解析没有结果	服务器一定不可用	先检查 DNS 与本地网络
规则命中正确	后续连接一定成功	继续检查连接与认证阶段
仅一个目标失败	全部配置失效	检查目标域名、规则和响应

日志中出现地址或域名，不代表对应内容已经传输成功。它可能只是一次解析、连接尝试或规则匹配记录。同样，没有看到预期日志，也不一定意味着应用没有处理请求，可能是筛选条件、记录范围或请求没有真正发出。推荐先检查日志视图的筛选状态，再用一个新的、明确的访问动作验证记录是否正在更新。

保留最少必要的诊断材料

求助前应删除密码、认证令牌、完整订阅地址和可识别个人使用习惯的记录。服务器地址、备注与访问域名也可能暴露敏感信息，应按问题所需保留最小范围。可以描述“同一网络下手动连接失败，认证阶段报错”，并附经过处理的少量相关行；没有必要把整个配置和全部日志公开，尤其不能直接发送订阅原文。

详细记录可能增加存储占用和诊断噪声，推荐仅在需要时按当前界面提供的方式启用，并在排查完成后恢复原先状态。日志级别和初始状态以应用显示为准，不为追求“信息越多越好”而长期保留所有细节。清理前先保留解决问题所需的片段，清理后再复测一次，以免把旧错误误当作新的失败。

速度慢时按照本地网络、协议参数、线路状态、服务器负载逐层检查。每层只替换一个条件，记录真实任务的变化。更完整的比较顺序见连接后速度慢的分层排查。其中测试结果只能说明当时条件，不能据此推导未来稳定性，也不应用来评价或推荐任何连接服务。

诊断结束后，把解决问题的条件写清楚：修改了哪项、原值是什么、使用哪个目标验证、是否在第二种网络复测。没有效果的改动应撤销，临时切换的 Global Routing 也应恢复。这样下次出现相似现象时，可以从已知基线开始，而不是重复一轮没有记录的随机调整；日志的作用最终是减少变量，而不是增加操作次数。

06 / CONFIGURATION DATA

Subscribe、Add Server 与 Config 的数据边界

Subscribe 管理用户已有的订阅信息，Add Server 用于添加服务器条目，Config 管理配置文件。三者关联但不互相替代。推荐先确认拿到的资料属于哪一种类型，再选择对应入口；不要仅凭内容看起来像链接就使用同一种导入方式。默认字段与导入选项以当前应用显示为准，服务器参数则以用户已有资料为准。

订阅更新与运行配置分别核对

订阅通常用于获取和更新一组服务器条目，但不能因此假定它必然包含完整分流规则。导入后先检查实际生成的内容：条目数量是否发生变化、备注是否符合预期、是否出现解析错误。随后单独确认 Config 中使用的文件及 Global Routing。列表里有服务器，只能说明有连接资料，不代表规则已经完成选择。

订阅地址通常带有识别用户的参数，应像密码一样保存。复制时避免混入空格、换行或说明文字，粘贴后也不要把完整链接放入备注。若更新失败，先确认该地址仍有效，并根据当前网络环境检查访问结果；不要为了测试把它提交到不明网页。对于更新机制和内容含义不清楚的情况，应核对用户已有服务资料中的说明。

更新之前记录当前正在使用的条目，更新之后检查是否仍指向预期服务器。条目可能新增、删除或改变名称，原先选择可能因此受到影响。推荐保留能够确认身份的备注，同时避免把密码写进名称。遇到重复条目时，先核对它们的来源和实际参数，再决定清理；仅靠相同名称不能证明是同一连接端点。

Add Server 参数不能靠经验猜测

手动添加时，地址、端口和认证信息必须与已有资料一致。Shadowsocks、VMess、VLESS、Trojan、WireGuard、Hysteria2 等协议的字段并不相同，不能把某个协议的填写习惯直接套到另一个协议。推荐按当前选择的协议逐项检查必填项，保留字段英文原名，并对照资料确认含义；缺少参数时应先补齐资料，而不是随机尝试。

传输方式、加密连接相关字段和证书名称可能影响握手结果。服务器地址可达不代表这些字段已经正确。不要为了绕过报错随意关闭证书验证，也不要把访问失败一律归因于密码。应先记录原始错误，再检查域名、时间、认证资料和协议要求是否一致。安全校验的失败需要定位原因，不能只追求开关变成已连接。

二维码导入也需要检查结果。Scan QR Code 能够减少手动输入，但不能替代参数核对；来源可信也不代表当前资料仍然有效。导入后检查协议、地址、端口和备注，确认没有误选其他条目，再尝试连接。如果内容并非当前入口支持的数据类型，应停止重复扫描，先识别它是服务器资料、订阅地址还是其他配置内容。

Config 的编辑、选择与回退

编辑 Config 前先保留副本，并在副本中做局部修改。一个配置可能包含通用设置、规则和其他章节，不应为了加入几行规则就删除原有内容。保存后查看应用是否提示格式问题，再确认运行时选中了这份文件。文件在列表中的位置、最近编辑时间或显示名称，都不能单独作为正在使用的证据，应以实际选中状态为准。

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

示例只展示规则语法，其中私有地址范围也仅用于解释按地址匹配的方式。真实局域网可能使用其他范围，不能照抄后认定已经覆盖所有本地资源。DOMAIN 与 DOMAIN-SUFFIX 的匹配范围不同，FINAL 应作为兜底理解。推荐先针对一个明确目标验证，再扩大规则范围；修改后同时检查预期目标和相邻功能，避免引入误伤。

远程配置的更新可能带来规则变化，因此本地编辑与远程更新之间需要明确分工。更新前确认哪些内容需要保留，更新后查看关键规则是否仍然存在。不要把一个持续更新的来源与大量未记录的本地改动混在一起，否则很难判断变化来自哪里。对于重要修改，应记录用途和验证方法，并保留能够恢复到上一个可用状态的副本。

多个订阅并存时，推荐按来源用途建立清晰备注，先整理再清理。删除订阅与删除其生成条目的实际影响，以当前应用操作提示为准，确认前不要连续批量操作。更具体的整理顺序见多个订阅的分组、排序与重复条目处理。本手册只说明已有资料的管理方法，不提供、不销售、不推荐节点或订阅。

本章的最终检查是让三种数据各归其位：Subscribe 能够更新已有条目，Add Server 中的参数与资料一致，Config 已选择并能产生预期规则结果。若其中一层失败，先在该层处理，而不是反复重新导入所有内容。需要从头完成操作主线时，可返回快速使用说明，按导入、选择、连接和验证的顺序执行。

07 / CONTINUITY

Widget 是便于查看或触发操作的系统入口，iCloud 相关功能用于当前应用支持范围内的数据延续。两者都不能替代主界面中的实际状态核对，也不能证明连接已经成功。推荐先在主应用中完成验证，再加入快捷入口或同步流程。可用能力、同步范围和默认状态以当前应用与系统显示为准，不假定所有数据都会同步。

Widget 显示与真实连接分别验证

添加 Widget 时，应使用系统提供的小组件管理流程，查看当前设备实际可选的 Shadowrocket 组件及尺寸。组件种类与交互方式以系统界面为准，不根据其他设备的布局推断。添加后先从主应用确认连接和所选条目，再观察组件显示是否对应。组件没有立即变化时，先返回应用检查真实状态，不要连续点击制造多次连接切换。

系统可能控制组件刷新时机，因此显示内容可能不是每一瞬间都与主应用完全同步。若组件显示异常，而主应用能够正常连接，应先把问题限制在显示与刷新层面检查。推荐通过一次明确的连接或断开操作进行比较，并留出系统更新显示的时间；反复更换服务器或删除配置，通常不能直接解决组件自身的刷新问题。

锁屏或桌面上可见的备注可能泄露使用信息。给服务器和配置命名时，应兼顾识别与隐私，不把完整地址、认证资料或订阅链接写进容易展示的位置。共享设备还应考虑其他使用者能否看到或触发操作。推荐使用能够区分用途但不含敏感凭据的简短名称，并在添加组件后检查实际呈现，而不是只在应用列表中检查。

iCloud 同步前先明确数据范围

启用同步前，应先检查系统账户、iCloud 可用状态，以及当前应用提供的相关选项。同步范围需要逐项确认，不能把“已开启 iCloud”理解成服务器、配置、日志、连接状态与所有偏好都已完整保存。推荐先用一项不含敏感资料的可识别改动验证同步，再决定是否依赖它进行设备间整理；默认状态以当前应用显示为准。

同步是数据状态的延续，不是历史备份库。一次误删或错误修改也可能影响其他设备，因此重要内容仍需保留独立副本。副本应注明其用途和包含范围，并存放在自己能够控制的位置。不要只因为第二台设备能看到一个文件名，就认定全部内容已经同步成功；应打开核对关键条目，再确认是否能够用于实际连接。

多设备同时编辑容易让来源变得不清楚。推荐先指定一台设备完成整理，等待其他设备出现预期结果后再继续操作。若出现同名副本或内容差异，先分别保留，再比较关键字段，不要立即删除其中一份。比较时重点看规则顺序、服务器参数和备注对应关系，而不是仅看文件名；名称相同并不能证明内容一致。

区分导入文件与持续同步

Import from Cloud JSON 应按当前应用提供的入口与提示理解。一次从文件导入内容，不等于已经建立持续同步；文件被成功读取，也不代表所有字段都适用于当前设备。操作前确认文件类型与来源，操作后检查实际生成或改变的内容。不要凭文件扩展形式猜测其中一定是服务器条目，更不要把来源不明的数据直接覆盖到可用配置上。

系统网络授权通常需要在具体设备上核对，不能因为另一台设备已经允许连接，就推断当前设备也完成授权。新设备首次连接时，应按系统提示确认，并重新验证本地网络、服务器与规则。应用购买的适用范围及兼容性以 App Store 页面标注为准；同步内容可见与设备满足运行条件，也是需要分别确认的两件事。

若同步迟迟没有出现结果，先检查两台设备的系统账户与网络状态，再查看应用内相关选项，最后再判断是否需要重新导入。不要在未保留副本前关闭并清除云端数据，也不要通过连续开关同步来碰碰运气。每次改变只涉及一个环节，并记录另一台设备实际出现的变化，才能判断是传输延迟、范围差异还是内容冲突。

完成设置后，把组件和同步当作辅助入口，而不是唯一控制面。日常出现异常时，仍回到主应用确认连接、Global Routing、当前 Config 与服务器选择。定期检查备份能否读出、敏感信息是否出现在可见备注中，以及不再使用的副本是否需要整理。这样既保留操作便利，也维持清晰、可核对的设备状态。

08 / LOCAL LISTENING & REVIEW

Proxy 端口、本地监听与设置复核

Proxy 相关端口描述的是特定代理服务的监听位置，不能与远端服务器端口混为一谈。是否提供 HTTP、SOCKS5 或其他本地监听选项，以及它们的默认值和生效条件，均以当前应用显示为准。推荐没有明确需求时保留现有设置，不猜测固定端口，也不为了改善速度随意更改监听参数。

区分远端端口与本地监听端口

Add Server 中的端口通常用于连接用户已有的远端服务器，必须与服务器资料一致。本地 Proxy 端口则用于让符合条件的请求连接到本机提供的代理入口。两者处在不同位置，修改本地端口不会改变远端服务监听的端口，也不会自动修复远端认证错误。排查前先确认正在编辑哪一种端口，并把对应地址一起记录。

一个代理入口需要地址、端口和协议共同构成，仅知道端口数字不足以完成连接。使用 HTTP 方式连接到仅支持 SOCKS5 的入口，或将远端地址与本地监听端口拼在一起，都可能失败。推荐严格依据当前应用显示的能力与已有需求进行配置，不把网页中看到的常用数字当作默认值，也不把端口号大小当作性能指标。

监听地址决定哪些来源可能访问入口。仅面向本机的地址与面向局域网的地址，作用范围不同；若当前界面提供相关选项，应先阅读说明再决定。开放到更广范围可能使同一网络中的其他设备尝试连接，因此必须确认访问边界与认证能力。没有明确跨设备需求时，推荐保持最小必要范围，并在测试结束后撤销临时开放。

判断生效条件、冲突与可达性

本地监听能否使用，可能与应用连接状态、当前启用的功能及系统网络条件有关。先确认应用确实处于预期运行状态，再从需要使用代理的那一端检查地址和协议。不能因为设置页保存了端口，就推断任何时间都在监听；也不能因为本机可用，就推断其他设备一定可达。两种测试对应不同的访问路径。

如果出现端口占用或无法绑定的提示，先保存原始错误，并核对是否存在重复使用相同监听位置的情况。端口的有效数字范围并不意味着其中每个值都适合当前用途，系统限制和现有服务也可能影响绑定。推荐根据明确需求选择可用值，修改后重新确认保存与生效情况，不通过连续随机输入数字来掩盖冲突原因。

局域网访问还取决于设备是否处在同一可互通的网络、无线网络是否隔离设备以及地址是否发生变化。访客网络可能允许访问互联网，却不允许设备之间直接通信。排查时先验证基础互通条件，再检查 Proxy 入口，不能把所有失败都归结为 Shadowrocket。共享网络环境中应保持谨慎，完成临时测试后及时恢复原先边界。

检查项	默认值处理	推荐取值原则
远端服务器端口	以已有服务器资料为准	与远端实际服务一致
本地 Proxy 端口	以当前应用显示为准	满足用途且没有监听冲突
监听地址	以当前应用显示为准	最小必要访问范围
入口协议	核对当前可用能力	与使用端的配置一致

修改后的完整复核与恢复路径

端口修改完成后，应分层验证：入口是否可达、协议是否匹配、请求是否进入应用、路由是否符合预期、目标是否返回结果。前一层成功不代表后一层成功。例如已经进入应用但目标超时，应继续查看服务器连接与规则；入口完全不可达时，则先处理监听状态和网络范围，不必立即更换远端服务器。

对所有 Settings 修改，都可以使用同一张复核清单：记录原值、说明修改目的、只改变一个变量、使用固定目标测试、检查日志、验证原本正常的功能、保留有效修改并撤销其他修改。对于没有明确改善的变动，应优先恢复原值。设置保持少量且可解释，通常比积累大量“可能有用”的开关更便于长期维护。

应用更新后不需要机械地重做全部设置，但应核对常用选项和关键流程是否仍符合预期。更新通过 App Store 管理，具体变化以商店页与应用内显示为准，不根据旧截图猜测新界面。先测试日常连接、配置选择和必要的按需行为；若出现差异，保留原有数据并逐项核对，而不是立即清空后重新开始。

最后将维护记录收敛为能够复现的状态说明：使用什么网络、哪一份 Config、哪个服务器条目、何种 Global Routing，以及哪些 Settings 曾经调整。记录无需包含真实凭据，却应足以让自己再次建立相同环境。遇到未解决的问题时，返回对应章节继续定位；首次操作流程查阅使用说明，购买与设备要求查阅下载页，各页面分别承担清晰的查阅任务。