应采用请求头标识与IP白名单双重校验，或通过auth_request对接网关认证接口；禁用Referer校验，确保仅信任网关转发的请求。
要让 Nginx 静态资源服务**只允许特定应用网关访问**（而非浏览器 Referer），就不能依赖 valid_referers——因为网关转发时通常会清空或覆盖 Referer，且 Referer 本身可伪造、不具身份可信性。真正可靠的方式是：**基于请求头标识 + IP 白名单双重校验**，或更稳妥地**配合网关透传的认证凭证（如自定义 Token 或 JWT）做校验**。
用请求头 + IP 白名单限制网关访问
适用于网关固定出口 IP、且能统一添加可信请求头的场景（例如 Kong、API7、Nginx Ingress Controller 等）。
- 在网关侧配置转发规则，为所有发往静态资源服务的请求添加唯一可信头，例如：
X-Forwarded-By: internal-gateway或X-Auth-Source: app-gateway-v2 - 在 Nginx 的静态资源 location 块中，同时检查该请求头和来源 IP：
示例配置：
location ^~ /static/ {
alias /var/www/static/;
# 只允许来自指定网关 IP 段
allow 10.20.30.0/24;
deny all;
<pre class='brush:php;toolbar:false;'># 同时要求必须携带合法网关标识头
if ($http_x_forwarded_by != "internal-gateway") {
return 403;
}}
⚠️ 注意：if 在 location 中慎用，但此处仅做字符串等值判断，属安全范围；若需更健壮逻辑（如多值匹配），建议改用 map 指令预处理。
用 auth_request 对接网关认证接口
当应用网关已集成统一认证（如 OAuth2 introspect、JWT 校验服务），可让 Nginx 将请求“先送过去验身份”，成功才放行静态资源——这是生产环境推荐做法。
- 在 Nginx 中定义一个内部 location，指向网关提供的鉴权端点（如
/authz/check） - 在静态资源 location 中调用
auth_request，并设置失败响应 - 确保网关返回
200 OK表示授权通过（响应体可为空）
示例配置：
location = /authz/check {
internal;
proxy_pass https://auth-service.internal/oauth2/introspect;
proxy_pass_request_body off;
proxy_set_header Content-Length "";
proxy_set_header X-Forwarded-For $remote_addr;
proxy_set_header Authorization $http_authorization; # 若需透传 Bearer Token
}
<p>location ^~ /protected/ {
alias /var/www/protected-assets/;
auth_request /authz/check;
auth_request_set $auth_status $upstream_status;
error_page 401 403 = @forbidden;
}</p><p>location @forbidden {
return 403 "Access denied: not authorized by gateway";
}补充：禁用 Referer 校验，避免干扰
既然目标是“只认网关”，就应明确关闭基于 Referer 的逻辑，防止误拦截：
- 不要在该 location 中使用
valid_referers - 避免
if ($invalid_referer)类判断 - 若共用全局配置，可用
valid_referers none;主动清空校验，确保 Referer 不参与决策
关键点在于：网关不是“用户来源”，而是“可信代理”。防护逻辑要从「谁在看」转向「谁在转发」，靠可信信道（IP）+ 可信凭证（Header / Token）组合落地。
