精准放行运维内网网段需在location或server块中按序配置allow指令并以deny all结尾，代理环境下须通过set_real_ip_from和real_ip_header还原真实IP，推荐用geo+include方式提升可维护性。
要精准放行特定运维内网网段，核心是用 allow 指令配合严格顺序和真实 IP 识别机制，不能只写几行规则就完事——顺序错、IP 拿不准、作用域不对，都会导致白名单失效。
必须放在 location 或 server 块内
allow/deny 只在 http、server、location 块中生效。常见错误是写在 upstream、events 或 if 块里，Nginx 直接忽略或报错。
- 正确位置示例：
location /admin/ { allow 10.20.0.0/16; deny all; } - 不能写成：
if ($uri = "/admin/") { allow 10.20.0.0/16; }—— 语法合法但不生效 - 若管理路径分散（如
/api/v1/health、/ops/），每个对应 location 都需单独配置
按顺序写 allow，末尾必须加 deny all
规则按自上而下匹配，首个命中即终止。白名单逻辑是“只放行列出的，其余一律拒绝”，所以 deny all 是安全底线，缺了就等于没控制。
- 先写所有
allow行，每行一个网段或 IP，支持 IPv4 和 IPv6 混用 - 例如运维网段为
10.20.0.0/16、172.16.100.0/24、跳板机 IP192.168.5.10：
location /admin/ {
allow 10.20.0.0/16;
allow 172.16.100.0/24;
allow 192.168.5.10;
deny all;
}
- 严禁颠倒：不能先写
deny all再写allow，否则后面全被拦掉 - 也不可漏掉
deny all，否则未列明的 IP 默认放行
代理环境下必须还原真实客户端 IP
如果前端有 CDN、SLB 或 Traefik，$remote_addr 是代理节点 IP，不是运维人员真实出口 IP，直接 allow 会完全失准。
- 确认上游透传了
X-Real-IP或X-Forwarded-For头，且该头可信（已在代理层清洗） - 在
http块开头添加：
set_real_ip_from 203.208.60.0/24; # 填你所用 CDN 的真实 IP 段
set_real_ip_from 100.64.0.0/10; # 若用阿里云 SLB，填其回源网段
real_ip_header X-Real-IP;
- 之后
allow才真正基于用户原始 IP 判断 - 漏掉
set_real_ip_from，哪怕写了real_ip_header也无效
提升可维护性：用 geo + include 管理多网段
当运维网段较多、或需分环境（测试/生产）差异化放行时，硬编码在 location 里难审计、易出错。
- 新建文件
/etc/nginx/conf.d/ops-whitelist.conf，内容为：
geo $ops_ip {
default 0;
10.20.0.0/16 1;
172.16.100.0/24 1;
2001:db8:abcd::/48 1;
}
- 在对应 location 中引用：
location /admin/ {
if ($ops_ip = 0) { return 403; }
}
- 修改网段只需改 conf 文件，reload 即生效；支持 Git 版本管理与灰度验证
- 比纯 allow/deny 更灵活，也避免因顺序问题引发误拦
