Nginx secure_link模块链接过期功能失效求助

你的Nginx secure_link过期时间不生效，核心原因大概率是生成链接的机器与Nginx服务器的系统时间不同步，其次可通过调试日志验证Nginx的时间判断逻辑。

排查步骤 #

1. 检查时间同步情况
   在生成链接的Python脚本所在机器和Nginx服务器上分别执行date命令，对比两者的系统时间。如果时间差超过你设置的30秒过期时长，就会导致Nginx误判链接仍未过期。

   • 解决：使用NTP服务同步两台机器的系统时间，比如执行ntpd -q（类Linux系统）或timedatectl set-ntp true（systemd环境）。

2. 添加调试日志验证Nginx逻辑
   修改Nginx配置，添加响应头输出关键变量，确认过期时间判断是否正常：

   location ^~ /file/ {
           root /var/www/html;
           secure_link $arg_md5,$arg_expires;
           secure_link_md5 "$secure_link_expires$remote_addr$uri 6v#Q6zu3BEk4Y27Rkig7dKjW@Vd6YHV";
           # 调试用响应头
           add_header X-Nginx-Current-Time $time_iso8601;
           add_header X-Link-Expires $arg_expires;
           add_header X-Secure-Link-Status $secure_link;
           if ($secure_link = "") { return 403; }
           if ($secure_link = "0") { return 410; }
           add_header Content-Disposition "attachment; filename=$arg_name";
   }
   

   重载Nginx配置后，用curl请求过期后的链接：

   curl -I "http://192.168.250.83/file/test.mp3?md5=xxx&expires=xxx"
   

   查看响应头：

   • 若X-Secure-Link-Status为0但Nginx未返回410，检查if语句是否被其他配置干扰；
   • 若X-Nginx-Current-Time对应的时间戳小于X-Link-Expires，说明Nginx服务器时间确实滞后。

3. 排除缓存干扰
   确认Nginx未开启proxy_cache、fastcgi_cache等缓存配置，若有缓存可能会跳过secure_link验证直接返回缓存内容，可临时关闭缓存测试。

补充说明 #

你之前添加的expires $arg_expires;是控制浏览器缓存的响应头，和secure_link的服务器端过期验证逻辑无关，因此不会生效。

内容的提问来源于stack exchange，提问作者DrakeTaylor