HTTPS混合内容扫描清单

本地处理

打赏支持
分享链接
反馈建议

把站点切到 HTTPS 之后，如果页面里还残留 http:// 的资源引用，浏览器就会报「混合内容」。主动型（脚本、样式、iframe、表单）会被直接拦截，页面功能直接坏掉；被动型（图片、音视频）会被自动升级或标记为不安全。用本工具扫一遍再改，比在控制台里一条条翻快得多。

粘贴页面源码或一批 URL（每行一个）

明文资源数

主动型(会被拦截)

被动型(可升级)

已是 https 资源

#	类型	风险	URL

扫描逻辑：匹配文本中所有 http:// 开头的资源地址，再按它所在的标签归类。主动型混合内容（script、link、iframe、form、object、embed、CSS 内联 import）会被浏览器直接阻止加载；被动型（img、video、audio、source、CSS background 的 url()）会被自动升级为 https，失败则降级显示。

为什么浏览器要「拦截」自己的资源

HTTPS 的意义是端到端加密。如果页面本身来自 HTTPS，却加载了一段来自 HTTP 的脚本，那么这段脚本在传输途中可以被任何人篡改——攻击者只要在中间人位置替换脚本内容，就能拿到页面上的所有数据，包括登录凭据和会话 cookie。整条加密链就被这一段明文打穿了。所以浏览器选择直接拦截，而不是放行。

主动型 vs 被动型

类型	包含标签	浏览器行为	后果
主动型（blockable）	script、link、iframe、form、object、embed、@import	直接阻止加载	脚本不执行、样式不生效、表单提交失败、插件挂掉
被动型（upgradable）	img、video、audio、source、CSS url()	自动尝试升级为 https	多数无声升级成功；失败则显示为不安全或空白

主动型是必须立即修的硬故障。被动型容易被忽略但同样值得处理：地址栏的「不安全」提示、图片因目标服务器不支持 https 而加载失败（表现为空白或裂图），都会实际影响体验与转化。

三套主流处理方案

Content-Security-Policy: upgrade-insecure-requests：让浏览器自动把所有明文子资源请求升级为 https，是改造期最省事的临时方案。但它无法解决「目标服务器不支持 https」的情况。
HSTS（Strict-Transport-Security）：强制该域名后续一律走 https。注意开启后无法轻易回退，且对子资源域名需要单独设置。
直接改源码：把 http:// 全部替换为 https:// 或改用协议相对写法。这是唯一彻底的做法，也是本工具「一键升级」在帮你做的事。

改造时的四个实操要点

先确认目标域名支持 https。有些第三方 CDN、图床、统计脚本本身只有 http，替换后照样加载失败，需要换服务商或自建代理。
别忘了 CSS 和 JS 里的硬编码地址。背景图、字体文件、字体 CDN 地址经常藏在样式文件里，比 HTML 里的更难发现。
检查 content 属性与结构化数据。og:image、twitter:image、JSON-LD 里的图片地址，虽然不直接影响页面加载，但分享卡片会坏掉。
别忘了数据库里的存量内容。用户上传的描述、富文本里的图片地址往往直接存了 http，需要批量做一次数据清洗，否则新页面也会带回明文资源。

最后补一个诊断技巧：Chrome DevTools 的 Console 会把混合内容全部列出来，Network 面板里被拦截的请求会标成 (blocked:mixed-content)。但控制台只报「当前渲染路径上」的问题——某些分支代码、懒加载资源、只在特定设备上出现的组件不会触发。所以上线前用源码扫描做一次全量检查，比只依赖控制台更稳。

你可能还想问

混合内容有什么危害？

加密页面里的非加密资源会被中间人篡改，破坏整体安全性；浏览器还会提示不安全或直接拦截该资源，影响体验与信任。

最常见的是哪几类？

图片、脚本、样式与外链字体；尤其老站里硬编码的旧地址、第三方组件里的非加密地址最容易漏。

怎么彻底排查？

用浏览器控制台筛出被拦截的资源、扫描源码里的非加密地址、检查动态注入的内容；一次性全量排查比逐个等用户反馈更靠谱。