给站点装上證书、把訪問地址切到 https，通常只是运维层面的一個動作。但切換完成之後，頁面上只要還残留一個 http 開头的图片、脚本或样式，浏览器就可能在地址栏收起鎖形图标，或者直接把這段资源拦下来。這類問题不會让整站打不開，所以很容易長期潜伏，直到某天有人截图反馈才被發現。
為什么值得單獨查一遍
訪客侧的体驗是直观的：地址栏的提示一旦從安全變成不安全，表單填寫、支付跳轉這類動作的信任度會立刻下降。有些浏览器還會對混合内容做主動拦截，表現為图片空白、样式错乱、脚本不执行，而頁面本身依然返回 200，從监控上看不出任何異常。
抓取侧同样值得留意。蜘蛛訪問的是 https 地址，頁面里却指着一批 http 资源，等于每抓一個頁面都要多走一轮协议跳轉；如果這些资源的域名已经停用或證书過期，抓取過程還會碰到一连串失敗請求，白白消耗時間和连接數。
混合内容常见的几個来源
- 歷史正文里的绝對地址：早期編輯在文章中直接粘贴了 http 開头的图片、附件或站外連結。
- 模板與主题里的硬编碼：头部文件寫死了 http 的字体库、統計脚本、CDN 前缀。
- 第三方组件：评论系統、客服悬浮窗、广告位、地图嵌入代碼、分享按钮。
- 内容迁移遗留：從舊站導入的文章，正文内鏈和图片路径仍然是舊协议、舊域名。
- 缓存中的舊版本：CDN 或反向代理還缓存着切換前的 HTML，訪客拿到的仍是老頁面。
- 下一层资源：CSS 里用 url() 引用的背景图、JS 里拼接出来的接口地址，這些不會出現在頁面源碼的顯眼位置。
怎么查：從人工抽查到批量掃描
- 打開浏览器開發者工具，切到網絡面板，按协议或域名排序，把 http 開头的請求挑出来；控制台里通常也會有混合内容的告警。
- 用無痕窗口分別訪問几類代表性頁面：首頁、栏目列表頁、内容詳情頁、站内搜尋结果頁、带表單的頁面。缓存會掩盖問题，無痕加禁用缓存更可靠。
- 把頁面源碼抓下来做文本检索，搜尋 http:// 和 // 開头的寫法，重点看模板文件和公共头部、底部。
- 顺着 CSS 和 JS 再查一层，很多资源是在样式表或脚本里被間接引用的，只查 HTML 會漏掉。
- 單獨用移動端或窄屏设备看一遍，部分站点會按终端下發不同的模板，問题可能只出現在其中一套。
- 检查响應头里的 Content-Security-Policy，如果設定了 upgrade-insecure-requests，實际表現會和源碼看起来的不一致，排查时別被誤導。
修复时的几個注意点
- 能改相對路径就改相對路径，能改协议相對寫法就改协议相對寫法，减少以後再次切換域名时的工作量。
- 批量替換前先备份，並且注意 http:// 也可能出現在正文的示例文本、代碼块里，全局替換會把不该動的内容一並改掉。
- 有些老服務确實不支持 https，這时要考虑換源或把资源放到自己服務器上，而不是简單地改個前缀了事。
- 改完之後再走一遍重定向检查，確認没有因為协议切換产生新的跳轉环或者多余的中間跳。
- 如果用了 CDN，记得刷新對應目錄的缓存，否則修好的頁面可能還在邊缘节点上睡着舊版本。
一份简單的自查清單
- 首頁與主要栏目頁的地址栏提示是否正常，没有“不安全”或警告图标。
- 頁面源碼中是否還存在指向 http 的图片、脚本、样式引用。
- CSS 與 JS 内部引用的下一层资源是否也已切換。
- 第三方组件、統計代碼、客服脚本的地址是否為 https。
- 站内舊文章正文中的图片與内鏈是否已批量處理。
- HTTP 到 HTTPS 的跳轉是否為單次跳轉且無循环。
- sitemap、robots 中声明的地址與目前訪問协议是否一致。
协议切換不是一次性任務，而是一條需要定期回看的检查項。新發布的文章、新接入的第三方服務、新換的模板，都可能把 http 资源重新带進来。把它纳入日常巡站流程，比事後补救省力得多。