静态资源白名单应在location块内配置，优先使用allow/deny指令按“先放行后拒绝”顺序控制IP访问，需结合realip_module处理代理场景，并通过include抽离IP列表提升可维护性。
静态资源服务（如 CSS、JS、图片等）通常对外公开，但有时也需要限制访问——比如内部管理系统前端资源只允许内网或特定合作伙伴 IP 访问。配置白名单的关键是：不破坏静态资源的高效服务特性，同时精准控制入口。
优先在 location 块中配置，避免影响全局
静态资源一般由独立的 location 处理，例如：
location ~* \.(js|css|png|jpg|gif|ico|svg|woff2?)$ {
root /var/www/static;
expires 1y;
add_header Cache-Control "public, immutable";
}
白名单规则必须嵌入这个 location 块内，而不是写在 server 或 http 层。否则可能误拦健康检查、CDN 回源或监控探针请求。
- 只对静态资源路径生效，不影响 API 或 HTML 主页
- 支持正则匹配扩展名，也支持前缀匹配（如 location /assets/）
- 若用 root 指令，确保 allow/deny 在 root 之后、expires 之前（顺序不影响逻辑，但便于维护）
正确书写 allow/deny 顺序
白名单逻辑是“先放行，后拒绝”。例如只允许运维网段和本地开发机访问：
location ~* \.(js|css|png|jpg)$ {
allow 10.10.0.0/16;
allow 127.0.0.1;
deny all;
root /var/www/static;
try_files $uri =404;
}
- 每条 allow 后不加分号以外的符号（如逗号、空格多余）
- deny all 必须放在所有 allow 之后，且是该 location 中最后一条访问控制指令
- IPv6 同样支持，如 allow 2001:db8::/32;
注意代理环境下的真实 IP 判断
如果静态资源走 CDN 或负载均衡（SLB），$remote_addr 是代理 IP，直接 allow 会失效。需启用 real_ip_module：
set_real_ip_from 10.0.0.10; # CDN 或 SLB 的可信出口 IP
real_ip_header X-Forwarded-For;
# 然后在 location 中使用 $realip_remote_addr 判断（需配合 geo 或 if）
- 仅当 Nginx 编译时含 --with-http_realip_module 才可用
- 不能在 location 内直接写 allow $realip_remote_addr; —— allow 不接受变量
- 推荐方案：用 geo 定义 $is_trusted，再 if ($is_trusted = 0) { return 403; }
提升可维护性：用 include 抽离 IP 列表
当白名单 IP 变多或需跨多个 location 复用时，把规则单独存为文件：
# /etc/nginx/conf.d/static-whitelist.conf
allow 192.168.50.10;
allow 192.168.50.11;
allow 172.16.0.0/12;
deny all;
然后在 location 中引用：
location /static/ {
include /etc/nginx/conf.d/static-whitelist.conf;
alias /var/www/static/;
}
- 修改 IP 列表只需编辑外部文件，无需重载整个配置
- 同一份 whitelist.conf 可被 /admin/js/ 和 /assets/ 共享
- 配合 CI/CD 自动更新该文件，实现白名单动态管理
