当Shadowrocket添加去广告规则后App内广告依然出现时，首先开启应用连接日志功能，在广告加载过程中捕获App发起的网络请求，从日志中识别出疑似广告的域名（通常包含ad、ads、doubleclick、googlesyndication等特征关键词），然后进入当前激活的配置文件的规则列表，手动添加这些域名规则并将策略设为REJECT，保存配置并重新加载后再次测试广告是否消失。如果日志中无法捕获广告请求，可能源于App使用了IP直连方式绕过域名规则，此时应检查设备的DNS设置是否开启广告过滤功能，或在配置文件中添加DNS规则将疑似广告域名解析至无效IP地址。对于已缓存广告素材的App，添加规则后需要在iOS的iPhone存储空间中卸载并重新安装该App以清除本地缓存，然后重新打开验证去广告效果。同时检查配置文件中的规则顺序，确保所有REJECT去广告规则位于GEOIP、CN等直连规则之前，避免广告域名在匹配到拒绝规则前被直连规则提前命中。当以上操作均尝试后广告仍未消失，则确认该App的广告使用了与正常内容相同的域名且无法通过域名规则区分，此时可考虑在Shadowrocket中启用MitM解密功能并结合URL-REGEX规则拦截广告路径，但需注意MitM可能触发部分应用的SSL Pinning保护机制导致App网络异常。去广告是一个需要持续维护的过程，用户需定期更新社区规则集并针对自己常用App手动补充遗漏的广告域名，逐步完善规则库。如果去广告需求强烈且手动维护成本过高，可考虑更换为AdGuard等专业去广告工具，或在系统层面使用支持广告过滤的DNS服务，与Shadowrocket配合实现多层防护。
规则本身未覆盖该App的广告域名
去广告规则集的覆盖范围存在局限性
社区维护的去广告规则集（如adblock.list、neoHosts等）虽然涵盖了数万个已知的广告和追踪域名，但不可能穷举互联网上所有App使用的广告服务器。每个App可能对接不同的广告联盟或使用自定义的广告分发域名，规则集维护者未能收录的广告域名自然不会被屏蔽。当用户在Shadowrocket中添加了通用去广告规则后，如果某个App内的广告依然出现，首先应怀疑是该App使用的广告域名未被当前规则集覆盖，而非规则配置错误。
通过连接日志捕获遗漏的广告域名
用户打开Shadowrocket的连接日志功能，然后打开仍有广告的App并触发广告加载，在日志中观察该App产生的所有网络连接请求。广告请求通常会指向包含ad、ads、doubleclick、googlead、googlesyndication等关键词的域名，或指向某些非常规端口。用户从日志中识别出疑似广告域名的条目后，可手动将该域名添加至配置文件的规则列表中，指定策略为REJECT或REJECT-DROP。添加完成后重新加载配置并再次打开App测试广告是否消失，这是针对特定App广告最精准的补全方式。
使用“抓包”工具辅助发现隐藏的广告请求
对于Shadowrocket日志无法捕获到的加密或非标准端口广告请求，用户可借助MitM（中间人）解密功能或第三方抓包工具（如Surge、Charles）来分析App的完整网络行为。这类工具能够解密HTTPS流量并展示请求的完整URL路径，从而发现隐藏在加密请求中的广告服务器地址。识别出这些域名后，同样将其添加至Shadowrocket的拒绝规则中即可生效。需要注意的是，使用MitM功能需在设备安装并信任对应证书，操作有一定复杂度，适合进阶用户。
规则匹配顺序不当导致去广告规则未生效
去广告规则被前置的直连规则覆盖
Shadowrocket的规则引擎按列表顺序逐条匹配，一旦某个规则命中，后续规则不再执行。如果用户在配置文件中将国内直连规则（如GEOIP,CN,DIRECT）或泛域名直连规则放置在去广告规则之前，而App的广告域名恰好属于国内IP段或匹配了泛直连规则，则广告请求会优先被直连规则命中并直接发出，完全跳过后续的去广告拒绝规则。用户应检查配置文件中的规则顺序，确保所有REJECT规则（包括去广告规则集引用）位于DIRECT规则之前，或至少位于可能覆盖该广告域名的直连规则之前。
去广告规则集引用位置过晚导致失效
当用户通过RULE-SET引用外部去广告规则集时，该引用在配置规则列表中占据特定位置。如果该引用位于多个泛匹配规则之后，或者位于FINAL兜底规则之后，则规则集中的所有规则都不会被评估，广告流量可能直接落入其他规则的处理范围。用户应在配置编辑界面中调整规则集的排列顺序，将去广告规则集尽量上移，放置在GEOIP,CN,DIRECT等大规模匹配规则之前，确保广告域名在被直连规则覆盖之前就能命中拒绝规则。
特定App使用IP直连方式绕过域名规则
部分App为了绕过域名级别的广告拦截，会直接通过IP地址请求广告内容，而非通过域名。去广告规则集中的DOMAIN-SUFFIX和DOMAIN-KEYWORD规则对IP直连请求无效，因为IP请求不包含域名信息，无法匹配任何基于域名的规则。用户可尝试在规则中添加IP-CIDR规则，将广告服务器的IP段直接标记为REJECT，但IP段信息较难获取且变化频繁。更多时候，用户需结合GEOIP规则或配置更严格的DNS解析来间接处理IP直连广告。
DNS解析环节未被纳入拦截链
去广告规则仅作用于HTTP/HTTPS层面的请求
Shadowrocket的域名规则拦截发生在连接建立阶段，主要针对应用发起的域名解析和HTTP/HTTPS请求。但部分App内置了DNS解析逻辑或使用了HTTPDNS服务，直接通过IP地址连接广告服务器，完全绕过了域名匹配规则。这种情况下，即使规则集中包含了广告域名，App也不会向Shadowrocket发出包含域名的请求，规则自然无法命中。用户需检查设备的DNS设置，将DNS服务器切换至支持广告域名过滤的公共DNS（如AdGuard DNS），在解析层面即阻断广告域名的IP返回。
配置DNS规则将广告域名解析至无效地址
在Shadowrocket的配置文件中，用户可以添加DNS级别的规则，将特定广告域名指向无效的IP地址（如0.0.0.0或127.0.0.1）。当App尝试解析该域名时，DNS服务器返回无效IP，连接随即失败，广告无法加载。这种方式的优势在于即使App采用非标准端口或加密协议请求广告，只要其依赖域名解析，DNS规则即可生效。用户可将日志中捕获的广告域名批量加入配置文件的DNS规则区域，策略设为REJECT或指向黑洞IP。
开启Shadowrocket的“DNS over HTTPS”防止广告域名被篡改
部分运营商或恶意软件可能篡改DNS响应，将广告域名解析至正常IP以使广告穿透拦截。用户可在Shadowrocket的设置中开启“DNS over HTTPS”或“DNS over TLS”，并指定支持广告过滤的DNS服务器（如https://dns.adguard.com/dns-query），确保每个DNS查询都经过加密且返回的解析结果经过过滤，从源头切断广告域名的可达性。这种加密DNS方式还能规避运营商对特定域名的DNS污染，确保去广告规则在实际解析环节得到执行。
App端缓存和预加载机制导致广告残留
App已将广告内容预缓存至本地存储
许多App在加载广告时会提前预取多个广告内容并缓存在设备本地，当用户随后添加去广告规则时，这些已缓存的广告素材可能仍然在有效期内，App会优先展示缓存内容而非重新发起网络请求。用户可在添加去广告规则后，进入iOS的“设置→通用→iPhone存储空间”，找到该App并执行“卸载App”（保留文稿数据）或“删除App”（清除所有数据），重新安装后App的广告缓存被清空，新的网络请求才会被去广告规则拦截。注意卸载App可能导致部分登录状态和数据丢失，需提前备份。
清除App内广告标识符（IDFA）减少定向广告
部分App使用的广告基于设备广告标识符（IDFA）进行定向投放，即使网络请求被拦截，App仍可能基于本地缓存的IDFA和用户画像展示之前预加载的广告内容。用户可在“设置→隐私→跟踪”中关闭“允许App请求跟踪”，并前往“设置→隐私→分析与改进”中重置广告标识符。这一操作虽然不直接拦截广告请求，但能减少App基于用户画像加载针对性广告的动机，部分依赖定向广告的App在无法获取IDFA后可能自动减少广告展示频率。
App重启或设备重启后验证效果
添加去广告规则并清除缓存后，用户应强制关闭App（从后台多任务卡片中上滑退出），然后重新打开App测试广告是否消失。如果重启App后广告仍然存在，可尝试重启整个设备，因为部分App的广告服务在系统启动时即与广告服务器建立了长连接，设备重启会重置所有网络连接状态，使新的去广告规则得以完整生效。
广告使用HTTPS且规则未启用MitM解密
广告域名规则拦截不依赖解密即可生效
需要明确的是，Shadowrocket的域名规则拦截发生在TLS握手之前，即使广告请求使用HTTPS加密，只要App在连接阶段发送了域名（通过SNI字段），规则引擎即可根据域名信息命中REJECT规则，无需解密流量内容。因此，用户无需开启MitM功能即可拦截大部分HTTPS广告域名。如果广告请求使用了加密DNS或IP直连方式绕过了域名暴露，才需要考虑更深层次的拦截手段。
MitM解密可识别URL路径级别的广告请求
部分App的广告请求与正常内容请求共用同一域名，仅通过URL路径（如/api/ad/）来区分。这种情况下，基于域名的REJECT规则无法精准拦截，因为拒绝整个域名会导致正常内容也无法加载。用户可在Shadowrocket中启用MitM解密功能，在配置文件中添加更精细的URL-REGEX规则，匹配包含/ad/、/ads/、/banner/等广告路径的请求并单独拒绝，而允许同一域名下的其他路径通过。MitM功能的启用需要安装和信任证书，且在iOS 14及以上系统需要额外开启“解密HTTPS流量”的权限，操作门槛较高。
MitM可能引发应用证书锁定（SSL Pinning）问题
部分安全级别较高的App（如银行、支付类App）以及一些主流社交App会启用SSL Pinning机制，禁止任何中间人解密其HTTPS流量。当用户启用MitM功能并尝试解密这些App的通信时，App会因证书不匹配而拒绝连接，表现为网络异常或加载失败。因此，用户在使用MitM拦截广告时需注意区分App类型，对于启用了SSL Pinning的App，即使广告未被屏蔽，也不应强制启用MitM，以免影响App正常使用。
规则集格式错误或未正确加载
检查规则集是否在配置列表中被激活
用户在添加去广告规则集后，需要确认该规则集已被正确引用至当前激活的配置文件中，且配置文件处于启用状态。进入“配置”标签页，点击当前配置名称进入编辑界面，在规则集列表中确认去广告规则集条目是否存在且未被禁用。如果规则集条目显示为灰色或带有禁用标记，需重新启用或重新添加。同时确保当前配置名称左侧有蓝色选中标记，表明该配置确实处于激活状态，否则规则不会生效。
验证规则集是否成功拉取并缓存
对于远程去广告规则集，用户应进入“配置”标签页下拉刷新，观察规则集更新时是否返回成功提示。如果刷新过程中出现错误，规则集内容未被正确拉取，则去广告规则为空，自然无效。用户可进入该规则集的预览页面，查看是否已显示出具体的规则条目。如果预览为空，说明规则集未成功下载，需检查网络连接或更换规则集链接后重新添加。
规则集内规则语法错误导致部分条目被忽略
如果去广告规则集中的某些条目使用了Shadowrocket不支持的语法（如Clash专属的DOMAIN-SET类型），应用在加载时会跳过这些不兼容的条目而不报错，导致部分广告域名未被覆盖。用户可仔细阅读规则集发布页面的说明，确认该规则集是否明确标注“兼容Shadowrocket”。如不兼容，可寻找专门为Shadowrocket适配的去广告规则集，或将不兼容的规则条目手动转换为Shadowrocket支持的格式再内联添加。
常见问题FAQ
添加去广告规则后，部分App的广告屏蔽了但其他App还有，正常吗？
完全正常。不同App使用的广告联盟和广告分发域名各不相同，通用的去广告规则集不可能覆盖所有App的全部广告来源。用户在发现某个特定App广告未被屏蔽时，应通过日志捕获该App特有的广告域名，手动补充至配置规则中，实现针对性的补全。随着用户为各个常用App逐步补全广告域名，整体去广告效果会越来越好。
去广告规则会让App变慢或闪退吗？
在极少数情况下，如果去广告规则过于严格地拦截了App用于验证授权或加载必要资源的域名，可能导致App功能异常或启动变慢。用户应通过日志识别哪些域名被拒绝后App出现异常，临时将该域名从拒绝规则中移除或更换为DIRECT策略。通常情况下，规范的广告域名拦截不会影响App核心功能，但在某些免费或广告依赖型App中可能出现意外行为。
为什么去广告规则在Wi-Fi下有效，但在蜂窝网络下无效？
这种情况通常源于蜂窝网络环境下运营商DNS对广告域名的解析结果与Wi-Fi下不同，或App在蜂窝网络下使用了不同的广告分发渠道。用户可检查Shadowrocket的“仅在Wi-Fi下更新规则集”和“仅在Wi-Fi下启用MitM”等网络环境相关设置，确保去广告规则在所有网络环境下均被应用。同时确认蜂窝网络下Shadowrocket的代理开关处于开启状态，VPN配置已正确连接。
手动添加的广告域名规则与规则集中的规则重复了怎么办？
重复规则不会产生冲突，Shadowrocket会按照规则在列表中的先后顺序执行匹配。手动添加的规则如果放置在规则集引用之前，会优先于规则集中的同名规则执行。用户可保留手动规则，也可以等规则集更新后对比是否已包含该域名，若已包含则可删除手动规则以减少冗余。重复规则对去广告效果无负面影响，仅增加少量规则匹配开销。