Shadowrocket Settings 设置手册

一、Settings、Config 与运行状态的作用范围

调整前先确认问题属于哪一层。Settings 中的应用偏好、Config 中选用的配置文件、Home 中选择的服务器与连接开关，并不是同一份状态。服务器决定连接目的地与协议参数，配置文件决定规则及相关处理方式，Global Routing 决定当前采用哪种分流姿态。只修改某个设置，不代表另一层已经随之切换；排查时应把这几处分别记下来。

Global Routing 的三种姿态

日常需要按规则处理请求时，使用 Config，并核对 Config 页面当前选中的文件。Proxy 适合临时确认代理路径，Direct 适合对照直接连接的表现；它们不是修复错误配置的替代品。尤其不能因为切到 Proxy 后某个网页能打开，就断定 DNS 与规则全部正确：这只能说明当前测试条件下，选用的代理路径能够完成该次访问。

默认值、当前值与建议取值

默认值指应用尚未经过相关调整时提供的初始状态；当前值可能已经被用户编辑、配置导入或恢复操作改变。看到开关处于开启状态，只能确认现在开启，不能据此推断它最初如此。本手册的建议是：不清楚用途的选项先保持原状，只有在能够描述问题、知道验证方法时才修改。涉及服务器协议的字段，以已有服务资料为准，不用所谓通用参数替换。

建立基线不需要清空数据。先记录 Global Routing、当前 Config 文件名、选中服务器以及相关开关；如果准备编辑配置，先保留本地副本。然后选择一个稳定、可重复访问的目标，记录在当前网络中的现象。每轮只改变一个条件，例如只换 DNS、只切服务器或只停用 On Demand，避免同时改动后无法确认究竟哪项产生影响。

配置文件中的设置怎样参与排查

配置文件可包含全局参数、规则和本地映射。下列片段用于说明结构，不是要求覆盖现有文件。示例域名只是教学对象，PROXY 应在当前运行环境中有可用的代理选择；若原文件使用具体策略名称，应保留有效引用。导入后还要确认文件被选中，并通过请求记录检查实际命中结果，而不是只确认文本保存成功。

[General]
dns-server = system

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

[Host]
localhost = 127.0.0.1

修改后的验证应包含三件事：目标请求是否成功、是否采用预期策略、其他常用目标是否仍然正常。失败时先恢复刚改动的一项，再比较结果。若恢复后仍异常，应检查测试期间是否发生网络切换、订阅更新或服务器变化。配置段落的详细结构见配置文件结构详解；首次导入步骤仍以教程页为主。

二、DNS：解析来源、配置覆盖与缓存判断

DNS 负责把域名解析成可连接的地址，但解析成功不等于连接成功。网页打不开，可能发生在域名解析、代理服务器连接、目标连接或后续加密通信阶段。调整 DNS 前，应先判断故障出现在哪一步：记录是否显示解析失败、是否已有目标地址、服务器本身是否可用。仅凭浏览器的一句连接失败提示，不能直接认定解析器有问题。

dns-server 与 system 的含义

在配置文件中，dns-server = system 表示使用系统提供的 DNS 解析来源。这是便于与当前网络对照的建议基线，并非本手册对所有设备出厂默认值的声明。系统解析条件也会随接入网络改变，因此同一配置在不同 Wi-Fi 与蜂窝网络下表现可能不同。若已有配置明确指定其他解析来源，应先弄清指定原因，再决定是否回退。

需要指定解析服务时，使用自己能够核验、符合当前网络要求的地址与格式。普通 DNS 与加密 DNS 的连接条件不同，后者还涉及服务域名、证书及到解析服务的网络路径。把一个地址填进输入框，并不意味着该方式一定可用；保存后应检查应用是否接受该格式，再通过新请求验证。不要将 DNS 地址当作代理服务器地址填写。

先检查配置与 Host，再更换解析器

如果只有单个域名异常，先检查当前配置中的 [Host] 是否存在对应映射。显式映射可能让请求继续使用固定地址，更换解析来源未必改变结果。再检查规则是否把该域名交给不符合预期的策略。规则命中与 DNS 查询不是同一个判断过程，观察到代理访问失败，也不能据此推断域名解析到了错误地址。

缓存会使改动后的第一轮验证不够直观。系统、应用以及目标网站使用的连接都有可能保留已有状态；切换解析来源后，已经建立的连接不一定重新解析。建议关闭正在测试的页面，重新发起请求，必要时按应用提供的清理入口处理相关缓存，再重新连接。不要把所有网站数据一并清除当作固定步骤，以免丢失与排错无关的登录状态。

IPv6、接入网络与解析故障的边界

有些目标同时提供 IPv4 与 IPv6 地址，而当前网络对两类地址的可达性不完全一致。若记录显示解析成功，但特定地址族的连接持续失败，才考虑围绕对应设置做单项对照。直接关闭相关能力可能暂时改变现象，却不能说明根因已经修复。应保留改动前的记录，并确认其他依赖该地址族的访问是否受到影响。

推荐排查顺序是：确认当前 Config，核对 dns-server 与 Host 条目，检查记录，再更换一个解析条件进行对照。测试时保持服务器与 Global Routing 不变。若只在某个接入网络失败，优先记录该网络的系统解析与认证状态；若切换网络仍失败，再检查配置本身。完成验证后撤回没有改善的调整，避免把临时试验长期留在配置中。

三、On Demand：自动连接的触发与停止条件

On Demand 用来按设定条件触发连接，不负责选择正确的规则，也不会替用户补齐服务器资料。开启前，应先确认手动连接能够工作：已有服务器可以连接，当前 Config 能正常使用，系统 VPN 配置授权已经完成。如果手动连接本身失败，先处理服务器、DNS 或规则问题，否则自动触发只会反复遇到同一个故障。

什么时候适合启用

当使用场景具有明确条件，例如希望在指定网络环境下自动建立连接，才适合配置 On Demand。首次设置建议先保持停用，完成手动验证后再单独启用；这里的停用是建议排查基线，不是宣称应用的统一默认状态。已经启用的设备，应先记录当前规则与条件，不要直接删除，因为其中可能包含用户为特定网络保留的例外。

设置时从 Settings 中查找 On Demand，逐项阅读当前界面实际提供的条件。不同条件之间可能存在匹配与顺序关系，应核对每条规则的动作以及覆盖范围。如果使用网络名称作为条件，注意名称只是匹配信息，并不等同于网络可信证明；多个接入点可能使用相同名称，名称变化也可能使原有条件不再适用。

系统 VPN 授权与应用开关的区别

首次建立连接时，系统可能要求添加 VPN 配置。该授权允许系统建立相应连接，并不等于已经导入服务器，也不表示所有应用设置已经完成。若授权流程中断，应返回应用检查连接状态，再根据系统提示处理。不要连续重复创建配置来碰运气；先确认现有配置与应用对应，再排查是否存在管理策略或其他连接配置的影响。

On Demand 启用后，手动断开与停止自动触发是两种操作。用户可能刚关闭连接，新的网络活动又满足条件，系统便再次发起连接，看起来像“开关自己打开”。遇到这种情况，先暂时停用 On Demand，再断开连接进行对照。若不再重连，就应检查触发条件，而不是把自动重连直接当作应用异常。

怎样做一次完整的触发测试

测试应覆盖进入条件、保持连接与离开条件三个阶段。先记录接入网络与当前连接状态，再启用 On Demand，按条件切换网络并发起一次正常访问。观察系统连接状态与应用记录，确认连接确实由预期条件触发。随后离开该条件，检查实际行为是否符合设置，而不是只看首次触发成功就结束验证。

需要登录认证的公共 Wi-Fi 应单独测试。网络尚未完成认证时，解析与服务器连接都可能受到限制；自动连接不能代替网络认证。如果认证页面无法显示，可以在明确了解当前操作的情况下暂时停用自动触发，完成网络认证后再恢复原设置。不要把认证期间的失败记录与正常联网后的结果混在一起比较。

如果设备受组织管理，部分 VPN 行为可能受到系统策略约束，本页的个人设备操作不能覆盖这些限制。恢复原状时，先停用 On Demand，再恢复原有条件与连接选择，最后重新手动验证。对于“断开后又连接”或“只在某个网络触发”的疑问，可继续查阅常见问题，但应保留当时的网络条件，避免只描述开关外观。

四、Ping 与 Connectivity Test：测试结果的边界

Ping 与 Connectivity Test 用于观察连接条件，不应被当成真实业务质量的完整结论。一次测试成功，说明当时使用的测试方式能够完成相应交互；网页、视频或其他请求仍可能因为解析、规则、目标服务或协议条件不同而失败。测试前应先核对方法、目标与超时条件，避免把不同含义的数字直接放在一起比较。

测试方法决定数字说明什么

在 Settings 中查找 Ping 相关设置，先阅读当前界面所选的测试方法。如果提供 TCP 类测试，它主要反映到目标端口的连接条件；如果提供通过代理发起的 HTTP 类测试，还会涉及代理协商、测试地址及响应过程。它们测量的阶段不同，因此即使显示相同单位，也不能不加区分地认定数值越小就一定更适合所有访问。

默认测试方式、测试地址与超时值应以当前应用显示为准，本页不预设一个固定数字。建议先使用现有设置建立可重复基线，只有在测试目标本身不可达、方法不符合排错目的时才调整。使用自定义测试地址前，确认地址稳定且自己有权访问；不要把需要登录、频繁跳转或限制自动请求的页面当作通用连通性目标。

超时不等于所有请求都失败

超时表示测试未在指定时间内完成，不足以单独判断服务器完全不可用。原因可能是端口不可达、协议参数不匹配、测试目标受限，或者测试期间网络发生切换。相反，快速返回也不能证明大文件传输稳定。遇到超时，应先在相同条件下复测，再用一个正常业务请求验证，并把两者的结果分别记录。

怎样比较已有服务器

比较时应保持接入网络、测试方法、测试目标与其他设置一致。先等待网络切换稳定，再对用户已有的服务器进行少量重复测试，观察结果是否持续接近，而不是挑选偶然出现的最小值。测试本身会产生网络请求；不需要为了排序而高频连续测试，更不能把某一时刻的顺序解释成长期可靠性排名。

协议字段错误也可能造成“地址可达但无法使用”。例如端口连接成功，只说明该端口有响应，不代表认证信息、加密方式或服务器名称等参数正确。应回到 Add Server 中核对已有服务资料，尤其注意复制时的空格、端口与字段位置。不要为了让测试变绿，随意关闭证书校验或更改协议安全参数。

把测试结果接回实际访问

完成 Connectivity Test 后，明确选中用于验证的服务器，再核对 Global Routing 与当前 Config。测试列表中某个条目成功，不代表当前连接已经切换到它；列表排序发生变化，也不能作为切换成功的依据。用一个可重复的目标请求验证，并从记录中确认实际采用的路径，才能将测试结果与真实访问对应起来。

若出现开关已打开但无法访问的情况，按网络、服务器、模式、DNS、规则的顺序检查，比反复测试所有条目更容易定位。详细流程见连接开关打开却无法访问的排查清单。问题描述中应写明测试方法及失败阶段，避免仅提供一个超时截图；这能减少把测试目标故障误认为服务器故障的情况。

五、Log 与 Data：请求记录、流量统计和隐私处理

Log 用于还原发生过什么，Data 用于观察应用统计范围内的数据变化，两者承担不同任务。连接开关打开，只能说明已经尝试建立相应连接，不能证明每个请求都按预期处理。遇到异常时，应从一次可复现请求入手，把发生时间、目标域名、命中策略与错误信息联系起来，而不是一次性浏览大量历史记录寻找看似相关的行。

日志详细程度如何选择

在 Settings 中核对 Log 相关选项与当前记录级别。若界面提供不同详细程度，日常保留足够观察问题的级别；需要排查具体故障时，才临时提高记录细度。当前选中项才是该设备的实际状态，本页不把某个级别写成固定默认。详细日志可能增加存储与处理负担，完成排查后应恢复原设置，并按需要清理记录。

复现前先记下时间，必要时清理本次排查无关的旧记录，再只访问一个目标。观察先后顺序：是否发生解析、是否得到地址、是否选择策略、是否开始连接、最终在哪个环节失败。不同记录行可能属于并发请求，不能仅因为相邻就认定属于同一连接；应结合目标、时间及应用展示的关联信息判断。

从规则命中确认设置是否生效

若本来希望某个域名走 PROXY，记录却显示 DIRECT，应先检查 Global Routing 是否为 Config，再检查规则顺序与当前文件。下面的片段表达“指定域名优先代理，其余直接连接”。规则按顺序判断，FINAL 放在末尾；示例只用于说明命中逻辑，不代表应覆盖用户现有配置。编辑后要重新发起请求，已有连接不一定立即重新匹配。

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

如果前面已经有一条范围更大的规则命中目标，后面的规则不会因为写得更具体就自动获得优先级。应检查完整列表，而不只看新添加的两行。DOMAIN、DOMAIN-SUFFIX 与 IP-CIDR 匹配对象不同，DNS 得到的地址也不等同于原始域名。规则基础可参阅规则关键字与匹配顺序。

Data 数字为什么不能直接当作账单

查看 Data 时，先确认界面展示的是当前会话、某个条目还是累计范围，并核对是否曾经重置。应用统计与服务方账单可能采用不同周期与口径，协议开销、统计边界和时间区间也可能不同。数字不完全相等并不直接表示异常，应先统一比较区间，再阅读已有服务对流量计算的说明。

连接后仍有少量数据变化，可能来自正常的连接维护、解析或其他应用请求，不能仅凭计数增长认定某个目标正在持续传输。需要判断来源时，应与请求记录结合。重置统计前先记录原数值和时间；重置通常用于建立新的观察起点，不会改变已经发生的服务用量，也不能用于修复连接问题。

导出与分享前的必要检查

日志可能包含访问域名、服务器地址、请求路径或认证相关内容，订阅资料还可能带有个人标识。分享前应复制必要片段，删除密码、完整订阅地址、令牌及可识别个人的信息。不要只遮住画面上最显眼的一行，却保留其他位置的同类内容。能够用错误阶段与少量上下文说明的问题，不需要公开整份记录。

一次有效记录应能回答：何时测试、在哪个网络、使用哪个模式、出现什么结果。完成定位后关闭临时详细记录，按需要清理导出副本，并恢复统计观察口径。后续再次出现问题时，用相同方法收集新的最小复现材料，比长期保留大量包含敏感信息的历史内容更便于判断。

六、Widget：快捷入口、状态刷新与系统限制

Widget 的作用是提供系统允许范围内的快捷入口或状态展示，不能代替应用内完整设置。它能否及时更新、提供哪些操作，受当前应用提供的组件与系统机制影响。设置前先在 Shadowrocket 中完成手动连接验证，再添加系统可用的组件；不要把组件已经出现，理解成服务器已导入、配置已选中或系统授权已经完成。

添加前先检查应用中的基础状态

先打开 Home，确认当前选择的服务器与连接状态，再到 Config 核对有效文件。需要通过规则分流时，还应确认 Global Routing 为 Config。随后检查 Settings 中当前提供的 Widget 相关选项；只调整能在设备上实际看到的项目。本页不预设组件数量、尺寸或固定按钮排列，也不把某种显示方式当作所有设备共同的默认状态。

在系统添加组件的界面中查找 Shadowrocket，选择当前可用的样式。若没有看到入口，先确认应用已完成首次打开，再按照系统当前的组件添加流程检查。系统要求以 App Store 页面标注为准。不要为了寻找某个并不存在于当前界面的样式，重置整份应用数据；先回到应用确认其基本功能是否正常。

显示状态与实际连接怎样对照

组件可能显示上一次刷新时的状态，不一定与应用内的实时画面完全同步。看到状态没有立即变化时，应打开应用检查，并通过实际请求验证。系统连接标识也只是其中一个观察点：它不能说明某个目标具体走了哪条规则，更不能证明服务器能够访问所有目标。判断时应将组件、应用与请求记录分开看待。

快捷操作与 On Demand 的交互

若通过快捷入口断开后又重新连接，先检查 On Demand。组件执行的操作与自动连接规则可能先后发生，最终状态不能只用刚才的一次点击解释。需要暂时停止自动连接时，应先在应用中处理自动触发条件，再执行断开。反复点击可能产生交错操作，使观察结果更难理解，建议每次操作后等待状态稳定再继续。

处于锁定状态、系统限制后台活动或需要额外确认时，快捷操作的完成方式可能与应用内直接操作不同。应遵循系统实际提示，不把后台权限、低电量模式或刷新设置视为必须全部放开的固定清单。只有能够复现某项系统限制对当前功能的影响时，才进行单项对照，并在验证后恢复不必要的调整。

显示内容与设备隐私

组件放在容易被他人看到的位置时，显示名称可能暴露服务器用途或个人使用习惯。为用户已有的条目设置便于辨认、不过度包含个人信息的名称，有助于降低误选和展示风险。不要把密码、订阅令牌或完整服务地址写入名称。名称主要用于识别，不会改变服务器认证信息，也不能用名称判断协议配置是否正确。

推荐基线是先让应用内流程稳定，再只保留自己确实需要的快捷入口。删除系统组件通常不等于删除应用中的服务器或配置，但实际清理前仍应区分操作对象。若问题只发生在组件中，先从应用内重复同一操作；若应用内也失败，就转入连接排查，而不是继续调整组件布局。这样可以把系统展示问题与网络处理问题分离。

七、iCloud 同步：数据范围、冲突与恢复顺序

iCloud 相关功能用于在当前支持范围内保存或同步应用资料，不应被理解为所有运行状态都会自动复制。服务器条目、配置文件、应用偏好与系统 VPN 授权属于不同对象，具体支持哪些内容，应以当前应用提供的入口与说明为准。首次使用前先保留本地可用副本，避免在尚不清楚同步方向时覆盖唯一可工作的配置。

先区分同步、导入与购买恢复

App Store 已购恢复处理应用的获取资格，不负责恢复用户的服务器与配置。使用原 Apple 账号重新获取应用后，仍应检查本地资料是否存在，再决定通过何种方式恢复。购买步骤见换机与已购恢复说明。通用购买适用性以 App Store 页面标注为准，不能从某台设备已经安装推断所有设备上的资料都相同。

同步强调多处资料之间的更新关系，导入通常是把选定内容加入当前应用，两者并不等价。看到 Import from Cloud JSON 时，应按该入口要求选择相应格式，不把普通配置文本或订阅地址直接当成同类文件。导入前核对来源、内容类型与目标位置；操作后检查是否产生重复条目，以及当前实际选中项是否仍然正确。

默认状态与推荐启用条件

iCloud 开关的当前状态可能受到设备系统设置、应用偏好与恢复记录影响，本页不声明统一默认。建议在单台设备上先验证资料有效，再按需要开启同步。若只使用一台设备且没有同步需求，保持现有方式即可。开启前检查系统是否允许 Shadowrocket 使用对应的 iCloud 能力，并确认账号与存储状态正常。

同步后不要立即删除本地副本来验证“云端是否真的保存”。更稳妥的方法是在另一台已具备使用条件的设备上检查可见资料，并确认文件内容、条目数量与必要字段。同步完成的界面提示，也不能替代实际连接测试；系统授权、当前服务器选择和网络环境仍需在该设备上单独核对。

多设备编辑发生冲突时

不要在两台设备上同时修改同一份重要配置，再期望系统自动合并出正确结果。网络延迟或离线编辑可能导致不同副本先后到达，修改时间也不等于内容一定更适用。计划调整时，先指定一台设备作为本次编辑端，保存副本、完成验证后再检查另一台。看到差异时先比较内容，不急于用其中一份覆盖全部资料。

订阅更新不等于云端同步

订阅更新从用户已有的订阅来源读取内容，iCloud 同步则涉及应用支持的数据对象。某份本地配置已同步，不代表订阅已经更新；订阅更新成功，也不说明另一台设备已经收到最新副本。排查时分别记录这两类操作，避免把“更新后条目变化”错误归因于云端覆盖。需要保留的本地备注或编辑内容，也应先确认更新行为是否会影响它们。

导出资料可能包含服务器认证信息，保存与传递时应按敏感数据处理。删除前先确认操作影响的是本地副本还是同步对象，不要假设删除只发生在当前设备。完整恢复顺序应是：取得应用、恢复资料、核对字段、选择配置、处理系统授权、手动验证，最后才恢复 On Demand。这个顺序便于定位问题，避免自动连接掩盖资料尚未恢复完成的事实。

八、Proxy 端口：本地监听、访问范围与回退验证

Proxy 端口相关设置需要先区分两种地址：服务器条目里的远端端口，以及本地提供代理入口时使用的监听端口。前者属于用户已有服务资料，后者属于当前设备上的接入设置。修改本地监听端口不会修复远端服务器端口填写错误，也不会改变远端认证参数。排查前先确认自己正在编辑哪一类字段，避免把同一个数字填进所有位置。

什么时候需要调整本地端口

普通的系统 VPN 连接流程不应仅为“优化”而随意改动本地 Proxy 端口。只有明确需要通过应用提供的本地代理入口接入，或已经确认监听冲突时，才检查相关设置。当前应用显示的协议类型、监听地址与端口才是实际依据，本页不指定固定默认端口。若界面没有提供某项能力，不应根据其他资料自行补造设置入口。

端口必须是有效数字，并与接入端填写的值一致。HTTP 与 SOCKS5 是不同的接入方式，不能因为都称为代理就互换配置。连接被拒绝时，先检查监听是否启动、地址与端口是否正确、所选协议是否对应，再检查后续远端路径。不要一开始就更换 DNS，因为请求可能尚未成功到达本地代理入口。

本机地址与局域网地址的区别

127.0.0.1 表示发起连接的设备自身。另一台设备填写这个地址，不会指向运行 Shadowrocket 的设备。需要跨设备接入时，必须确认应用当前确实提供并启用了相应访问能力，使用正确的局域网地址，并核对两台设备是否能够互通。接入点隔离、不同网段或设备休眠，都可能让端口无法连接。

允许更大范围访问会改变谁能使用该入口，不能只为一次测试就长期保持。若应用提供访问限制或认证选项，应结合实际需求设置；不需要共享入口时，推荐限制在本机范围，并保持相关扩展访问功能停用。这里仍是安全排查基线，而不是对应用出厂默认的声明。不要把本地代理入口暴露到自己无法控制的网络范围。

防止重复转发与错误回路

不要把本地代理入口又作为当前链路的远端服务器使用，否则可能形成重复转发或连接回路。若修改后出现大量重复连接、持续超时或异常流量，应立即停止本次测试，恢复原先的服务器选择与监听设置，再检查引用关系。诊断时先画清“请求从哪里进入、经过哪个策略、最终连接哪里”，比连续替换端口更有效。

规则文件仍然需要独立验证。希望只让指定域名走代理时，应检查 Config 模式与 DOMAIN-SUFFIX 等规则，而不是依靠端口设置实现目标选择。具体场景见只代理指定网站的规则写法。本地入口是否可连接与目标是否命中 PROXY，属于两个不同层次，测试材料应分别记录。

统一的变更验收与回退顺序

完成任一 Settings 调整后，先验证直接受影响的功能，再验证常用访问没有被改变。记录修改前后值、网络条件与结果；没有明确改善的改动应撤回。若同时涉及同步与自动连接，先稳定本地配置，再确认同步内容，最后启用 On Demand。这样可以避免配置仍在变化时，把自动触发结果误认为最终验收。

需要继续定位时，按本页的作用范围、DNS、测试、日志顺序查阅，并通过快速上手教程重建最小可工作流程。出现购买、恢复或设备要求问题则转到下载说明，不用改网络参数解决账号问题。手册中的建议应与当前应用实际界面共同使用：能够解释改动目的、复现验证结果并保留回退路径，才算完成一次设置调整。