必须在 nginx valid_referers 中显式包含 none 和 blocked 以允许 webview 等空 referer 场景，否则合法请求被误拦；推荐叠加 token 签名或 ua 识别提升可靠性，并通过真实环境与日志验证。
移动端 App 内嵌 WebView（如 iOS WKWebView、Android 系统 WebView）访问静态资源时，常因隐私策略、协议切换（HTTPS→HTTP）、或渲染模式（如 PWA standalone）导致 Referer 为空。若 Nginx 防盗链配置未适配，合法请求会被误拦为盗链，返回 403 或降级图。
必须允许空 Referer 场景
valid_referers 指令中显式包含 none 是基础前提，否则所有无 Referer 请求均被判定为非法：
- ✅ 正确写法：`valid_referers none blocked server_names *.yourdomain.com;`
- ❌ 错误写法：只写域名白名单，漏掉 `none` 和 `blocked`
- `none` 允许直接输入 URL、书签访问、WebView 初始加载等无 Referer 场景
- `blocked` 允许 Referer 存在但被截断（如值为 `example.com` 而非完整 URL），常见于代理或某些 CDN 中转
避免过度依赖 Referer 的单一校验
WebView 和小程序环境本身就不稳定发送 Referer，仅靠它做权限控制风险高：
- 微信内置浏览器、部分安卓 WebView、PWA display: standalone 模式会主动清空或伪造 Referer
- HTTPS 页面引用 HTTP 资源时，浏览器按规范清空 Referer —— 若你的站点混用协议，需额外兼容
- 建议对关键静态资源（如图片）保留 `none`，对管理后台表单类接口可收紧，但不要对 `/api/` 或 `/v1/` 接口启用 valid_referers
补充更可靠的识别方式
当 Referer 不可靠时，可叠加轻量级辅助手段提升识别准确率，不破坏原有流程：
- User-Agent 简单识别：在 if 判断中加条件，例如 `if ($invalid_referer && $http_user_agent !~* "MyApp|WKWebView|Chrome.*Mobile") { return 403; }`，仅拦截明显异常 UA，放过已知 App 流量
- Token 签名方案（推荐）：对 WebView 加载的 HTML 动态注入带时效签名的资源路径（如 `/img/logo.png?t=1721556549&sig=abc123`），Nginx 用 ngx_lua 或 map + secure_link 模块校验，彻底绕过 Referer 缺失问题
- 日志观察先行：开启 referer 日志 `log_format referer_log '$http_referer $invalid_referer $http_user_agent';`，真实统计空 Referer 来源占比，再决定是否放开或加权处理
验证与调试要点
部署后务必用真实 WebView 环境验证，而非仅 curl 模拟：
- 用 Chrome DevTools 远程调试真机 WebView，查看 Network 面板中图片请求的 Request Headers 是否含 Referer
- 模拟空 Referer 测试：`curl -H "Referer:" https://yoursite.com/photo.jpg` → 应返回正常图片（非 403）
- 检查 Nginx error log 和 access log，确认 `$invalid_referer` 值是否符合预期，避免因作用域错位导致变量未生效
