Shadowrocket 设置详解

01 / Scope

设置范围、默认值与修改基线

先区分 Settings、Config 与服务器字段

Shadowrocket 的设置不是一张所有项目都同时生效的总表。Settings 中的应用级选项、Config 中的配置文件，以及服务器编辑页中的连接参数，分别解决不同层面的问题。比如 DNS 可能同时涉及配置文件与应用内选项，服务器地址则属于连接端点。排错前先确认正在编辑哪一层，否则即使保存成功，也可能没有改变实际处理请求的那一处。

Home 用于观察当前连接和服务器选择，Config 用于管理及选用配置文件，Settings 用于查看应用设置。本文保留这些界面词；具体入口排列和可见选项以设备实际界面为准。找到同名设置后，应先读旁边的说明、当前值与可选范围，再操作，不要仅凭另一台设备截图中的位置寻找开关。配置文件里不存在的字段，也不能直接按中文说明自行拼写。

“默认值”至少有三种语境：新建配置的初始内容、应用首次运行的初始选项，以及某个订阅或配置文件导入后的值。三者并不等同。换机恢复后看到的选项可能继承旧设备，重新选择 Config 又可能切换到另一份文件。本页建议记录的是“修改前的实际有效值”，它比未经核对的默认值更适合用于回退，也能说明问题是否由本次修改引入。

用一份记录建立可回退的基线

开始前记录当前 Global Routing、选中服务器、活动配置文件，以及问题发生时使用的是 Wi-Fi 还是蜂窝网络。服务器名称只需在个人记录中保持可辨认，不必对外公开。再保存待修改配置的副本，并注明修改目的，例如“核对指定域名是否走预期策略”。这一记录不是应用日志，而是人工保留的实验条件，用于防止几轮排错后忘记最初状态。

每轮只改一个变量。若同时更换 DNS、服务器、路由姿态和测试方法，即便连接恢复，也无法知道哪个修改起了作用；下次出现同类故障仍需重做。一个完整回合应包括修改前测试、单项修改、重新建立连接、使用相同目标复测、观察记录和保留或撤销。涉及配置文件时，还要确认保存后的文件确实被选为当前活动配置。

“推荐取值”也需要条件。对尚能正常使用的设备，推荐通常是保留已验证的设置；对故障设备，推荐是回到最小、可解释的配置，再逐项恢复功能。提高数字、延长超时或开启更多选项，并不天然更稳定。尤其涉及网络可达性时，设置只能改变客户端如何处理请求，不能代替服务器端的可用性、凭据有效性和当前网络的访问条件。

配置示例中的 example.com 是说明用域名，不代表可连接的服务。PROXY、DIRECT 是策略关键字，和界面中 Global Routing 的 Proxy、Direct 在书写及作用范围上需要区分。示例中的保留地址用于说明匹配逻辑，不要求用户照抄。若已有配置包含自定义策略，应先确认其定义，再决定是否引用，避免写出无法解析的策略名。

如果当前连首次连接都未完成，先按入门指南的完整主线操作，不应直接进入复杂设置调优。若故障已经有明确报错，可结合常见问题缩小范围。本页接下来的章节按解析、路由、触发、测试、观察、同步和恢复分层展开；这种顺序的目的，是把“设置看起来正确”转化为“实际请求经过验证”。

02 / DNS

DNS 设置与域名解析路径

DNS 解决什么问题

DNS 把域名解析为地址，但“解析成功”不等于“连接成功”。一个请求可能已得到地址，却在连接服务器、建立加密会话或请求内容时失败；反过来，代理服务器地址如果使用域名，也可能在连接代理之前就需要完成解析。因此应先区分目标网站解析失败与代理服务器地址解析失败，二者发生在不同阶段，调整同一个设置未必同时有效。

在 Config 中查看当前活动文件的 [General]，核对是否包含 dns-server。下例的 system 表示采用系统提供的解析设置，是便于理解的起点，不代表所有文件都会自动包含这一行。它的实际结果受当前网络条件影响。若应用内还有 DNS 相关选项，应一并记录，不能只凭文件中的一行就断言所有请求都走同一条解析路径。

[General]
bypass-system = true
dns-server = system

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

这一片段同时展示了应用层处理、解析来源和规则匹配，但几行设置不是同一件事。bypass-system 是独立的配置选项，不是“修复 DNS”的通用按钮；dns-server 指定解析设置；[Rule] 决定匹配请求后的策略。复制其中一行之前，应确认它与原文件的位置、重复字段和已有规则不冲突，保留其他必要分节。

默认值与推荐取值如何判断

DNS 的初始值应从当前文件和应用界面读取。本页不指定一个适合所有网络的公共解析地址，也不把某个解析服务当作固定推荐。对没有解析异常的设备，先保留经过验证的设置；对只在某个网络失败的设备，先比较该网络与另一种网络的结果。只有当问题指向解析阶段，才有理由改变解析来源，并以同一域名重复测试。

如果已有配置使用加密解析，应核对该解析端点本身是否可达、是否需要先解析其域名，以及它在当前路由下如何连接。把解析方式改成另一种协议并不会自动消除前置依赖。故障时应先使用简单、可观察的条件确认基础路径，再恢复原来的解析设计；不要反复叠加端点，使失败时无法分辨究竟是哪一个端点正在参与请求。

域名规则与地址规则也会影响观察结果。DOMAIN-SUFFIX 根据域名后缀匹配，IP-CIDR 根据地址范围匹配，部分地址类判断可能涉及解析。若一个域名在不同网络得到不同地址，后续地址规则的结果可能随之改变。检查“为什么命中了这条规则”时，要同时核对请求域名、解析结果与规则顺序，而不是只看最后显示的策略。

缓存与局域网名称的边界

解析缓存可能存在于应用、系统及上游多个位置。修改 DNS 后，旧结果不一定立即全部消失；网页本身也可能复用已有连接。验证时先保存配置并重建连接，再重新发起请求。若仍需判断缓存影响，应使用可重复的测试步骤，而不是随意清除所有数据。清除范围越大，越容易把登录状态或其他现场证据一并移除。

局域网设备名称、内部域名与公开域名不一定依赖相同解析条件。切换为外部解析来源后，内部名称可能不再得到原有结果。若故障只涉及家庭或办公网络里的设备，先确认原网络的解析要求、地址范围与直连规则。不要把“公开网站可访问”作为内部名称配置正确的证据，也不要为了修复一个内部名称而整体改变所有请求的路由。

完成修改后，至少验证一个原本正常的目标、一个原本失败的目标，以及确实需要的局域网目标。记录是否得到地址、是否建立连接、是否返回内容这三个结果。若解析已经成功但内容仍失败，下一步应转向路由、服务器参数或目标服务，而不是继续轮换 DNS。保留这份分层结果，能使后续 Log 分析有明确上下文。

03 / Routing & Proxy

Global Routing、规则与 Proxy 端口

三种姿态不是三套服务器参数

Global Routing 决定请求采用怎样的总体处理方式。配置对应 Config，代理对应 Proxy，直连对应 Direct。Config 按活动配置的规则分配策略；Proxy 用于将通常由该路由设置处理的请求交给代理路径；Direct 用于直连。系统流量、排除项和具体配置仍可能构成边界，因此不要把任何一种姿态理解为对设备所有网络行为的绝对描述。

在 Config 下，一条写着 DIRECT 的命中结果可能完全符合配置，不代表服务器失效。相反，切换到 Proxy 后目标恢复，只能说明改变处理路径对结果有影响，还不能独立证明某条规则写错。应回到 Config，核对目标命中了哪一行、该行前面是否已有更宽泛的匹配，以及策略实际指向什么，再决定是否调整规则。

推荐日常使用哪一种姿态，取决于用户已经明确的配置目的。有经过核对的分流规则时，可以使用 Config；短时比较代理路径时，可临时切换 Proxy；核对直连条件时，可临时使用 Direct。测试结束应恢复原姿态，并重新建立连接。不要为掩盖一条错误规则而长期保留临时测试姿态，否则局域网访问与其他目标的路径可能一起改变。

规则片段的顺序与策略含义

规则通常按自上而下的顺序查找匹配项，具体规则应位于兜底规则之前。下例先处理示例域名和私有地址，最后由 FINAL 处理未命中的请求。这里的 FINAL,PROXY 是有意选择代理作为兜底，不是所有用户都应照抄的默认值。若改为 FINAL,DIRECT，未命中请求的路径就会不同，影响范围远大于单个域名。

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

不要用重复添加相同规则的方式“提高优先级”。如果前面已有一条能够命中的规则，后面的相同目标规则可能没有机会参与判断。先查命中记录，再移动或收窄规则，保存后重新验证。对于 REJECT，它表示拒绝匹配请求，不等于修复请求；具体匹配边界可参阅REJECT 规则的顺序与局限。

区分远端服务器端口与本地监听端口

服务器编辑页的端口是远端服务接收连接的位置，必须与用户已有服务器信息一致。Settings 中若提供本地 Proxy 端口，则是设备上某种本地代理入口的监听位置。两者即便恰好显示相同数字，也不意味着相互替代。把本地端口填到远端服务器字段，或把远端服务端口当成本地监听配置，都会让连接目标发生根本变化。

本地端口的当前值、协议类型和启用条件应以实际界面为准，本页不指定固定端口号。端口数字有效只是第一步，还需确认是否有服务在监听、发起请求的一方使用何种代理协议、监听是否仅限本机，以及网络是否允许访问。普通 iPhone 或 iPad 使用系统 VPN 配置连接时，不应为了“提升速度”随意修改本地监听端口。

如果确有本地 Proxy 使用需求，先保留原始设置，明确请求来自本机还是局域网其他设备，并选择应用实际支持的对应方式。HTTP 与 SOCKS5 的客户端配置不能随意混填；网页地址的路径也不是端口字段内容。验证失败时先检查监听是否开启及协议是否一致，再看目标请求，不能只凭端口数字相同判断设置已经完成。

完成路由或端口调整后，应分别验证普通网络请求与特定本地入口，避免把两种测试结果混在一起。如果改变端口后普通连接没有变化，这可能只是因为普通连接原本就没有使用该入口。配置工作应围绕实际请求路径展开：谁发起、连接到哪里、按何种协议进入、命中什么策略，最后才讨论是否需要修改数值。

04 / On Demand

On Demand 的触发条件与停止方法

按需触发不负责修复服务器

On Demand 用于按设定条件触发 VPN 连接，作用在“什么时候尝试建立连接”这一层，而不是替代服务器验证、订阅更新或路由配置。只有手动连接已经稳定、活动 Config 和服务器选择明确后，才适合配置自动触发。否则它可能反复触发同一条失败路径，使用户误以为应用在不断自行修改设置，实际上只是条件持续成立。

进入实际的 On Demand 选项后，先检查当前是否启用、已有条件是什么，以及系统中的 VPN 配置是否仍然存在。默认状态以当前设备显示为准：恢复旧数据、重新安装应用或重新授权后，不能假设仍与首次使用一致。若系统与应用呈现的状态不一致，应先回到手动连接测试，确认基础配置有效，再处理自动触发规则。

推荐取值不是“全部启用”，而是只保留能够解释的条件。若应用提供按网络类型或网络标识处理的选项，应根据实际需求逐项设置，不要照搬他人的网络名称。对于暂时不需要自动连接的使用方式，保留手动控制更便于观察。对于经常切换网络的设备，则需要在每一种常用网络下分别验证触发行为，不能只测试当前 Wi-Fi。

把自动连接拆成可重复的测试

第一步先停留在同一网络，手动建立连接，访问一个已知可用于验证的目标，并查看实际策略。第二步断开连接，确认正常的停止行为。第三步按需要设置 On Demand，再通过真实的网络状态变化观察触发结果。测试时不要同时切换服务器、更新订阅或更换 Config，否则连接变化可能来自其他操作，无法证明触发条件本身正确。

观察时应分清四件事：条件是否出现、系统是否发起连接、连接是否建立、建立后请求是否正常。自动触发已经发生但后续连接失败，排查方向应转向服务器与网络；完全没有发起连接，才需要继续核对触发条件和系统配置。状态栏出现 VPN 标识也只说明某种连接状态，不足以证明目标内容能够按预期返回。

网络切换时可能经历地址重新获取、解析条件变化和旧连接失效。短暂重连与持续循环失败不是同一种现象。记录切换前后使用的网络、触发时间顺序以及失败阶段，比连续开关更有价值。若某网络本身需要先完成网页认证，应先完成该网络的正常接入，再观察 On Demand；客户端触发设置不能替代网络自身的认证过程。

为什么断开后又出现连接

当 On Demand 的条件仍成立时，一次手动断开未必等于停用自动触发机制。如果需要确定地停止自动连接，先在相应设置中停用 On Demand，再断开并观察系统状态。不要立即删除所有配置；删除会让后续很难分辨究竟是触发规则、系统授权还是服务器参数有问题。确认停止后，再按原记录恢复必要的设置。

若设备存在其他 VPN 配置或由组织管理的网络限制，还需核对系统允许的连接方式。不要反复创建名称相近的配置，导致无法确认应用正在使用哪一个。涉及受管理设备时，应遵守设备管理要求，不能用本页一般操作替代相应管理流程。对普通个人设备，也应先看系统实际提示，而不是把所有连接失败都归因于应用选项。

On Demand 的验证还应覆盖一次设备锁定后的正常使用过程，但不要把后台状态变化直接解释为耗电或性能结论。设备的网络活动、系统策略和其他应用都会影响表现。若只需临时测试，应在结束后恢复原设置；若准备长期保留，则在配置或网络条件变化后再检查一次，确保自动连接仍然服务于明确的使用目的。

05 / Ping & Connectivity Test

Ping、Connectivity Test 与结果解读

先确认测试测量了哪一段

Ping 在使用语境中常被泛指为延迟测试，但具体测试可能采用不同方式。网络探测、建立传输连接和通过代理请求一个目标，覆盖的路径并不相同。使用前先读取测试方式及目标设置，不要仅凭按钮名称推断它验证了完整代理链路。测试方法不同，即使对象相同，结果也不应直接放在一起排序或比较。

如果界面提供 ICMP、TCP 或请求型测试，应分别理解其边界：ICMP 探测不验证代理协议认证；TCP 建连不一定验证加密和应用请求；请求型测试更接近某个目标的实际访问，但又受目标服务和解析影响。应用实际提供哪些方法、字段和选项，以当前界面为准，不应为了套用本页说明而寻找并不存在的开关。

Connectivity Test 用于观察所选测试流程的连通情况，它不是对所有网站、所有协议和整个使用时段的保证。一次成功只能证明当时的测试条件得到成功结果；一次失败也可能是测试目标不可达，而非服务器完全不可用。推荐先使用当前已验证的测试方式，再明确目标与路径，只有排错需要时才改变方法或目标。

测试目标、超时与默认值

测试目标的初始值、等待时间和其他参数，先从 Settings 当前页面读取。本页不给出统一超时秒数，也不建议把超时一直加大。等待过短可能将波动误记为失败，等待过长则让真正不可达的情况更晚结束。合理取值应服务于相同条件下的比较，并记录调整前后结果，而不是追求测试列表里全部出现数字。

若测试允许指定目标，应选择用户有权访问且能稳定用于验证的地址，并确认协议格式符合界面要求。域名字段、完整 URL 字段和服务器地址字段不能混用。不要把带有登录态或私密参数的地址作为公共排错材料。测试目标本身若发生跳转、认证或访问限制，结果就包含这些条件，不能再简单解释为代理服务器的纯传输延迟。

批量测试容易引入另一个变量：同时发出的探测会共享当前网络资源，也可能受到目标端响应策略影响。列表里的结果不是静止不变的服务器属性。对某个异常对象，应单独重复测试，并与实际请求对照。不要一边下载大文件一边把测试差异归因于服务器，更不要用一次排序替代对路由和协议参数的核对。

延迟、带宽与稳定性分别观察

较短的响应时间不等于较高的持续传输速率，也不保证长连接稳定。响应时间侧重一次交互的等待，持续传输还受到带宽、拥塞、目标内容服务和协议行为影响。若问题是视频停顿或文件传输中断，应记录发生场景与持续时间，并查对应请求日志；只反复执行 Ping，无法完整覆盖这类问题的成因。

测试失败但实际访问正常时，先确认测试目标是否具有特殊响应条件，保留正常访问作为对照。测试成功但实际访问失败时，则核对业务目标的 DNS、规则命中、连接阶段和返回结果。两种情况都不应该立即删除订阅。先把“测试流程失败”和“业务流程失败”分开，才可能判断需要改的是测试配置还是实际连接配置。

涉及 Hysteria2 等依赖特定传输条件的连接，还要注意 TCP 探测不能代替相应传输的实际验证。协议的工作条件可以结合Hysteria2 与 QUIC 基础说明查阅；VMess 与 VLESS 的字段核对见UUID、加密与传输方式说明。测试选项不能弥补协议字段填错。

最终应保留能够回答具体问题的测试，而不是保留最多的测试。确认问题后，把临时目标和超时调整恢复为日常已验证值，并记录为何保留某种方法。以后遇到同类现象，可以先复现相同条件，再决定是否需要扩大诊断范围，避免每次从不同的测试起点开始。

06 / Log & Data

Log、Data 与分层故障记录

从一次请求建立观察窗口

Log 用于观察请求和连接过程，Data 用于查看应用提供的流量等记录；具体可见内容、保留方式和入口以实际界面为准。流量计数增加不代表目标页面正确加载，出现连接记录也不等于返回内容成功。日志的价值在于说明故障发生在哪一阶段，而不是单凭记录数量判断应用是否“工作正常”。

开始排错前先记录时间顺序：当前网络、Global Routing、活动 Config、所选服务器，以及准备访问的目标。再只发起一次或少量可辨认的请求。不要同时打开多个应用反复刷新，否则日志里会混入系统活动、后台请求和重试。只看最近出现的一行，也可能把不相关请求的失败误认成正在排查的业务失败。

若有日志详细程度或保存相关选项，默认值以当前设备显示为准。推荐先使用能够看清问题的最低必要记录程度，确实需要时再临时提高；排错结束后恢复日常设置。更详细的记录通常意味着需要处理更多信息，也可能占用更多存储或处理资源，不应把长期保留最详细记录当作提高连接质量的设置。

按照请求阶段读记录

先看请求目标是否正确，再看是否完成解析，接着看命中规则与策略，然后确认连接到的服务器及后续结果。不同日志格式未必逐项展示这些字段，但阅读顺序可以保持一致。若某个阶段的信息不存在，应承认目前证据不足，回到相应测试补充，不要根据一条概括性错误推断整条连接路径。

例如“连接超时”可能发生在不同端点；应核对超时的是代理服务器、解析端点还是目标服务。“认证失败”则优先检查用户已有信息中的认证字段，以及是否选中了预期服务器。遇到证书相关提示，应核对地址、名称和服务器配置，不应为了让报错消失而盲目放宽验证。报错被隐藏与连接被正确修复不是同一回事。

日志中的 DIRECT、PROXY、REJECT 应结合命中规则解释。发现 DIRECT 时，先确认这是否就是用户的分流意图；发现 REJECT 时，查看前序规则是否过宽。不要把所有不符合预期的请求都改成 PROXY，因为问题也可能是错误域名、目标服务状态或应用自身的认证过程。

Data 计数与隐私边界

Data 中的统计应先确认统计范围和时间范围。连接持续时间、累计流量与某个请求耗时不是同一个指标；重连、清理或界面切换后，显示口径也应重新核对。不能把应用中的某一项计数直接当作运营商账单，也不能仅凭上传量增加就推断发生异常。应先区分正常后台通信、重试和正在执行的测试。

日志可能包含域名、地址、服务器标识和请求信息；导出的文件还可能附带更多上下文。分享前应删除密码、订阅链接、令牌、个人地址及可关联身份的信息。UUID 即使看起来只是随机字符，也可能属于连接凭据，不能原样贴入公开问答。保留必要的错误类别、先后关系和脱敏字段，通常比提供完整数据更适合讨论。

清理日志前先保留与问题直接相关的少量片段，尤其是修改前后的对照。不要在每次失败后立即清空所有记录，再凭记忆描述问题。需要重新采样时，可以明确一个新的起点，然后只重现一次。若故障很难稳定出现，记录触发条件和最后一次正常条件，比不断积累没有标记的大量日志更容易形成结论。

当记录显示基础连接已经成功，而只有某个业务失败时，应转向该业务的规则和返回条件；当记录在连接服务器之前就终止，则回到 DNS 与网络。将结果整理成“条件、动作、现象、证据、回退结果”五项，可以直接对应本页各章，也方便结合常见问题的分类排查继续缩小范围。

07 / Widget & iCloud

Widget、iCloud 同步与配置备份

Widget 是入口，不是独立连接配置

Widget 用于提供便捷入口或状态展示，实际可添加的类型、交互方式和展示内容取决于应用及系统当前支持。它不构成另一套服务器参数，也不应被当作后台连接是否成功的唯一证据。若 Widget 显示与 Home 中观察不同，先打开应用核对连接，再检查系统是否已更新展示，不要直接修改 DNS 或服务器端口。

添加 Widget 前，先保证在应用内能够正常完成连接与断开；之后再使用系统的添加与编辑流程，选择 Shadowrocket 提供的相应项目。若有可选内容，按实际需要选择，不必把所有形式都添加。界面中的默认展示项应以当前可见内容为准，本页不固定 Widget 的尺寸、布局或按钮数量，以免把系统差异误认为配置缺失。

从 Widget 发起操作后，应回到 Home 或实际访问结果核对状态。设备锁定、系统刷新与应用状态都可能影响展示时机，因此“卡片上的文字未变”与“连接没有建立”需要分别验证。如果应用内操作正常而入口未更新，先检查 Widget 本身及系统展示条件；如果应用内也失败，则应按前文网络和日志路径排查。

iCloud 同步不等于独立备份

iCloud 同步用于在满足账户和系统条件时同步应用支持的数据，但同步内容不应凭名称推断。先在实际设置中查看涉及哪些项目、是否启用，以及两台设备是否使用符合要求的 iCloud 账户。用于 App Store 购买的账户与系统中的 iCloud 账户可能不是同一账户概念；能重新获取应用，并不自动证明配置数据也已经同步。

推荐在一台内容完整的设备上先确认基线，再处理另一台设备。不要在两端同时大量编辑同名配置，否则很难判断最后看到的内容来自哪一端。尤其在某台设备暂时离线时，恢复联网后的结果需要再次核对。同步完成的判断应落到文件内容、服务器信息和实际连接，而不是只看某个同步选项处于开启状态。

同步会传播变化，因此不能把它当作不会改变的历史副本。误删或误改内容也可能随同步影响其他设备。进行大幅规则调整前，应另外保存当前配置文件，并在自己受控的位置标明用途。备份文件应保持可识别，但不要把密码或完整订阅链接写进文件名；文件本身也应按敏感配置管理，不能随意上传到公开位置。

导出内容与迁移后的重新验证

导出配置文件时，应打开副本核对实际包含的分节，而不是假设一个文件涵盖所有 Settings、所有服务器和系统授权。订阅内容、手工添加服务器和本地规则可能处于不同存储范围，具体以应用实际导出结果为准。换机前最好同时保留原始订阅信息、必要的服务器参数与本地规则副本，明确每种材料对应的恢复用途。

恢复后先检查文件完整性，再确认活动 Config、Global Routing 和当前服务器。系统 VPN 授权属于系统层面的流程，需要按照新设备提示完成，不能由文本配置代替。随后先做手动连接，再验证 On Demand 与 Widget。这样的顺序能够把数据恢复问题和自动触发问题分开，避免所有功能同时恢复后只看到一个笼统失败。

如果旧设备可用而新设备不可用，应保持旧设备不变作为对照。逐项比较两端网络、活动配置、认证字段与同步结果，先找出差异，再修改新设备。不要先清空旧设备来“强制同步”，因为那会移除最有价值的正常基线。涉及应用获取的账户问题，可查阅已购恢复说明，与配置迁移分别处理。

更详细的材料整理与操作顺序见iCloud 同步、配置导出与换机迁移；购买恢复的账户核对可参阅换机重装后的已购项目说明。保留这些分工，可以避免把同步故障误当作购买故障，也能减少不必要的重复编辑。

08 / Verification & Recovery

设置验证、故障分支与回退流程

按影响范围选择起点

出现问题时先回答“所有目标失败，还是只有部分目标失败”。所有目标都失败，应先确认设备基础联网、系统 VPN 配置、当前服务器和认证条件；只有部分目标失败，则优先查对应域名的解析、规则命中和目标返回。这个分支比先决定“改 DNS 还是改端口”更重要，因为它决定接下来需要采集哪一类证据。

再确认问题是首次出现、修改后出现，还是切换网络后出现。首次连接失败时，核对已有服务器信息与协议字段；修改后失败时，优先撤销最近一项修改；换网络后失败时，保持配置不动，单独检查新网络接入和解析条件。不要把这三种场景放进同一套随机调整流程，否则很容易丢失本来已经明确的因果线索。

若原本能够连接，只是在调整 Settings 后出现异常，最有价值的操作通常不是继续叠加设置，而是回到记录的基线。先停用临时 On Demand 条件，恢复原 Global Routing，选回原活动 Config，再使用原服务器手动连接。每完成一步都记录结果，避免一次性恢复所有项目后只知道“现在正常”，却不知道故障原因。

配置片段怎样安全用于对照

下例用于说明一份便于阅读的局部配置如何组织：[General] 放相关基础选项，[Rule] 放有序规则。它不是覆盖现有文件的建议，也不包含连接服务器所需的全部信息。真正编辑时应在副本中定位相应分节，避免重复创建同名字段，尤其不要因粘贴片段而删除原本必要的策略或其他配置。

[General]
dns-server = system

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

验证规则时，选择一个与新增规则确实相关的请求，再核对命中结果。示例域名只是语法说明，不能拿它的内容结果判断自己的服务是否可用。若新规则没有命中，先检查活动文件与前序规则；若已经命中但连接失败，继续检查策略对应的连接路径。规则语法正确、策略被命中和最终内容成功，是三项不同的验证结果。

最小恢复与长期保留的标准

所谓最小恢复，是先得到一条可以解释并重复成功的手动连接路径，而不是删除全部数据。保留已有有效服务器信息，使用明确的路由姿态与活动文件，暂时减少自动触发和不必要的实验选项。若此时仍失败，继续根据日志定位；若已经成功，再一次恢复一个功能，并在每次恢复后使用相同目标验证。

对每项准备长期保留的设置，都应能回答三个问题：它解决什么具体需求、如何确认它生效、失效时怎样撤销。如果无法回答，先保留原值通常比继续调整更合适。特别是 DNS 端点、本地 Proxy 监听和自动连接条件，它们扩大了需要维护的条件集合，不应仅因别人使用而添加到自己的设备上。

恢复过程中不要把重新获取应用当作第一步。应用来自 App Store，重新安装涉及已购获取、配置数据和系统授权等多个层面，可能移除排错现场。只有明确知道要解决的问题、已经保存必要材料并理解恢复步骤时，才考虑这一操作。正版开发者名为 Shadow Launch Technology Limited，应用 ID 为 932747118，核对方法见正版三要素说明。

若需要整理问题供进一步排查，保留一段简洁记录：在什么网络下、使用何种 Global Routing 与活动 Config、进行哪一项操作、出现什么现象、日志停在哪个阶段、撤销修改后是否恢复。不要公开真实订阅或认证字段。这样的记录能区分客户端设置、用户已有服务器条件与目标服务问题，比“全部照做仍然不行”更有诊断价值。

完成排错后，清理临时测试目标，恢复日常日志程度，确认 On Demand 与 Widget 的行为符合需要，并为最终配置保留副本。后续若更新已有订阅或更换网络，再针对受影响部分复测即可。需要重新走一遍完整连接流程时返回入门指南；需要按具体症状查找分支时进入常见问题，不必把本页所有设置重新修改一次。