Shadowrocket规则不生效？3类原因按命中、顺序和DNS排查

更新于 2026-11-12 · nianyun.store

简答：规则明明加了却走错线路，先打开Home确认Global Routing为Config，并核对正在编辑的文件就是当前启用的Config。然后查看请求记录：未命中查规则位置、类型和顺序；已命中但打不开，则转查策略、节点、DNS或目标连接。

定义：Shadowrocket规则是否生效，指当前请求是否按照正在使用的配置命中预期匹配条件并执行对应策略，而不是只看规则文字是否已经添加。

先看三行速查卡：10秒判断问题在哪一层

规则明明加了，访问却仍然走错线路时，先不要重复导入规则或更换节点。Shadowrocket 在 App Store 的产品说明中明确列出域名、域名后缀、关键词、CIDR IP 范围和 GeoIP 等规则能力，同时支持记录HTTP、HTTPS和DNS请求；因此排查重点应放在“当前配置是否启用、请求是否命中、命中后连接是否成功”三个层面。可参考App Store中的Shadowrocket产品说明。

看到的现象	先查什么	初步判断
未命中预期规则	`Home → Global Routing`、当前Config、规则顺序	请求可能没有经过目标配置，或被前面的规则提前匹配
规则已命中但策略不可用	命中策略、策略组、当前选中服务器	规则本身可能已经生效，问题在策略或服务器连接
命中且策略正常但网页仍失败	DNS、IPv4/IPv6、旧连接和目标服务	应转查解析、地址族、节点或目标连接

打开 Shadowrocket 的 Home 页面，记录当前连接开关、选中服务器和 Global Routing。
进入 Global Routing，选择 Config 进行规则测试；Proxy 和 Direct 只能作为对照模式。
进入底部 Config 页面，确认正在编辑的文件就是当前启用的配置，不要只确认文件存在于列表中。
重新打开目标应用或新建一次请求，再查看数据、请求记录或诊断页面。不同版本入口名称可能不同，以当前设备显示为准。

iOS 的网络扩展由系统网络能力承载，Apple 文档说明网络扩展可以创建VPN配置、代理流量或提供设备级DNS能力；首次启用相关网络配置时也可能需要用户授权。若连接开关无法建立或系统未出现授权提示，应先检查系统VPN配置权限，而不是先改规则。可参考Apple Network Extension文档。

固定排查路径：Home → Config → Global Routing → 请求记录

Shadowrocket的Config页面和Home → Global Routing不是同一个检查点。前者用于查看或编辑配置文件，后者决定当前流量使用Config、Proxy还是Direct。你编辑了正确文件，但如果Global Routing仍是Proxy或Direct，测试结果就不能用来判断规则是否生效。

Home：确认连接开关已开启，记录当前选中的服务器。
Global Routing：选择Config，不要把Proxy模式下的结果当成规则命中结果。
Config：打开当前配置，确认规则位于[Rule]区段，并检查文件是否刚被远程更新覆盖。
请求记录或数据页面：发起一个新的目标请求，查看目标域名、命中规则、最终策略和连接结果。App Store产品说明确认该应用具备请求记录能力，但不同版本的入口名称可能存在差异。
复测：同一设备、同一网络、同一目标、同一服务器，只修改一项设置，然后重新发起请求。

如果请求记录中没有目标域名，不要立即判断规则语法错误：目标应用可能访问了跳转域名、接口域名、CDN域名，或者当前流量没有进入Shadowrocket的网络扩展。先记录实际请求，再决定使用精确域名规则还是后缀规则。

规则区段和匹配类型：先确认写法与目标一致

常见配置会在[Rule]区段中按“匹配类型、匹配值、策略”组织规则。下面的域名仅用于语法演示，不能用来判断任何真实服务是否可用。

[Rule] DOMAIN,api.example.com,PROXY DOMAIN-SUFFIX,example.com,DIRECT IP-CIDR,192.0.2.0/24,DIRECT,no-resolve IP-CIDR6,2001:db8::/32,DIRECT,no-resolve GEOIP,CN,DIRECT FINAL,PROXY

规则类型	匹配对象	适合检查什么	常见误区
`DOMAIN`	精确域名	只处理指定完整域名	不会自动覆盖所有子域名
`DOMAIN-SUFFIX`	域名及其子域名	覆盖主域和子域	不等于任意关键词匹配
`DOMAIN-KEYWORD`	域名中包含指定字符串	按关键词匹配一组域名	范围可能过宽，误匹配其他域名
`RULE-SET`	远程或本地规则集整体	批量维护规则	范围较大，可能提前拦截后面的精确规则
`IP-CIDR`	IPv4地址范围	已知目标IPv4网段	不能直接匹配域名文字
`IP-CIDR6`	IPv6地址范围	已知目标IPv6网段	IPv4规则不会自动覆盖IPv6
`GEOIP`	目标IP的地理数据库分类	按IP归属分类处理	不等于网页语言、域名后缀或公司所在地
`FINAL`	前面没有命中的请求	设置兜底策略	放在前面会阻止后续规则参与判断

IP-CIDR和IP-CIDR6分别对应IPv4与IPv6。对域名请求而言，IP规则是否能够匹配还取决于请求是否已有目标地址、DNS解析方式以及是否使用no-resolve。no-resolve的含义是不要仅为了检查该IP规则而主动触发一次域名解析，它不是关闭DNS，也不能保证所有域名请求都能匹配该IP规则。具体行为以当前版本实际界面和配置解析结果为准。

可复制的最小测试方案：只保留一条目标规则

如果复杂规则集无法判断，先备份当前Config，再建立一个最小测试版本。把example.com替换成请求记录中实际出现的域名，把PROXY替换成当前配置中确实存在的策略名称。

[Rule] DOMAIN-SUFFIX,example.com,PROXY FINAL,DIRECT

进入 Config，备份原配置，不要直接覆盖唯一副本。
在[Rule]区段只保留一条目标域名规则和一条末尾FINAL。
确认PROXY是当前配置中已定义的策略；如果实际策略名称不同，使用实际名称。
返回 Home → Global Routing，选择Config。
固定一个服务器，关闭并重新打开目标应用，访问同一个目标域名。
在请求记录或数据页面查看：目标域名是否出现、命中哪条规则、最终策略是什么、连接是否建立。

结果判断：如果最小配置能命中，原问题通常在规则顺序、规则集、当前文件或远程更新覆盖；如果仍未命中，优先核对Global Routing、当前Config和实际请求域名；如果已命中但连接失败，则转查策略、节点、DNS或目标服务。

规则顺序冲突：具体规则要放在宽泛规则前

常见做法是按从上到下检查规则，前面已经匹配后，后面的规则通常不会再改变这次请求的策略。因此，精确域名例外应放在宽泛后缀、规则集、GEOIP或其他范围较大的条件前，FINAL作为最后的兜底。

典型冲突

假如规则顺序如下：

DOMAIN-SUFFIX,example.com,DIRECT DOMAIN,api.example.com,PROXY FINAL,DIRECT

访问api.example.com时，前面的后缀规则可能已经先匹配，后面的精确域名规则就不会按预期发挥作用。处理时应把精确例外放到前面：

DOMAIN,api.example.com,PROXY DOMAIN-SUFFIX,example.com,DIRECT FINAL,DIRECT

在当前启用Config中搜索目标域名。
从上到下检查目标规则之前的DOMAIN-SUFFIX、RULE-SET、GEOIP和其他宽泛规则。
确认FINAL位于规则列表末尾附近。
保存后重新发起请求，并以请求记录中的实际命中结果为准。

如果远程订阅更新后手动规则消失，先检查当前文件是否由远程地址提供。更新可能重新写入配置内容，使本地追加内容不再保留；可先备份，再选择维护远程源、使用独立本地Config，或在更新后重新合并。具体覆盖行为需结合当前配置来源核实。

按症状拆分处理：未命中、策略失败、节点或DNS失败

现象一：全部请求像直连

检查：打开Home → Global Routing，确认不是Direct，并确认当前Config已经启用。

判断：切换为Config后仍无规则记录，优先查当前文件、[Rule]区段和系统网络配置；只有一个域名异常时，转查域名和顺序。

处理：使用同一目标切换到Proxy做对照。Proxy能访问而Config不能，问题更接近规则或策略选择。

回滚：测试结束后恢复原来的Global Routing模式。

现象二：全部请求都走代理

检查：确认是否误选Proxy，并检查Config中的FINAL是否指向代理策略。

判断：Proxy模式本来就是整体代理，不能据此证明每条规则都已命中。

处理：切换回Config，把精确直连规则放在宽泛规则前，并将FINAL放在后面。

回滚：保留原配置副本，确认新顺序后再保存正式版本。

现象三：只有一个域名异常

检查：查看请求记录中的实际主域、子域和跳转域名。精确域名使用DOMAIN，主域及子域名范围使用DOMAIN-SUFFIX。

判断：没有命中记录，说明可能访问了另一个域名、当前未使用该Config，或规则被前项拦截；已经命中则转查策略和连接。

处理：使用最小配置只测试一个目标域名和一个明确策略。

回滚：测试结束后恢复原规则，避免临时规则影响其他请求。

现象四：规则已命中但网页仍打不开

检查：记录命中策略、选中服务器、连接状态和目标地址，再用同一服务器切换到Proxy模式测试。

判断：Proxy也失败，问题更可能在节点参数、服务器连接、DNS或目标服务；Proxy成功而Config失败，则重新检查规则指向的策略组。

处理：固定服务器，只逐项测试DNS、IPv4/IPv6和目标连接，不要同时换节点、改规则和改DNS。

回滚：恢复原服务器和Config，保留测试前后的请求记录用于对比。

DNS、IPv6、旧连接与请求记录：最后一轮复测

DNS问题不能替代规则顺序问题。尤其是使用IP-CIDR、IP-CIDR6或GEOIP时，必须确认请求实际使用的地址族和目标地址。IPv4规则不会自动覆盖IPv6；使用no-resolve时，如果请求只有主机名且没有可供比较的目标地址，IP规则可能无法按预期命中。

固定变量：同一设备、同一网络、同一目标域名、同一服务器。
记录模式：记下Global Routing、当前Config、命中规则和最终策略。
先测Proxy：确认选中服务器能否连接，再回到Config测试规则。
重新建连：关闭并重新打开目标应用或重新加载页面，避免旧连接继续沿用原路径。
查看请求：在数据、请求记录或诊断页面确认实际域名、目标地址和命中结果，入口名称以当前版本为准。
一次只改一项：按“配置启用 → 规则位置 → 匹配类型 → 策略组 → DNS → 节点”的顺序逐项修改。

如果最小规则能够命中而复杂配置不能，优先回到规则冲突、规则集和远程更新覆盖；如果Proxy模式也无法建立连接，就不要继续把问题归因于分流规则。

什么时候该停止改规则并转查节点或服务端

出现以下情况时，应停止重复修改规则：Proxy模式使用同一服务器也失败；请求记录已经显示命中正确策略但连接仍超时；多个不同目标在同一服务器上同时失败；或订阅、服务器参数、配置来源刚发生变化。

联系服务提供方前，可准备设备系统版本、Shadowrocket界面显示的模式、当前Config名称、目标域名、命中规则、策略名称、连接时间和诊断记录。不要公开完整订阅链接、服务器密码或含个人信息的配置文件。

本文为第三方使用指南，不是Shadowrocket官方页面。不同版本、系统和配置来源的菜单名称可能变化，操作入口以设备实际显示为准。

常见问题

Shadowrocket里已经添加规则，为什么访问仍然走错线路？

先打开Home中的Global Routing，确认选择的是Config；再进入Config确认编辑的文件就是当前启用文件。随后查看请求记录，检查实际访问域名、规则顺序以及前面是否存在更宽泛的DOMAIN-SUFFIX、RULE-SET、GEOIP或FINAL。

DOMAIN和DOMAIN-SUFFIX应该怎么选？

DOMAIN用于精确域名，DOMAIN-SUFFIX用于主域及其子域名。如果不确定目标应用实际访问哪些域名，先查看请求记录，不要直接改成范围更大的DOMAIN-KEYWORD。

IP-CIDR和IP-CIDR6有什么区别？

IP-CIDR匹配IPv4地址范围，IP-CIDR6匹配IPv6地址范围。双栈网络中同一域名可能分别使用IPv4或IPv6，因此只写IPv4规则不代表IPv6请求也会命中。

no-resolve是不是关闭DNS？

不是。no-resolve表示不要仅为了检查该IP规则而主动触发额外域名解析，不等于关闭DNS，也不保证只有主机名的请求一定能匹配IP-CIDR或IP-CIDR6。

规则已经命中，但网页还是打不开，是规则问题吗？

不一定。命中只说明客户端选择了对应策略，之后仍可能因为策略组没有可用服务器、节点参数错误、DNS解析失败、IPv4或IPv6路径异常，或目标服务不可达而失败。可用同一服务器切换到Proxy模式做对照。

为什么远程订阅更新后，手动添加的规则消失了？

如果当前Config来自远程地址，更新时可能重新写入配置内容，本地追加规则因此不再保留。先备份当前文件，再核对配置来源；可选择维护远程源、使用独立本地Config，或更新后重新合并。

FINAL应该放在哪里？

FINAL通常作为前面规则都没有命中时的兜底规则，应放在规则列表末尾附近。若FINAL位于具体规则前面，后面的规则可能无法参与判断。