前端开发者必看：Chrome94的CORS策略改动如何影响本地开发（含海康插件兼容方案）-CSDN博客

前端开发者必看：Chrome94的CORS策略改动如何影响本地开发（含海康插件兼容方案）

最近在调试一个本地视频监控项目时，团队里好几个同事都遇到了同一个诡异的问题：昨天还能正常播放的海康威视视频流，今天一打开Chrome浏览器，画面就黑屏了，控制台里躺着一行刺眼的CORS错误。起初大家以为是后端服务挂了，或者是网络代理配置出了问题，排查了一圈，最后发现“罪魁祸首”竟然是浏览器自己——Chrome在静默更新到94版本后，引入了一项新的安全策略。这个改动看似微小，却像一颗投入平静湖面的石子，在本地开发、内网测试，尤其是那些依赖特定浏览器插件或本地服务的场景中，激起了不小的涟漪。如果你也正在为突然出现的跨域请求被阻断而头疼，或者你的项目里集成了类似海康、大华这类硬件厂商的浏览器插件，那么理解Chrome 94这次更新的底层逻辑，并掌握一套从临时规避到长期根治的应对策略，就显得至关重要了。

1. 深入解析：Chrome 94的“Block insecure private network requests”到底是什么？

要解决问题，首先得弄清楚问题从何而来。Chrome 94版本中引入的这项新特性，其完整名称是 “Block insecure private network requests”。光看名字可能有点绕，我们可以把它拆解开来理解。

简单来说，这是一项旨在提升网络请求安全性的策略。它的核心目标是：阻止来自公网（或相对不安全上下文）的网页，向你的本地私有网络（如localhost、你的家庭路由器内网IP 192.168.1.x、或公司内网地址）发起非安全的（即HTTP协议）请求。

为什么Chrome要这么做？这背后是私有网络访问（Private Network Access, PNA） 规范逐步落地的一部分。想象一个场景：你访问了一个恶意的公共网站，这个网站上的脚本试图偷偷扫描你本地局域网（比如192.168.1.0/24网段）中的路由器、NAS设备或智能家居设备，如果这些设备的管理界面存在漏洞且未设置密码，攻击者就可能得逞。这项策略就是为了防范这类“从外到内”的探测与攻击。

注意：这里的安全上下文（Secure Context）通常指的是通过HTTPS服务的页面，或者来自localhost、file://协议的页面。而“私有网络”则包括了本地回环地址（如127.0.0.1, localhost）和本地网络地址（如192.168.x.x, 10.x.x.x）。

在Chrome 94之前，这项检查默认是关闭或警告状态。但从94版本开始，它被**默认启用（Enabled）**了。这就直接导致了我们开发中常见的几种“事故”：

本地开发服务器（HTTP）访问本地API后端（HTTP）：你的前端项目运行在 http://localhost:3000，它向同样运行在本地的 http://localhost:8080/api 发起请求，现在会被阻止。
公网测试环境（HTTPS）访问内网服务（HTTP）：你们公司的测试站点是 https://test.example.com，它需要调用部署在内网某台机器上的 http://192.168.1.100:9000 的服务，也会被拦截。
浏览器插件与本地应用的通信：这正是海康视频插件问题的典型场景。插件通常以本地应用或服务的形式运行，通过HTTP与浏览器页面通信。当页面来源不符合“安全上下文”访问“私有网络”的规则时，通信即告失败。

理解了这个机制，我们就能明白，那行令人困惑的CORS错误信息 The request client is not a secure context and the resource is in more-private address space ‘local’，其实是在非常精确地告诉你：“你当前这个页面环境不够安全，却想访问一个更私密的本地资源，根据新规，我（浏览器）不允