直接用 secure_link_secret 是最简方式，适合单个资源路径轻量级签名校验，基于“密钥+URI路径”MD5并Base64 URL安全编码比对，配置简单但链接永久有效、不支持时效控制。
直接用 secure_link_secret 是最简方式，适合对单个资源路径做轻量级签名校验，不依赖时间戳，也不需要额外参数解析，但灵活性较低。
secure_link_secret 的工作逻辑
它基于“密钥 + URI 路径”拼接后计算 MD5，并自动与 Base64 URL 安全编码后的结果比对。Nginx 内部会：
- 取配置中指定的密钥（如
MySecret） - 拼接
$uri（注意：含前导斜杠，如/images/logo.png） - 对拼接字符串做 MD5，再转为 Base64 URL 安全编码（去掉
+、/、=） - 将该值与请求 URL 中的
md5参数（或默认位置）比对
基础配置写法
在 location 块中启用：
location /protected/ {
secure_link_secret MySecret;
if ($secure_link = "") {
return 403;
}
}
此时 Nginx 默认从请求 URL 的 md5 参数读取签名，例如：
https://example.com/protected/file.zip?md5=abc123xyz
服务端会校验 MD5("MySecret/protected/file.zip") 编码后是否等于 abc123xyz。
签名生成要点
后端生成签名时必须严格匹配 Nginx 的计算逻辑：
- 密钥完全一致（区分大小写、空格）
-
$uri必须带开头的/，且不能含查询参数（即只取路径部分） - 使用标准 MD5 + Base64 URL 安全编码（Python 可用
base64.urlsafe_b64encode()） - 不要添加过期时间或额外字段，否则无法通过校验
适用场景与局限
适合静态资源目录级保护，比如内部文档库、固定下载入口：
- 优点：配置简单，无需处理时间同步、参数提取等细节
- 缺点：链接永久有效，无法设置过期；每个 URI 需独立签名，不支持通配或动态路径泛化
- 不推荐用于用户级临时下载、付费内容等需时效控制的场景
