Nginx配置实战：一键修复Mixed Content安全警告

1. 混合内容警告：一个让前端和运维都头疼的“小”问题

不知道你有没有遇到过这种情况：辛辛苦苦把网站升级成了HTTPS，看着浏览器地址栏那个小锁图标，心里美滋滋的，觉得安全又专业。结果一刷新页面，控制台里突然冒出一堆红彤彤的报错，说什么“Mixed Content: The page at 'https://.../' was loaded over HTTPS, but requested an insecure... This request has been blocked”。翻译过来就是，你的HTTPS页面里，混着一些用普通HTTP发起的请求，浏览器出于安全考虑，把这些请求给拦截了。

这个就是典型的“混合内容”（Mixed Content）问题。我刚开始做全栈项目的时候，没少被它折腾。特别是那种老项目改造，前端代码里可能到处都写死了http://开头的API地址、图片链接或者样式表。你光把服务器配成HTTPS没用，这些写死的资源请求还是会走HTTP，然后就被现代浏览器（比如Chrome、Edge）无情地屏蔽掉。用户那边可能看到的就是页面布局错乱、图片加载不出来，或者更糟——登录、提交表单这些关键功能直接失效，就像原始文章里那个登录接口被拦截的例子一样。

为什么浏览器要这么“严格”呢？其实很好理解。HTTPS就像给你的网站数据装上了一辆防弹运钞车，全程加密，防止被窃听和篡改。但如果你的页面（运钞车）里，突然派人去路边一个没有保护的普通商店（HTTP资源）取东西，那整个安全链条就断了。攻击者完全可以在中间劫持那个HTTP请求，注入恶意代码或者偷走你的数据。所以，浏览器为了用户的安全，默认会阻止这种“混合”行为。对于我们开发者来说，这当然是好事，但修复起来也确实是个麻烦。手动去代码里把每一个http://改成https://？在大型项目里，这无异于大海捞针，而且万一有第三方库或者CDN资源也用了HTTP，你根本改不了。所以，我们需要一个更“聪明”的、在服务器层面就能一劳永逸的解决方案。

2. 为什么Content-Security-Policy是修复利器

面对混合内容问题，很多人的第一反应是去改Nginx的代理配置，或者绞尽脑汁去改前端代码的请求基地址。这些方法当然有效，但不够优雅，也容易有遗漏。这里我要给你安利一个更强大的武器：Content-Security-Policy（内容安全策略，简称CSP） 响应头。

你可以把CSP想象成你网站资源的“保安队长”兼“交通指挥官”。你通过它给浏览器下达一套非常详细的指令，告诉浏览器：我这个页面，只允许从哪些地方加载脚本、图片、样式，或者必须用什么方式去连接。而我们解决混合内容问题的关键指令，就是 upgrade-insecure-requests。

这个指令的作用简单又暴力：浏览器，你看到我这个页面里所有用http://发起的请求了吗？别管它原来是什么，通通给我自动升级成https://再发出去！ 这个升级动作发生在浏览器端，在请求真正发出之前就完成了替换。这意味着，你完全不用动前端一行代码。无论前端代码里写的是http://api.example.com，还是http://static.cdn.com/image.jpg，只要你的Nginx服务器给页面加上了这个CSP头，浏览器都会乖乖地以https://的方式去请求。

它的工作流程，用大白话复述一下原始文章里的那个时序图就是：

1. 用户访问你的HTTPS网站（比如 https://www.yoursite.com）。
2. Nginx在返回页面内容的同时，附赠一个指令：Content-Securi