Nginx IP访问控制规则以最后一条匹配成功的指令为准，非“先写先匹配”；需确保allow/deny置于server或location块内，正确配置real_ip识别真实客户端IP，并避免satisfy any导致绕过。
IP 访问控制规则顺序写错，不是语法错误，nginx -t 不会报错，但策略完全不生效——比如写了 allow 192.168.1.100; 却仍被 deny all; 拦住，或本该拦截的 IP 反而放行。问题核心在于 Nginx 不按“先写先匹配”执行，而是以最后一条匹配成功的指令为准。
看 location 内 allow/deny 的实际执行顺序
在同一个 location 块中，所有 allow 和 deny 指令按配置文件中的书写顺序逐条判断，但最终起作用的是最后一条匹配成功的规则，不是第一条。
- 例如这段配置实际效果是全部拒绝：
location / {
deny 192.168.1.100;
allow 192.168.1.0/24;
deny all;
}
Linux Security Scanner
下载
Linux 安全审计工具，检查 SSH 配置、开放/监听端口、防火墙规则（ufw/iptables/nftables）、失败登录尝试、sudoers 权限...
- 因为
deny all匹配所有请求，且写在最后，它覆盖了前面所有规则 - 正确写法应把
deny all当作兜底项，放在所有allow之后、无其他 deny 干扰的位置
检查规则是否落在正确的配置块层级
allow/deny 必须写在 server 或 location 块内，不能放在 http 块顶层，否则会报 directive is not allowed here 错误（注意：这不是 IP 无效，而是位置错）。
- 用
nginx -t检查时，如果报这个错，说明规则没生效，但错误提示和 IP 本身无关 - 常见误写：把白名单直接写在
http { ... }里，而不是嵌套进某个server或location - 多 server 共享规则时，不能靠继承，必须显式 include 或重复写入每个需要管控的块
验证真实客户端 IP 是否被正确识别
即使规则顺序正确，如果 $remote_addr 是代理内网地址（如 10.0.0.2），而不是用户真实出口 IP，那所有 allow/deny 都作用在错误的地址上。
- 在目标 location 中临时加日志：
access_log /var/log/nginx/access_realip.log main;，并在 log_format 中加入$http_x_forwarded_for $remote_addr - 访问后查看日志：若
$remote_addr始终是固定内网 IP，而$http_x_forwarded_for有变化，说明没启用real_ip指令 - 补全配置：
set_real_ip_from 10.0.0.0/8;+real_ip_header X-Forwarded-For;（根据实际代理段调整）
排除 satisfy any 等指令干扰
如果 location 中启用了 satisfy any;，并搭配了 auth_basic 或 auth_request，那么只要任一条件满足（比如密码正确），IP 限制就会被绕过。
- 检查是否有类似配置：
satisfy any;、allow和auth_basic同时存在 - 这种组合下，IP 白名单形同虚设——用户输对密码就能进，无需满足 allow 条件
- 如需双重校验，改用
satisfy all;，并确保所有条件都必须满足
