为什么配置了IP白名单还是被访问？五个容易被忽视的排查点

上周我在给客户部署新系统时遇到了一个棘手的问题：明明配置了严格的IP白名单，但日志里还是出现了不明IP的访问记录。作为一个自认为对网络安全还算了解的老手，这个问题让我折腾了大半天。今天就把这次踩坑经历和排查思路分享给大家，希望能帮你少走弯路。

1. 先确认配置真的生效了吗？

说出来你可能不信，我第一个排查的竟然是——我是不是忘记保存配置了？这种事情在凌晨三点赶工的时候特别容易发生。建议先用这个命令快速验证：

# Nginx示例
sudo nginx -t
sudo systemctl reload nginx

更隐蔽的情况是：有些云服务商的控制台需要点两次保存，或者需要等待1-2分钟才能生效。我就遇到过某云平台，界面上显示配置成功了，但实际上后台还在排队处理。

2. 检查配置的作用域

有一次我给站点配置白名单时，自信满满地在location /api块里加了限制，结果发现静态资源还是能被任意访问。原来是因为：

location / {
    # 这里没有限制！
    root /var/www;
}

location /api {
    allow 192.168.1.100;
    deny all;
}

这种作用域问题特别容易出现在复杂的Nginx配置中。我的经验是：配置完成后，一定要用curl测试所有关键路径。

3. 代理层和CDN的坑

现代架构里经常有多层网络组件。比如我们系统前面有Cloudflare，结果白名单配的是客户端的真实IP，而实际上收到的是Cloudflare的IP。正确的做法是：

set_real_ip_from 173.245.48.0/20;
real_ip_header CF-Connecting-IP;

同理，如果你用了ELB、API Gateway等服务，也要注意X-Forwarded-For头的处理。我曾经就因为这个漏掉了AWS的某个IP段，导致白名单形同虚设。

4. 系统防火墙的干扰

应用层的白名单和系统防火墙(iptables/ufw)是两套独立的体系。有一次我明明在Nginx配了白名单，但发现某些IP还是能访问到默认页——原来是服务器防火墙直接放行了80端口。

建议用这个命令双重确认：

sudo iptables -L -n | grep 80
sudo ufw status numbered

5. 最容易被忽视的IPv6

这是我这次踩坑的根本原因！现代服务器默认都启用了IPv6，而我只在配置里限制了IPv4：

allow 203.0.113.45;  # 只限制了IPv4
deny all;

攻击者通过IPv6轻松绕过了限制。正确的做法是：

allow 203.0.113.45;
allow 2001:db8::1;   # IPv6地址
deny all;

或者在确定不用IPv6的情况下，直接禁用IPv6监听更安全。

写在最后

网络安全配置就像打地鼠，你以为堵住了一个洞，往往还有其他漏洞。我的经验是：每次修改配置后，一定要从外网多角度测试，最好写个自动化测试脚本定期验证。如果你们也遇到过类似问题，欢迎在评论区分享你的踩坑经历！