原生secure_link无法实现IP绑定，因其签名生成与校验均不支持动态嵌入或比对$remote_addr；它仅基于预设密钥、URI及过期时间做单向哈希校验，无运行时IP提取与验证机制。
直接用 Nginx 的 secure_link 模块实现“IP 绑定”的私有视频流播放权限，存在根本性限制——secure_link 本身不支持动态嵌入客户端 IP 到签名中。它只校验 URL 中携带的哈希签名是否匹配服务端用预设密钥 + 固定字符串（如文件路径、过期时间）生成的结果，无法在签名阶段自动加入请求方真实 IP 并在验证时比对。
为什么原生 secure_link 无法真正绑定 IP
secure_link 的工作流程是单向校验：
- 签名生成依赖服务端可控变量（如
$uri、$arg_e过期时间、自定义变量），但$remote_addr在生成签名时不可用于构造原始签名串（因为签名需提前生成并写入 URL，而服务端无法预知谁会访问）； - 验证阶段，Nginx 只重新计算一次哈希，对比 URL 中的
secure_link参数，不执行“取出当前请求 IP，再拼进验证逻辑”的操作； - 即使通过
secure_link_md5手动构造含 IP 的签名，也无法在验证时让 Nginx 自动提取并参与比对——模块无此机制。
可行的高安全性替代方案（推荐）
要实现“该链接仅限某 IP 访问”，需组合使用 Nginx 原生能力与外部控制逻辑：
-
方案一：Token + IP 白名单（轻量可靠）
后端生成 token 时，将ip_hash（如 md5($remote_addr + secret + expire)）作为签名一部分，URL 形如/video/abc.mp4?token=xxx&e=1717020000；Nginx 用secure_link校验 token 和过期时间，再用map+if对比请求 IP 与 token 解析出的 IP（需后端把 IP base64 编码进 token 或拆成独立参数）； -
方案二：Lua 脚本动态验证（灵活强控）
使用nginx-lua-module，在access_by_lua_block中解析 token、还原原始 IP、比对$remote_addr，不匹配直接返回 403；可结合 Redis 缓存 token 状态，支持即时吊销； -
方案三：JWT 签名 + Nginx auth_request（标准可扩展）
后端签发 JWT，payload 含ip、exp、file；Nginx 用auth_request转发到内部鉴权服务（如 Python/Go 微服务），由其解析 JWT 并校验 IP 是否一致，返回 200 或 403。
若坚持用 secure_link，只能做“弱 IP 关联”
适用于对安全性要求不高、仅需简单区分网络段的场景：
- 用
map指令将不同 IP 段映射到不同密钥：map $remote_addr $secure_key {<br> ~^192\.168\.1\. $key_office;<br> ~^10\.0\.0\. $key_internal;<br> default $key_public;<br>}
再在secure_link_md5中使用$secure_key，使同一 URL 对不同网段产生不同校验结果； - 缺点明显：无法精确到单 IP，且密钥映射需重启或重载 Nginx 才生效，不支持运行时策略变更。
关键提醒：视频流还需注意传输层安全
即使权限控制严密，仍需配套措施防旁路：
- 禁用目录浏览：
autoindex off;； - 限制 Referer（辅助防盗链）：
valid_referers none blocked *.example.com;； - 配合 HTTPS 强制加密，防止 token 在传输中被截获；
- 对 HLS/DASH 流，确保
.m3u8和所有.ts分片都走同一套鉴权逻辑，避免只保护主清单而放行分片。
不复杂但容易忽略：真正的 IP 绑定必须在验证环节实时比对，而不是靠 URL 签名“假装包含”。选方案时优先考虑可审计、可撤销、不依赖 Nginx 重启的能力。
