Nginx中IP白名单需将allow置于deny all之前，支持CIDR和域名（不推荐）；Apache 2.4+用Require ip配合Require all denied，且须启用mod_authz_host；失效常见原因包括配置未重载、反向代理未设real_ip、规则被其他块覆盖。

nginx 里用 allow/deny 实现 IP 白名单

直接在 location 或 server 块里写 allow 和 deny 是最常用方式，但顺序不能错——nginx 按配置顺序匹配，遇到第一个匹配就停止。常见错误是把 deny all 写在前面，结果所有请求都被拦了。

• allow 必须写在 deny all 之前，否则白名单无效
• 支持 CIDR 格式，比如 allow 192.168.1.0/24，也支持域名（但不推荐，DNS 解析失败会导致拒绝）
• 如果用了 real_ip_header（比如前端有 CDN 或 LB），得配合 set_real_ip_from，否则 $remote_addr 不是你想要的客户端 IP
• 示例：

  location /admin {<br>    allow 203.0.113.5;<br>    allow 2001:db8::/32;<br>    deny all;<br>}

Apache 的 Require ip 白名单配置

Apache 2.4+ 用 Require 指令替代老版本的 Order/Allow/Deny，语法更直白，但必须确保 mod_authz_host 已启用，否则会报 Invalid command 'Require' 错误。

• 白名单写法是 Require ip 192.0.2.10 或 Require ip 192.0.2.0/24，IPv6 同理
• 多个 IP 要写多行 Require，不是用空格或逗号分隔
• 必须搭配 Require all denied 放在最后，否则默认放行（这是最容易漏的一步）
• 若目录下有 .htaccess，且 AllowOverride 没开 AuthConfig，Require 不生效

为什么加了白名单还是能访问？查这三处

白名单失效往往不是语法错，而是环境链路干扰。重点看这三个位置是否绕过了你的规则：

Apache Superset Dashboard and SQL Exploration Skill

Apache Superset 是一个广泛采用的开源 BI 平台，用于 SQL 探索、图表构建和仪表板交付。当代理需要查询仓库数据、组装仪表板或使用成熟的分析界面解释指标而不是临时笔记本代码时，此技能非常有用。

下载

• Nginx/Apache 配置是否加载成功？运行 nginx -t 或 apachectl configtest 确认，别只改了文件没重载
• 前端有没有反向代理（如 Cloudflare、SLB）？它们会把真实 IP 变成代理 IP，需在 Nginx 加 set_real_ip_from + real_ip_header X-Forwarded-For，Apache 则要启用 mod_remoteip
• 有没有其他 location/server 块覆盖了你的规则？比如泛域名 server 块里写了 deny all，而你的白名单在子 location 里，可能根本没走到

限制 API 接口时，别只靠 IP 白名单

IP 白名单对内部系统调用有用，但对公网 API 来说，它既不安全也不可靠——IP 可伪造、可变动、NAT 后还共享。真要控访问，得叠加其他手段。

• 单靠 allow 或 Require ip 拦不住恶意扫描或代理池请求
• 如果后端是 Node.js/Python，建议在应用层校验 token 或签名，IP 只作辅助（比如限流按 IP 分组）
• 云厂商 WAF（如阿里云、Cloudflare）支持更细粒度的 IP+路径+Header 组合策略，比 Web 服务器原生命令灵活得多
• 临时调试时，可用 curl -H "X-Real-IP: 203.0.113.5" 模拟，但生产环境绝不能依赖这种 Header

实际配完白名单，记得用不在名单里的 IP 真实测一次 403 响应，别只信日志里的“access denied”。很多问题出在测试方式本身——比如本地 hosts 绑定、浏览器缓存 301、甚至公司出口 NAT 把你的真实 IP 隐藏了。