在 nginx 中，`secure_link` 模块负责验证 url 中的加密签名（如 md5），而 `rewrite` 指令用于将验证通过的请求重写到实际的文件路径。核心做法是：在 `location` 块中先使用 `secure_link` 进行校验，若校验失败则返回 403；若校验成功，则利用 `rewrite` 将带有签名的 url 重写为内部文件路径，并配合 `internal` 指令防止外部直接访问该路径。
如何配置 secure_link 的密钥与表达式
要实现链接加密，首先需要定义一个共享密钥（secret）和用于生成签名的表达式（expression）。通常表达式包含 IP 地址、过期时间戳和文件名，以确保链接的安全性和时效性。Nginx 通过 `secure_link_secret` 设置密钥，并通过 `secure_link` 指令指定计算签名的字符串。如果签名匹配，变量 `$secure_link` 会被设置为 "1"，否则为空或 "0"。
server {
listen 80;
server_name example.com;
# 定义密钥，实际生产中应更复杂
set $secret_key "my_super_secret_key";
location /protected/ {
# 1. 解析 secure_link 参数
# 假设 URL 格式: /protected/file.mp4?expires=1678886400&md5=abc123
secure_link "$arg_md5,$arg_expires";
secure_link_secret $secret_key;
# 2. 检查链接是否有效
if ($secure_link = "") {
return 403 "Forbidden";
}
# 3. 检查是否过期 (secure_link 会返回 "0" 如果过期)
if ($secure_link = "0") {
return 403 "Expired";
}
# 4. 重写路径到实际文件位置
rewrite ^/protected/(.*)$ /var/www/files/$1 break;
}
}
上述配置中，`secure_link` 指令接收两个参数：第一个是用于计算 MD5 的字符串（由 `$arg_md5` 和 `$arg_expires` 组成，注意这里为了演示简化了逻辑，实际通常是将 IP+Time+File 进行 MD5 计算后放入 URL 的 md5 参数中），第二个是密钥。当请求进入时，Nginx 会根据传入的 `expires` 和 `md5` 重新计算签名并与 URL 中的 `md5` 对比。如果一致，`$secure_link` 变为 "1"。接着，`rewrite` 指令将 `/protected/filename.ext` 映射到服务器磁盘上的 `/var/www/files/filename.ext`。`break` 标志位确保重写后不再继续处理后续的 rewrite 规则，而是直接进入文件读取阶段。
如何结合 internal 防止未授权访问
仅仅使用 `rewrite` 是不够的，因为如果攻击者知道了内部文件路径 `/var/www/files/`，他们可以直接访问该目录下的文件，绕过 `secure_link` 的检查。因此，必须将内部文件路径标记为 `internal`。这意味着只有来自 Nginx 内部的请求（即经过 `rewrite` 后的请求）才能访问该路径，外部直接请求该路径将被拒绝。
# 在另一个 location 或同一 location 中定义内部路径
location /var/www/files/ {
internal;
alias /var/www/files/;
}
# 或者直接在 protected location 中使用 try_files 指向内部路径
location /protected/ {
secure_link "$arg_md5,$arg_expires";
secure_link_secret $secret_key;
if ($secure_link = "") {
return 403;
}
if ($secure_link = "0") {
return 403;
}
# 使用 try_files 替代 rewrite，更推荐的方式
# 它会自动检查文件是否存在，并在内部重定向
try_files /$1 /protected/404.html;
}
在使用 `try_files` 的方案中，我们不再显式使用 `rewrite`，而是让 Nginx 尝试查找 `/protected/` 下对应的文件。由于 `try_files` 的内部重定向是受控的，我们可以将实际的静态文件根目录设置为 `internal`。例如，创建一个专门用于内部访问的 location：
location /files/ {
internal;
root /var/www/;
}
然后修改 `protected` location：
location /protected/ {
secure_link "$arg_md5,$arg_expires";
secure_link_secret $secret_key;
if ($secure_link = "") {
return 403;
}
if ($secure_link = "0") {
return 403;
}
# 将 /protected/file.txt 映射到 /files/file.txt
rewrite ^/protected/(.*)$ /files/$1 last;
}
这里使用了 `last` 而不是 `break`，因为我们需要触发新的 location 匹配 `/files/`。当请求被重写到 `/files/file.txt` 时，Nginx 会再次匹配 location，发现它是 `internal` 的，但由于这是内部重定向，所以允许访问。如果用户直接访问 `/files/file.txt`，则会收到 404 错误，因为外部请求无法通过 `internal` 检查。这种分离关注点的方式使得安全检查和文件服务更加清晰。
如何处理动态生成的 secure_link 签名
在实际应用中，`secure_link` 的签名通常不是硬编码在 HTML 中的，而是由后端应用（如 PHP、Python、Node.js）动态生成的。后端应用需要知道相同的密钥和算法来生成正确的 MD5 值。前端页面加载时，后端会生成一个包含过期时间和签名的 URL，并将其嵌入到 `` 标签或 `` 标签中。Nginx 只负责验证这个签名，而不参与生成过程。
例如，后端可能生成如下 URL：
/protected/video.mp4?expires=1678886400&md5=a1b2c3d4e5f6
其中，`md5` 值是通过对字符串 `IP_ADDRESS:1678886400:/protected/video.mp4` 使用密钥 `my_super_secret_key` 进行 MD5 哈希计算得到的。Nginx 接收到请求后，提取 `expires` 和 `md5`，并使用相同的密钥和算法（通常是 MD5）对 `REMOTE_ADDR:$arg_expires:$uri` 进行计算，然后将结果与 `$arg_md5` 进行比较。如果两者匹配，则允许访问。这种方式确保了即使链接被截获，如果在过期时间之前未被使用，且 IP 地址发生变化，链接也会失效（取决于具体的表达式设计）。
