PHP无法真正加密视频链接，只能生成带签名和过期时间的临时token；需Nginx配合auth_request调用PHP校验，通过HMAC-SHA256签名、时效验证及路径严格匹配实现访问控制。
PHP 本身不能直接“加密视频播放链接”使其不可被复制或下载，它只能生成带有时效性、权限校验的临时访问凭证。真正起作用的是服务端鉴权逻辑 + Web 服务器（如 Nginx/Apache）的配合，而非对 URL 做可逆加密。
为什么 base64_encode 或 openssl_encrypt 不适合直接用于“保护视频链接”
这类函数只是编码或加密字符串，只要攻击者拿到加密后的 URL 和 PHP 源码（或逆向出密钥/算法），就能解密还原原始路径。视频文件一旦通过 HTTP 可达，浏览器就能抓包、开发者工具就能看到真实请求地址。
-
base64_encode()不是加密，是编码，完全无安全意义 -
openssl_encrypt()若密钥硬编码在 PHP 中，等同于明文暴露 -
前端 JS 拼接的 URL、
中的地址，始终可见
推荐做法：用 PHP 签发带签名和过期时间的临时 token
核心思路：不隐藏 URL，而是让每个视频链接附带一个一次性的、有时效的、服务端可验证的签名参数，由 Web 服务器在转发前做拦截校验。
例如生成这样的链接：
立即学习“PHP免费学习笔记（深入）”；
https://cdn.example.com/video/123.mp4?token=abc123&expires=1717028400&sign=9f8e7d6c5b4a3928
其中 sign 是服务端用密钥对 video/123.mp4|1717028400 计算的 HMAC-SHA256 值。
- PHP 负责生成
expires（Unix 时间戳）和sign，不暴露文件真实路径给前端 - Nginx 需配置
secure_link模块或用auth_request转发到 PHP 鉴权脚本 - 用户无法手动构造有效 token：过期时间一过即失效，签名错则 403
实际部署时 Nginx + PHP 的最小可行配合
假设你用 Nginx 的 auth_request 指令做鉴权，PHP 提供一个轻量接口：
location /video/ {
auth_request /auth;
alias /var/www/videos/;
}
location = /auth {
internal;
proxy_pass https://www.php.cn/link/9f31d6fe1de940d081e72ce1778c5661;
proxy_pass_request_body off;
proxy_set_header Content-Length "";
proxy_set_header X-Original-URI $request_uri;
}
check-token.php 示例逻辑（只校验，不输出内容）：
if (!isset($query['token'], $query['expires'], $query['sign'])) {
http_response_code(403);
exit;
}// 简单防重放：拒绝 5 分钟前的 expires
if ((int)$query['expires'] < time() - 300) {
http_response_code(403);
exit;
}
// 签名验证：约定 secret_key + path + expires 拼接后 hash
$secret = 'your_very_secret_key_here';
$path = parse_url($uri, PHP_URL_PATH);
$expected_sign = hash_hmac('sha256', $path . '|' . $query['expires'], $secret);
if (!hash_equals($expected_sign, $query['sign'])) {
http_response_code(403);
exit;
}
http_response_code(200); // 允许访问
?>
- 注意
hash_equals()防时序攻击，别用== -
$path必须严格取自原始请求 URI，不能从$_GET拼接，否则绕过路径限制 - Web 服务器必须禁用目录浏览，且视频目录不在 Web root 下（如放在
/var/www/videos/，不通过http://...直接访问）
真正的难点不在 PHP 写几行 sign 代码，而在于 Web 服务器能否可靠拦截每一个视频请求并交由 PHP 校验——漏掉一个没走 auth_request 的路径，整个机制就形同虚设。