海洋 CMS 开启 HTTPS 之后视频播放失效怎么办

结论：海洋 CMS 开启 HTTPS 后视频播放失效，99% 是「混合内容」（Mixed Content）导致的——页面本身走 https://，但播放器脚本、播放地址或 iframe 还在走 http://，浏览器会直接拦截这类请求，播放器黑屏或转圈。按「查控制台 → 批量改协议 → 清缓存 → 加 CSP 兜底」四步走，通常 20 分钟内能修好。

为什么开启 HTTPS 之后视频就播不了了？

结论：因为浏览器规则是「HTTPS 页面不允许加载 HTTP 的主动资源」，播放器 JS 和视频流都属于主动资源，会被硬拦截而不是降级。

具体表现是：页面能正常打开、图片偶尔能显示，但播放器区域一片黑，或者点击播放没反应。此时按 F12 打开开发者工具，Console 里会出现 Mixed Content: The page at 'https://...' was loaded over HTTPS, but requested an insecure ... 的红色报错，Network 面板里对应的请求状态往往是 (blocked:mixed-content)。

这不是海洋 CMS 的 bug，是浏览器从 Chrome 46、Firefox 23 开始就强制执行的同源安全策略。播放器脚本被拦，播放器就初始化不了；m3u8/mp4 地址被拦，就永远缓冲不出来。

怎么快速定位到底是哪些资源被拦截了？

结论：用浏览器开发者工具 + 服务器端 grep 双向确认，比盲目改代码快得多。

第一步，浏览器里按 F12，切到 Console，过滤关键词 Mixed Content，把报错里的 URL 记下来；再切到 Network，点开过滤框输入 http://，看哪些请求是 http 协议。

第二步，登录服务器，在网站根目录执行：

grep -rn "http://" ./template ./player ./js 2>/dev/null | grep -v "http://www.w3.org"

grep -rn 的意思是递归查找并显示行号。http://www.w3.org 是 HTML 的命名空间声明，属于合法写法，必须排除掉，否则会看到一大堆误报。把命中结果里跟播放有关的行挑出来，就是嫌疑名单。

模板和播放器文件里的 http:// 怎么改？

结论：统一改成协议相对地址 //，让浏览器自动跟随当前页面的协议，一份代码同时兼容 HTTP 和 HTTPS。

例如模板里写的是：

<script src="http://你的域名/player/ckplayer/ckplayer.js"></script>

改成：

<script src="//你的域名/player/ckplayer/ckplayer.js"></script>

只删掉 http: 两个字符加冒号，保留 //。这样 HTTP 访问时走 HTTP，HTTPS 访问时走 HTTPS，不用维护两套模板。如果某些播放器文件明确支持 HTTPS，直接写死 https:// 也可以。

改完记得清理海洋 CMS 后台的缓存（后台一般有「更新缓存」或「清除缓存」入口），否则页面还在读旧的编译模板。

数据库里采集来的 HTTP 播放地址怎么批量替换？

结论：播放地址存在数据库里，改模板没用，必须用 SQL 批量替换，操作前务必备份。

先备份数据库：

mysqldump -u用户名 -p 数据库名 > backup_$(date +%F).sql

然后在 phpMyAdmin 或命令行里，对存放播放地址的表执行替换。海洋 CMS 的播放地址通常存在视频主表的播放地址字段里，字段名可能是 playurl、v_playurl 之类的多行文本。可以先查一下：

SELECT id, playurl FROM 你的视频表 WHERE playurl LIKE '%http://%' LIMIT 5;

确认字段名和内容格式后，再执行替换：

UPDATE 你的视频表 SET playurl = REPLACE(playurl, 'http://', 'https://')
WHERE playurl LIKE '%http://%';

注意关键点：只有你自己的域名和确认支持 HTTPS 的资源站才能替换。如果采集源本身只有 HTTP（比如某些小站的 m3u8 地址），强行换成 https 反而会 404，这种情况只能换源或走代理。

服务器是 CDN 或反向代理，还需要额外配置吗？

结论：需要。CDN 回源或 Nginx 反代时，PHP 拿到的可能是 HTTP，导致程序生成的播放地址又变回 http，形成死循环。

在 Nginx 的站点配置里补一行，把真实协议透传给后端：

location / {
    proxy_set_header X-Forwarded-Proto $scheme;
    proxy_set_header Host $host;
}

同时在网站根目录的入口 PHP 文件顶部加判断（放在最前面，早于程序初始化）：

if (($_SERVER['HTTP_X_FORWARDED_PROTO'] ?? '') === 'https') {
    $_SERVER['HTTPS'] = 'on';
}

有没有一行代码就能兜底的应急方案？

结论：有，加 upgrade-insecure-requests 响应头，让浏览器自动把页面内的 http 请求升级为 https，但这是兜底不是根治。

Nginx 里加：

add_header Content-Security-Policy "upgrade-insecure-requests";

或者写在模板 <head> 里：

<meta http-equiv="Content-Security-Policy" content="upgrade-insecure-requests">

它只对同一域名下的资源有效，第三方 HTTP 地址仍会被拦截。而且如果目标服务器根本不支持 HTTPS，升级后的请求会直接失败——所以它适合「临时救火」，正式方案还是老老实实把源头改成 // 或 https://。

总结一下：先看 Console 确认是不是混合内容，再用 grep 找模板里的 http:// 改成 //，用 SQL 替换数据库里的播放地址，配好 X-Forwarded-Proto 防止程序再生成 http 地址，最后清缓存、用 upgrade-insecure-requests 兜底。四步做完，HTTPS 下的播放基本就恢复正常了。