Shadowrocket
Settings 设置项参考
按设置作用范围、连接路径与验证结果查阅。先确认当前值，再调整单个变量；默认值无法统一确认时，以当前应用显示为准。
- 设置含义
- 默认值核对
- 取值建议
- 规则排查
本页是 Shadowrocket 官方手册的系统查阅部分。尚未完成首次连接，请先阅读教程中的快速上手主线，完成已有服务器或订阅的导入、服务器选择与连接验证，再返回本页定位具体选项。已经能够连接但遇到解析、自动连接、测试或同步问题，可直接按目录进入对应章节。
本文以用户已有自己的订阅或服务器信息为前提。客户端一次性买断 ≠ 线路套餐；本站不提供、不销售、不推荐节点或订阅。应用为闭源商业应用，唯一获取入口为 App Store；购买、兼容性和系统要求请通过正版核验与下载说明核对，以 App Store 页面标注为准。
Settings、Home、Config 等入口名称保留英文。部分选项会随当前配置、设备与应用状态变化；这里的建议是排查起点，不是覆盖所有环境的固定参数。操作前保存正在使用的 Config，并记录 Global Routing、选中服务器及相关开关，避免把原有行为误认成修改后的结果。
Global Routing 与设置生效范围
Global Routing 决定连接采用哪一种总体处理方式，是查阅 Settings 前需要确认的第一项。界面中的 Config、Proxy、Direct 分别对应配置、代理、直连三种姿态。它们与顶部连接开关不是同一件事：开关表示客户端连接是否运行，Global Routing 表示运行后怎样处理连接。系统显示 VPN 状态，也不能单独证明某个目标正在经过所选服务器。
区分总体姿态与单条规则
Config 使用当前启用配置中的规则决定策略，适合需要按目标区分连接路径的情况。Proxy 以代理处理为主，可用于验证已有服务器是否能承载指定访问。Direct 以直连处理为主，适合做对照检查。具体保留行为还需结合当前配置与应用说明核实，不应把姿态名称推导成每一种系统流量都完全相同的处理结果。
| 界面取值 | 含义 | 建议用途 |
|---|---|---|
| Config | 由当前配置规则选择策略 | 日常分流与规则命中检查 |
| Proxy | 以代理处理为主 | 隔离规则因素，检查服务器路径 |
| Direct | 以直连处理为主 | 对照本地网络与目标可达性 |
切换到 Proxy 后访问恢复，只能说明总体路径变化与结果相关，不能立即断定某条规则有误。还需要检查是否同时换了服务器、是否复用了旧连接、域名是否重新解析。相反，Direct 下能够打开目标，也不能证明代理参数有效。有效的对照应固定目标、网络和服务器，每次只切换一个姿态，并为测试建立新的连接。
核对 Settings、Config 与服务器的边界
同一个现象可能涉及三层设置：Settings 中的应用级选项、Config 中的规则及解析设置、服务器编辑页中的协议参数。某个值在一处出现，不代表它一定覆盖其他位置的同名设置。先确认当前实际启用哪份 Config，再查看是否存在相关条目；导入文件后，原先的应用级选择是否继续生效，应通过实际行为与 Log 验证，而不是凭文件存在来判断。
默认值的核对也应分层。首次安装时看到的值、恢复数据后的值、导入配置后的值，可能并不相同。本手册对无法可靠统一确认的项目均采用“以当前应用显示为准”。建议记录设置名称、所在入口、修改前取值以及预期影响，例如“仅比较解析方式，不更换服务器”。这比保存一张缺少上下文的局部画面更便于复原。
建立可重复的基线
开始排查时，先选择一个已知正常且由用户自己维护的服务器，确认 Home 中的选择标记，再记录 Global Routing 与当前 Config。暂停自动订阅更新和可能触发重新连接的条件，只在测试期间保持环境稳定；完成后恢复原有安排。测试目标可使用自己能确认状态的页面，不要把不同网站的访问结果混在一起比较。
每轮测试记下操作顺序：断开连接、修改一项、重新连接、建立新请求、查看对应记录。若结果不符合预期，先恢复上一状态并复测，确认问题是否可重复。浏览器缓存、持续下载和后台长连接都可能沿用旧结果，因此刷新页面并不总是等于重新建立完整连接。必要时关闭该目标页面后再打开，但不需要为了单次失败清空所有应用数据。
DNS：解析方式与连接路径
DNS 将域名转换为可用于连接的地址。出现“域名打不开、直接使用地址却有不同结果”时，应检查解析，但不能据此立即修改所有 DNS 选项。解析请求是否成功、返回地址是否适合当前网络、后续连接走哪条策略，是三个不同问题。域名解析成功只表示得到答复，不代表目标端口、TLS 握手或页面内容已经能够正常访问。
系统 DNS、自定义 DNS 与加密解析
系统 DNS 沿用当前系统和网络提供的解析安排，适合先建立基线。自定义 DNS 指定另外的解析目标，便于控制解析来源，但该目标必须在当前环境中可达。DNS over HTTPS 通过 HTTPS 传输解析请求，增加了对解析服务地址、证书和连接路径的依赖。选用它不等于所有后续业务流量都会采用同一种策略，两者应分别核对。
建议从当前可工作的解析方式开始。需要更换时，先记录已有条目及其顺序，只替换一个解析来源，重新连接后对同一个域名测试。不要同时加入多个来源来“增加成功机会”，因为返回结果、响应先后与缓存可能让问题更难复现。若某解析入口本身也需要域名解析，还要考虑首次连接时能否先获得该入口地址，避免形成相互依赖。
| 方式 | 需要核对 | 取值建议 |
|---|---|---|
| 系统 DNS | 当前网络提供的解析是否正常 | 作为初始对照，不把它视为固定服务地址 |
| 自定义 DNS | 地址格式、可达性与解析结果 | 使用自己已确认可用的解析目标 |
| DNS over HTTPS | 完整入口、证书与访问路径 | 确有需求再调整，保留原值便于恢复 |
检查配置覆盖、缓存与地址类型
Config 可能包含 DNS 相关条目，因此不能只看 Settings 一处。若修改后表现完全不变，先检查启用文件中的相关设置，再确认测试请求是否仍使用缓存。不同层级可能各自缓存结果，重新打开网页不一定触发新的解析。观察 Log 中是否出现新的解析记录，比连续多次点击刷新更有判断价值；也不要把一次缓存命中误认成新的解析响应。
同一域名可能返回 IPv4 与 IPv6 地址。若其中一条网络路径不可达，表现可能是等待较久后才成功，或部分请求失败。此时应分别观察返回地址类型与连接错误，而不是先认定解析服务错误。是否启用相关选项应依据当前网络、服务器能力与目标情况决定，默认值以当前应用显示为准；调整后要同时检查原先能够访问的目标是否受到影响。
按失败阶段决定下一步
没有得到解析答复时，优先核对解析入口的格式、网络可达性及配置生效位置。已经得到地址但连接超时，应转查路由策略与服务器。能够建立连接却出现证书错误，应核对访问域名、设备时间及服务器相关参数，不要用反复更换 DNS 掩盖证书问题。某个网站返回业务错误页面时，网络连接可能已经完成，继续改解析设置通常缺少针对性。
涉及本地设备名称或局域网服务时，还需考虑名称解析范围。公共解析来源未必知道家庭或办公网络中的内部名称；把所有解析都交给同一个外部入口，可能改变原先可用的本地访问。应保留原始配置，并用一个本地目标与一个普通域名做成对测试。修改目标是使解析符合实际需求，而不是让配置中出现更多协议名称。
On Demand：触发条件与自动连接
On Demand 用于按照已经设置的条件触发连接。它不是服务器自动修复，也不是订阅更新功能；条件满足只意味着系统可以按照相关安排尝试连接，连接能否完成仍取决于当前服务器、配置与网络。手动关闭连接后又恢复运行，首先应检查这里是否仍有生效条件，而不是认定顶部开关失效或应用状态显示错误。
先确定需要自动化的场景
配置前先写清目标，例如只希望在某类网络中触发，还是希望连接状态在网络切换后继续保持。再查看当前应用实际提供的条件类型与匹配方式，不要把其他界面的字段名称直接套用过来。如果需要按无线网络名称区分环境，应逐字核对名称，注意空格与相似字符；同名网络可能出现在不同地点，仅靠名称不能证明网络身份。
默认开关及初始条件以当前应用显示为准。对尚在排查首次连接的用户，建议先暂停 On Demand，手动确认单个服务器可以正常工作，再增加自动条件。否则连接失败与条件反复触发会叠加，Log 中可能出现多轮相似记录，很难判断是哪次手动操作对应的结果。恢复自动化时，每次只增加一条有明确目的的条件。
系统授权与网络切换
首次建立连接时，系统可能要求允许添加 VPN 配置；应核对应用名称并按系统提示完成。已经允许不代表任何自动条件都已启用，启用条件也不代表系统授权一定完整。若应用中显示已打开而系统未能建立连接，应分别检查授权状态与连接错误。系统要求和设备兼容性以 App Store 页面标注为准，不依据旧设备经验推定当前状态。
无线网络与蜂窝网络切换会改变可达路径，也可能使现有连接中断。测试 On Demand 时应先固定网络，观察条件是否触发，再执行一次明确的网络切换，并记录切换前后状态。不要同时更换服务器和 Config，否则即使连接恢复，也不能说明自动条件设置正确。对于需要网页登录确认的网络，先完成网络自身的接入步骤，再验证代理连接。
| 现象 | 先核对 | 下一步 |
|---|---|---|
| 关闭后再次连接 | 是否仍有自动触发条件 | 暂停条件后重复手动断开 |
| 切换网络后未连接 | 条件是否匹配新网络 | 手动测试新网络中的服务器可达性 |
| 反复尝试连接 | 服务器错误与网络接入状态 | 暂停自动化，单独复现连接失败 |
排查自动行为与手动行为的差异
若手动连接正常、自动连接不符合预期，应优先查触发条件，而不是修改协议参数。检查条件是否已经保存、当前网络是否确实满足、是否有其他条件产生不同动作，并确认系统配置仍然有效。若手动连接也失败，则先回到服务器与解析排查。把两种情况分开，可以避免为了一个自动触发问题重建全部已有数据。
另一类常见现象是应用退出前台后，用户以为已经断开，但系统连接仍存在。应用界面是否在前台，与系统网络扩展是否运行不是同一个状态。判断时应结合系统连接状态与重新进入应用后的显示，不把后台应用列表当成连接开关。需要停止自动连接时，先处理生效中的 On Demand 条件，再断开并确认结果，避免条件立即重新触发。
长期使用前，至少完成三种验证：条件满足时能够连接、条件不满足时行为符合预期、服务器不可达时错误能够被识别。自动连接只应减少重复操作，不应遮蔽故障。若设备由组织管理，系统配置可能还有管理限制，应依据设备实际提示判断；不要通过反复删除与添加配置替代对条件和授权的检查。
Ping 与 Connectivity Test：测试结果的边界
Ping 与 Connectivity Test 用于观察连接状态，但不同测试方法测量的对象并不相同。服务器地址能够响应，不等于代理协议认证成功；代理可以访问测试目标，也不等于所有业务目标都可用。读取结果前，先确认当前选择的测试方法、测试目标以及被测服务器，再解释数值或失败提示，避免把一个局部结果扩大成整体网络结论。
区分网络可达与代理可用
Ping 相关设置可能影响服务器列表采用的测试方式。具体可选项与默认值以当前应用显示为准。基于网络层响应的测试主要说明地址路径的情况，基于端口建立连接的测试主要说明端口是否能够接入，经过代理访问目标的测试则还涉及协议、认证、解析与目标服务。测试层次越多，失败原因也越多，不能仅凭一个失败标记确定是哪一层出错。
例如服务器地址可以到达，但密码或 TLS 名称不正确时，简单可达性测试与实际访问可能出现不同结果。反过来，某些网络不返回特定探测响应，业务请求却能够完成。遇到这种差异，应保留两种结果，继续观察真实连接记录，而不是为了使列表全部显示成功就修改服务器参数。参数应与用户已有服务器的信息一致，测试显示不是配置事实的替代品。
选择稳定且明确的测试目标
测试目标应是自己能够确认用途与状态的地址。若设置允许填写 URL，需要核对协议、域名、路径是否完整；目标重定向、要求登录或暂时限制访问，都可能改变测试结果。不要把一个经常变化的业务页面当作唯一标准。更换测试目标时只改目标，不同时改超时与服务器，这样才能知道结果变化来自哪里。
超时值过短，可能把正常但建立连接较慢的路径判为失败；过长则会增加等待时间，使批量测试难以辨认问题。默认值以当前应用显示为准，建议先保留已有值，在多次同条件测试都接近等待边界时再考虑调整。延长超时不会修正错误凭据、错误端口或失效证书，也不能使不可达的目标变为可达，因此应先读错误类别。
| 观察结果 | 能够说明 | 仍需验证 |
|---|---|---|
| 地址或端口可达 | 某一层路径能够响应 | 协议、认证与实际目标 |
| Connectivity Test 成功 | 本次测试条件下目标可访问 | 业务请求与规则路径 |
| 测试超时 | 等待范围内未完成测试 | 解析、连接、认证与目标状态 |
让对照测试具有可比性
建议先对当前选中的服务器进行单独测试，再使用相同目标比较其他已有服务器。测试时固定网络、Global Routing 和 Config，避免边测试边刷新订阅。批量测试可能同时产生多条请求，其结果与单条请求的负载条件不同；应把它作为筛查工具，再对异常项做单独复测，不依据一次排序结果频繁更换配置。
首次连接验证还应包括一次真实访问：确认 Home 中选中服务器，打开连接开关，再访问目标并观察 Log。列表测试可能针对某个条目执行，而业务连接使用的是另一个当前选择，两者必须对应起来。更完整的操作顺序见首次连接与 Connectivity Test 验证。若测试成功而页面失败，优先比较目标与规则，不要立即重置测试设置。
记录结果时，保留测试方法、目标、网络类型、选中服务器和错误文字即可，不需要公开完整订阅。短时间内重复测试只能说明这段时间的情况；网络条件变化后应重新验证。把测试用于回答具体问题，例如“此端口能否建立连接”，比笼统追求某个更小的数值更能指导后续操作。
Log 与 Data：按失败阶段读取记录
Log 用于还原连接发生的过程，Data 用于观察流量相关信息；二者都需要放在明确的时间范围内解读。总量增加只能说明有数据经过统计范围，不能证明某个页面加载成功。某条连接记录出现，也不代表完整请求已经完成。排查时应先确定目标与操作时刻，再从记录中寻找对应的解析、策略选择、连接建立及错误阶段。
先缩小记录范围，再复现问题
日志开关、详细程度与保留方式以当前应用显示为准。推荐仅在复现期间使用足够定位问题的记录范围，结束后恢复日常设置。记录越详细，越容易混入后台应用、页面附带资源与重复连接；如果不先缩小目标，更多内容反而会降低判断效率。开始前暂停不相关的测试和订阅更新，记下现有状态，再只执行一次目标操作。
如果界面允许清理记录，先确认是否已经保存需要保留的信息，然后清理本次观察范围。若不清理，也可记录开始位置或操作时间。随后重新建立目标连接，避免浏览器沿用旧连接而没有新的匹配记录。不要在一次复现中同时访问多个不相关页面，否则很难区分页面主请求与其他资源请求，更不能把最靠近末尾的错误自动归给当前目标。
区分解析、连接、认证与业务响应
解析阶段没有获得结果，应回到 DNS 检查；得到地址后建立连接超时，应核对网络、端口与选定路径；出现认证或握手错误，应检查服务器字段是否与已有信息一致。TLS 相关错误还应核对名称、证书条件与设备时间。能够收到目标服务的拒绝或业务响应，往往意味着已经走过前面的若干网络阶段，下一步应针对响应本身分析。
规则排查时，重点不是“记录里出现了这个域名”，而是它命中了什么规则、选择了什么策略、最终尝试连接哪里。一个页面通常涉及多个域名，主域名正常并不能排除其他资源被不同策略处理。应先锁定确实失败的请求，再查看它的命中结果。若日志没有提供足够字段，不要补猜缺失信息，可通过单条规则对照与重复测试验证假设。
| 失败阶段 | 优先核对 | 避免的误判 |
|---|---|---|
| 解析 | DNS 来源与入口可达性 | 直接归因于服务器密码 |
| 建立连接 | 地址、端口、网络与策略 | 仅凭超时判定规则语法错误 |
| 认证或握手 | 协议字段、TLS 名称与时间 | 依靠延长超时修复字段不一致 |
| 业务响应 | 目标服务与实际请求 | 把所有错误页面都视为连接失败 |
流量统计与隐私处理
Data 中的统计范围、累计起点和展示单位，需要按当前界面说明理解。连接期间其他应用也可能产生流量，页面缓存又可能使本次新增很少，因此不能用总量直接计算某个请求的完整大小。需要比较时，先固定观察窗口，只执行一次明确操作，记录前后变化；如果统计被重置或设备重连，应在结论中说明范围已经改变。
日志可能包含目标域名、地址、服务器名称及其他能够反映使用情况的信息。分享前应去除订阅地址、认证字段、个人标识与不相关访问记录，只保留定位问题所需的最小片段。即使链接看起来只是一个普通地址，也可能包含访问凭据；不要把完整导出文件直接放入公开讨论。示例和说明可以用 example.com 替换实际域名，但应保持错误类别与字段结构。
完成排查后，将修改项恢复或保存为明确的新基线，并关闭不再需要的详细记录。若问题仍不能解释，整理“预期行为、实际行为、固定条件、唯一修改、对应错误”五项信息，再继续缩小范围。这样既能避免重复尝试，也能保留足够上下文；单独一句“无法连接”或一张截断的错误画面，通常不足以判断应该修改哪个设置。
Widget、iCloud 同步与已有订阅管理
Widget 提供便捷入口或状态呈现，iCloud 相关选项用于在支持范围内保存或同步应用数据，它们都不等于连接路径设置。桌面显示没有及时变化，不能单独证明系统连接异常；另一台设备上出现配置，也不代表那台设备已经选中相同服务器并采用相同 Global Routing。便利功能需要与实际连接状态分别验证。
Widget 显示与真实连接状态
Widget 的可用形式、展示字段与默认行为，以当前系统和应用显示为准。系统会安排组件刷新，显示内容可能与打开应用后的即时状态不同。遇到状态不一致时，先进入 Shadowrocket 查看连接开关、选中服务器与当前配置，再回到系统连接状态核对。不要因为组件仍显示旧内容就连续执行连接操作，否则可能使原本清晰的状态变得难以追踪。
添加或调整 Widget 后，先测试它提供的是打开应用入口、状态显示还是实际操作，再依据真实行为使用。若相关设置未出现，应先核对设备系统支持情况与应用内说明，而不是寻找同名配置文件字段代替。涉及系统要求时，以 App Store 页面标注为准。组件适合减少查找入口的步骤，不宜作为判断某个域名是否经过代理的证据。
同步范围、冲突与恢复顺序
iCloud 同步的默认开关及覆盖范围以当前应用显示为准。启用前先检查系统账户与应用的 iCloud 权限，并保留一份当前可用配置。同步不是完整备份的同义词，不应推定全部服务器、历史记录、系统授权与连接状态都会一起迁移。应对照应用实际提供的同步项目，分别核对配置文件、服务器列表及相关选项是否到位。
多台设备同时编辑同一份内容时，可能出现先后顺序难以判断的情况。建议先在一台设备完成修改，等待另一台确认收到，再继续编辑。若看到旧内容重新出现，先暂停重复修改，分别保存两边需要保留的信息，比较实际差异后决定保留哪份。不要立即清空一端数据试图“强制同步”，因为同步操作可能继续传播删除或覆盖结果。
| 行为 | 解决的问题 | 不应推定 |
|---|---|---|
| iCloud 同步 | 在支持范围内交换应用数据 | 系统授权与连接状态全部一致 |
| 订阅刷新 | 重新获取用户已有订阅内容 | 另一设备已自动启用同一条目 |
| 手动导入 Config | 增加或更新配置文件 | 导入后已经成为当前启用配置 |
订阅更新不是应用数据同步
Subscribe 保存的用户已有订阅，需要按其更新方式重新获取内容。iCloud 出现了订阅条目，不表示订阅地址当前有效，也不表示返回内容已经刷新。手动更新、打开时自动更新与逐条更新的差异，可查阅订阅更新方式说明。排查期间建议先更新单条，再核对内容变化，避免批量操作掩盖某一条的错误。
更新成功后，应检查条目数量与选择状态是否符合预期，而不是只看完成提示。原先选择的服务器可能已被来源内容替换，名称相近也不代表参数相同。如果列表为空或提示解析失败，先保留现有可用内容，再核对地址完整性、来源状态与返回内容；具体顺序见订阅解析失败或列表为空自查，不要反复删除并重新添加同一地址。
换机恢复时，先完成应用获取与系统授权，再核对同步数据和当前选择，最后测试真实连接。App Store 已购恢复与 iCloud 数据同步属于不同流程，购买记录不会自动证明应用内配置已恢复。相关购买步骤见已购恢复说明。恢复完成后再安排自动更新与 On Demand，可以减少多个后台行为同时发生造成的误判。
Proxy 端口与服务器参数：区分本地和远端
Proxy 相关端口首先要分清所在位置。Add Server 中的端口属于用户已有远端服务器参数，必须与对应服务一致；Settings 中若提供本地代理监听选项，其端口属于设备本地入口。二者用途不同，即使数值相同也不能相互替代。修改前应记录入口名称、地址与使用者，先回答“谁连接到这个端口”，再判断应该调整哪一处。
本地监听的地址、端口与暴露范围
本地 HTTP 或 SOCKS5 入口是否提供、是否启用以及默认端口，以当前应用显示为准，不预设固定数字。仅由当前设备上的程序使用时，应优先限制到所需的最小范围。允许局域网访问会改变可访问者范围，需要同时考虑认证、网络可信程度和实际用途；不要为了排查一个网页故障就开启额外监听，增加不相关的变量。
端口占用与端口错误是不同问题。监听无法启动时，应检查是否有其他功能占用该端口，以及当前选项是否真正生效；远端连接失败则应核对服务器地址、远端端口与网络路径。把远端端口改成本地监听值不会修复服务端配置。系统网络环境变化后，可访问的本地地址也可能变化，因此不能只凭上一网络中的地址继续判断入口状态。
协议字段必须与已有信息对应
Add Server 中先确认协议类型，再检查该协议实际需要的字段。Shadowsocks 的加密方式与密码、VMess 或 VLESS 的身份及传输设置、Trojan 的密码与 TLS 相关字段，各自有不同含义。界面中出现相似名称不代表可以互换。应根据用户已有的服务器信息逐项填写，不通过随机修改协议或复制其他条目的参数来尝试连接。
服务器地址、TLS 使用的名称和特定传输方式中的 Host 可能不是同一字段。地址决定最初连接到哪里，名称相关字段参与相应握手或请求处理，应按既有服务器配置核对。遇到证书错误时，不应把关闭验证作为常规建议；先检查名称是否匹配、设备时间是否正确、配置来源是否完整，再确认服务器证书状态，避免用放宽检查掩盖字段错误。
| 字段位置 | 含义 | 取值来源 |
|---|---|---|
| 本地 Proxy 端口 | 设备上的代理接入位置 | 当前应用与本地使用需求 |
| Add Server 端口 | 远端服务的接入位置 | 用户已有服务器信息 |
| TLS 名称相关字段 | 握手及名称匹配所需信息 | 对应服务器的实际配置 |
| 传输路径与 Host | 特定传输方式使用的请求参数 | 该传输方式对应的既有参数 |
按传输能力定位失败
TCP 请求正常而另一类请求失败时，应检查协议、服务器与网络对相应传输的支持情况。不能因为网页能够打开，就推断所有 UDP 或实时业务都能通过。WireGuard、Hysteria2 等协议也有各自的地址、认证与传输要求，必须按实际字段核对。这里只说明查阅方法，不提供可用于连接的凭据，也不替用户推定服务器已开启某项能力。
订阅导入能够减少手工输入，但仍需要核对解析后的字段是否符合原始信息。编辑订阅生成的条目前，先确认后续刷新是否会覆盖本地修改；需要做测试时，应保留原条目并明确区分测试副本，避免下一次更新后误以为应用没有保存。手动添加的连贯步骤见Add Server 教程，已有订阅的导入见Subscribe 教程。
有效的验证顺序是地址与端口、协议与认证、TLS 与传输字段、实际目标访问。每完成一层检查，都用新连接复测，并查看 Log 中失败阶段是否改变。错误从超时变为认证失败，说明观察范围发生了变化，但尚不能宣布已经解决。只有参数与已有信息一致，且真实请求完成，才适合将该条目作为后续规则排查的基线。
Config 规则与逐项排查闭环
Config 将规则及相关配置组织在一起。导入文件、选中启用文件和让新连接使用该文件，是需要分别确认的步骤。排查前先在 Config 核对实际启用项，再返回 Home 确认 Global Routing 为 Config。若当前采用 Proxy 或 Direct，总体姿态已经改变，不能继续用规则中的预期策略解释所有访问结果；先统一检查条件，再讨论具体规则。
规则从上到下匹配，先命中者生效
规则顺序是结果的一部分。范围较宽的规则放在前面，可能使后面的精确规则没有机会命中。DOMAIN 针对指定域名，DOMAIN-SUFFIX 用于域名后缀及其范围，DOMAIN-KEYWORD 按域名中的关键字匹配；IP-CIDR 与 IP-CIDR6 描述地址段，GEOIP 依据地址归属数据，FINAL 作为未命中前面规则时的后续处理。选择类型时，应先明确要匹配域名还是地址。
| 关键字 | 匹配对象 | 检查重点 |
|---|---|---|
| DOMAIN | 指定域名 | 域名拼写与实际请求是否一致 |
| DOMAIN-SUFFIX | 域名后缀范围 | 范围是否过宽及前置规则 |
| DOMAIN-KEYWORD | 域名中的关键字 | 是否误包含其他目标 |
| IP-CIDR / IP-CIDR6 | 对应地址段 | 地址类型、网段与解析结果 |
| GEOIP | 地址归属分类 | 所用数据与实际地址 |
| FINAL | 前面均未命中的连接 | 是否位于规则末尾及策略是否正确 |
用最小片段验证策略
下面是规则语法示例，不是适合所有环境的完整配置。example.com 为示例域名；PROXY、DIRECT、REJECT 是策略关键字，不是服务器协议。使用时应先复制当前可用 Config，在副本中调整，并保留原文件。不要将片段直接覆盖包含其他必要内容的配置，也不要因示例包含 GEOIP 就把它当作必须采用的分流方案。
[Rule]
DOMAIN-SUFFIX,example.com,PROXY
IP-CIDR,192.168.0.0/16,DIRECT
GEOIP,CN,DIRECT
FINAL,PROXY逐行阅读时，先看匹配类型，再看匹配值，最后看策略。DIRECT 表示直接连接目标，PROXY 表示交给相应代理路径，REJECT 表示拒绝匹配连接。若希望测试某个域名的策略，应将范围明确的测试规则置于可能遮挡它的宽泛规则之前，并通过新连接查看命中结果。测试后恢复原顺序，避免临时规则长期改变其他访问行为。
GEOIP 与地址段规则涉及目标地址；域名规则则依赖请求中的域名信息。不同请求形式与解析阶段可能影响能够用于匹配的信息，所以“同一个网站”不必然在每次访问中留下相同记录。看到地址规则命中时，应结合 DNS 返回值解释；看到关键字规则误匹配时，应收窄到 DOMAIN 或合适后缀，而不是不断追加更多宽泛例外。
把设置修改收束为可验证结论
完整排查从问题描述开始：明确失败目标、当前网络、选中服务器、Global Routing 与启用 Config。随后判断故障是在解析、连接、认证还是规则阶段，只修改该阶段最有依据的一项。重新连接并建立新请求，查看结果是否稳定变化；若没有变化，恢复原值并检查设置是否实际生效，而不是继续叠加第二项、第三项不相关修改。
验证成功后，还要检查一个原本正常的目标和一个本地访问场景，确认修复没有扩大影响范围。将最终保留的设置与原因记入自己的配置说明，删除测试副本中的敏感信息，恢复需要的订阅更新与 On Demand。后续再次出现问题时，优先与这份基线比较，而不是重新从全部 Settings 开始尝试。应用更新与订阅更新也应分开记录其影响。
常见问题可以按本页章节回查：解析异常看 DNS，自动连接异常看 On Demand，测试与访问不一致看 Ping，状态证据看 Log，数据不一致看同步，握手失败看服务器参数，策略不符看规则顺序。购买与恢复问题则查看价格与买断事实及已购恢复，不要用网络配置操作处理商店购买流程。