Chrome扩展通过declarativeNetRequest修改响应头导致无关SSO认证类Web应用异常

看起来你的问题核心是规则误匹配或者Chrome declarativeNetRequest的字段兼容性问题导致无关请求受到影响，下面是具体的分析和解决方案：

首先排查规则匹配范围的问题 #

你当前的规则用了regexFilter: 'https://somedomain.com'，这个正则会匹配任何包含该字符串的URL（比如其他网站的跳转链接参数里包含https://somedomain.com的情况），再加上旧的domains字段（已被Chrome废弃，建议改用initiatorDomains/requestDomains），很可能导致规则误作用到其他网站的请求上。

举个例子：如果那个ASP.NET仪表盘的页面URL里恰好包含https://somedomain.com（比如作为跳转参数），而发起请求的域名又刚好被domains字段误判，就会触发规则修改该页面的响应头，进而导致后续的Application Insights跟踪请求（dc.services.visualstudio.com）因为页面初始化异常而缺失请求头。

修正规则的具体步骤 #

1. 改用精确的URL匹配方式
   放弃regexFilter，使用urlFilter做前缀匹配，确保只命中目标域名的请求：

   condition: {
     urlFilter: "*://somedomain.com/*", // 匹配somedomain.com下所有路径
     requestDomains: ["somedomain.com"], // 明确指定请求的目标域名是somedomain.com
     initiatorDomains: ["somedomain.com"], // 可选：仅匹配由somedomain.com发起的请求
     resourceTypes: [chrome.declarativeNetRequest.ResourceType.MAIN_FRAME]
   }
   

   • requestDomains：限制请求的目标域名，避免误匹配其他网站URL中包含somedomain.com的情况
   • initiatorDomains：可选，进一步限制只有somedomain.com自身发起的请求才会触发规则

2. 测试规则是否误匹配问题请求
   在background.js里添加测试代码，验证问题请求是否被你的规则命中：

   chrome.declarativeNetRequest.testMatchOutcome({
     url: "https://dc.services.visualstudio.com/v2/track",
     initiator: "https://你的ASP.NET仪表盘域名.com",
     resourceType: "xmlhttprequest"
   }, (result) => {
     console.log("匹配的规则：", result.matchedRules);
   });
   

   如果输出里有你的规则ID（123456），说明规则确实误匹配了，需要进一步调整requestDomains/initiatorDomains。

3. 检查权限和规则优先级

   • 确保manifest.json的host_permissions只包含*://somedomain.com/*，避免不必要的权限导致规则越界
   • 规则优先级设为1没问题，但如果有其他扩展的规则优先级更高，可能会冲突（不过你说只有自己的规则，这个可能性低）

4. 尝试静态规则替代动态规则
   动态规则有时候会有缓存或生效延迟的问题，你可以尝试把规则写到静态文件里：
   在manifest.json里添加：

   "declarative_net_request": {
     "rule_resources": [
       {
         "id": "main_rules",
         "enabled": true,
         "path": "rules.json"
       }
     ]
   }
   

   然后创建rules.json：

   [
     {
       "id": 123456,
       "priority": 1,
       "condition": {
         "urlFilter": "*://somedomain.com/*",
         "requestDomains": ["somedomain.com"],
         "resourceTypes": ["main_frame"]
       },
       "action": {
         "type": "modifyHeaders",
         "responseHeaders": [
           {
             "header": "foo",
             "operation": "set",
             "value": "bar"
           }
         ]
       }
     }
   ]
   

   静态规则的生效更稳定，也更容易排查问题。

额外排查点 #

• 检查background.js里是否有其他代码（比如webRequest监听器）干扰请求流程，即使你觉得只有这段规则代码，也可以暂时注释其他代码测试
• 尝试清空浏览器缓存，有时候旧的规则缓存会导致异常行为

按这个思路调整后，应该能解决规则误作用到其他SSO应用的问题。

备注：内容来源于stack exchange，提问作者zovorap