Shadowrocket
规则与配置参考

Config、Proxy、Direct 的职责

查阅规则之前先检查 Home 中的 Global Routing。配置姿态对应 Config，表示按当前配置的分流逻辑处理；代理姿态对应 Proxy，主要用于把请求交给代理方向；直连姿态对应 Direct，主要用于直接访问。后两种姿态不能当作验证 Rule 顺序的替代环境。某个域名在 Proxy 下可以访问，只能说明该测试路径的代理连接有机会工作，不能由此证明 DOMAIN-SUFFIX 写法正确。

本页的规则推演以 Global Routing 为 Config、目标配置已启用且连接已重新建立为基础。若界面中还有 Scene，应先确认当前场景实际采用的配置和策略，不要把场景名称本身当作一条规则。不同设备上的界面组织可能有差异，核对时以当前界面显示的选择结果为准，重点是明确“请求最终使用哪套处理逻辑”，而不是只记住一个按钮的位置。

General 不是第二份 Rule

General 中的选项影响更基础的处理环境，例如使用哪个 DNS 来源、是否处理某些地址族，以及哪些目标被排除在特定处理范围之外。它们并不等价于 Rule 中的逐条条件。假如某类请求已经被更早的网络范围设置排除，继续在 Rule 尾部添加针对它的规则可能不会产生预期结果。排错时应同时查看 General，但不应一次改动所有通用参数。

例如 dns-server = system 表示使用系统 DNS 来源；它不表示所有请求都会直连，也不表示 DNS 一定能解析你要访问的域名。代理方向由策略决定，名称解析则为后续连接提供地址，两者需要分别检查。若原配置带有其他 DNS 选项，应先理解它们之间的关系，不要为了让示例看起来一致就整段替换已有设置。

[General]
dns-server = system

[Rule]
DOMAIN,api.example.com,PROXY
FINAL,DIRECT

在这段示例中，只有完整域名 api.example.com 被显式交给 PROXY。Config 下可以据此检查首条条件；切换到其他姿态后，观察到的连接方向不再足以证明这两行的顺序。做对照实验时，先记录模式，再发起相同请求，最后恢复原来的 Config。否则一次临时切换就可能让后续所有规则测试失去共同前提。

连接状态与旧会话

配置保存后，已经建立的长连接可能继续沿原来的路径运行。浏览器连接复用、应用后台会话与名称解析缓存都会影响观察。测试应尽量关闭目标应用的旧会话，按需要断开并重新连接，再发起一个新的请求。不要因为一个仍然播放的媒体连接没有改变方向，就认定新规则没有生效；也不要把页面来自本地缓存的显示当作成功联网。

Connectivity Test 可帮助判断某个服务器的基本连接表现，但它与具体业务请求不是同一个测试对象。服务器测试通过后，目标域名仍可能解析失败，服务端也可能拒绝当前请求。相反，业务页面加载了一部分，也不代表所有相关子域名都采用了同一策略。完整的规则验证应围绕具体请求和匹配结果进行，而不是只依赖一个测试图标。

IP-CIDR：按网络前缀匹配

IP-CIDR 使用地址和前缀长度描述 IPv4 地址范围。192.168.0.0/16 表示一个以十六位网络前缀划分的地址段，并不是只匹配字符串以 192.168 开头的某个页面 URL。前缀长度越大，范围通常越小；单个 IPv4 地址可用 /32 表达。编辑前先确认目标是整个网段还是单台主机，不要把子网掩码、端口号和 CIDR 前缀混在同一参数中。

局域网服务通常需要直接到达本地地址，但应结合自己的实际网络设置例外。把一个私有地址段交给 DIRECT，并不保证跨网段路由已经存在，也不会自动绕过设备或路由器的访问控制。如果设备连到不同 Wi-Fi 后地址范围发生变化，之前的本地例外可能不再对应同一服务。公司网络、访客网络和家庭网络还可能使用重叠地址，应按当前环境验证。

[Rule]
IP-CIDR,192.168.0.0/16,DIRECT
IP-CIDR,10.0.0.0/8,DIRECT
IP-CIDR,172.16.0.0/12,DIRECT
FINAL,PROXY

no-resolve：减少为规则匹配发起的解析

IP 类规则可以使用 no-resolve 参数，表达不为匹配这条规则额外触发域名解析的意图。它适用于已经知道目标地址、或希望避免仅为检查某个地址段而解析名称的情形。不要把它理解为“整个连接都不需要 DNS”，更不能由此断言后续代理端、应用或其他规则不会解析。请求是否已有地址，以及后面还有哪些条件，都会影响实际行为。

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

这里把明确的域名策略放在前面，把本地地址例外放在后面。若请求只有域名，带 no-resolve 的地址规则不应被当作必然能通过该域名识别私有地址的保证；若请求已经携带目标 IP，则可以根据地址继续判断。配置维护者需要选择自己真正需要的行为：是否愿意为地址分类获得解析结果，还是优先保留域名路径，不能机械地给所有 IP 规则追加同一参数。

IP-CIDR6：单独处理 IPv6 范围

IPv6 不会自动被 IPv4 网段覆盖。若环境中使用 IPv6，必须把相应地址族纳入测试。IP-CIDR6 的匹配值同样使用 CIDR 形式，但地址采用 IPv6 表示法。下面的 2001:db8::/32 是文档示例地址段，适合说明格式，不应作为真实业务网段直接投入使用。实际规则应来自你确认拥有或需要处理的目标地址范围。

[Rule]
IP-CIDR6,2001:db8::/32,DIRECT,no-resolve
FINAL,PROXY

域名同时返回 IPv4 和 IPv6 地址时，应用可能优先尝试其中一种，也可能并行尝试。于是只看一次成功或失败，很难知道是哪条地址规则参与了处理。应分别记录所用地址族和目标 IP，再检查规则覆盖。如果 IPv6 路径存在问题，应先确认网络连通性及配置支持，不要把随意关闭某个地址族当作所有问题的统一答案。

GEOIP：地址归类，不是内容归类

GEOIP,CN,DIRECT 按目标 IP 的地理归属数据进行判断。它不依据网页语言、网站经营者或设备所在位置，也不保证每个地址的归类都与用户预期相同。内容分发网络、共享地址和服务迁移会使同一域名在不同网络获得不同地址；因此某次命中 GEOIP 的结果不宜无限推广到该网站的所有请求。

若业务需要稳定的域名策略，应优先写清域名例外，再使用 GEOIP 作为较宽的地址分类条件。排查归类差异时，记录当时解析到的 IP、测试网络和命中行，避免只说“这个网站应该属于某地”。还应确认当前使用的地理数据是否适合你的用途；任何归类都不能替代对具体目的地址和网络可达性的验证。

DNS 结果与分流结果是两项观察

DNS 把域名转换为连接需要的地址；Rule 决定匹配请求采用的处理策略。二者会相互影响，但并非同一项设置。一个域名可以解析成功却无法连接，也可能在某条路径上需要由不同位置完成名称解析。分析问题时，至少记录域名、获得的地址、命中规则和最终策略四项信息。仅看到“域名有 IP”不能证明分流正确，仅看到 PROXY 也不能证明目标地址可达。

General 中的 DNS 来源会影响解析环境。使用系统来源时，结果可能随着 Wi-Fi、蜂窝网络和系统网络设置变化；指定其他来源时，也要检查该来源在当前网络是否可达，以及配置是否另有解析行为选项。不要为了追求某个测试结果，未经记录就同时替换 DNS、服务器和规则顺序。这样即使恢复访问，也无法判断真正起作用的是哪一项变化。

Host 只建立显式的名称到地址关系

Host 适合为自己管理的实验服务、固定内部设备或临时迁移测试指定地址。写法通常是域名、等号和地址；它不应该填写页面路径，也不负责存储协议密码。下面的配置把 lab.example.com 指向一个私有地址，并为该域名设置 DIRECT。两部分各自表达一个决定：Host 负责地址映射，Rule 负责处理方向。

[General]
dns-server = system

[Rule]
DOMAIN,lab.example.com,DIRECT
FINAL,PROXY

[Host]
lab.example.com = 192.168.10.20

该地址只在你的网络确实存在相应设备和服务时才有意义。保存映射不会创建服务器，也不会让设备获得访问另一局域网的路由。如果目标服务使用 HTTPS，还必须让证书与访问域名相符；把域名映射到一个能建立 TCP 连接的地址，并不等于 TLS 验证会成功。出现证书错误时应检查域名、证书和服务配置，不要把关闭验证当成 Host 的常规配套步骤。

为什么不应长期固定公共服务的地址

公共服务常通过 DNS 调度到不同区域、不同负载或不同地址族。手工固定某个地址会绕过这一调度过程，短期成功的地址以后可能迁移、停止服务，或不再适合当前网络。共享服务还可能依赖请求中的域名来选择站点。因此 Host 更适合有明确原因、可验证且可撤销的映射，而不是把一次排错获得的 IP 永久写入所有设备。

如果确需临时映射，应记录原始域名、原解析结果、替换地址和恢复方式。完成测试后删除映射，再检查普通解析是否恢复。一个过时的 Host 条目可能让后续所有 DNS 调整看似无效，因为该名称仍被显式指向旧地址。检查这类问题时，应先搜索完整域名是否出现在 Host，而不是只在 General 中更换解析来源。

缓存与地址族造成的观察差异

解析缓存可能存在于系统、应用、浏览器及连接处理流程的不同位置。保存配置后立即刷新页面，有时仍使用之前获得的地址或已有连接。比较映射前后的结果，应建立新的请求会话，必要时重新连接，并观察实际目标地址。不要仅以页面是否再次显示判断缓存是否清空，页面本身也可能来自本地数据。

另一个常见差异是 IPv4 与 IPv6 并存。只映射一个 IPv4 地址、只测试一个地址族，可能不能解释应用的全部连接行为。应结合应用实际访问记录确认它最终选择的地址，再检查 IP-CIDR 与 IP-CIDR6 是否覆盖对应范围。对于直接访问 IP 的请求，Host 域名映射通常不是排错入口，因为此时并没有相应名称需要转换。

建立最小且可回退的验证流程

先复制当前可用配置，选择一个你有权测试的目标域名，写下期望策略，再插入一条完整域名规则。确认它位于相关宽泛条件与 FINAL 前面，保存并启用该副本，把 Global Routing 设为 Config。随后建立新连接，观察目标域名、目的地址、命中条件及采用策略。只有这些观察与预期一致，才逐步扩大规则范围或合并到日常配置。

不要直接用一份很长的新配置替换工作环境，再从大量异常中反推原因。对于远程配置，保留原始来源和本地差异；对于会更新的订阅，区分服务器数据变化和规则文件变化。若更新后异常，先确认到底更新了哪个对象。服务器地址或认证信息改变，与 DOMAIN 拼写错误属于不同问题，不能通过同一项规则调整解决。

1. 记录当前网络、Config 名称、Global Routing 与测试目标，保存原始副本。
2. 只修改一项规则或一个参数，检查所属段及前后覆盖关系。
3. 保存并确认当前启用的确实是修改后的文件，重新建立测试会话。
4. 对照日志中的域名、地址、规则和策略；必要时用 Direct、Proxy 建立比较基线。
5. 恢复 Config，记录结果；未达到预期时撤销该次改动，再检查下一项。

根据现象缩小范围

如果完全没有看到预期规则的命中记录，先查模式、配置选择和请求是否真正在当前会话中发出，再查域名是否写成 URL、是否存在前面的宽泛条件、是否直接连接 IP。如果已经命中 PROXY 但访问失败，应转向所选服务器、协议参数、DNS 和目标服务，而不是继续增加相同域名规则。命中正确与连接成功必须作为两项结果分别记录。

协议排错还应与规则排错分工。例如 Trojan 的地址、端口、密码和 SNI 属于连接参数，可参阅Trojan 参数填写要点；Hysteria2 与网络 UDP 条件的关系可参阅Hysteria2 与 QUIC 说明。协议参数有误时，分流规则即使命中也不能替它补齐认证信息。

分享诊断信息前清理敏感内容

能够解释问题的最小记录通常包含规则片段、所用姿态、目标域名和失败阶段，不需要整份订阅。分享前移除订阅链接中的令牌、服务器密码、身份标识和私人网络信息；截图也要检查地址栏、二维码与通知区域。用 example.com 等教学域名替代时，应说明哪些内容经过替换，但保留规则顺序和语法结构，否则他人无法判断覆盖关系。

维护规则应以实际用途为单位。删除不再使用的 Host、整理重复域名、确认 FINAL 仍在末尾，并为关键业务保留几个测试输入。网络切换后重新检查局域网地址与地址族，不要把家庭 Wi-Fi 的一次验证视为所有场景的保证。规则越多并不意味着范围越准确；能说明每条例外的目的、输入与恢复方式，才便于长期维护。

客户端获取与使用前提

Shadowrocket 是闭源商业应用。iPhone / iPad 版在 App Store $2.99 一次性付费，Mac（Apple 芯片与 Intel）、Windows、安卓、Linux 版免费；客户端一次性买断 ≠ 线路套餐。本站不提供、不销售、不推荐节点或订阅，本手册只解释如何使用用户已有的信息。iPhone / iPad 系统要求以 App Store 页面标注为准，设备获取与系统放行说明统一见全平台下载页，其他平台安装包通过本站 /dl/ 获取。

需要从连接权限和 Home 页面重新核对时，可回到快速上手主线；有关获取、已购恢复与安装的常见问题，见下载常见问题。处理规则问题时始终先保存当前状态，按可复现的最小改动测试；若测试不能解释结果，就撤销改动继续缩小范围，而不是把临时修补长期留在配置中。