nginx访问控制规则需通过curl测试并结合日志验证：先nginx -t检查语法、nginx -s reload平滑重载，再用允许/拒绝ip分别请求，观察200或403状态码；同时tail -f error.log | grep "403"确认拦截记录，并排查allow/deny位置、顺序及网段格式等常见失效原因。
直接用 curl 或浏览器发起请求，是最简单有效的测试方式。关键不是“怎么测”，而是“测什么”和“怎么看结果”。
确认配置已生效并重载
修改 nginx.conf 或 server 块后，必须执行重载操作，否则新规则不生效：
-
检查语法是否正确：运行
nginx -t，输出 “syntax is ok” 和 “test is successful” 才算通过 -
平滑重载配置：运行
nginx -s reload（不要用 restart，避免服务中断） -
验证进程未重启：执行
ps -eo pid,comm,args | grep nginx，主进程 PID 不变说明是 reload 而非 restart
按规则逐条验证访问行为
测试核心是模拟不同来源 IP 的请求，观察返回状态码（主要是 200 或 403）：
-
允许的 IP 访问：在被允许的机器上执行
curl -I http://your-domain-or-ip:port/，应返回HTTP/1.1 200 OK -
明确拒绝的 IP：从被 deny 的设备（如同事电脑）发起相同请求，应返回
HTTP/1.1 403 Forbidden - 兜底规则验证：换一台不在 allow 列表里的设备（如手机热点、云服务器）访问，也应返回 403
-
注意代理干扰：若 Nginx 前有 CDN 或负载均衡，
$remote_addr可能是代理 IP，此时需配合$http_x_forwarded_for或使用geo模块做真实 IP 判断
借助工具批量验证与日志定位
单次 curl 只能验证一个点，复杂场景建议结合日志和压测工具交叉验证：
-
实时查看拒绝记录：执行
tail -f /var/log/nginx/error.log | grep "403"，发起被拒请求时，会看到类似access forbidden by rule的提示 -
用 ab 模拟并发访问：安装
httpd-tools后，运行ab -n 10 -c 5 http://192.168.10.5:18072/，可快速验证多请求下规则是否稳定生效 -
对比配置前后日志：在修改前开启
access_log，记录原始访问 IP；改完后再比对，确认哪些 IP 被拦截、哪些放行
常见失效原因排查
测试失败时，90% 是配置位置或顺序问题，而非功能本身：
-
指令写错层级：
allow/deny必须放在http、server或location块内，不能写在upstream或注释里 -
顺序颠倒：如果先写
deny all;再写allow xxx;，后者永远不生效——Nginx 匹配到第一条就终止 -
网段格式错误：
192.168.1.0/24正确，192.168.1.0/255.255.255.0或192.168.1.*无效 -
IPv6 未覆盖：若客户端走 IPv6，而配置只写了 IPv4 规则，需额外加
allow 2001:db8::/32;类似语句
