nginx Troubleshooting
HTTPS 混合内容(Mixed Content)排查
HTTPS 页面加载 http:// 资源被浏览器提示 Mixed Content blocked 时，用 F12 Console 定位被阻止的 script/stylesheet/image，区分 active/passive 混合内容并逐个改成 https 或相对协议，也可在 Nginx 加 CSP upgrade-insecure-requests 兜底。
页面 HTTPS 但资源 HTTP 会被浏览器拦截。先用 F12 Console 看被阻止的资源，再逐个改成 HTTPS 或相对协议。
Scenario
这篇文章解决什么问题
适用于“HTTPS 混合内容(Mixed Content)排查”对应的线上或本地排障场景。不要只根据最终报错下结论，应先把问题拆成入口、链路、目标服务和资源限制几层，再用命令逐层证实。页面 HTTPS 但资源 HTTP 会被浏览器拦截。先用 F12 Console 看被阻止的资源，再逐个改成 HTTPS 或相对协议。
Symptoms
典型现象
- HTTPS 页面加载 http:// 资源被浏览器提示 Mixed Content blocked 时，用 F12 Console 定位被阻止的 script/stylesheet/image，区分 active/passive 混合内容并逐个改成 https 或相对协议，也可在 Nginx 加 CSP upgrade-insecure-requests 兜底。
- 相关日志、命令或页面中反复出现 nginx、https、mixed-content 等关键词。
- 同一服务在不同机器、不同入口或不同时间段表现不一致，需要通过证据链缩小范围。
Before Debugging
排查前先确认
- 确认请求是否真正到达当前 Nginx，而不是 CDN、负载均衡或另一台机器。
- 保留一次失败请求的时间、域名、路径、状态码和客户端 IP，方便和 access/error log 对齐。
- 修改配置前先导出 nginx -T 的最终合并配置，避免只看了未生效的片段。
Root Causes
常见根因分层
入口层未命中或命中了旧配置
server_name、location 优先级、SNI、默认站点和 include 顺序都会让请求落到意外配置。症状通常是本机看起来配置正确，但线上响应头、证书或错误页与预期不一致。
- 用 nginx -T 看最终配置
- 用 curl -H Host 或 openssl -servername 精确复现
- 确认 reload 成功且没有旧进程残留
反向代理到后端链路异常
502、超时、上传失败和跨域问题经常发生在 Nginx 到 upstream 的这一跳，包括端口、DNS、协议、body size、header 和超时设置。
- 从 Nginx 机器 curl upstream
- 区分 connect refused、timeout、reset、invalid header
- 检查 upstream keepalive 与后端连接限制
前置网关和应用限制不一致
CDN、Ingress、API Gateway、Nginx、应用框架可能都有独立限制。只改其中一层会造成看似随机的失败。
- 逐层确认响应来源
- 统一上传大小、超时和 CORS 策略
- 修复后从外网重新验证
Diagnosis Path
分步诊断流程
1. 固定现场，避免追着变化状态跑
先记录故障时间、影响入口、完整错误和最近一次变更。HTTPS 混合内容(Mixed Content)排查 这类问题经常在重启、重试或缓存刷新后短暂消失，没有现场信息会很难复盘。
- 截图或保存完整错误文本
- 记录请求域名/IP/端口/namespace/服务名
- 标出最近发布、配置、证书、镜像或依赖变更
curl -I https://example.com/
grep -r "http://" /var/www/html/2. 在故障发生的同一位置复现
很多误判来自测试位置不同：本机通不代表服务器通，容器内通不代表宿主机通，集群外通也不代表 Pod 内通。复现命令要尽量贴近真实流量路径。
- 从报错服务所在机器执行测试
- 必要时加 Host、SNI、namespace 或代理参数
- 把成功路径和失败路径的输出并排比较
grep -r "http://" /var/www/html/
sudo nginx -T | grep -i upgrade
curl -v -H "Upgrade-Insecure-Requests: 1" https://example.com/3. 读取服务端证据，而不是只看客户端提示
客户端报错通常是结果摘要。真正能区分根因的是服务端日志、内核日志、事件、进程状态或数据库状态。
- 用 F12 Console 和 Network 面板查看被阻止的混合内容资源。
- 区分 active（脚本、样式）和 passive（图片）混合内容，active 会被完全阻止。
- 逐个将 http 资源改为 https 或相对协议。
sudo nginx -T | grep -i upgrade
curl -v -H "Upgrade-Insecure-Requests: 1" https://example.com/4. 做最小修复并立即回归验证
每次只改一个变量，修复后用同一条复现命令回测，并观察日志是否停止增长。这样可以避免多个临时改动互相掩盖。
- 逐个将 http 资源改为 https 或相对协议。
- 检查 CSP 头是否配置了 upgrade-insecure-requests。
- 确认后端重定向和模板生成的是正确的 HTTPS URL。
sudo nginx -T | grep -i upgrade
curl -v -H "Upgrade-Insecure-Requests: 1" https://example.com/Commands
排查命令与使用意图
命令 1
用于从指定位置模拟真实请求。加 -v 可以看到 DNS、TCP、TLS、HTTP 头和代理连接过程，是定位链路阶段的关键证据。
curl -I https://example.com/命令 2
用于补充“HTTPS 混合内容(Mixed Content)排查”的排查证据链。grep 的输出需要结合上下文其他命令交叉验证，不要单独依赖某一条结果下结论。
grep -r "http://" /var/www/html/命令 3
用于确认 Nginx 最终加载配置和语法状态。排查时应看合并后的配置，而不是只看某个片段文件。
sudo nginx -T | grep -i upgrade命令 4
用于从指定位置模拟真实请求。加 -v 可以看到 DNS、TCP、TLS、HTTP 头和代理连接过程，是定位链路阶段的关键证据。
curl -v -H "Upgrade-Insecure-Requests: 1" https://example.com/Risk Notes
容易踩坑的地方
- 不要在生产环境直接 restart Nginx，优先 nginx -t 后 reload，restart 会中断正在处理的连接。
- 不要为了临时修复把 body size、CORS 或 TLS 校验无上限放开，应设置合理的业务上限并记录调整原因。
- 不要忽略 error.log 中反复出现的 upstream 超时或 SSL 错误，这些往往是更大问题的早期信号。
Verification
修复后怎么确认
- 原始故障现象已经消失，且使用同一入口重新测试 HTTPS 混合内容(Mixed Content) 能稳定成功。
- 服务端日志不再出现同类错误，监控中的错误率、重启次数、连接数或延迟回到正常区间。
- 如果做过临时绕过，已经记录恢复计划，例如还原宽松策略、补监控、补限制或提交正式配置。
Prevention
后续预防
- 把 nginx -t 和 reload 后健康检查写入发布流程，每次变更都做一次端到端验证。
- 为关键站点保留一条外网探测，监控状态码、证书有效期和响应时间，避免等到用户反馈才发现问题。
- 把上传大小、代理超时、CORS 允许来源写成显式配置，避免散落在多个 location 中导致不一致。
- 建立 Nginx 配置模板管理机制，所有 server block 使用统一模板，减少手写配置的语法错误和遗漏。
常见问题
upgrade-insecure-requests 能解决所有问题吗？
不能。它只是浏览器侧自动升级，最好从源头改成 HTTPS，避免依赖浏览器行为。
为什么本地没问题线上有？
本地可能是 HTTP 环境不触发混合内容检测，或代理自动改写了资源协议。
Long-tail SEO
你可能正在搜索这些报错
下面这些错误原文、场景词和中英文搜索词，都是排查同类问题时常见的入口。
- HTTPS mixed content blocked
- nginx 混合内容 排查
- Mixed Content blocked
- upgrade-insecure-requests CSP
- https 加载 http 资源
- nginx https 资源被阻止
- active mixed content
- nginx http 转 https 资源
Need More Help
这个问题还没完全解决？
把你的报错、环境和已经尝试过的步骤发给我，后续会优先补充到排障手册。