Shadowrocket Settings 设置手册

01 · Settings 当前值与 Global Routing

打开 Shadowrocket 底部的 Settings，先阅读列表分组与项目名称，再进入相应详情。设置项的位置与可见内容以当前应用为准；没有看到某个选项时，不要把名称相近的项目当成替代项。Home 负责当前服务器与连接入口，Config 负责配置文件及其中的规则，Settings 则集中呈现应用行为和工具相关设置。这三处共同影响连接，但它们不是同一层控制，排查时应分别记录。

修改前建立可恢复的基线

建议先写下当前网络是 Wi-Fi 还是蜂窝网络、Home 中选中的服务器、Global Routing 的姿态，以及 Config 中当前使用的文件名称。接着记录准备修改的项目、原值和预期结果。例如，预期可以是“切回指定 Wi-Fi 后不再自动建立连接”，而不是笼统的“网络更快”。若原值是自动、空白或继承，也应照原样记录；空白并不一定表示关闭，可能表示交由配置文件或系统处理。

“默认值”需要区分三种来源：首次使用时应用给出的初始值、导入配置文件明确写入的值，以及你之前保存并可能同步过来的值。单凭界面当前显示无法反推出它属于哪一种。本手册对无法统一核实的项目采用“保留当前可用值”的建议，不声称某个端口、测试地址或开关状态适用于所有设备。这样既能避免覆盖已有需求，也能让每次变化与实际结果建立对应关系。

Global Routing 的三种姿态

在 Home 中查看 Global Routing。配置、代理、直连分别对应 Config、Proxy、Direct。Config 根据当前配置文件中的规则选择策略；Proxy 适合临时判断问题是否与分流选择相关；Direct 则用于观察不经过所选代理服务器时的访问情况。三者是路由行为的选择，不是连接质量等级，也不能替代正确的服务器参数。用于对照测试后，应恢复原来需要的姿态，避免把临时诊断状态长期保留。

用一次变化解释一个结果

每次只修改一个变量，再重新发起同一请求。若同时更改 DNS、服务器与 Global Routing，即使页面恢复，也无法判断是哪一项起作用。测试应包含打开新页面或重新建立连接，不能只观察已经载入的内容；浏览器缓存、现有连接和应用后台状态都可能掩盖变化。修改需要重新连接才能参与新会话时，先停止，再开启，并检查 Home 显示的当前项是否仍然正确。

首次建立连接所需的系统 VPN 配置授权，与 Config 文件里的代理规则是两回事。系统授权允许应用建立相应网络连接，并不代表服务器信息已经正确，也不代表订阅已经导入。若开关可开启但页面不可用，请按首次连接检查核对选择与测试步骤。对于没有明确目的的高级开关，推荐维持现状；能说明原值、修改理由和恢复路径，才算完成一次可管理的设置调整。

02 · DNS：解析来源、配置范围与故障判断

先在 Settings 中查看 DNS 相关项目，再到 Config 打开当前配置文件，核对是否存在 DNS 设置。界面中的具体项目以实际显示为准，不同入口可能分别控制解析行为与配置内容。DNS 的工作是把域名解析为地址，随后才涉及连接目的地址、选择路径和完成上层请求。因此“域名可以解析”和“网页能够打开”是两个不同结论，不能用其中一个直接证明另一个。

先确认设置来自哪里

配置文件中可以通过 General 区域声明解析服务器。下面的片段演示使用系统解析来源的写法，不代表所有配置的默认值，也不是要求你替换现有文件。先检查当前文件是否已有对应条目；重复添加同一参数会让维护和定位更加困难。若文件由远程内容更新，手工修改还可能在后续更新时被替换，应先保存独立副本，再决定由哪个文件承担日常使用。

[General]
# 教学示例：使用系统 DNS 来源，不代表默认值
dns-server = system

[Rule]
# 示例域名通过 PROXY
DOMAIN-SUFFIX,example.com,PROXY
# 私有地址范围通过 DIRECT
IP-CIDR,192.168.0.0/16,DIRECT
# 其他请求通过 PROXY
FINAL,PROXY

不要仅凭某个设置项在界面上可编辑，就假定它必然覆盖 Config 中的全部内容。若界面提供说明、继承状态或作用范围，应优先按该说明判断；没有明确说明时，用当前配置副本进行单变量测试，并查看请求记录。推荐值不是某个固定解析地址，而是能够满足你当前网络与配置需求、且经重复测试确认可用的来源。已有正常解析时，没有必要为追求一个抽象指标更换全部设置。

把解析异常与连接异常分开

诊断时先选一个你平时能够访问的域名，记录解析是否返回结果，再观察连接是否超时。若所有域名都无法解析，优先检查当前网络、解析来源是否可达，以及配置条目是否写错。若只有某个域名异常，则应考虑域名记录、缓存或针对该域名的规则。若解析正常但连接失败，应继续检查所选服务器、目标服务和路由，不要不断更换 DNS 来处理并非解析层的问题。

某些规则需要域名信息，另一些规则以目的地址判断。域名经过解析后可能返回多个地址，访问过程也可能涉及多个域名，因此一次页面加载出现不同策略并不必然表示设置失效。观察时应对照同一次新请求的域名、目标地址与匹配结果，而不是只看页面名称。对于 IPv6，也应先核对当前网络和目标是否支持，再检查对应解析与地址规则；不建议把关闭某类地址当成普遍的第一步。

缓存、网络切换与推荐做法

修改解析来源后，旧缓存或已经建立的连接可能继续被使用。先结束旧请求，必要时重新连接，然后访问新页面；如果当前界面提供缓存清理工具，再按工具说明操作。不要为清理一个域名问题直接删除所有配置。切换 Wi-Fi 与蜂窝网络后，系统获取的解析来源和可达性也可能改变，所以一个网络上的结果不能直接代表另一个网络，测试记录应始终附上网络环境。

若使用需要额外连接步骤的解析方式，还应考虑该解析服务本身的可达路径。为了获得地址而先要访问某个域名，可能使初始解析更复杂；看到超时后应检查这条依赖，而不是只检查目标网站。推荐从已验证可用的简单配置开始，再按实际需求增加选项。恢复时还原原有解析条目并重新建立连接，同时确认没有遗留另一份重复配置，才能判断问题是否真正回到修改前的状态。

03 · On Demand：条件触发与手动连接的关系

在 Settings 中进入 On Demand，先查看总开关，再检查当前配置的网络条件与对应动作。On Demand 用于按条件管理连接行为，不是用于提高服务器速度，也不会自动补齐缺失的服务器信息。开始设置前，应先确认同一服务器在手动连接时可以正常工作；否则条件触发与服务器故障会叠在一起，让自动连接失败的原因难以辨认。

先定义条件，再选择动作

常见条件围绕网络环境展开，例如 Wi-Fi、指定 SSID 或蜂窝网络。以实际界面允许的项目为准，逐条确认匹配对象和行为，不要把“包含某个网络”理解成“排除其他全部网络”。SSID 是 Wi-Fi 网络名称，不是服务器名称；录入时应核对大小写、空格和设备显示的完整文字。对于名称相同但实际环境不同的网络，仅依赖名称无法表达所有差异，应保留手动检查连接的习惯。

推荐先只建立一条容易验证的条件。例如，先观察从蜂窝网络切到常用 Wi-Fi 后是否出现预期动作，成功后再添加下一项。若一开始配置多条相互覆盖的条件，遇到意外连接时很难判断是哪一条生效。不要假定列表里的每一项都以你想象的顺序累加执行；应阅读当前界面的说明，明确优先关系，再用实际切网结果确认。未说明的行为不宜依靠猜测补全。

为什么停止后又出现连接

如果手动停止后连接再次出现，先返回 On Demand 查看是否仍有适用条件，而不是反复删除系统中的 VPN 配置。系统可依据已启用的按需条件响应新的网络请求，因此停止一次连接与停用自动触发不是同一操作。需要暂时进行纯手动排查时，应先停用 On Demand，再停止连接，随后验证新的请求是否还会触发；结束排查后按记录恢复原来的条件。

网络切换也不是瞬时完成的。设备可能先失去原链路，再获得地址和解析信息，然后才能建立新的连接；在中间阶段观察到短暂不可用，并不能直接证明条件设置错误。应等 Wi-Fi 或蜂窝网络稳定后，重新发起请求，同时查看 Home 的当前服务器是否仍为预期项。On Demand 负责连接触发，不应被误当作每次切网都会替你选择另一台服务器的机制。

锁屏、后台与恢复检查

锁屏与后台运行受到系统调度和网络状态影响，不宜根据应用是否一直显示在前台判断连接是否存在。若问题只在长时间锁屏后发生，应记录解锁时的网络、连接状态和首个新请求，再与普通切网测试对照。不要为了观察后台行为连续快速切换开关；这种操作会增加状态变化，反而模糊触发链路。一次测试应留出网络稳定与请求完成的时间。

关于默认状态，本页不把你当前看到的 On Demand 开关当成全新安装的统一初始值，因为设备可能保留已有配置。推荐没有自动连接需求时保持手动控制；确有需求时，以最少条件覆盖明确场景，并记录怎样停用。若出现不符合预期的动作，先停用总开关确认手动连接正常，再逐条恢复条件。保留这条回退路径，比一次设置很多例外后再寻找冲突更可靠。

04 · Ping 与 Connectivity Test：测试对象和结果边界

先在 Settings 中查看 Ping 相关设置，确认当前提供的测试方式及目标；再回到 Home 观察服务器列表的测试结果。具体选项以应用实际显示为准，不能只凭一个数字判断用了哪种测试。Ping 在日常描述中常被泛指延迟测试，但不同方式可能测量不同阶段：有的关注地址可达，有的关注端口连接，有的还包含向指定目标发起请求的过程，结果不应混在一起排序。

数字说明了什么

一次测试只描述当时、当前网络、当前方法下的部分表现。测试目标、DNS、协议握手和服务端响应都可能影响结果，所以数值较低不保证网页加载较快，数值较高也不一定表示连接不可用。若某种探测没有回应，而实际页面能够正常打开，应先考虑该探测方式的适用范围。相反，端口能够建立连接，也不能证明认证、上层协议和最终目标请求都会成功。

修改测试参数之前，应记录原方法和原目标，避免把新旧结果当作同一组数据比较。测试目标若由你自行填写，应使用可持续访问且符合测试方式要求的地址，不要把订阅地址当作测试目标，也不要把包含访问凭据的链接放进去。测试地址的用途是完成一次探测，不是导入服务器。对于超时设置，建议先保留当前值；过短可能把正常波动记为失败，过长则会延长无响应时的等待。

列表测试与真实请求交叉验证

在 Home 中确认当前服务器前的选择标记，再开启连接，并运行 Connectivity Test。测试结束后，使用你实际需要的页面发起一次新请求。这样可以区分“列表探测有结果”“应用测试完成”和“目标业务可用”三个层次。只看列表数字而没有选中服务器，可能导致后续请求使用另一项；只看系统 VPN 标识，也无法确认上层访问是否已经完成。

为了比较两个已有服务器，应维持同一网络、相同测试方法和相同目标，并尽量在相近时间测试。不要一边切换蜂窝网络，一边更改测试地址，再把结果归因于服务器本身。对有明显波动的结果，应重复少量测试，观察能否稳定完成，而不是只保留最好的一次。更多选择方法可查阅延迟、地区与协议类型的判断说明，其中同样强调数字与实际体验的区别。

如何设置推荐测试基线

本手册不指定所有设备必须使用的统一测试目标或统一超时数值，也不把当前保存值称为应用默认值。推荐选择能够解释实际需求的方式：如果目的是观察最终网页请求，就需要把实际访问纳入验证，而不能停留在更早的连接阶段。保留一个长期使用的测试基线，有助于识别网络变化；频繁更换目标，会让历史记录失去可比性。

若 Connectivity Test 与实际页面表现矛盾，应检查两者是否经过相同路由、是否访问不同域名，以及测试目标本身是否有响应。某个目标维护或临时异常，不代表所有访问同时失效。恢复时还原测试方法和目标，重新选中服务器，再进行同一请求。把时间、网络、方法、目标和结果放在一起记录，比只保存一个延迟数字更能支持后续判断。

05 · Log 与 Data：从请求记录定位设置问题

在 Settings 中查看 Log 相关设置，再按当前界面提供的入口进入日志或请求记录；Data 中可见的数据内容也以实际界面为准。Log 更适合解释请求经过了什么处理，Data 则帮助观察连接与流量情况，两者不应与账单或服务商统计混为一谈。排错前先明确问题发生的时间和请求对象，再打开相应记录，避免在大量历史内容中依靠猜测寻找原因。

先制造一个可辨认的新请求

开始记录后，只操作一个需要排查的页面或功能，并记下大致时间。若同时打开很多应用，后台请求会使记录迅速增多，容易把另一个域名的错误认作当前页面的问题。页面加载可能涉及多个域名，主页面返回成功而资源请求失败，也会表现为内容不完整。因此应围绕同一次操作查看一组相关请求，而不是找到一条失败记录就立刻调整全部设置。

阅读时可以依次关注域名、目的地址、匹配的规则与策略，以及连接阶段是否出现错误。只有当前记录确实提供的字段才能作为证据，不要因为某字段没有显示就推断系统没有执行该步骤。若请求命中 REJECT，应先确认这是否符合规则意图；若命中 DIRECT，而预期是 PROXY，应检查规则顺序和 Config 是否选错，而不是直接修改服务器密码或测试超时。

日志等级与保留范围

日志等级决定记录的详细程度，不同等级的具体内容以应用说明为准。推荐日常保留能够满足基本观察的当前等级，遇到可重复问题时再临时提高详细程度，排查结束后恢复。更多记录不等于更正确的连接，也可能增加查找负担。不要把详细记录作为提升性能的开关；它的用途是收集证据，不能替代修正错误规则或服务器参数。

[General]
# 教学示例：日志等级，不代表应用默认值
loglevel = notify

[Rule]
# 具体域名规则应放在更宽泛规则之前
DOMAIN-SUFFIX,ad.example.com,REJECT
DOMAIN-SUFFIX,example.com,PROXY
# 其他请求使用 PROXY
FINAL,PROXY

上面的示例中，较具体的域名规则放在前面，避免被更宽的匹配范围提前覆盖。规则自上而下匹配，命中后采用对应策略，因此排查重点应是“实际命中了哪一行”，而不仅是“文件里是否写过这一行”。REJECT 的适用范围与误拦处理可继续查阅REJECT 规则说明。示例域名仅用于解释语法，不表示任何可用服务。

Data 数值与敏感信息处理

观察 Data 时，应先确认统计范围和起算条件。连接重建、应用重新打开或统计清理都可能改变你看到的范围，不能把两次不同范围的数字直接相减并解释为某个应用的消耗。存在少量流量只说明发生了数据交换，不足以证明目标页面完整可用；没有明显变化也可能与请求缓存有关。推荐把 Data 当作辅助线索，与日志和实际请求一起判断。

日志可能含有域名、地址、请求路径、订阅信息或其他访问细节。需要保存排查材料时，先保留本地原件，再制作经过检查的说明副本，删除访问凭据和无关内容；不要直接公开整段订阅链接。清理日志前，确认必要的时间点与匹配结果已经记下。若问题不能重现，也不要无限提高记录等级长期等待，先恢复正常设置，再在下次出现时按同样步骤收集最小范围的证据。

06 · Widget：快捷操作、显示状态与系统刷新

先在 Settings 中查看 Widget 相关设置，再到系统的小组件管理界面确认设备当前可以添加的 Shadowrocket 组件。可选尺寸、展示内容与交互方式以应用和系统实际提供为准，不应把另一台设备的布局当作本机一定具有的选项。Widget 的作用是提供状态或快捷入口，它并不是独立的一套服务器配置，也不替代 Home 中的当前项与连接检查。

添加之前先确认应用内状态

建议先在 Home 中选中要使用的服务器，确认 Global Routing，并通过实际请求验证连接，然后再添加 Widget。这样当组件显示与预期不符时，就能把问题限定在显示或快捷交互，而不是同时怀疑服务器配置。若组件允许选择展示对象，应确认它指向当前项、指定项还是其他分组；没有提供选择的组件，不要推测它会依据延迟结果自动选择服务器。

添加后先核对文字与应用内状态是否一致，再测试组件明确支持的操作。某些入口可能先打开应用，再由应用执行后续动作；另一些交互是否可直接完成，取决于当前系统与组件能力。操作时应观察最终状态，而不只是点击反馈。若需要确认已经切换到目标服务器，返回 Home 查看选择标记，再发起新请求，避免把打开应用误认为完成了连接切换。

为什么显示可能不是即时更新

系统会管理小组件的刷新与后台执行，Widget 通常不能视作逐秒更新的实时监视面板。网络刚切换、连接刚停止或服务器刚更换时，组件可能仍展示先前状态。推荐先打开 Shadowrocket 核对，再等待组件刷新，而不是根据旧显示反复点按。反复触发连接与停止，可能使实际状态持续变化，进一步增加组件与应用显示不一致的机会。

如果应用内与实际请求都正常，只有组件长时间没有反映变化，应按显示问题排查：确认组件属于 Shadowrocket，检查组件配置，再尝试重新进入应用或重新添加组件。不要第一步就删除服务器和 Config 文件。若应用内也无法连接，则应回到 Home、On Demand 与网络检查流程，不能期待重新添加组件修复服务器认证或 DNS 错误。

与 On Demand 配合时的行为

Widget 的手动操作和 On Demand 的条件触发可能先后发生。比如通过快捷入口停止后，系统又根据适用条件建立连接，此时应检查 On Demand，而不是直接判断组件失灵。测试快捷操作时，推荐暂时停用按需触发，确认手动行为，再恢复条件进行组合验证。把“入口是否执行”和“执行后是否被其他条件改变”分开，才能看清真正的原因。

锁屏状态下可见的信息还应考虑个人隐私。若组件展示服务器名称或连接状态，应检查这些名称是否包含你不希望在屏幕上公开的内容。服务器备注可以帮助辨认，但不宜写入密码、完整订阅地址或其他访问凭据。名称只是本地管理线索，修改备注并不会修改服务器实际地址与协议参数；调整后仍应到 Home 核对所选条目，避免同名条目造成混淆。

关于默认与推荐，本页不指定一种固定组件尺寸或布局，也不把组件缺席解释成安装失败。推荐只添加你确实需要的展示或快捷入口，并保留应用内验证路径。系统要求与支持情况以 App Store 页面标注及本机实际界面为准。恢复 Widget 设置时，可以先撤下组件并保持应用配置不变，确认日常连接正常后再逐项添加，这种隔离方式比重置整个应用更容易保留已有可用环境。

07 · iCloud 与 Config：同步范围、备份和文件更新

先在 Settings 中查看 iCloud 相关项目，并阅读当前界面对同步范围的说明；再到 Config 核对本机文件。同步是否可用，还受到系统 iCloud 状态、应用访问权限和网络条件影响。不要把启用一个开关理解为全部数据已经立即传到另一台设备，也不要假设 Home、Config、统计记录和系统授权一定属于相同的同步范围，具体以界面明确列出的内容为准。

同步之前保存可识别的副本

在启用或调整同步前，建议先整理当前文件名称，记录哪份正在使用，并通过应用实际提供的保存或导出方式保留可恢复副本。文件名可以包含用途，例如“日常规则”或“排查副本”，但不要用名称暗示未经验证的效果。仅复制一个文件而不确认内容是否完整，不能算完成备份；应重新打开副本，检查 General、Rule 等需要的区域确实存在。

同步与备份的目标不同。同步用于让参与设备获得相应内容变化，误改也可能随之传播；备份则用于找回修改前的状态。因此在两台设备上同时编辑同一份文件之前，应先明确哪一份作为当前基线。若出现冲突提示或同名副本，先分别保存并对照规则内容，不要只按文件名称选择覆盖。名称相同不代表内容相同，设备上最后一次打开的文件也未必就是你希望保留的版本。

Config 更新与本地修改的边界

在 Config 中确认当前启用的文件，再检查它是否来自远程内容，以及是否存在更新入口。远程配置更新与 Home 中的 Subscribe 更新不是同一对象：前者涉及规则和配置内容，后者围绕你导入的服务器信息。两者可能同时影响连接，但应分别核对。订阅链接从你的服务商处获取，导入后不要把它当作可公开分享的普通网址，也不要为同步方便写入公开备注。

对远程配置直接进行本地修改前，应考虑下次更新是否可能覆盖这些变化。推荐把需要长期保留的个性化规则放入独立、可管理的副本，并清楚记录更新来源与合并方法。若当前应用提供其他维护方式，应按其说明操作，而不是凭经验假定所有本地内容都会自动保留。更新后应检查关键规则和最终策略，再发起真实请求，不要只看更新动作是否结束。

换机与同步异常的检查顺序

另一台设备没有出现预期内容时，先确认系统账户与 iCloud 可用性，再核对 Shadowrocket 的相关权限和应用内开关，然后等待网络稳定并重新查看。不要反复开关同步并立即删除本地文件，这会让唯一完整副本面临风险。若两台设备只有部分内容不同，应先确认该内容是否在声明的同步范围内，再讨论同步是否失败；不属于范围的内容需要按应用提供的方式单独处理。

应用重新获取与应用内数据恢复也应分开看。已购应用通过 App Store 找回，具体步骤见已购恢复说明；服务器、规则和系统连接授权仍需逐项核对。若有多个订阅分组，可参考多订阅管理说明整理重复项目。推荐在新设备验证完成之前保留旧设备的可用配置，并暂缓两端同时编辑，待基线一致后再恢复日常同步。

08 · Proxy 端口：监听范围与设置恢复检查

在 Settings 中查看 Proxy 相关项目，区分本地代理监听、连接共享或其他实际提供的设置；项目名称与支持范围以当前界面为准。这里的本地端口，与 Add Server 中远端服务器的 Port 不是同一个参数。前者描述本机某个代理入口如何接收连接，后者描述客户端要连接远端服务的哪个端口。把两者改成同一数字并不会让连接更正确，反而可能破坏已有参数。

先判断是否确实需要本地监听

如果日常通过 Home 开关使用 Shadowrocket，并没有其他明确的本地代理使用需求，不应仅因为看到 Proxy 项目就开启额外监听。推荐保留当前可用状态，只在明确知道接入方支持何种代理协议、需要连接哪个地址与端口时调整。HTTP 与 SOCKS5 的接入方式不同，接入方选错协议时，即使端口可达，也可能无法完成请求；不能只核对一个端口数字。

本地回环地址通常表示只在本机内部访问；若当前界面提供对局域网开放的选项，其范围与风险就不同。启用之前应确认网络是否可信、哪些设备能够接入，以及界面是否提供认证或访问限制。不要把能够连接到同一 Wi-Fi 的设备一律视为可信，也不要在公共网络上为排查方便扩大监听范围。存在明确需求时，同样应采用满足需求的最小范围，用完后恢复。

端口、地址与冲突排查

端口需要是有效数字，并与接入方填写的值一致。若监听无法启动，先核对开关状态、填写格式与是否存在端口冲突，再检查应用的实际提示。不要随机连续更换端口后只保留一次偶然成功的结果；每次变化都应同时修改接入方，并记录前后值。对于本页无法统一核实的端口默认值，不提供猜测数字，应读取当前界面和对应说明，保留能够验证的原值。

地址也必须与使用范围对应。本机内部接入与另一台设备接入时，填写的地址不能不加区分地照抄。设备在 Wi-Fi 中取得的地址可能随着网络变化而改变，所以昨天保存的接入地址今天未必仍然正确。若问题只在切网后出现，应先核对当前地址和网络隔离条件，而不是立刻修改远端服务器参数。关闭额外监听后，原有手动连接能否正常，是一个有用的隔离检查。

回到规则与完整验证链

连接进入应用之后，仍需要按照当前 Global Routing 与 Config 判断策略。下面的片段演示规则顺序：先处理明确域名和私有地址，再处理区域规则，最后使用 FINAL。GEOIP 的匹配依赖地址及相应数据，不能理解成网站页面语言或服务器名称。该片段只用于语法教学，不应不加检查地覆盖你的完整文件，尤其要确认原配置中是否已有必要的例外规则。

[Rule]
# 指定域名使用 PROXY
DOMAIN-SUFFIX,example.com,PROXY
# 私有地址范围使用 DIRECT
IP-CIDR,192.168.0.0/16,DIRECT
# 匹配相应地址数据时使用 DIRECT
GEOIP,CN,DIRECT
# 前面的规则均未命中时使用 PROXY
FINAL,PROXY

完成调整后，按顺序核对当前网络、Home 选择项、Global Routing、Config、On Demand，以及刚修改的 Proxy 项目，再发起一个新请求并查看记录。这个顺序能够区分“入口没有接通”“规则选择不符”和“远端连接失败”。不要因为某个本地接入请求失败，就同时重置 DNS、同步和所有服务器；先把影响限定在刚改变的范围，才能保留可用基线。

若仍无法解释结果，恢复所记录的原值，停用本次新增的监听或条件，并重新验证修改前的路径。恢复成功说明问题与本次调整相关，但还不能证明某一个参数一定有错，需要重新进行单变量测试。日常推荐值因此不是一张固定数字表，而是一套可复现的状态：必要功能启用、作用范围明确、原值可找回、真实请求可验证。首次连接操作回到快速上手教程查阅，购买与兼容性问题则回到正版下载说明，避免用网络设置处理不属于它的问题。