必须先还原真实ip再控制：在http块用set_real_ip_from指定cdn可信ip段、real_ip_header设为x-forwarded-for并开启real_ip_recursive，使$remote_addr变为用户真实ip，之后allow/deny、limit_conn等指令才有效且不误伤。
直接用 allow/deny 按 $remote_addr 限制，CDN 环境下必然误伤——因为这时的 $remote_addr 是 CDN 节点 IP，不是用户真实 IP。核心解法只有一个：先还原真实 IP，再基于它做控制。
第一步：正确获取用户真实 IP
CDN 或代理会把原始用户 IP 写在请求头里（常见为 X-Forwarded-For 或 X-Real-IP），Nginx 默认不信任这些头，必须显式声明哪些来源可信，才能覆盖 $remote_addr：
- 在
http块中添加可信 CDN 节点网段，例如 Cloudflare、阿里云 CDN、360 网站卫士等官方公布的 IP 段 - 指定真实 IP 来源头字段，如
real_ip_header X-Forwarded-For; - 开启递归解析（
real_ip_recursive on;），确保多层代理时取最左边的有效 IP
配置示例：
http {
# 填入你所用 CDN 官方公布的全部可信 IP 段（不可写 0.0.0.0/0！）
set_real_ip_from 103.21.244.0/22;
set_real_ip_from 103.22.200.0/22;
set_real_ip_from 103.31.4.0/22;
# ... 其他 Cloudflare IP 段（务必查最新文档补全）
<pre class="brush:php;toolbar:false;">real_ip_header X-Forwarded-For;
real_ip_recursive on;}
第二步：用真实 IP 替代 remote_addr 做访问控制
还原后，$remote_addr 就是用户真实 IP，所有基于它的指令（allow/deny、limit_conn、limit_req）就自然生效了：
- 白名单控制：在
location中写allow 203.123.45.67; deny all;，此时拦的是真实访客，不是 CDN 节点 - 限流限连：用
$binary_remote_addr作为limit_conn_zone和limit_req_zone的 key，压测或爬虫就再也绕不开真实 IP 限制 - 日志记录：确保
log_format中记录的是$remote_addr，监控和封禁才有依据
第三步：防兜底失效与配置陷阱
即使做了前两步，仍可能因细节翻车：
-
顺序不能错：所有
allow/deny必须按“先 allow，后 deny all”排列；若deny all在最前，所有请求立刻被拒 -
避免伪造头绕过：仅靠
X-Forwarded-For不安全，CDN 必须配置为“只透传、不开放伪造”，且 Nginx 的set_real_ip_from必须精准匹配 CDN 出口 IP，否则攻击者可伪造头绕过 -
内网穿透场景要单独处理：如果服务同时接受直连（无 CDN）和 CDN 流量，需用
map判断请求来源，对直连流量仍用原$remote_addr，对 CDN 流量才走真实 IP 解析
补充：当真实 IP 也不可靠时的备选方案
极端情况（如大规模 CGNAT、恶意代理池），大量用户共享同一出口 IP，仅靠 IP 控制会误伤严重：
- 改用会话标识：如
hash $cookie_session_id或limit_req zone=by_cookie，把控制粒度从 IP 下沉到用户级 - 结合 User-Agent + 请求行为建模：用 OpenResty 或 WAF 做简单规则判断（如高频访问登录页但无 Cookie），不依赖单一 IP 字段
- 关键后台强制二次认证：IP 白名单 +
auth_basic双因子，兼顾灵活性与安全性
