Hybrid App 的 HTTP 请求通常不携带 Referer，导致 Nginx valid_referers 默认拦截为 403；应显式配置 valid_referers none 并结合 X-Client-Type 或 UA 特征做差异化校验，关键接口改用 Token 或 Origin 替代 Referer 鉴权。
移动端混合开发容器（如 Cordova、Capacitor、微信小程序 WebView、uni-app 的 App 环境）发起的 HTTP 请求，绝大多数情况下 不携带 Referer 头，或仅在特定条件下（如同源页面跳转）才带。这导致 Nginx 的 valid_referers 规则默认将这类请求判为 $invalid_referer = "1"，直接 403 拦截——不是配置错了，而是行为符合预期，但需主动适配。
为什么 Hybrid App 请求没有 Referer？
原因很明确：
- WebView 容器通常不自动设置 Referer，尤其在加载本地 HTML（
file://）或通过 JSfetch/XMLHttpRequest发起请求时 - 微信/支付宝/百度等小程序 WebView 对 Referer 控制更严格，多数接口调用默认无 Referer
- Capacitor/Cordova 的
cordova-plugin-ionic-webview默认使用capacitor://localhost协议，浏览器策略视其为“无来源”，Referer 被清空 - 即使设置了
Referrer-Policy: no-referrer或容器本身禁用 Referer，Nginx 也收不到
允许空 Referer 是最直接有效的方案
只要业务逻辑不依赖 Referer 做身份校验（比如后台不用它鉴权），就应在对应 location 中显式允许 none：
location /api/mobile/ {
valid_referers none blocked server_names yourweb.com *.yourweb.com;
if ($invalid_referer) {
return 403;
}
proxy_pass http://backend;
}其中 none 表示「Referer 字段完全缺失」属于合法来源，这是适配 Hybrid App 的关键一步。不要省略它，也不要只写 blocked 或域名——blocked 只匹配「存在但被截断」的 Referer（如 example.com 无协议），对空 Referer 无效。
区分 Web 端与 App 端请求，避免一刀切
若需对 Web 页面（有 Referer）和 App 内嵌页（无 Referer）做差异化控制，可结合 User-Agent 或自定义 Header：
- 让客户端在请求头中加标识，例如
X-Client-Type: hybrid-app，Nginx 用map提取并跳过 Referer 校验 - 或利用常见 Hybrid UA 特征（如包含
Cordova、WebView、MicroMessenger），配合if ($http_user_agent ~* "Cordova|WebView") { set $skip_referer_check "1"; }，再在 if 判断中排除 - 注意：User-Agent 可伪造，仅作辅助识别；核心仍应靠客户端主动传可信标识
真正需要 Referer 的场景，改用 Origin 或 Token 替代
如果后端必须验证来源（比如防止第三方非法调用支付回调），不应依赖 Referer，因为：
- Hybrid App 无法稳定提供 Referer
- Referer 本身可被任意篡改，安全性低
- 浏览器策略（如 Strict-Origin-When-Cross-Origin）会让跨域请求只带源，路径丢失
更合理的做法是：
- 前端在请求中带上签名 Token（如 JWT），由后端校验时效性与权限
- 对关键接口使用
Origin头校验（Origin: capacitor://localhost或https://yourapp.com），Origin 不含路径，天然适配浏览器策略 - App 启动时向服务端换取短期有效凭证，后续请求附带该凭证
