Shadowrocket
Settings 设置项参考

1. Settings 的作用范围与默认状态

先区分设置、配置与服务器

Shadowrocket 中，Settings 管理客户端行为，Config 承载配置文件与分流规则，Home 用于选择服务器、检查 Global Routing 和控制连接。三者关联，但不能互相替代。修改 DNS 不会补齐服务器密码，切换服务器也不会自动修正错误的规则。排查前先写清目标：是某个域名打不开、网络切换后断开，还是所有请求都失败。目标不同，应该进入的设置路径也不同。

本手册以 iPhone / iPad 的路径名称组织内容；Mac、Windows、安卓与 Linux 版同为 Shadowrocket，但系统权限、后台机制和可见选项可能不同。没有看到某一行时，先检查平台和当前页面，不要根据其他设备的截图寻找完全相同的位置。涉及系统级网络权限时，以本机提示为准；涉及 iPhone / iPad 系统要求时，以 App Store 页面标注为准。

默认值、当前值与推荐值不是同一个概念

“默认值”指首次创建相应设置时的初始行为，“当前值”可能已经受到导入配置、恢复备份或同步的影响，“推荐值”则取决于使用目标。本页不把某台设备的现状写成所有版本通用的出厂值。遇到没有稳定统一默认值的项目，明确要求读取当前界面或活动配置；遇到未显式填写的字段，也不把空白直接解释为关闭，更不建议为了对照手册而重置全部数据。

建立可回退的修改记录

操作前记录活动 Config 名称、选中的服务器和 Global Routing 姿态，再保存准备修改的字段。需要备份文件时，放到自己可控制的位置；配置可能含有认证信息，不能把完整内容贴进公开问答。推荐一次只改一组相关设置，例如先保持路由不变，只调整 DNS，验证后再处理 On Demand。多项同时修改即使恢复连接，也无法确认是哪项起作用，之后复发更难定位。

修改后应重新建立测试连接。浏览器已有的长连接、应用缓存或系统解析缓存，可能让旧状态暂时保留；只刷新同一个页面未必能反映新值。可以先停止正在进行的测试，断开后重新连接，再打开明确知道用途的测试目标。若结果没有改善，先恢复原值，再进入下一分支。不要把频繁切换所有开关当作排查方法，也不要直接导入来源不明的整份配置覆盖现有设置。

客户端一次性买断 ≠ 线路套餐。iPhone / iPad 版 App Store $2.99 一次性付费，Mac / Windows / 安卓 / Linux 版免费。本站不提供、不销售、不推荐节点或订阅；客户端设置不能替代已有服务的有效认证与可用连接。

需要获取客户端时，使用下载指南：iPhone / iPad 从 App Store 获取，Mac 含 Apple 芯片与 Intel 两个版本，其他平台安装包均经本站 /dl/shadowrocket/ 提供。涉及首次打开的系统拦截，先按安装放行说明处理，再回到本页调整设置；安装问题与 DNS、规则问题应分开处理。

2. DNS 解析路径与失败排查

DNS 解决的是域名到地址的转换

访问一个域名时，应用通常先获得对应地址，再建立实际连接。因此，Connectivity Test 有结果而网页打不开，并不能直接说明远端服务器正常或异常：测试可能只覆盖其中一段，实际页面还可能请求其他域名。DNS 的作用是提供解析结果，不负责修复错误密码、过期认证或目标网站自身的问题。判断时应把解析、连接与应用响应分开，而不是把所有失败都归到 DNS。

默认状态需要同时核对 Settings 中的 DNS 相关选项和活动 Config 的内容。导入的配置可能显式指定解析器，也可能保留系统提供的解析路径。字段空白时，应结合说明和日志判断实际行为，不能自行推断它必然指向某个公共服务。推荐初次使用时保留已能工作的解析设置；只有出现明确的解析失败证据，才针对路径进行调整，而不是为了某个“通用最佳值”改动全部选项。

先确认查询能否到达解析器

检查顺序是：当前网络能否正常访问基础服务、服务器地址本身是否能解析、解析器能否通过预期路径到达、返回的地址是否随后连接成功。如果服务器地址也是域名，启动连接前可能就需要一次解析；若解析器的可达性又依赖尚未建立的代理，就可能形成依赖循环。此时应检查配置设计，而非连续换用更多解析器。把多个地址填进列表不等于它们都会按期望并行工作。

地址族与加密解析的边界

同一域名可以返回 IPv4 与 IPv6 地址。存在 IPv6 记录并不代表当前网络拥有完整的 IPv6 通路；反过来，禁用 IPv6 也不是所有异常的统一解法。推荐先查看失败连接实际使用的地址族，再比较另一条路径。需要临时改变相关设置时，应记录原状态，验证完成后按网络条件决定是否保留，避免为了单个网络的问题长期改变其他网络上正常的行为。

加密 DNS 主要改变查询的传输方式，不等于自动改变网页流量的策略，也不意味着解析结果必然适合当前线路。填写时要区分解析器地址、协议与可达性；如果当前界面允许使用相应方式，应按该字段接受的格式输入。不要把普通网页地址当作解析服务地址。涉及证书校验错误时，先检查系统时间与输入内容，不应通过关闭验证来掩盖解析链路的问题。

如何验证一次 DNS 修改

选一个可重复访问的域名，记下修改前的现象，然后仅调整一处解析设置。重新建立连接后，在 Log 中查看查询是否成功、返回什么地址、后续请求命中了什么策略。浏览器可能使用自己的解析机制，应用也可能缓存地址，因此应结合客户端实际记录判断，而不是仅凭一次刷新结果。若只有一个应用异常，先确认它是否沿用了独立解析或既有连接。

解析成功不等于目标可访问；连接超时也不等于解析失败。先识别故障所在阶段，再决定是否修改 DNS。

恢复时应还原解析器、地址族相关开关及活动配置，不只删除最后输入的一行。若恢复后仍异常，检查是否切换了网络、是否重新选中了另一份 Config。完整排查示例见DNS 解析失败排查；所有目标都无法连接时，继续查看无法连接常见问题，不要只围绕 DNS 重复试错。

3. On Demand 按需连接条件

触发连接与选择策略分别配置

On Demand 用来定义系统在什么条件下尝试建立或恢复 VPN 连接。它不是服务器选择器，也不是规则策略；即使按需连接成功，某个请求最终走 PROXY 还是 DIRECT，仍取决于 Global Routing 和活动配置。理解这一点可以避免常见误区：希望某个网站走代理，却只打开 On Demand；或者希望网络切换时恢复连接，却反复调整域名规则。

默认状态以当前设备实际开关和已保存条件为准，不能根据连接按钮显示开启就断定 On Demand 已启用。恢复数据或调整系统 VPN 设置后，也应重新核对。推荐先让手动连接稳定工作，再配置按需连接；如果手动状态下已经持续报错，自动重试只会重复同一种失败，增加日志噪声，不能修复远端地址、认证或网络条件。

按网络条件逐条建立规则

进入 Settings › On Demand 后，先阅读当前界面提供的条件类型，再设置确有需要的项目。若按无线网络名称区分行为，应准确核对名称，并留意大小写、空格以及同名网络。网络名称只是一项匹配条件，不能证明网络身份可靠。不要把名称相同直接视为相同的安全环境，也不要因此给本地代理端口开放更宽的访问范围。

推荐从一条容易验证的条件开始，例如明确区分当前无线网络与移动网络，确认系统实际触发结果后再增加其他条件。条件之间可能存在顺序或覆盖关系，应按当前界面说明排列。某条条件没有命中时，检查网络接口与名称是否符合，而不是立刻删除全部条件。测试时保留记录：切换前网络、切换后网络、触发时间和连接状态，这些信息比“偶尔会断”更容易定位。

手动断开后再次连接的原因

如果手动关闭后连接很快恢复，先检查 On Demand 和系统 VPN 按需设置，而不是直接判断客户端故障。系统可能在后续网络请求或网络变化时再次触发连接。要进行断开状态测试，应先暂停相关触发条件，再观察系统状态。仅反复点击连接开关，无法证明自动触发已停止；重启设备后若条件仍保存，也可能重新出现相同现象。

需要注意，连接状态与业务连续性不是同一件事。无线网络切到移动网络时，底层地址和链路发生变化，既有下载、通话或长连接可能需要应用自行恢复。On Demand 不能保证每个应用的会话保持，也不能绕过系统对后台运行和网络权限的管理。验证应使用新建请求，并把旧会话中断与新连接失败分开记录。

推荐顺序：手动连接正常 → 添加一条按需条件 → 切换网络验证 → 再补充其他条件。每增加一条，都保留可回退的原状态。

若条件看似正确却没有触发，核对系统中的 VPN 配置是否仍对应 Shadowrocket、是否存在其他连接占用，以及当前设备是否受管理策略限制。不要为了排查直接移除所有系统配置；先保存必要信息，再处理明确相关的项。首次权限与 Home 页面说明见首次打开设置，自动连接后的流量走向则继续查看本页 Config › Rule。

4. Ping 与 Connectivity Test 测试范围

先确认测量的是哪一段

Ping 是测试相关设置的索引名称，具体可选方式应以当前界面为准。不同方式覆盖的范围不同：有的主要反映网络往返，有的尝试建立目标端口连接，有的还涉及一次应用层请求。不能只看结果显示了数值，就认为认证、域名解析、规则匹配和所有网站访问均已通过。测试结果应与所选方法一起记录，脱离方法比较数值通常没有诊断意义。

默认测试方式、超时与目标应在 Settings › Ping 中读取；不同设备或恢复后的数据可能已有自定义值，本手册不规定一个适合所有网络的固定超时。推荐初始阶段保留当前可用方法，先观察实际访问。如果需要比较多个已有服务器，应固定网络、测试方式和测试目标，再进行多次重复测量，避免把无线信号波动与远端差异混在一起。

按测试方式理解成功与失败

当界面提供 TCP 类测试时，成功通常说明相关端口能够完成连接过程，不代表应用层认证一定通过。若提供 HTTP 类测试，还要留意目标响应、重定向、证书与解析是否参与其中。网络设备可能对某些探测方式限速或过滤，因此某种测试失败、真实业务却正常，并不矛盾。应先确认测试的定义，再决定结果是否与当前问题相关。

测试目标与超时怎样选择

如果允许自定义测试目标，推荐使用用途明确、能够稳定响应的目标，并在整轮比较中保持一致。不要用需要登录、会频繁跳转或对自动请求严格限制的页面来代表线路质量。目标本身异常时，所有服务器都可能显示失败；更换目标后恢复，也不能直接证明线路被修复。需要记录的是测试目标是否变化，以及失败出现在解析、握手还是响应阶段。

超时过短会把短暂抖动记为失败，过长则会让一次不可达测试等待较久。推荐先沿用当前默认表现，在确认网络确实需要更长等待时再调整；不要把超时设得很大来隐藏持续失败。并发测试也会消耗网络与设备资源，尤其在信号较弱、后台任务较多时，测量本身可能干扰结果。比较时应停止不必要的大流量任务，留出相近的测试条件。

与实际访问建立对应关系

在 Home 运行 Connectivity Test 后，应选择一个具体的失败业务进行验证：记录域名、Global Routing 姿态和所选服务器，再查看 Log 中的新建请求。测试成功而页面失败时，先检查该页面是否走了另一种策略、是否请求了额外域名、是否存在证书或认证错误。不要只依据服务器列表的排序切换来回，因为排序结果没有包含每个应用的真实需求。

推荐把一次验证写成三项：测试方式、测试目标、实际访问结果。延迟不是带宽，单次成功也不是持续可用性的保证。

当所有测试同时失败，先检查本机基础网络与权限；只有一个服务器失败，再核对其地址、端口和协议参数。协议包括 Shadowsocks、VMess、VLESS、Trojan、Hysteria2 与 WireGuard，各自所需字段不同，不应根据测试失败随意互换协议。参数应与用户已有服务器信息一致；具体导入过程见Add Server 操作说明，不要用测试设置弥补缺失的认证内容。

5. Log 记录范围与证据整理

从一次可重现的操作开始

Log 用于观察连接和处理过程，不是把所有错误自动归因的结论页。相同的“超时”可能发生在解析器、服务器端口或最终目标，必须结合上下文判断。推荐先把问题缩小为一次操作，例如连接后打开一个指定域名，然后查看这次操作附近的记录。一次打开多个应用、同时更新订阅并批量测试，会把多条事件混在一起，难以识别因果顺序。

日志记录是否开启、记录详细程度以及可保存范围，应以当前 Settings › Log 的可见选项为准，不假定所有平台都拥有相同等级。默认状态可能受到已有设置影响；日常使用推荐保留满足基本定位需要的程度，只有重现问题时才临时增加细节。持续详细记录可能增加存储与处理开销，也会积累更多域名、地址和连接信息，排查结束后应恢复原来的级别。

按连接阶段阅读，而不是只找错误词

先找请求涉及的域名或地址，再看匹配策略，随后检查连接建立与响应过程。若请求根本没有出现，可能是应用仍沿用旧连接、请求未经过当前路径，或记录范围不包含该类事件；不能因此断定网络没有请求。若出现明确 REJECT，优先检查规则；若连接目标始终是服务器本身，则应先核对协议和认证，而不是立即修改最终网站的域名规则。

建立最小重现记录

开始前记下本机时间和当前网络，保留旧日志中仍有价值的片段，再按界面提供的方法清理或定位记录起点。随后只做一次操作，记下结果并停止额外测试。整理时保留故障前后的连续片段，而不是只截取一个错误单词；前一行可能说明目标地址，后一行可能说明重试结果。缺少这些上下文，别人很难判断同一句提示属于哪一段连接。

如果问题只在无线网络切换后发生，应把切换前后的日志分开比较，查看新连接是否使用了新的路径。若只在某一 Config 下出现，保持服务器不变，比较活动文件和命中规则。每次比较只改变一个变量，才有机会把原因缩小到设置层面。看到重复错误不必立刻开启所有调试项目；先确认重复记录是不是自动重试或 On Demand 再次触发。

导出前处理隐私信息

日志可能包含访问域名、服务器地址、账号字段、订阅地址或其他可识别内容。分享前删除完整订阅链接中的认证参数、密码和个人信息；如果必须替换地址，保持同一个地址在整段记录中使用同一代称，否则会破坏连接关系。不要上传整个配置来代替问题描述，也不要把包含凭据的截图放进公开讨论。即使密码没有直接显示，带认证参数的链接也应作为敏感信息处理。

日志用于建立证据，不应用来证明某条线路“绝对正常”。保留阶段、策略与结果，删除认证和个人信息，再描述可重现步骤。

排查完成后，恢复日志级别，按需要清理本地导出副本，并确认没有为了测试而遗留的 DNS 或路由改动。若需要继续定位，先把问题归入解析、认证、规则或系统权限四类，再查连接故障问答。单纯增加日志数量不会自动得到更明确的结论；可复现条件与连贯上下文才是下一步判断的基础。

6. Widget 显示、快捷操作与状态核对

快捷入口不等于完整设置页面

Widget 用于在系统提供的位置显示信息或执行当前支持的快捷操作。具体形式、尺寸与可操作内容取决于系统和 Shadowrocket 当前界面，不能把一台设备的小组件布局当成所有平台通用功能。它适合减少重复进入客户端的步骤，不适合替代 Config 编辑、协议参数核对和日志分析。遇到状态异常时，应回到 Home 与系统 VPN 状态确认，而不是只根据小组件文字判断连接。

默认显示内容以 Settings › Widget 和系统添加界面为准，未添加到桌面也不意味着客户端连接功能被关闭。推荐先在客户端内验证连接与断开操作，再添加实际需要的组件。若系统没有提供相应类型，应以当前可用入口为准，不要为了寻找相同外观而修改 DNS 或重新导入服务器。组件是否出现，通常属于系统展示或权限问题，与域名规则是否正确没有直接关系。

添加后核对关联状态

在系统的小组件添加界面选择 Shadowrocket 后，按界面支持的方式放置并完成设置。首次使用先打开客户端一次，确认需要展示的信息已经保存；然后返回组件观察内容。若组件允许选择项目，应核对它关联的是当前使用的对象，而不是旧条目。删除或重命名服务器、调整配置后，也需要确认快捷入口是否仍指向有效对象，不能仅凭原来的标题推断关联没有变化。

刷新、后台与网络切换

系统可能限制小组件的刷新频率，因此显示内容不一定与客户端每个瞬间同步。推荐把组件视为便捷入口与状态参考，而不是连续网络监测器。锁屏、低电量状态、后台调度和网络变化都可能影响展示时机。出现旧状态时，先进入客户端核对，再等待系统刷新；不要连续删除配置或切换服务器来追赶一个尚未更新的显示结果。

如果使用快捷操作关闭连接，但随后又看到连接恢复，优先核对 On Demand，而不是认为组件没有执行。动作可能已经成功，随后系统按条件再次建立连接。反过来，组件显示开启也不保证目标请求通过了正确策略；Config 中的 DIRECT 或 REJECT 仍然可能生效。验证时应新建一次实际访问，并结合 Log 确认路径，不把图标或开关外观当作流量去向的证据。

显示信息与隐私边界

组件位于桌面或系统其他可见区域时，旁人可能看到服务器备注、配置名称或连接状态。推荐使用不包含账号、邮箱和认证信息的简短备注。若设备经常用于投屏、演示或共享屏幕，应提前检查组件展示内容；重命名不应改变原始连接参数。不要把订阅链接直接作为备注，也不要为了方便识别而把密码写进名称，名称与凭据应保持分离。

推荐取值原则：只展示日常需要的信息，只保留明确理解用途的快捷动作。系统状态与实际请求发生分歧时，以客户端、系统 VPN 状态及新建请求共同核对。

组件持续不可用时，先检查客户端能否正常打开、系统是否允许添加该组件、原关联项目是否仍存在，再尝试按系统方法移除后重新添加。不要在没有备份的情况下卸载客户端来修复展示问题，以免同时丢失本地配置。若客户端本身也无法连接，问题已超出 Widget 范围，应返回 Settings 总览确定修改范围，再按 DNS、权限或服务器参数分支继续排查。

7. iCloud 同步、迁移与覆盖风险

区分数据同步、购买记录与系统权限

iCloud 相关功能用于在支持的环境中处理应用数据，不能代替 App Store 的购买记录，也不能保证系统 VPN 权限跟随迁移。新设备上看到配置，不代表已完成首次网络权限确认；使用相同购买账号获取应用，也不等于一定能看到另一台设备的所有设置。应分别检查商店账号、系统云服务账号和客户端实际同步范围，避免把三种状态混为一个开关。

默认是否启用、哪些项目参与同步，应在 Settings › iCloud 和系统相关设置中查看。本手册不假定同步覆盖每个字段，也不承诺其他平台采用相同的云服务机制。推荐首次启用前先保存本地可恢复副本，并检查界面列出的范围。若只需要迁移一份 Config，可以先使用明确的导出与导入流程，而不是为了单个文件开启所有同步项目。

先确定哪一份数据需要保留

两台设备已有不同配置时，先选定需要保留的来源，并把另一台设备的重要差异单独记下。不要在两端同时大量重命名、删除和添加条目后，再期待系统自动判断哪份更合理。同步负责传递状态，不负责理解你的操作意图。冲突发生时，应阅读当前界面的处理提示；如果提示涉及替换或覆盖，先停下来核对备份，不要连续确认。

同步完成后仍要验证实际连接

在目标设备打开客户端，先看条目是否完整，再核对活动 Config、Global Routing 和选中的服务器。只检查名称相同并不够，端口、协议和附加参数都可能影响连接。随后手动建立一次连接，确认权限提示已经处理，再测试一个实际目标。最后才配置 On Demand 和 Widget，这样可以区分数据迁移问题与自动触发、展示问题。

订阅同步与订阅更新也不是同一个动作：同步可能让另一台设备获得已有条目，而更新需要访问用户已有的订阅地址，并依据返回内容处理数据。若新设备上的条目数量或名称不同，先核对更新是否成功、是否使用同一地址、是否存在本地编辑。不要立即删除旧数据再反复更新，否则可能同时失去仍可工作的本地记录与比对依据。

账号与敏感数据的处理

启用同步前，应理解配置可能包含服务器地址、密码、认证字段和订阅信息。设备与账号由谁控制，决定了这些数据可能被谁访问。共享设备上应谨慎保留完整配置；出售、转交或停止使用设备时，按系统与客户端提供的方法处理个人数据。仅从桌面移除 Widget 不会删除配置，仅关闭某个同步开关也不等于所有已保存副本被清除。

同步不是独立备份。删除和错误修改也可能传播；重要变更前保留一份不依赖实时同步的可恢复副本。

同步迟迟没有变化时，先检查云服务登录、可用空间、网络与应用权限，再观察客户端提示。不要为了催促同步在两台设备来回切换全部设置，这会增加状态差异。若必须恢复，先停止继续编辑，保留双方现状，再从确认过的副本恢复一端并验证。已购应用的重新获取另见换机与重装说明；数据恢复不能替代客户端购买与获取流程。

8. Proxy 本地端口与访问范围

本地监听端口不是远端服务器端口

Proxy 相关设置可能包含供本机应用连接的本地 HTTP 或 SOCKS 代理端口，具体项目以当前界面为准。这些端口属于客户端在本地提供的入口，与 Add Server 中填写的远端服务器端口不同。修改本地端口不会改变服务商提供的远端参数，也不会自动让其他应用采用代理。需要使用它的应用，必须支持相应代理方式并明确填写本地地址与端口。

默认端口及监听地址应读取当前设置，不根据网上示例猜测固定数字。推荐没有本地代理需求时保留原状态，不为完成“优化”而额外开放监听。确有需要时，记录端口、协议与访问范围；若界面允许绑定地址，优先把仅供本机使用的入口限制在本机。扩大到局域网会改变谁能够连接这个入口，必须同时考虑网络可信度、访问控制与系统防火墙。

地址、端口与协议必须对应

回环地址 127.0.0.1 表示当前设备自身，不代表同一无线网络中的另一台设备。在电脑上填写该地址，连接的是电脑本身，而不是手机上的 Shadowrocket。若确实配置跨设备访问，需要使用提供服务设备的实际可达地址，并检查监听范围；这属于额外的网络管理任务，不应仅因为端口开启就假定其他设备一定能连接。

端口冲突与连接失败怎样区分

端口被其他进程占用时，客户端可能无法建立对应监听。此时应先查看提示与日志，确认是哪一个本地入口失败，而不是修改服务器密码。需要换端口时，选择当前未使用且界面允许的值，同时更新调用该代理的应用设置。只改客户端、不改调用方，会产生新的不一致；测试完成后还应记录新值，避免下次恢复旧配置时再次出错。

如果本地入口可以连接，但目标请求失败，应继续检查客户端连接状态、Global Routing 和活动规则。应用可能已经成功把请求交给本地代理，后续却在远端认证或目标连接阶段失败。反过来，如果应用报本地连接被拒绝，先确认客户端仍在运行、对应入口已启用以及地址端口正确。将这两类现象分开，能避免把所有问题都归为线路异常。

系统隧道与显式代理的边界

系统 VPN 隧道与应用显式填写的代理设置，是两种不同的流量接入方式。不是每个应用都会遵循系统的显式代理设置，也不是打开一个本地端口就能覆盖所有应用。不要在不了解路径的情况下叠加多层代理，以免形成回环、重复处理或让日志难以阅读。推荐先验证一种接入方式，再判断是否真的需要同时启用另一种，避免把路径复杂化当作功能增加。

推荐原则：本机用途限制在本机，跨设备用途先明确访问边界。不要把本地代理端口暴露到无法控制的网络，也不要将其当作对外提供连接的服务。

退出测试时，除了恢复 Shadowrocket 的端口与监听状态，还要清除其他应用中临时填写的代理地址。否则客户端停止后，那些应用可能继续尝试访问失效的本地入口，看起来像整机网络异常。桌面系统若同时改过系统代理，也应按原记录恢复。确认普通网络恢复后，再逐项启用必要设置；规则去向不符合预期时，转到下一章检查 Config，而不是继续更换本地端口。

9. Global Routing、规则与设置联动

先确认当前采用哪种姿态

Global Routing 的配置、代理、直连分别对应 Config、Proxy、Direct。Config 按活动配置处理请求，Proxy 用于代理姿态，Direct 用于直连姿态。排查规则前必须确认当前处于 Config；否则即使编辑的规则语法正确，也可能没有按照预期参与请求处理。默认姿态应读取 Home 当前显示，不把教程中某一步的选择当作所有设备永久不变的初始值。

规则顺序与 FINAL 的位置

规则从上到下匹配，命中第一条后使用对应策略，因此更具体的条件通常应放在更宽泛的条件之前。DOMAIN 匹配指定域名，DOMAIN-SUFFIX 用于域名后缀，DOMAIN-KEYWORD 根据关键字匹配；IP-CIDR 和 IP-CIDR6 面向地址范围，GEOIP 根据地址归属数据判断。不同规则依赖的信息不同，域名存在并不代表地址规则无需解析即可完成判断。

FINAL 是前面规则没有命中时的兜底，通常置于规则列表最后。把它放在需要执行的其他规则前面，会使后续规则失去匹配机会。下面是可用于理解语法的最小 .conf 片段，不是完整配置，也不是通用推荐列表；示例域名与局域网范围仅用于说明顺序，导入前应根据自己已有的配置判断是否适合。

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

这个片段中，example.com 及其子域名先命中 DOMAIN-SUFFIX，不会继续落到后面的关键字规则。PROXY、DIRECT、REJECT 分别表示代理、直连和拒绝策略，不能与界面姿态的大小写混写来替代含义。需要阻止特定目标时，可以使用 REJECT，但应先明确影响范围；一个页面通常涉及多个域名，拒绝其中某个资源可能改变页面表现，而不是只让一个可见按钮失效。

推荐用比较法隔离设置影响

当 Config 下失败而 Proxy 下成功，优先检查命中策略、活动文件和 DNS 路径，不必立刻更换服务器；当两种姿态都失败，再检查远端参数和基础连接。Direct 的结果只说明当前直接路径的表现，不代表其他路径必然有问题。每次切换后使用新建请求验证，避免旧连接继续保留原来的路由，使比较结果看起来互相矛盾。

订阅更新、配置文件更新与手动编辑需要分开管理。订阅主要用于处理用户已有的服务器信息，Config 则负责相应配置内容，不能因为更新了其中一项就假定另一项也已同步变化。编辑前确认自己修改的是活动文件，更新前保留重要自定义规则；外部配置重新导入后，应检查是否覆盖了本地修改，不要只看文件名称相同就认定内容没有变化。

日常推荐使用已核对的 Config；排查时短时比较 Proxy 与 Direct。测试结束恢复原姿态，并重新确认 DNS、On Demand 与活动规则，避免留下临时状态。

规则与 DNS 的联动应通过 Log 验证：先找到目标，再看首条命中规则，最后检查后续连接。需要进一步理解优先级时，阅读自定义规则优先级与 FINAL；需要补做导入步骤时，返回Subscribe 操作说明。把配置变更、一次请求和对应记录联系起来，比堆叠更多规则更有助于稳定维护。