网段写错是IP访问控制失效最隐蔽也最常见的原因，需验证CIDR准确性、配置作用域、真实客户端IP识别及nginx-T展开配置。
网段写错是 IP 访问控制失效最隐蔽也最常见的原因——规则语法没错、位置也没错，但实际放行范围远超预期，甚至把整个公网都放进去了。排查关键不是看“写了什么”，而是验证“实际匹配了什么”。
检查 CIDR 表示法是否准确
CIDR 写错会导致网段大幅扩大或缩小。例如：
- 10.0.0.0/8 是 10.0.0.0–10.255.255.255（整个 A 类私有网段）；误写成 10.0.0.0/16 就只覆盖 10.0.0.0–10.0.255.255，漏掉大量运维主机；
- 192.168.1.0/24 正确；但写成 192.168.1.0/25 只放行 192.168.1.0–192.168.1.127，另一半被 deny all 拦住；
- IPv6 网段如 fd00::/8 是非法写法（ULA 前缀应为 fd00::/7），Nginx 会静默忽略该行，等于没配。
确认配置作用域是否覆盖真实请求路径
allow/deny 只在生效的 location 或 server 块内起作用。常见脱节场景：
- 你在
location /admin/里配了allow 10.20.0.0/16; deny all;，但运维人员访问的是/api/v1/health—— 这个路径没受控，直接放行； - 用了 rewrite 跳转，比如
rewrite ^/ops$ /admin/ last;，但 allow 规则在/admin/块，而 rewrite 后的请求不重新进入该 location 匹配（last 不触发重匹配），导致控制失效； - HTTPS 和 HTTP server 块分离，只在 HTTP 块中配了 allow，但运维走的是 HTTPS，规则完全不生效。
验证真实客户端 IP 是否被正确识别
如果前端有 CDN、SLB 或多层 Nginx，$remote_addr 默认是上一跳代理 IP，不是运维机器出口 IP。此时用 allow 10.20.0.0/16 实际是在放行代理集群地址，而非真实网段。
必须同时满足三项：
- 上游代理正确设置
X-Forwarded-For（如proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;）； - Nginx 配置
set_real_ip_from指定可信代理网段（如set_real_ip_from 10.100.0.0/16;）； - 启用
real_ip_header X-Forwarded-For;并确认解析逻辑符合信任链（如real_ip_recursive on;处理多级头）。
验证方法：在对应 location 中临时加日志：log_format debug '$remote_addr — $http_x_forwarded_for — $realip_remote_addr';，看 $realip_remote_addr 是否为你期望的运维内网 IP。
用 nginx -T 输出完整展开配置并人工核对
nginx -T 会合并所有 include 文件、展开所有变量和嵌套块，输出最终生效的配置。重点检查：
- 目标 location 块中是否确实存在你写的 allow 行，且顺序无误（allow 在 deny all 之前）；
- 有没有其他 location 或 if 块意外覆盖了同一路径（Nginx location 匹配优先级可能绕过你的控制块）；
- 是否存在重复的
deny all或遗漏的deny all（缺了就等于白名单失效）。
