为什么现在值得写某天下午正在工位上摸鱼划水后台突然弹出一一条读者私信“博主你的博客是不是被黑了怎么一点进去就跳到那种不可描述的网站”第一反应是不信。我的博客托管在 GitHub Pages套了 Cloudflare 的 CDNDNS 解析也锁得死死的怎么可能会被挂马紧接着第二反应是慌。赶紧掏出手机断开 WiFi 用 4G 流量刷了一下正常连上公司 WiFi 刷一下也正常回家打开宽带一试——好家伙那个熟悉的极简风博客瞬间变成了花花绿绿的博彩页面弹窗乱飞简直像是在我脸上扇了一巴掌。那一刻我才意识到所谓的“大厂托管 静态页面”在运营商的 HTTP 劫持面前不过是一张没穿铠甲的白纸。这次排查和修复的过程像极了一场没有硝烟的攻防战值得每一个还在用 HTTP 的站长警惕。案发现场如何确认是 HTTP 劫持排查第一步排除 DNS 劫持既然网站被跳转了第一怀疑对象自然是 DNS。如果域名被解析到了黑客的服务器那跳转就是顺理成章的事。我立刻打开终端熟练地敲下ping和nslookup。结果显示域名解析出的 IP 地址完全正确清一色指向 GitHub Pages 的服务器段。DNS 没问题那问题就出在数据传输的路上。排查第二步锁定 HTTP 响应注入既然 IP 对得上那就看看 HTTP 响应头。在终端输入curl -I检查响应头屏幕上跳出的结果让我心里一沉返回了一个诡异的 301 重定向目标正是那个非法网站。紧接着打开浏览器开发者工具切到 Network 面板刷新页面。在第一个文档请求里我看到了真相HTTP 响应体里被硬生生塞进了一段恶意的 JS 脚本正是这段代码把我的博客“踢”到了那个非法站点。这行注入代码比我正文还显眼结论这是一次典型的 HTTP 劫持证据链闭环了DNS 解析正常说明域名没被盗但 HTTP 响应被篡改说明有人在数据传输的必经之路上动了手脚。结合“家里宽带跳转、手机 4G 正常”的现象嫌疑人直接锁定——运营商。因为 HTTP 协议是明文传输运营商的网关设备完全有能力在响应包里“夹带私货”插个广告算轻的直接劫持跳转才是真的黑。根因拆解为什么运营商能劫持你的博客HTTP 明文传输的致命弱点HTTP 就像在明信片上写情书经手的每一个邮递员都能偷看内容甚至拿起笔涂改两句。对于运营商来说HTTP 流量就是一块肥肉。他们可以在你的网页里注入广告脚本赚取外快甚至把你的流量“卖”给第三方。虽然国家一直在打击但在某些地区、某些小运营商的网络环境下这种“中间人攻击”依然屡禁不止。为什么 HTTPS 是解药HTTPS 则是把明信片装进了上了锁的保险箱。只有持有钥匙的服务器和浏览器才能打开。即便运营商截获了数据包看到的也只是一堆乱码根本无法注入代码。这就是为什么全站 HTTPS 是现代网站的标配——不是为了显得高级而是为了不被“中间商”赚差价。手术方案从强制 HTTPS 到 HSTS 的完整配置既然病根在 HTTP那治疗方案就很明确强制全站 HTTPS不给 HTTP 任何露脸的机会。方案一GitHub Pages 强制 HTTPS登录 GitHub 仓库的 Settings找到 Pages 选项卡。如果你的域名 DNS 解析正常这里通常可以直接勾选Enforce HTTPS。但这里有个坑如果你的域名刚解析过去GitHub 的证书还没签发下来这个选项可能是灰色的。别急等个半小时再刷新Let’s Encrypt 的自动签发很快。方案二Cloudflare 加密模式选择这一步最关键也是最容易踩坑的地方。在 Cloudflare 的SSL/TLS设置里加密模式一定要选Full (strict)。⚠️踩坑提醒千万别选Flexible。这个模式下用户到 Cloudflare 是加密的但 Cloudflare 到你的源站GitHub Pages是 HTTP 的。这不仅没解决根本问题还可能在源站环节被劫持。只有Full (strict)才能保证全链路加密并且验证源站证书彻底堵死中间人下手的缝隙。方案三HSTS 防止降级攻击光有 HTTPS 还不够如果有人故意把你重定向到 HTTP 链接怎么办这时候就需要 HSTSHTTP Strict Transport Security。在 Cloudflare 的SSL/TLS-Edge Certificates里开启 HSTS。这相当于告诉浏览器“以后只许用 HTTPS 连我任何 HTTP 链接直接拒绝。”建议刚开始把max-age设置短一点比如 6 个月测试没问题再加长到 1 年甚至更久。方案四Cloudflare Page Rules 强制跳转为了保险起见我还配置了一条 Page Rules如果 URL 匹配http://*则转发到https://使用 301 永久重定向。这相当于在门口派了个保安凡是想走 HTTP 进来的一律踹到 HTTPS 那边去。进阶加固CSP、DNSSEC 与 SRI 构建纵深防御解决了眼前的劫持还得防着未来的变种。安全这事儿永远没有“做完”的一天。配置 Content-Security-Policy (CSP)CSP 响应头可以限制浏览器只加载你信任的资源防止被注入恶意脚本。在 Cloudflare 的Rules-Transform Rules中添加响应头Content-Security-Policy: default-src self; script-src self unsafe-inline https://cdn.jsdelivr.net; style-src self unsafe-inline https://fonts.googleapis.com;这段配置的意思是默认只加载同源资源脚本和样式允许从指定的 CDN 加载。根据你自己的博客实际引用情况调整域名白名单。启用 DNSSEC 防止 DNS 篡改虽然这次是 HTTP 劫持但 DNS 劫持也是常见手段。在域名注册商后台开启 DNSSEC相当于给 DNS 解析过程加了一把数字签名锁防止解析结果被伪造。使用 SRI 保护外部资源如果你引用了第三方 CDN 的 JS 或 CSS一旦那个 CDN 被黑你的网站也会跟着遭殃。SRISubresource Integrity可以解决这个问题。在引用标签里加上integrity属性浏览器会校验文件的哈希值scriptsrchttps://cdn.jsdelivr.net/npm/example1.0.0/dist/main.jsintegritysha384-oqVuAfXRKap7fdgcCY5uykM6R9GqQ8K/uxccrossoriginanonymous/script如果文件被篡改哈希值对不上浏览器就会拒绝加载。写在最后折腾了一晚上终于把博客从“赌场”变回了技术净土。用 SSL Labs 测了一下拿到了 A 评级看着那个绿色的评分心里总算踏实了。这次事故给我上了一课在网络安全领域任何侥幸心理都是给黑客留后门。HTTP 看着省事其实是在裸奔HTTPS 配着麻烦却是现代互联网的底线。你的博客现在用的是 HTTP 还是 HTTPS有没有遇到过类似的运营商劫持欢迎在评论区聊聊你的排查经历。参考文献MDN Web Docs - HTTP Strict Transport Security来源https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Strict-Transport-Security用途解释 HSTS 的工作原理和配置参数Cloudflare Docs - SSL encryption modes来源https://developers.cloudflare.com/ssl/encryption-modes/用途说明 Full (strict) 模式与其他模式的区别GitHub Docs - Securing your GitHub Pages site with HTTPS来源https://docs.github.com/en/pages/configuring-a-custom-domain-for-your-github-pages-site/securing-your-custom-domain-with-https用途GitHub Pages HTTPS 强制开启的官方指南MDN Web Docs - Content-Security-Policy来源https://developer.mozilla.org/en-US/docs/Web/HTTP/CSP用途CSP 头的配置语法和作用Qualys SSL Labs - SSL Server Test来源https://www.ssllabs.com/ssltest/用途作为验证 HTTPS 配置正确性的在线工具推荐延伸入口个人博客站点https://tobemagic.github.io/ai-magician-blog/posts/2026/03/27/博客变赌场一次运营商-http-劫持的排查与绝地反击/公众号计算机魔术师想看系统化归档、原文版本与后续补充优先回到个人博客站点想追更新和合集去公众号。