declarativeNetRequest混合内容升级规则sub_frame不生效如何解决

该规则不生效来自两个核心机制限制：

• 主流Chromium内核浏览器的混合内容拦截逻辑执行优先级高于扩展declarativeNetRequest（以下简称DNR）规则，主动混合内容（脚本、子框架、XHR/Fetch请求等）会在到达DNR规则匹配层之前被直接拦截
• 未显式声明resourceTypes字段的DNR规则，在Chrome 100+版本中默认仅匹配main_frame主框架导航请求，不会覆盖各类子资源，这也是测试时仅主框架请求生效的直接原因

按落地成本从低到高排序：

1. 修正DNR规则配置，显式声明匹配范围+提高规则优先级 #

不要依赖规则的默认匹配逻辑，显式列出所有需要升级的子资源类型，同时将规则优先级调到足够高，避免被其他低优先级规则覆盖，参考配置：

{
  "id": 1001,
  "priority": 1000,
  "condition": {
    "resourceTypes": [
      "sub_frame",
      "script",
      "stylesheet",
      "image",
      "font",
      "media",
      "xmlhttprequest",
      "websocket",
      "other"
    ],
    "excludedResourceTypes": ["ping"]
  },
  "action": {
    "type": "upgradeScheme"
  }
}

2. 配合contentSettings API放开前置拦截 #

单靠修正DNR规则无法解决浏览器前置拦截的问题，需要在扩展中申请contentSettings权限，给需要生效的站点临时放开混合内容拦截，让请求可以到达DNR规则层完成升级：

• 先在扩展manifest.json的permissions数组中添加"contentSettings"权限
• 在扩展后台脚本中添加如下配置，放开对应站点的混合内容前置校验：

chrome.contentSettings.mixedContent.set({
  primaryPattern: "*://对应业务域名匹配规则/*",
  setting: "allow"
});

注意：该配置仅调整拦截执行顺序，不会真的允许明文HTTP请求发送——所有匹配的HTTP请求都会被DNR规则升级为HTTPS后再发起，不存在额外安全风险。如果需要对所有站点生效，primaryPattern可配置为<all_urls>，但不推荐该配置，会增加不必要的规则匹配开销。

3. 可控站点直接配置CSP响应头 #

如果对要访问的站点有控制权，最稳定的方案是直接在页面响应头中添加CSP指令：

Content-Security-Policy: upgrade-insecure-requests

该指令会在页面资源请求发起前自动将所有HTTP资源引用替换为HTTPS，优先级高于浏览器默认混合内容拦截逻辑，不需要依赖扩展规则即可生效。

• 不要配置过宽的域名匹配规则，避免误升级不支持HTTPS的域名导致资源加载失败
• upgradeScheme动作仅会替换当前请求的协议为HTTPS，不会修改请求的域名、路径参数，如果页面引用的第三方HTTP资源对应的域名不支持HTTPS，升级后依然会加载失败

内容的提问来源于stack exchange，提问作者resu