Shadowrocket Settings 设置项参考

ENTRY 01 / SCOPE & BASELINE

设置范围与修改基线

Settings、Config 与服务器参数

Settings 是应用级选项的入口，通常涉及测试、记录、自动连接及界面辅助功能；Config 是配置文件入口，负责规则和文件中的相关参数；Home 中的服务器编辑页保存某个连接对象的地址、端口与协议字段。三者共同影响一次请求，但作用范围不同。默认状态以当前应用显示为准，推荐先确定问题属于哪一层，再进入相应位置修改，而不是看到相似名称就同时调整。

全局行为与单个服务器的行为也要分开。修改一台服务器的 TLS 参数，通常不能修复另一台服务器；修改当前 Config 的规则，会影响使用该文件时的请求选择。订阅更新可能替换订阅内对象的部分字段，远程配置更新也可能重新带入文件内容。操作前应记下对象名称、来源及当前选中的配置，防止把“刚才改过”误当成“正在使用”。

先记录 Global Routing

Global Routing 决定总体处理姿态。配置对应 Config，代理对应 Proxy，直连对应 Direct。Config 依据当前配置处理请求；Proxy 用于将请求交由代理路径处理；Direct 用于直连。具体例外仍应结合应用说明和实际记录判断。推荐日常使用已验证的 Config，临时切到 Proxy 或 Direct 只作对照；测试结束恢复原值，避免把临时排查姿态遗留为长期设置。

建立可重复的基线

基线是一组修改前的条件，不是某个速度数字。至少记录当前网络是 Wi-Fi 还是蜂窝、Home 选中的服务器、Global Routing、当前 Config、DNS 原值及 On Demand 状态。随后选择一个允许访问且容易重复请求的目标，记下失败发生在解析、建立连接还是内容加载阶段。推荐用相同目标和相同网络比较前后结果，避免一次更换网络、服务器和规则后无法判断原因。

每轮只改变一个变量。先复制需要编辑的配置或在个人受控位置记录原值，执行一次修改，再重新建立连接并请求同一目标。某些设置对已经建立的连接不会立即体现，旧页面还可能使用缓存结果，因此验证时应发起新请求。若现象没有改善，先恢复原值再检查下一项；连续叠加多个未经验证的改动，会让可恢复的局部问题变成难以追踪的组合问题。

系统权限与商店事实

首次建立连接时，系统可能要求允许添加 VPN 配置，这是系统管理网络配置的授权步骤，不是服务器账号验证。未允许时，应先按系统提示完成授权，再排查协议。系统要求以 App Store 页面标注为准。iPhone 与 iPad 是本文主要操作对象，其他 Apple 设备的兼容性及通用购买适用性也应查商店说明，不把一台设备上的选项布局直接套用到另一台设备。

核对应用时，应使用官方图标、开发者 Shadow Launch Technology Limited 与应用 ID 932747118 三处信息。购买应用只取得客户端使用资格，连接所需的订阅或服务器信息仍由用户自行准备。若尚未完成安装与首次连接，应返回教程按顺序操作；本页的选项调整建立在基本配置可辨认、来源可确认的前提上，不代替账号与参数核实。

ENTRY 02 / NAME RESOLUTION

DNS 设置与解析路径

DNS 解决什么问题

DNS 用于把域名解析为地址。应用请求一个域名时，可能先查询地址，再根据地址建立连接；代理路径也可能由远端处理部分解析。因此，域名打不开不一定等于 DNS 故障，DNS 有返回也不等于后续连接可用。默认解析配置以当前应用和当前 Config 显示为准。推荐先保留能正常工作的解析路径，再围绕明确的失败目标检查，不把更换解析服务器当成所有故障的第一步。

Settings 中的 DNS 相关选项与 Config 内的 DNS 参数需要一起核对。实际生效来源可能受当前文件与功能开关影响，不能只看其中一页。操作时先确认正在使用的 Config，记录其中已有的解析条目，再查看应用内 DNS 项的说明。若两个位置都存在配置，依据当前界面的作用范围说明逐项验证；不要凭条目出现的位置推断固定优先级，也不要一次写入多组未经确认的地址。

普通解析与加密解析

普通 DNS 与加密 DNS 的区别主要在查询传输方式。DoH 通常以 HTTPS URL 表达解析端点，DoT 通常使用 TLS 连接到解析服务；二者都要求客户端能够先到达相应端点。加密传输不自动决定出口策略，也不能替代证书验证。推荐仅使用自己了解且当前网络可达的解析服务，并按输入框支持的格式填写；普通地址栏与完整 URL 栏不能混用，不能只凭字符串相似就互相复制。

某个加密解析端点本身使用域名时，还涉及如何获得该端点地址的问题。若基础解析不可用，单纯填入一个域名形式的端点可能无法建立首次连接。此时应检查端点是否可达、系统时间是否准确、当前网络是否要求先完成登录，以及应用内相应解析路径是否可用。推荐恢复原有可工作的 DNS 做对照，再决定是否继续排查该端点，而不是同时关闭多项校验来绕过错误。

域名规则与地址规则

域名规则可以直接依据请求携带的域名匹配；地址规则则依据目标地址处理。在需要地址信息才能判断时，解析结果可能影响后续选择。下面片段展示 Config 的常见写法，不是 DNS 服务地址，也不应直接粘贴进 DNS 输入框。示例中的 example.com 仅作说明，GEOIP 的结果依赖应用使用的数据；阅读记录时要分清“解析得到什么”和“规则选择什么”是两个问题。

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

no-resolve 用于地址规则时，可避免仅为匹配该规则而主动发起域名解析；它并不表示整个请求过程都不再使用 DNS。推荐仅在理解匹配意图时添加。若预期直连的域名进入了代理路径，应检查更靠前的规则和最终策略，而不是立即认定解析错误；若返回地址与预期不同，再结合缓存、网络切换和实际解析服务定位。

验证与回退顺序

验证 DNS 时，先用同一网络重复请求同一域名，观察失败是否稳定，再检查 Log 中可用的解析或连接信息。能取得地址但建立连接超时，应继续检查路由与服务器；解析就超时，则优先检查解析服务可达性和填写格式。若只有某个应用失败，还要考虑该应用自己的缓存或解析行为，不能把单个应用的结果当作所有系统请求的共同结论。

修改 DNS 后，按应用提供的方式重新建立连接；若需要清理缓存，仅使用当前界面明确提供的操作。随后重新请求目标并比较记录。恢复原值后问题消失，才说明改动与现象有关；若依然失败，应继续检查当前网络、Config 和协议字段。推荐保留一组已经验证的基线，避免每次网络变化都增加新的解析条目，最终无法辨认哪组设置仍然必要。

ENTRY 03 / AUTOMATION

On Demand 按需连接

触发连接与选择策略

On Demand 是依据条件请求系统建立或处理 VPN 连接的机制，不是规则分流的另一种写法。它回答何时连接，而 Config 回答连接之后如何处理请求。默认开关及已有条件以当前应用显示为准。推荐先验证手动连接稳定，再启用最少量的按需条件；如果手动连接尚未成功，自动触发只会重复失败，不会补齐服务器缺少的参数。

配置前，应先定义希望发生的结果：在某个 Wi-Fi 下连接、在蜂窝网络下连接，还是仅在特定域名条件下触发。不同条件可能对应连接、忽略或其他系统行为，实际可选动作以界面显示为准。不要把“不触发新的连接”直接理解为“立即断开现有连接”，也不要把手动关闭之后的短暂断开当成规则已经停用；下一次网络变化仍可能再次触发。

Wi-Fi 与 SSID 条件

SSID 是无线网络名称，不是路由器管理地址。填写时应按界面要求保留实际名称中的大小写、空格和符号，避免额外复制换行。推荐先添加一个能够现场验证的网络条件，在连接该网络时检查系统 VPN 状态，再离开该网络观察变化。家庭内多个接入点可能使用同一 SSID，名称相同不能证明网络环境相同，也不能作为访问某个服务的可信凭据。

如果设计了排除某个 Wi-Fi 的条件，需要同时检查是否还有覆盖更广的 Wi-Fi 条件。条件的排列、匹配范围与动作都可能影响结果，应按当前编辑页展示的顺序与说明理解。遇到“在排除网络仍连接”的现象，先确认是否存在先前已建立的连接，再看其他条件是否命中，最后考虑系统配置是否已保存；不要仅删除一条条件后就认定所有自动连接已经停止。

蜂窝切换与域名触发

蜂窝条件用于设备使用移动网络时的按需行为，与某个 SSID 的条件不等价。测试时应确认设备确实离开 Wi-Fi，并检查应用是否具有使用蜂窝数据的系统权限。推荐分别测试“新建连接”和“已有连接跨网络切换”两种情况，因为后者可能涉及会话重建。网络切换中的短暂中断并不必然说明规则错误，需结合触发时间与连接记录判断。

域名条件针对特定域名相关的触发判断，不表示同一域名的所有请求必然经过某个代理策略。系统缓存、已有连接及应用请求方式都可能改变可观察结果。填写时应遵循当前输入框允许的域名格式，不把完整网页地址和路径随意当作域名条件。推荐使用一个自己允许访问、能重复请求的域名测试，并在建立连接之后另外检查 Config 是否选择了预期策略。

自动重连与暂停排查

如果手动关闭后又自动连接，首先检查 On Demand 及其条件，再检查系统中对应的 VPN 配置状态。排查时推荐暂时关闭应用内按需功能并确认保存，然后手动断开，观察是否仍会重建。不要同时反复删除系统配置、重导订阅和修改规则；这些动作会破坏触发前后的对照关系，使“系统重新触发”与“用户重新安装配置”混在一起。

恢复自动连接前，应清理测试时留下的重复条件，逐条确认用途，并在 Wi-Fi、蜂窝与锁屏后重新使用的场景中验证。对后台行为的预期应以系统实际允许的执行方式为准，不把某次测试结果当作持续运行承诺。更具体的场景拆解见On Demand 按 Wi-Fi、蜂窝与域名触发说明；如只需要日常手动连接，可以保留已验证的手动流程。

ENTRY 04 / CONNECTIVITY TEST

Ping 与 Connectivity Test

测试结果代表的范围

Ping 与 Connectivity Test 用于观察某种探测方式下的可达性或耗时，不是完整业务请求的保证。测试可能针对服务器入口，也可能通过指定路径访问测试目标，含义取决于当前选中的测试方式。默认方式、目标与超时值以当前应用显示为准。推荐先阅读测试项说明，确定测的是哪一段路径，再比较数字；不能把不同测试方法的结果放在同一个排序依据里。

入口可达只说明探测到的地址和端口在当时有响应。协议认证、TLS 协商、远端解析以及目标服务仍可能失败。反过来，某些探测方式未获响应，也不必然说明正常请求不能完成，因为服务器可能限制特定探测。推荐把测试当作缩小范围的线索，并用实际允许访问的目标发起一次新请求确认，不把单次绿色状态或单次超时当作最终结论。

测试目标与超时

测试目标应选择自己允许访问、响应稳定且用途明确的地址。若应用要求完整 URL，应按该格式填写；若只要求主机或端口，则不应粘贴整段网页地址。目标发生重定向、要求登录或限制请求频率，都可能让结果偏离真实使用。推荐先确认目标自身可用，再用它对比不同服务器，避免所有对象同时超时时仍逐个修改协议密码。

超时值控制等待结果的上限，不直接提高网络性能。过短可能把较慢但可用的连接判作失败，过长则让批量检测等待更久。推荐先保留原值，在确认网络较慢且请求最终能完成时再谨慎调整。更改超时之后应记录新值，比较同一对象的多次结果；若只是为了得到“成功”而不断延长等待，就失去了发现异常的意义。

比较前保持条件一致

横向比较至少需要相同的网络、测试方法、测试目标与大致相近的测试时间。Wi-Fi 与蜂窝结果、前台与网络切换过程中的结果不宜直接混排。推荐先测试当前实际准备使用的服务器，再对照其他已有对象；批量测试会同时产生请求，结果可能受到瞬时拥塞和设备状态影响，不应因一次排序变化就持续自动切换，反而增加连接重建。

耗时较低不等于吞吐量较高，也不等于应用体验必然更好。小请求测试更接近建立连接或收到响应的某个阶段，大文件传输、视频缓冲和持续会话会受到不同因素影响。判断日常可用性时，应同时观察业务请求能否完成、失败是否重复，以及网络切换后是否恢复。推荐用适量重复测试排除偶发值，而不是高频探测来追求一个稳定不变的数字。

按失败阶段定位

全部已有对象在同一时刻失败时，优先检查本地网络、测试目标、系统时间以及当前是否需要完成网络登录。只有某个对象失败时，再检查该对象是否过期、地址是否能解析、端口是否正确、协议字段是否完整。测试正常而浏览器失败时，应继续检查当前 Global Routing、Config、DNS 与目标本身，而不是反复运行同一测试来等待业务自动恢复。

协议字段的核对应来自用户自己的服务器信息。Shadowsocks 的加密方式与密码、VMess 或 VLESS 的身份字段、Trojan 的认证与 TLS 信息、WireGuard 的密钥与地址范围各有含义，不能因为界面里都有“端口”就交叉填写。测试结果没有提供某字段正确的直接证据时，不应凭延迟高低猜测其取值；推荐逐字段与原始信息对照，保留可回退的原记录。

完成调整后，先停止无必要的批量测试，再重新连接并访问实际目标，避免探测流量干扰观察。如果故障仍在，记录测试方式、失败时间段、网络类型和经过脱敏的错误类别。可按连接超时排查顺序继续定位；提交材料时不需要附带完整订阅链接、认证信息或整份配置，足够说明失败阶段即可。

ENTRY 05 / OBSERVABILITY

Log 与 Data 诊断记录

Log 与流量统计的分工

Log 用于观察应用记录的连接事件、错误与请求处理线索；Data 用于查看应用提供的流量统计。二者都不是完整的网络审计，也不能替代目标服务的响应结果。默认记录状态、保留范围和统计周期以当前应用显示为准。推荐在复现问题前查看相关选项说明，只启用当前需要的诊断范围，并记住开始观察的时间，避免在大量历史记录中搜索不相关事件。

统计数值首先要看范围。某个页面可能显示当前会话、某个服务器或累计数据，不能把不同范围的数字相加后解释成运营商账单。重启、重置、切换对象及同步行为也可能改变显示基线。推荐比较同一统计页在一次可控请求前后的变化，确认其口径；若需要核实设备整体用量，应另行参考系统提供的统计，不用应用内某一计数推导所有网络活动。

用一次复现建立时间线

有效的复现应尽量简短。先确认当前网络、服务器、Global Routing 与 Config，再打开诊断入口，记下时间，然后只执行一个失败操作。回到 Log 后优先找相邻时间内的事件，按解析、连接、协商和响应阶段理解。如果同时打开多个应用、更新订阅和进行批量测试，记录会混入大量无关请求，难以判断哪个错误真正对应刚才的现象。

阅读错误时应保留上下文。连接超时说明某阶段没有在等待期限内完成，不自动证明远端永久不可用；连接被拒绝通常应检查目标端口及服务状态；证书相关错误需要核对时间、域名和 TLS 参数，而不是直接关闭验证。不同协议和请求的具体文本可能不同，推荐根据当前记录的原文定位，不把本页的错误类别当作必须逐字出现的界面字符串。

从记录核实规则选择

在当前界面提供相应信息时，可查看请求域名、目标地址、命中规则和所用策略。若某请求走向不符预期，先检查它是否真的使用了当前 Config，再查看更靠前的规则是否已经匹配。若日志只展示地址而没有域名，不应强行推断域名规则一定参与判断；请求可能已经由应用解析，或采用了不同的连接方式，需要根据可见证据限定结论。

记录中的敏感信息

Log、订阅地址与配置可能包含访问域名、服务器地址、用户标识和认证材料。导出或截图前，应先在个人受控位置检查并脱敏，尤其注意 URL 的查询参数与包含凭据的整行文本。推荐只保留错误附近必要片段，隐去可识别账号的内容。脱敏后仍需保留事件顺序与错误类型，否则虽然隐藏了信息，也可能使排查失去依据。

诊断完成后，应按当前应用提供的功能关闭临时增加的详细记录，必要时清理不再需要的本地记录。长期保留大量历史内容会增加检索负担，也可能留下额外的访问轨迹。不要把关闭 Log 理解为已经删除旧记录，也不要把清理 Data 理解为清除了订阅或服务器；各项操作的对象不同，应阅读确认提示后再执行，避免误删配置。

最终结论应能对应一条证据链：在什么网络、使用什么对象、执行什么请求、出现什么记录、修改什么之后发生变化。若无法建立这种对应关系，推荐回到最小复现场景重新观察，而不是继续扩大记录范围。涉及系统设置、当前配置和请求本身的交叉问题，可以把本章与 DNS、Config 两章联读；已有错误类别的场景也可通过文末排错问答快速回查。

ENTRY 06 / WIDGET & ICLOUD

Widget、iCloud 同步与配置保存

Widget 的作用边界

Widget 是系统提供的应用信息展示或快捷操作入口，具体可见内容与交互能力取决于设备系统和当前应用实现。默认是否添加、显示哪些项目，以系统与应用当前界面为准。推荐先在应用内完成一次正常连接，再添加需要的 Widget；不要把桌面上出现组件视为 VPN 已经连接，也不要把组件显示未刷新直接当成服务器断开。

添加时，可通过系统的组件编辑流程找到 Shadowrocket，并选择当前提供的样式。若 Settings 中有对应显示选项，再依据用途调整。组件更新受到系统调度影响，应用内状态与桌面显示可能并非同时变化。推荐在重要操作后打开 Home 核实连接和当前服务器，尤其是刚切换网络、修改配置或结束测试时，不依赖一个可能尚未刷新的快捷显示作唯一判断。

快捷操作与自动连接的关系

Widget 中的操作是发起动作的入口，不改变服务器认证与 Config 的基本要求。首次系统授权未完成、所选对象参数不全或 On Demand 仍有触发条件时，快捷操作的结果可能与预期不同。推荐先在应用内排除这些问题，再回到组件验证。若点击后状态反复变化，应同时检查 On Demand，而不是不断重新添加组件来尝试修复连接逻辑。

iCloud 同步不等于订阅更新

iCloud 同步用于当前功能明确支持的数据同步，不等于向用户自己的服务商请求最新订阅，也不保证所有系统授权与临时状态都跨设备复制。默认开关及同步对象以当前应用说明为准。推荐先确认两台设备的账号、iCloud 使用权限与网络状态，再检查应用支持同步的具体项目；不能因另一台设备已经安装应用，就假定其中所有连接对象已经自动就绪。

订阅更新、远程 Config 更新与 iCloud 同步属于不同动作。订阅更新可能改变订阅内服务器列表；配置更新可能替换规则内容；同步则可能把已保存的数据传播到另一台设备。遇到“修改后又变回去”时，应先判断是哪类动作发生，而不是把全部变化归为同步故障。推荐记录条目的来源，并避免在多台设备上同时编辑同一个对象，尤其不要一边更新远程内容一边覆盖本地副本。

同步冲突与删除传播

同步冲突指不同设备对同一数据存在不同修改，实际保留方式应以当前应用行为为准，不能默认最新看到的内容一定是唯一正确版本。处理前，先在个人受控位置保存两端仍有价值的配置，确定准备保留哪一份，再逐项合并或重新导入。不要在不明确同步方向时反复开关功能，或连续删除对象试图强迫刷新；删除本身也可能被传播。

保存副本时，应区分服务器信息、订阅来源和 Config 文件，不把三者混成一个无法辨认的导出物。文件名可记录用途与个人修改说明，但不要在名称里写入密码或完整订阅地址。推荐将含认证信息的材料保存在个人受控存储中，导入后检查对象数量与关键字段是否完整；备份成功的标准是能够恢复并完成验证，不是看到文件已经生成。

换机后的验证顺序

换机时先从 App Store 获取 Shadowrocket，应用已购恢复与购买适用性见换机和重装说明。随后核对同步或导入的数据，再完成设备本身需要的系统授权。VPN 权限、Widget 布局与当前网络环境不能简单当作另一台设备的副本。推荐先手动连接一台已确认参数完整的服务器，成功后再恢复 On Demand 与辅助显示设置。

最后检查两台设备是否都在使用预期 Config，并确认订阅更新后本地修改是否仍存在。对重要规则的调整，建议保留修改缘由，便于更新后复核。若只是一台设备出现问题，应优先比较该设备的权限、网络和当前选中项，不立即删除另一台设备的可用配置。按照“获取应用、恢复数据、手动验证、恢复自动化”的顺序处理，更容易保留可用基线。

ENTRY 07 / PROXY & PROTOCOL

Proxy 端口与服务器协议参数

本地端口与远端端口

Proxy 相关端口首先要区分方向：本地监听端口供明确配置为使用该入口的请求连接，服务器端口则指用户自己的远端服务入口。二者不是同一个数字，也不能互相替代。默认端口、监听范围与功能状态以当前应用显示为准。推荐没有明确用途时保留原值；只有确实需要本地代理入口，并理解请求如何到达它时，再修改相关设置。

修改本地端口时，应检查输入范围与当前功能是否启用，避免与其他监听服务冲突。端口值改变后，显式指向旧端口的请求不会自动知道新值，需要同步修改其连接设置。若界面提供允许其他设备访问之类的选项，还应确认监听范围与所在网络的访问条件。推荐仅开放确有需要的范围，不把允许访问当成提高速度的开关，也不把应用退到后台视为入口必然持续可用。

协议字段不能交叉套用

远端服务器编辑应以用户已有的完整参数为依据。Shadowsocks 常涉及加密方式与密码；VMess、VLESS 涉及相应身份字段及传输设置；Trojan 通常需要认证与 TLS 相关信息；Hysteria2、WireGuard 则有各自的认证或密钥、地址等字段。推荐先确认协议类型，再核对当前界面显示的必填项，不把一个协议的密码直接填进另一个协议的身份字段来尝试。

通过 Subscribe 导入的对象也可能存在字段缺失、格式不匹配或信息已变更的问题。导入成功只表示应用识别并保存了某种内容，不证明远端认证已经通过。若手工修改了订阅内对象，还应留意下次更新是否覆盖。推荐先保存需要比较的原始信息，在明确自己有权使用这些配置的前提下逐字段核对；不要通过随意更换协议类型来试探服务器。

TLS、SNI 与系统时间

TLS 用于建立受证书验证约束的加密连接，SNI 通常用于在握手中指明相应服务器名称。地址、证书域名与应用里的相关字段可能不完全相同，填写方式应来自用户自己的服务器信息。推荐保留证书验证，并核对域名拼写、设备时间与必要的中间配置。发生证书错误时，不应通过填入无关域名或关闭验证来掩盖问题，否则会改变连接的验证前提。

传输层字段同样需要精确。路径可能区分大小写，Host 可能与连接地址承担不同角色，额外空格也可能导致请求不匹配。推荐在编辑前复制原值作为对照，修改后重新建立连接，观察错误是否从入口连接阶段推进到协议协商或响应阶段。若错误完全相同且没有更明确证据，应恢复原值；反复修改多个字段只会让原始可用信息逐渐丢失。

远端配置与本地能力的边界

某些功能依赖远端支持，不能只靠本地开关增加。端口可达不说明远端已经启用所选协议，测试成功也不说明所有传输方式都可用。对于 WireGuard，地址范围与路由意图需要与已有配置一致；对于其他协议，认证与传输设置也要配套。推荐把服务器提供的信息视为一组相互关联的参数，而不是可以独立随机组合的候选值。

完成核对后，先在不改变规则的情况下验证单个服务器，再回到 Config 检查目标请求的策略。若某个目标仍失败，应判断它是未经过所选服务器，还是经过后无法完成响应。本地 Proxy 入口、远端连接和目标请求属于连续但不同的环节，每一环都需要自己的证据。没有使用本地监听功能的需求时，不必为了排查远端认证问题去改本地端口。

ENTRY 08 / CONFIG & VERIFICATION

Config 规则、修改验证与回退

规则的顺序与最终策略

Config 保存用于请求处理的配置内容，规则按顺序参与匹配，先命中的适用规则决定相应策略，FINAL 负责前面未匹配的请求。默认规则集以当前选中的文件为准，推荐先理解现有文件的意图，再添加必要规则。仅编辑一个未被选中的文件，不会让当前请求立即采用其内容；验证前应返回 Config 确认使用对象，并检查 Global Routing 是否处于 Config。

规则关键字决定匹配条件，策略决定命中后的处理方式。DOMAIN 用于精确域名，DOMAIN-SUFFIX 用于域名后缀，DOMAIN-KEYWORD 用于包含指定关键字的域名；IP-CIDR、IP-CIDR6 用于地址范围，GEOIP 使用地理地址数据。PROXY、DIRECT、REJECT 是不同的策略意图，不能把关键字与策略位置互换。推荐优先使用范围明确的条件，避免过宽的关键字误匹配无关请求。

[Rule]
DOMAIN,api.example.com,DIRECT
DOMAIN-SUFFIX,example.com,PROXY
IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
IP-CIDR6,fc00::/7,DIRECT,no-resolve
GEOIP,CN,DIRECT
FINAL,PROXY

这个片段中，api.example.com 先命中精确规则，其余匹配 example.com 后缀的域名再采用后续策略。地址范围规则表达示例中的直连意图，不保证所有网络都使用相同的本地地址规划。片段只用于理解语法与顺序，不是适合所有人的完整配置。推荐将需要的规则放进已经备份的文件中逐条测试，而不是直接用这几行覆盖自己原有的全部内容。

远程更新与自定义修改

远程 Config 更新可能带入新的规则内容，本地修改是否保留需要按当前应用的保存与更新方式确认。推荐明确区分原始远程文件与自己的试验副本，在修改记录中写明“为何添加”和“验证了哪个目标”。订阅里的服务器列表与 Config 的规则来源也应分别记录；更新前者不等于更新后者，出现变化时先核对实际更新对象，避免把服务器名称变化解释成规则顺序变化。

当一个请求没有命中预期规则时，按固定顺序核对：是否使用 Config 姿态、当前文件是否正确、前面是否有更宽规则、实际请求是否仍使用原域名、最终策略是否提前兜底。某些应用请求可能只有地址，或经重定向访问另一个域名，因此编辑最初看到的域名不一定覆盖整个过程。推荐通过 Log 中可见的信息确定匹配对象，再决定添加域名规则还是地址规则。

完成一次闭环验证

一次完整修改应包含修改前基线、单项变更、重新建立连接、同目标请求与结果记录。成功标准不是开关保持开启，而是预期目标通过预期路径完成操作，其他必要请求也未受影响。推荐在同一网络验证后，再检查常用的另一种网络条件；如果同时使用 On Demand，还要确认自动连接触发后仍采用预期 Config，而不是只验证手动连接时的表现。

回退应恢复刚才改动的对象，不必立即重置全部应用。规则错误先恢复文件，DNS 错误先恢复解析设置，协议错误先恢复对应服务器字段。只有在无法识别现有状态且已保存重要数据时，才考虑更广范围的重建。恢复后也要重复同一请求，确认基线确实回来；若恢复仍失败，说明可能存在网络变化或远端变化，需要重新建立当前条件下的基线。

常见排错问答

如果尚未完成首次导入，回到快速上手教程按主线操作；需要核对规则范围与 FINAL 的位置，可继续阅读自定义规则与最终策略说明。本页的使用方法是按失败阶段回查对应章节，保留原值、少量修改、依据记录验证，而不是一次启用全部设置。