核心是确认访问控制作用于真实用户IP而非CDN节点IP：先查日志验证$remote_addr是否为CDN段，再配set_real_ip_from与real_ip_header还原真实IP，最后用map提取并校验$HTTP_X_FORWARDED_FOR，叠加iptables限制回源IP段防绕过。
排查 Nginx 中 IP 访问控制与 CDN 边缘节点源 IP 冲突问题，核心不是检查规则写得对不对，而是确认 访问控制真正作用在哪个 IP 上——它大概率不是用户真实 IP，而是 CDN 节点的回源地址。一旦这个前提错，所有 allow/deny 都形同虚设。
第一步：确认日志里记录的是谁的 IP
Nginx 默认用 $remote_addr 记录建立 TCP 连接的客户端，CDN 接入后它永远是 EdgeOne、Cloudflare 或阿里云节点的内网或公网 IP。先查 access log：
- 如果日志中
$remote_addr大量出现固定几段（如100.64.x.x、173.245.48.0/20），说明你正在对 CDN 节点做访问控制，而非真实用户 - 加一行日志格式临时验证：
log_format debug '$remote_addr - $http_x_forwarded_for - $http_x_real_ip';，再看实际头里有没有传真实 IP - EdgeOne 默认只带
X-Forwarded-For，且值就是用户真实 IP（不追加自身节点）；Cloudflare 则用CF-Connecting-IP，需单独配置识别
第二步：检查 realip 模块是否已“授信”并生效
光有请求头不够，Nginx 必须被明确告知：哪些上游 IP 是可信代理，可以放心用它们传来的头替换 $remote_addr。
- 在
http块开头配置腾讯云 EdgeOne 可信段：set_real_ip_from 100.64.0.0/10;（CGNAT 段）、set_real_ip_from 129.226.0.0/16;（EdgeOne 官方回源段，以控制台文档为准） - 指定头字段：
real_ip_header X-Forwarded-For;（EdgeOne）或real_ip_header CF-Connecting-IP;（Cloudflare） - 加完后重启 Nginx，再 curl 测试：
curl -H "X-Forwarded-For: 1.2.3.4" http://your.site，观察日志中$remote_addr是否变成1.2.3.4
第三步：验证访问控制是否真在用真实 IP 判断
即使 realip 生效，allow/deny 指令默认仍作用于 $remote_addr。但如果你用了 map 提取真实 IP，就得确保策略调用的是那个变量。
- 不要写：
deny 192.168.1.100;—— 这个 IP 是用户还是 CDN 节点？不确定 - 推荐做法：先用 map 提取可信客户端 IP：
map $http_x_forwarded_for $client_real_ip {<br> ~^(\d{1,3}\.\d{1,3}\.\d{1,3}\.\d{1,3})$ $1;<br> default $remote_addr;<br>}
再在 location 中使用：allow $client_real_ip;或配合限流：limit_req zone=perip burst=5 nodelay; - 特别注意：若未配置
set_real_ip_from，$client_real_ip可能被恶意伪造，必须搭配白名单才安全
第四步：拦截非法回源请求，避免控制逻辑被绕过
攻击者可能直接模拟 CDN 头发起请求，绕过你的地理围栏或白名单。不能只信头，还要叠加校验。
- 限制回源来源 IP：用 iptables/nftables 只放行 CDN 官方 IP 段访问 80/443 端口，其他一律 DROP
- 校验 Host 头是否匹配预期回源域名（如
origin.example.com），不匹配则return 444; - 若 CDN 支持签名头（如
X-Edge-Sign），用 map + if 做初步过滤，再交由后端服务验签
