Chrome 禁用下载文件验证拦截的方法

场景

chrome 浏览器在下载资源时总是提示已拦截未经验证的下载内容

解决方法

路径：设置-隐私和安全-网站设置-更多内容设置-不安全内容
在允许显示不安全的内容中进行添加

[*.]cn
[*.]com

「已拦截未经验证的下载内容」是什么触发的

这个提示对应的是 Chrome 的混合内容下载拦截（Mixed Content Download Blocking），从 Chrome 86 开始逐步生效。触发条件很具体：

页面是 HTTPS 的，但下载链接指向 HTTP 地址。

也就是说你在一个加密的页面上，点了一个不加密的下载链接。Chrome 认为这种情况有风险，因为：

HTTP 传输的文件在链路上可以被任意篡改。攻击者可以在你和服务器之间把安装包替换成带后门的版本，而你完全看不出来——文件名、页面显示的一切都是对的。
页面是 HTTPS 的会给用户一种「这个下载是安全的」的错觉，实际上下载本身完全没有保护。

Chrome 对不同文件类型的处理强度不同，按危险程度分级：

可执行文件（.exe、.dmg、.pkg、.apk、.msi）— 直接阻止
归档文件（.zip、.iso、.gz）— 阻止
文档类（.pdf、.docx）— 警告但允许
图片、音视频、文本 — 不拦

所以你会发现「有的文件能下，有的下不了」，这不是随机的，是按扩展名分级的。

那个设置项其实不是最对症的

正文用的路径是 设置 → 隐私和安全 → 网站设置 → 更多内容设置 → 不安全内容，往允许列表里加域名模式。

这个设置项（Insecure content）本来是控制「HTTPS 页面里能不能加载 HTTP 的子资源」的，比如 HTTP 的图片、脚本、iframe。它确实也会影响混合内容下载的判断，所以在部分情况下有效。

[*.]cn 和 [*.]com 这种写法是 Chrome 的内容设置模式语法：

[*.]example.com — 匹配 example.com 及其所有子域
example.com — 只匹配这个确切的域名
https://example.com:443 — 可以带协议和端口

但把 [*.]com 和 [*.]cn 加进去，等于对整个互联网的绝大部分放开了不安全内容加载。 这两个后缀覆盖了网上大部分站点。这个改动的实际效果是把这一层防护整体关掉了，而不是针对某个站点开个口子。

更合理的做法是只给你确实需要的那个域名开口。比如你要从公司内网的某个下载站取文件：

[*.]内网域名.com

一条一条加，用完了删掉。这样其它站点的防护还在。

更对症的几个做法

做法一：直接改下载链接为 HTTPS（首选）

大部分站点其实是支持 HTTPS 的，只是页面里的链接写死成了 HTTP。右键复制链接地址，把 http:// 改成 https:// 粘到地址栏，多半就能直接下载了。

这是最好的解法——它解决了根本问题（传输没加密），而不是绕过警告。

做法二：用命令行下载

curl 或 wget 不受浏览器的这套策略约束：

curl -L -O http://example.com/path/file.zip

-L 跟随重定向，-O 用远端的文件名保存。

但要理解：这只是换了个工具，传输依然是不加密的，篡改风险照旧存在。所以拿到文件后应该校验完整性。如果站点提供了校验值：

# macOS / Linux
shasum -a 256 file.zip
# 对比站点公布的 SHA256 值

:: Windows PowerShell
Get-FileHash file.zip -Algorithm SHA256

校验值和站点公布的一致，说明文件没被改过。这是应对 HTTP 下载风险的正确手段——不是关掉警告，而是自己做完整性验证。

做法三：Chrome 下载栏里的「保留」

被拦的下载会在下载列表（chrome://downloads）里留一条记录，有些情况下旁边有「保留」按钮，点一下就下了。这个是针对单次下载的放行，比改全局设置精确得多。

另一个容易混淆的拦截：Safe Browsing

Chrome 还有另一套下载拦截机制，报错文案不一样，很容易和上面那个搞混：

「已拦截未经验证的下载内容」 → 混合内容拦截，因为链接是 HTTP。本文讨论的这个。
「此文件可能有危险，因此 Chrome 已将其屏蔽」/ 「文件不常见，可能有害」 → Safe Browsing（安全浏览）判断，跟 HTTP/HTTPS 无关，是基于文件的信誉和哈希做的判断。

Safe Browsing 的设置在 设置 → 隐私和安全 → 安全 里，有三档：

增强保护 — 把下载文件的哈希（某些情况下是文件本身）送到 Google 做实时检测。检出率最高，但有隐私成本。
标准保护（默认）— 用本地的恶意网址/文件列表比对，不上传文件。
不提供保护 — 关掉。不建议。

如果你遇到的是 Safe Browsing 拦截，改「不安全内容」那个设置是没用的——两套机制完全独立。Safe Browsing 的单次放行方式是在下载列表里点「保留危险文件」。

自建工具、小众开源软件被 Safe Browsing 误判很常见（因为下载量少，没有信誉数据）。这种情况下自己确认来源可靠就放行，不用为此关掉整个保护。

我的实际取舍

这类「关掉安全提示」的操作，我的原则是：能改根因就不绕过，必须绕过就限定范围和时间。

具体到这个场景：

先试 HTTPS。九成情况下这一步就解决了。
确实只有 HTTP 的，用 curl 下载 + 校验哈希。文件来源如果是开源项目，校验值一般在 release 页面或者 SHASUMS 文件里。
必须在浏览器里下且频繁需要（比如公司内网的老系统），才去加白名单，且只加那个具体域名，不加 [*.]com 这种泛匹配。
记下改过什么，需求过去了改回来。

Chrome 的这些拦截确实有时候很烦，但它们拦的是真实存在的攻击路径——通过篡改 HTTP 下载分发恶意软件是一种被实际使用过的手法，尤其在公共 Wi-Fi 和被入侵的运营商网络环境下。放开整个 .com 和 .cn 的成本，是让所有站点都能往你的 HTTPS 页面里塞 HTTP 内容，这个交换在多数情况下不划算。