Shadowrocket Settings 设置手册

Chapter 01

Settings 的阅读顺序与可恢复基线

先区分连接状态、路由姿态和设置参数

Shadowrocket 的常见问题往往不是某一个开关单独造成，而是 Home 的连接状态、Global Routing 的当前姿态、选中的 Config、服务器信息以及 Settings 参数共同作用的结果。开始调整之前，先在 Home 确认当前选中的服务器或配置是否符合预期，再记录 Global Routing 处于 Config、Proxy 还是 Direct。Config 表示按照配置文件中的 Rule 逐条匹配；Proxy 表示将适用流量交给当前 Proxy；Direct 表示直接连接。三种姿态的用途不同，不能把 Direct 下观察到的结果当成 Config 规则失效，也不能在 Proxy 下判断某一条 DIRECT 规则是否命中。

Settings 更适合处理解析、连接触发、测试方式、日志记录、同步和本地端口等行为。它不会替代服务器信息，也不会自动补充用户尚未配置的服务。使用本手册时默认用户已经持有自己的 Subscribe 地址或服务器参数，并且知道这些信息应由原提供方维护。Shadowrocket 是在 App Store 购买的一次性付费客户端；客户端一次性买断 ≠ 线路套餐，购买应用本身不包含可用服务器信息。有关开发者名 Shadow Launch Technology Limited、应用 ID 932747118 与商店入口的核对方法，可查看下载指南的正版核验部分。

建立修改前的四项记录

建议在更改任何设置前写下四项基线。第一项是网络环境，例如当前使用家庭 Wi‑Fi、办公 Wi‑Fi 还是蜂窝网络；第二项是 Home 中实际选中的服务器条目；第三项是当前 Config 名称和 Global Routing 姿态；第四项是问题的可重复现象，例如“只有某个域名无法解析”“切换到蜂窝网络后不会自动连接”或“Connectivity Test 在某一步停止”。这四项信息能把模糊的“不能用”拆成可验证条件，也便于在恢复设置后判断是否回到原状态。

修改时采用单变量方法：一次只调整一个项目，保存后关闭再重新建立连接，然后执行相同的验证动作。若同时更换 DNS、Config、服务器和 On Demand 条件，即使问题暂时消失，也无法确认是哪一项产生作用。相反，如果新问题出现，也很难准确撤销。对 DNS、IPv6、Proxy 端口和 iCloud 同步这类可能影响多个场景的项目，单变量记录尤其重要。

怎样理解默认值与推荐值

Settings 中的默认状态可能随商店版本、设备系统和既有配置迁移而变化，因此本手册不把某个固定数字写成所有设备都相同的默认值。查看某一项目时，应把客户端当前显示值、重新安装后由系统给出的状态以及 Config 内显式声明的参数分开理解。Config 中显式写入的项目通常比仅依赖界面习惯更容易复现，但前提是语法正确，并且清楚该参数作用于哪个范围。

所谓推荐值也不是越复杂越好。稳定使用时，优先保留系统或 Config 已经工作的取值；只有在能够描述具体问题时才添加覆盖设置。DNS 解析失败才调整 DNS，网络切换触发不符合预期才检查 On Demand，测试结果与实际访问不一致才重新选择 Ping 或 Connectivity Test 方法。通过这种顺序，可以避免把诊断功能误当成加速功能，也能减少长期遗留但无人知道用途的设置。

Chapter 02

DNS：解析路径、取值范围与失败定位

DNS 在连接过程中的位置

访问域名时，设备需要先把域名解析为地址，再建立后续连接。节点延迟能够返回，只能说明测试所使用的目标和路径在某个阶段可达，不能证明所有域名都已经正确解析。因此，“Ping 看起来正常但网页打不开”需要把 DNS 单独列为检查对象。Shadowrocket 中的 DNS 行为可能同时受系统网络、Settings、当前 Config 和具体 Rule 影响。判断问题时先确认是全部域名失败、特定后缀失败，还是只有切换网络后出现缓存差异。

系统 DNS 适合用作基线：如果 Direct 姿态下常用站点也无法打开，应先检查当前 Wi‑Fi 或蜂窝网络，而不是立即修改复杂参数。如果 Direct 正常、Proxy 正常但 Config 下某些域名失败，则应检查规则命中和 Config 的 DNS 声明。如果只有一个域名异常，可以对比其主域名、子域名以及直接输入地址时的表现，避免把目标服务自身故障误判成全局解析故障。

选择解析方式时关注的三个边界

第一是解析请求从哪里发出。使用系统提供的解析路径时，结果通常与当前网络保持一致；在 Config 中指定 DNS 时，应确认该地址在当前网络环境中可达。第二是返回结果如何交给规则判断。DOMAIN、DOMAIN-SUFFIX 和 DOMAIN-KEYWORD 直接依据域名匹配，而 GEOIP、IP-CIDR 与 IP-CIDR6 需要地址信息参与判断。第三是缓存何时刷新。更改 DNS 后若仍看到旧结果，应断开当前连接、等待系统网络状态刷新后重新建立连接，再用同一个域名复测。

对于日常使用，推荐先使用能够稳定工作的系统解析路径，不因为某个偶发现象同时加入多组解析地址。需要在 Config 中指定时，应控制数量并记录顺序，避免首选地址不可达导致每次查询都等待超时。使用加密解析方式时，也要考虑其服务域名本身如何完成初始解析；如果初始路径被阻断，表面上会出现“设置更先进但完全无法解析”的结果。排错时先回到简单路径，再逐层增加条件。

Config 中的 DNS 与规则协作

配置文件可以明确记录 DNS 和 Rule，但不要把不熟悉的示例整段复制到正在工作的 Config。先复制一份配置作为测试副本，再只加入必要项目。规则从上到下匹配，越具体的域名规则通常应放在越靠前的位置，FINAL 负责承接前面没有命中的连接。若 DOMAIN-SUFFIX 已把某个域名交给 PROXY，后续 GEOIP 规则不会再次改写同一请求的策略。诊断 DNS 时，应同时查看解析是否成功以及最终命中了哪条规则。

[General]
dns-server = system

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

以上片段用于说明结构和匹配顺序。example.com 是文档示例域名，不代表实际服务；dns-server = system 表示从系统解析路径开始建立基线。实际 Config 还可能包含代理分组、远程规则和其他 General 项目，合并时必须保留原有段落结构，避免重复的节标题或拼写错误。保存后先确认 Config 能被正常读取，再测试规则，而不是在解析失败时继续添加更多 DNS 地址。

分步排查解析失败

第一步切到 Direct，对两个无关联域名进行测试。如果都失败，处理本地网络；如果都成功，进入第二步。第二步切到 Proxy，保持同一服务器不变；若失败，检查服务器连接与协议参数，不先改 Rule。第三步切到 Config，观察问题是否只在规则模式出现。第四步打开 Log，查找目标域名对应的匹配结果，确认是 DOMAIN-SUFFIX、GEOIP 还是 FINAL 接管。第五步才修改 DNS，并在每次修改后重新建立连接。

如果问题集中在“有时成功、有时失败”，需要记录发生时间、网络类型和是否刚刚切换 Wi‑Fi。间歇性失败常与首选解析地址超时、网络切换后连接未重建或多个地址返回顺序变化有关。不要只连续点击 Ping 得出结论，应以实际域名请求、Log 和 Connectivity Test 的组合结果判断。更完整的分层案例可继续阅读DNS 设置与解析失败排查。

Chapter 03

On Demand：自动连接条件与网络切换

On Demand 解决什么问题

On Demand 用于根据网络状态触发连接，而不是替代 Home 中的手动开关，也不会自动判断某个服务器当前是否适合使用。启用前必须先确认手动连接稳定：在固定网络下选择明确的服务器和 Config，手动建立连接并完成访问验证。若手动连接本身失败，加入 On Demand 只会让失败被更频繁地触发，甚至造成用户难以判断客户端何时重新连接。

自动连接最常见的用途是设备在 Wi‑Fi 与蜂窝网络之间切换后维持预期状态，或者对已知网络采用不同动作。设计条件时应从少量、明确、互不冲突的规则开始。每一条条件都要能回答三个问题：它匹配哪类网络、匹配后执行什么动作、没有匹配时使用什么默认行为。不要用多个范围重叠的条件描述同一个网络，否则实际结果会依赖匹配顺序，后续排错也会变得困难。

先定义网络分类，再决定动作

可以把日常环境分为可信任的固定 Wi‑Fi、其他 Wi‑Fi 和蜂窝网络三类。这里的“可信任”仅表示用户熟悉该网络并愿意为它指定单独动作，不代表对网络安全作绝对判断。固定 Wi‑Fi 通常通过其网络名称辨认；其他 Wi‑Fi 用作兜底；蜂窝网络则单独处理。若设备经常连接名称相同但实际不同的网络，不宜仅依赖名称作出复杂决策，应保留手动确认步骤。

动作选择应围绕真实需求。希望进入某类网络后自动建立 Shadowrocket 连接，就为该条件指定连接行为；希望保持手动控制，则不要为该网络设置强制触发。配置完成后必须逐个环境测试，而不是只看开关已开启。测试时先停留在一个网络，记录 Home 状态；再切换到第二个网络，等待系统完成网络变更，观察连接是否重新建立；最后返回第一个网络，确认行为可重复。

条件顺序与冲突判断

范围具体的条件应排在范围宽的条件之前。例如，针对某个固定 Wi‑Fi 的规则应先于“任意 Wi‑Fi”一类的兜底条件。若宽条件先匹配，后面的具体条件可能没有机会生效。修改顺序后要重新执行网络切换测试，并检查 Home 是否显示预期状态。遇到反复连接、连接开关短时间内多次变化时，优先怀疑条件互相覆盖、系统网络在两个接入点之间切换，或当前 Config 无法在新网络完成连接。

On Demand 与系统网络状态紧密相关。设备刚解锁、网络信号较弱或 Wi‑Fi 正在获取地址时，连接建立可能晚于界面变化。此时不要连续手动切换开关，因为手动动作可能与自动触发交叠。先等待网络状态稳定，再查看 Log 中是否出现新的连接过程。如果自动触发后使用了错误服务器或 Config，应检查切换前 Home 中实际选择的项目，而不是把问题归因于 On Demand 条件本身。

推荐的启用步骤

第一步关闭 On Demand，在常用 Wi‑Fi 下手动连接并验证 DNS、规则和访问均正常。第二步保持服务器和 Config 不变，在蜂窝网络下重复手动验证。第三步只建立一条最常用条件，开启 On Demand 后完成一次往返切换。第四步查看 Log，确认每次网络变化只触发一次清晰的重连。第五步再加入第二类网络条件。只要某一步出现异常，就回退刚增加的条件，不继续扩展。

需要暂时排查网络问题时，可关闭 On Demand，避免自动重连干扰对照测试。关闭后仍应检查 Home 的当前连接状态，因为停用自动触发不等于立即改变已经建立的连接。完成排错后，先恢复可工作的手动状态，再重新开启 On Demand。这样可以把“连接本身是否可用”和“自动条件是否正确”分成两个独立问题。

Chapter 04

Ping 与 Connectivity Test：测试结果怎样解读

延迟数字不等于完整连接质量

Ping 用于快速观察目标是否能在指定测试方式下响应以及往返耗时的大致范围。它适合发现完全不可达、明显超时或同一网络下结果差异较大的条目，但不能单独证明网页、视频或其他应用流量一定正常。实际连接还涉及 DNS、目标端口、协议握手、传输参数、规则命中以及目标服务响应。只根据一次延迟排序选择服务器，容易把偶然抖动当成稳定差异。

执行 Ping 前应固定测试条件：保持同一网络、相同 Global Routing 姿态和相同测试方法，避免在扫描过程中切换 Wi‑Fi。对结果至少观察两到三轮，重点看是否持续超时、波动是否过大，而不是追求单次最小数字。若所有条目同时变差，优先检查本地网络；若只有一个条目持续异常，再检查该服务器信息或其网络路径。测试数据只用于定位，不应用来编造长期性能结论。

Connectivity Test 的分层价值

Connectivity Test 更适合回答“连接过程停在哪一层”。测试项目可能随当前界面和网络环境呈现不同内容，但阅读顺序应保持一致：先确认本地网络具备基本连通性，再确认服务器地址可达，然后观察协议握手和实际请求是否完成。某一步通过只代表该层成立，后续步骤仍可能失败。例如服务器地址可达并不表示鉴权参数正确，协议握手成功也不代表 DNS 与 Rule 会把目标请求交给预期策略。

测试失败时记录最早失败的阶段，而不是只记录最终红色结果。最早失败点更接近原因：如果解析阶段就停止，应转到 DNS 章节；如果服务器连接阶段超时，应核对网络可达性和服务器信息；如果实际请求失败而前面阶段通过，应检查 Rule、FINAL、目标服务和协议传输参数。修改后重复同一测试，确认失败点是否后移或消失。

怎样减少测试误差

测试过程中关闭会持续产生大量网络请求的前台任务，可以让 Log 更容易阅读，但不需要改变所有系统设置。保持设备位置和网络接入点不变，先测试一个已知可工作的条目作为对照，再测试目标条目。若使用蜂窝网络，信号变化会直接影响延迟；若使用 Wi‑Fi，接入点切换和局域网拥塞也会造成波动。单次超时后先重复验证，不立即修改协议参数。

对比不同服务器时，应确认测试方式一致。有些测试只验证 TCP 建连，有些测试可能包含实际请求；如果方法不同，数字不能直接横向比较。Shadowrocket 当前界面提供哪些 Ping 方式，应以 Settings 中实际项目为准。不了解选项含义时保留默认或当前可工作方式，不因数字更小就频繁切换。排查“速度慢”还要分别考虑本地网络、服务器、线路时段、协议和目标服务，可参考速度慢分层排查。

从测试结果回到设置项

如果 Ping 全部超时但 Direct 访问正常，检查测试是否通过当前 Proxy、服务器地址是否可达以及协议参数是否完整。如果 Ping 正常而 Connectivity Test 在解析阶段失败，按 DNS 路径排查。如果两项均正常但 Config 下访问不符合预期，查看 Log 中 DOMAIN、GEOIP、IP-CIDR 或 FINAL 的匹配结果。如果 Proxy 下正常而 Config 下失败，问题通常更接近规则或配置，而不是服务器本身。

完成诊断后，应把临时测试设置恢复到长期使用需要的状态。例如为了对照而切到 Direct，结束后要明确恢复 Config；为了观察详细过程而提高 Log 记录范围，完成后应按实际需求调整；为了测试某个服务器而改变选中项，也要确认 Home 最终使用的是预期条目。诊断的结束标准不只是问题暂时消失，还包括配置回到可理解、可重复的状态。

Chapter 05

Log 与 Data：查看规则命中和流量记录

Log 应回答哪几个问题

Log 的主要用途是还原某次请求经过了什么判断，而不是只寻找醒目的错误文字。阅读一条记录时，依次关注时间、目标域名或地址、匹配的 Rule、最终策略以及错误发生阶段。对于规则问题，最关键的是确认请求是否命中预期的 DOMAIN、DOMAIN-SUFFIX、DOMAIN-KEYWORD、GEOIP、IP-CIDR、IP-CIDR6 或 FINAL。若记录显示命中了更靠前的规则，就需要回到 Config 调整顺序，而不是反复切换服务器。

开始记录前先清空不相关操作：保持一个测试目标，只执行一次打开或刷新，然后立即返回 Log 查找对应时间段。后台应用会产生大量系统请求，不能看到陌生域名就认定异常。应通过时间、目标和重复动作建立对应关系。例如连续两次访问同一示例域名，Log 中相近时间出现两条相似记录，才更容易确认哪条属于本次测试。

错误信息的分层阅读

解析相关错误通常指向 DNS 地址不可达、域名没有返回结果或网络切换后解析路径尚未恢复。连接超时更接近服务器地址、目标端口或网络路径问题。握手或鉴权失败需要核对用户已有服务器信息中的协议、密码、UUID、传输参数或证书相关设置是否一致。规则命中与预期不同，则应检查 Config 的顺序和关键字。不同层的错误不宜用同一种处理方式。

如果错误只出现一次而随后请求成功，可以先观察是否与网络切换或短暂超时有关；如果每次都在同一阶段失败，则按该阶段进行单变量检查。不要一次性导出大量日志后只搜索“error”，因为上下文中的上一条连接动作和下一条回退策略同样重要。记录时间线比孤立错误词更有价值。

Data 适合观察什么

Data 用于查看客户端记录的流量概况和连接使用情况。它能帮助发现某个应用或域名是否持续产生请求，也能作为规则调整前后的辅助对照，但不能单独用于判断计费、网络质量或服务器状态。系统统计口径、连接复用和缓存都可能让 Data 与用户直观看到的页面大小不同，因此应把它当成趋势信息，而不是精确账单。

观察 Data 时先限定时间范围和测试动作。例如调整一条 DOMAIN-SUFFIX 规则前，记录对应目标在现有策略下的表现；调整后重新连接，仅执行相同请求，再比较是否由预期策略处理。若后台应用持续产生流量，应避免用总量判断单个目标。对异常增长的排查应回到 Log，确认具体域名和策略，而不是仅凭 Data 删除 Config 或服务器条目。

分享诊断信息前的整理

向服务器信息提供方反馈问题时，建议提供问题发生时间、网络类型、协议名称、Connectivity Test 最早失败步骤以及经过整理的 Log 片段。服务器地址、密码、UUID、Subscribe 地址中的访问凭据和其他敏感参数不应出现在公开截图或公开文本中。可以保留域名后缀、错误阶段和规则关键字，以便说明问题所在层。

整理日志时不要改写错误含义。若必须遮盖内容，应统一替换敏感部分，并保留字段结构和相邻上下文。例如保留“某目标命中 DOMAIN-SUFFIX 后使用 PROXY，随后连接超时”的顺序，比只发一张最终失败页面更便于判断。问题解决后，可以删除临时导出的诊断文件，并把 Log 记录范围恢复到日常所需状态。

Chapter 06

Widget 与 iCloud 同步：快捷操作和配置迁移

Widget 是快捷入口，不是独立连接

Widget 提供从系统界面查看或触发常用状态的快捷方式，但它仍依赖 Shadowrocket 中已经存在的服务器、Config 和连接权限。Widget 显示异常时，应先打开 Shadowrocket，确认 Home 能正常加载并可以手动连接，再检查系统是否允许 Widget 刷新。若客户端本身尚未完成首次连接授权，单独操作 Widget 不能绕过该步骤。

配置 Widget 时应只放高频、含义明确的动作。若同时放置多个名称相近的服务器或 Config，快捷操作容易选错。建议让条目名称能够反映用途，但不要在名称中写入密码、地址凭据或其他敏感内容。修改 Shadowrocket 内部条目后，如果 Widget 仍显示旧状态，可先进入客户端确认保存成功，再让系统刷新 Widget，而不是反复删除当前可工作的配置。

Widget 状态与实际状态不一致

系统可能为了电量和资源管理延迟 Widget 刷新，因此界面展示与 Home 的实时状态可能存在短暂差异。判断连接是否建立，应以打开 Shadowrocket 后的 Home 状态和实际请求验证为主。若点击 Widget 后没有预期动作，先检查设备是否刚重启、客户端是否被系统要求重新确认权限、当前网络是否可用，以及 On Demand 是否同时触发了其他连接行为。

排查顺序为：先从 Home 手动完成一次连接；再回到 Widget 执行同一动作；若 Home 成功而 Widget 失败，移除并重新添加系统中的 Widget；若两者都失败，则问题不在 Widget，应转向服务器信息、DNS 或网络测试。不要在 Widget 故障时修改 Proxy 端口或 Rule，这些项目通常与系统快捷入口刷新没有直接关系。

iCloud 同步的作用边界

iCloud 同步用于在符合条件的 Apple 设备之间保存或同步应用数据，具体可同步内容和呈现方式以当前 Shadowrocket 界面为准。它不等于对每项数据进行实时、双向、无冲突复制，也不应替代手工备份。启用前先检查设备使用的 iCloud 状态，再确定哪一台设备上的配置是当前基线。多台设备同时编辑同名 Config 时，可能出现旧内容覆盖新内容或产生难以辨认的副本。

推荐采用“主设备修改、其他设备核对”的顺序。先在主设备完成 Config 变更并验证可用，记录配置名称和关键 Rule；等待同步后，在另一台设备打开 Shadowrocket，确认服务器条目、Config 内容和 Global Routing 是否符合预期。若未出现更新，不要立刻在第二台设备重新编辑同名项目，因为这可能形成新的冲突。先检查 iCloud 状态、网络和客户端是否已完成加载。

导入、同步与 Subscribe 更新的区别

Import from Cloud JSON 是一次导入动作，iCloud 同步是设备间的数据同步机制，Subscribe 更新则根据用户已有的 Subscribe 地址刷新相应条目。三者不要混为一谈。导入 JSON 后得到的是导入时的数据副本；后续是否变化取决于用户如何维护。Subscribe 更新通常会按来源重新生成相关条目，手工修改的字段是否保留应以实际结果为准。iCloud 则可能把本地变化带到其他设备。

执行任一批量变化前，先保留可工作的 Config，并记录当前选中的服务器。更新后不要立即删除旧条目，应先检查新条目的协议、地址、端口和名称是否完整，再运行 Ping 或 Connectivity Test，最后通过 Config 验证 Rule。发现重复条目时，先识别来源，再决定保留哪一份；只凭名称相同批量删除，可能误删仍被 Config 引用的项目。

跨设备使用的核对清单

在 iPhone 与 iPad 之间迁移后，至少核对五项：Home 当前服务器、Global Routing 姿态、Config 是否存在且能打开、On Demand 是否符合该设备的网络环境、Widget 是否指向有效条目。设备用途不同，On Demand 条件未必应该完全相同。例如经常移动的 iPhone 与长期连接固定 Wi‑Fi 的 iPad，可以共享基础 Config，但分别维护自动连接条件。

Mac、Apple TV 与 Apple Vision 的兼容性信息可在同一 App Store 产品页查看，具体系统要求以 App Store 页面标注为准。即使数据能够同步，也应在每台设备上单独确认网络权限、界面可用项目和实际连接结果。同步完成只说明数据可能已经到达，不代表连接环境也完全一致。

Chapter 07

Proxy 端口：本机监听、局域网访问与冲突检查

Proxy 端口表示什么

Settings 中的 Proxy 端口用于让本机应用通过指定的 HTTP 或 SOCKS5 入口把连接交给 Shadowrocket。端口是设备上的本地监听编号，不是远端服务器端口，也不是协议配置中的服务端口。两者数字即使偶然相同，含义仍然不同。修改 Proxy 端口不会修复服务器密码、UUID 或传输参数错误，也不会改变 Config 中 Rule 的匹配顺序。

日常只使用系统连接开关时，通常不需要频繁调整本地 Proxy 端口。只有某个应用明确支持手工填写 HTTP 或 SOCKS5 Proxy，或者需要进行本机调试时，才应关注这些值。填写时以 Shadowrocket 当前 Settings 显示的地址和端口为准，不套用其他设备上的数字。端口取值应处于合法范围，并避免与设备上其他正在监听的服务冲突。

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

本机应用连接本地 Proxy 时，通常使用回环地址或 Settings 展示的本机入口。回环地址只指向当前设备，其他设备不能把自己的回环地址当作这台 iPhone 或 iPad。若需要局域网内另一台受控设备访问，必须确认 Shadowrocket 是否开启了相应的局域网监听能力、系统是否授予局域网访问权限，并使用提供服务设备在当前局域网中的实际地址。

局域网访问会扩大监听范围，应只在明确需要、网络环境可控并了解访问方的情况下启用。完成调试后恢复到原状态。公共 Wi‑Fi 或无法确认同网设备的环境不适合作为长期共享入口。即使开启监听，另一台设备也必须与提供服务的设备处于可达网络，网络隔离、访客网络和路由器策略都可能阻止连接。

端口冲突的表现与处理

端口冲突可能表现为监听无法启动、应用连接被立即拒绝，或填写正确地址后仍无法访问。排查时先恢复 Shadowrocket 原有端口并重新连接；若原值可用而新值不可用，说明新端口可能被占用或填写不一致。修改后需要同步更新所有使用该本地 Proxy 的应用，旧配置不会自动跟随。不要一次同时修改 HTTP 和 SOCKS5 两个端口，否则难以确认哪一个发生冲突。

确认协议类型同样重要。应用要求 HTTP Proxy 时，应填写 HTTP 对应入口；要求 SOCKS5 时，应填写 SOCKS5 对应入口。把类型与端口交叉填写，可能出现连接建立失败或请求行为异常。若应用支持认证字段，而 Shadowrocket 当前本地入口没有要求相同方式，应按客户端实际设置填写，不自行添加远端服务器凭据。

局域网调试的最小步骤

先在提供服务的设备上确认 Shadowrocket 手动连接正常。然后只开启必要的局域网访问设置，记录当前网络地址和对应 Proxy 端口。在同一受控网络中的另一台设备上填写该地址、端口和正确的 HTTP 或 SOCKS5 类型，只访问一个测试目标。若失败，依次检查两台设备是否真的处于同一网络、系统局域网权限、路由器是否隔离设备以及端口是否填写一致。

如果另一台设备能连接端口但目标请求失败，应回到 Shadowrocket 的 Log 查看请求是否到达、命中了哪条 Rule、使用了哪种策略。如果 Log 中完全没有对应时间的请求，问题更接近局域网路径或填写错误；如果请求出现但后续超时，则按 DNS、服务器或规则继续排查。测试结束后关闭不再需要的局域网监听，并删除另一台设备中的临时 Proxy 设置。

什么时候不应修改 Proxy 端口

当问题是 Subscribe 无法更新、服务器 Ping 超时、某个 DOMAIN-SUFFIX 命中错误、On Demand 不触发或 DNS 解析失败时，本地 Proxy 端口通常不是首要检查项。端口设置只影响通过该入口连接的应用，不会统一修复所有网络问题。先确认故障场景是否真的使用了本地 HTTP 或 SOCKS5 入口，再决定是否调整。

若只是希望在 iPhone 或 iPad 上正常使用 Shadowrocket，应优先完成 Home 连接、Global Routing、Config 和实际访问验证。Proxy 端口属于有明确手工代理需求时的扩展设置。保留当前可工作值通常比尝试随机数字更稳妥；必须修改时记录原值，并在验证结束后决定是否长期保留。

Chapter 08

Config 维护：规则顺序、备份与完整排错流程

Config 的职责边界

Config 用于组织 General 设置、Rule、代理分组和其他连接行为。它决定请求如何被分类和交给 PROXY、DIRECT 或 REJECT，但不会自动修正错误的服务器信息。维护 Config 时应把“服务器是否可连接”和“规则是否按预期选择策略”分开验证：先在 Proxy 姿态下确认当前服务器可用，再回到 Config 姿态检查 Rule。若 Proxy 已失败，继续调整 DOMAIN-SUFFIX 或 GEOIP 没有诊断价值。

规则按照从上到下的顺序匹配。DOMAIN 适合精确域名，DOMAIN-SUFFIX 覆盖指定后缀及其子域名，DOMAIN-KEYWORD 按域名中的关键字匹配，USER-AGENT 依据请求特征匹配，GEOIP 按地址归属判断，IP-CIDR 与 IP-CIDR6 按地址范围匹配。越宽的规则越容易提前截获请求，因此一般把明确、具体的规则放在宽泛规则之前，并让 FINAL 位于规则末尾承担兜底。

[Rule]
DOMAIN,api.example.com,PROXY
DOMAIN-SUFFIX,example.com,PROXY
DOMAIN-KEYWORD,example,DIRECT
IP-CIDR,192.0.2.0/24,DIRECT
IP-CIDR6,2001:db8::/32,DIRECT
GEOIP,CN,DIRECT
FINAL,PROXY

示例展示关键字和顺序，不应直接覆盖用户现有 Config。示例地址属于文档用途，实际维护时要根据自己的目标和服务信息编写。注意 DOMAIN-SUFFIX,example.com,PROXY 位于更宽的 DOMAIN-KEYWORD,example,DIRECT 之前，因此对应后缀会先使用 PROXY。若调换顺序，关键字规则可能提前命中并改变结果。这也是查看 Log 时必须记录“命中了哪一条”的原因。

Config、Subscribe 与手工条目的关系

用户已有的 Subscribe 负责提供相应服务器条目，Config 负责描述规则和策略，两者可以互相关联但不是同一内容。更新 Subscribe 后，条目名称、顺序或可用性可能变化；如果 Config 引用了特定名称，应确认引用仍然存在。手工添加的 Add Server 条目则依赖用户输入的协议参数。无论来源如何，更新后都要先核对协议、地址、端口和必要字段，再进行测试。

不建议直接在唯一可工作的 Config 上进行大范围重写。先复制测试副本，在副本中一次修改一组相关规则，并保留原文件作为回退。若配置来自用户信任并自行选择的来源，应记录更新时间和本地改动位置，避免下一次更新覆盖手工修改后无法辨认。本站只说明 Shadowrocket 的导入与维护方法，不提供服务器信息或 Subscribe 内容。

从最小配置逐步恢复

当复杂 Config 出现难以定位的问题时，可以复制一份测试配置，只保留必要的 General、少量明确规则和 FINAL。先验证一个 DOMAIN 规则，再加入 DOMAIN-SUFFIX，随后加入 GEOIP 或地址范围规则。每增加一组就重新连接并查看 Log。这样能够识别是哪一组规则、哪个远程资源或哪个 General 设置引入问题，而不是在数百条规则中随机移动位置。

若最小配置正常而原配置失败，比较两者的 DNS、Rule 顺序、代理分组引用和重复段落。若最小配置也失败，则回到 Proxy 姿态验证服务器，再到 Direct 验证本地网络。完整流程应始终从环境到连接、从连接到配置、从配置到单个目标，不能倒过来只盯着最终页面。

完整故障排查顺序

1. 确认本地网络：在 Direct 下访问多个无关联目标，判断 Wi‑Fi 或蜂窝网络是否具备基础连通性。
2. 确认服务器：切到 Proxy，固定一个服务器，使用 Ping、Connectivity Test 和实际请求交叉验证。
3. 确认 Config：切回 Config，查看目标请求命中的 Rule 和最终策略。
4. 确认 DNS：若域名无法解析，使用系统路径建立基线，再检查 Config 中的覆盖设置。
5. 确认自动触发：手动连接稳定后，再启用 On Demand 并执行网络切换测试。
6. 确认扩展功能：最后核对 Widget、iCloud 同步和 Proxy 端口，不让辅助功能干扰主线诊断。

如果完成上述步骤仍无法判断，可在FAQ中按“规则与故障排查”查找具体症状。反馈问题时提供最小复现条件、失败阶段和经过处理的 Log，不公开服务器凭据。对于首次使用者，建议回到快速上手教程重新确认 Add Server、Subscribe、Global Routing 和连接验证主线；本手册用于解释设置细节，不替代首次操作顺序。

维护后的收尾检查

每次完成较大调整后，检查 Home 当前服务器、Global Routing、Config、On Demand、DNS、Widget 和本地 Proxy 端口，确认临时测试值已经恢复。对 Config 保留一份已验证副本，并用清楚名称区分正式配置与测试配置。更新 Subscribe 或通过 Import from Cloud JSON 导入数据后，重新核对引用关系，不默认旧名称一定保持不变。

Shadowrocket 的应用更新由 App Store 提供。iPhone、iPad 以及商店兼容性栏中列出的其他 Apple 设备，其系统要求均以 App Store 页面标注为准。需要重新核对购买、恢复已购或设备说明时，使用本站App Store 下载指南进入产品页。设置维护的目标是让每项参数都能说明用途、能够复现、出现问题时能够回退，而不是长期累积无法解释的开关和规则。