很多站长在搭建网站时，源站IP通过各种途径泄露了——DNS历史记录、邮件头信息、SSL证书透明日志、甚至第三方服务回调。一旦源站IP暴露，攻击者可以直接绕过CDN和WAF，直打源站，所有前端防护形同虚设。本文实战讲解：源站IP已经泄露的情况下，如何通过 Cloudflare + 雷池SafeLine WAF 构建双重隐藏防线，彻底切断直连攻击路径。
一、源站IP是怎么暴露的
在动手修复之前，先搞清楚泄露途径，避免修完又漏。
常见泄露渠道：
- DNS历史记录：更换CDN前，A记录直接指向源站IP，历史解析被收录。
- 邮件服务：网站发送的邮件头中包含源站IP（如Postfix默认配置）。
- SSL证书透明日志：源站独立申请过证书，CT日志中留有IP关联记录。
- 第三方服务回调：支付接口、Webhook、API回调暴露了源站地址。
- 子域名/旁站：主站走了CDN，但mail.yourdomain.com、ftp.yourdomain.com仍指向源站IP。
- 扫描器探测：攻击者通过全网段扫描，根据网站特征（如HTTP头、页面内容）反查源站。
二、补救核心思路：切断直连路径
暴露的IP无法"撤回"，但可以让它"失效"——让攻击者拿到IP也打不通。
核心策略：
用户请求
↓
Cloudflare（第一层：隐藏真实IP，提供DDoS防护）
↓
雷池SafeLine WAF中转机（第二层：独立IP，源站IP不对外）
↓
源站服务器（仅允许雷池IP访问，拒绝所有公网直连）关键点：
- 源站IP不再出现在任何公网DNS记录中
- 源站安全组只放行雷池WAF的IP
- 即使攻击者知道源站IP，也无法直连访问
三、第一步：更换源站IP（如果可能）
如果源站IP已经泄露，最彻底的做法是更换IP。
操作步骤：
- 云服务商控制台申请更换公网IP（部分厂商支持免费更换）
- 或者将业务迁移到新实例，旧实例直接释放
- 更换后立即执行后续隐藏措施，避免新IP再次泄露
如果无法更换IP（如固定IP、备案绑定），则严格执行后续防火墙策略，让暴露的IP"看得到，打不到"。
四、第二步：雷池WAF中转机部署
沿用之前的雷池中转架构，但做以下调整：
- 中转机使用全新的、未在任何历史记录中出现过的IP
- 中转机只监听80端口，SSL由Cloudflare处理
- 中转机上游指向源站内网IP或新公网IP
雷池站点配置：
域名：yourdomain.com
监听端口：80（HTTP）
上游服务器：http://源站新IP:80
SSL：关闭
防护模式：观察模式 → 确认无误后切拦截中转机安全组：
端口 来源 说明
80 0.0.0.0/0 业务转发，对外开放
9443 你的办公IP/32 管理后台，严格限制
其余 拒绝 全部关闭
五、第三步：源站防火墙加固（最关键）
源站必须拒绝所有非雷池IP的访问。
Nginx 层限制（推荐）：
server {
listen 80;
server_name yourdomain.com;
# 只允许雷池WAF中转机IP
allow 雷池中转机IP;
deny all;
location / {
proxy_pass http://127.0.0.1:8080; # 你的实际业务端口
}
}安全组/防火墙层：
# 仅允许雷池中转机IP访问80端口
iptables -A INPUT -p tcp --dport 80 -s 雷池中转机IP -j ACCEPT
iptables -A INPUT -p tcp --dport 80 -j DROP
# 443端口完全关闭（SSL在CF终结）
iptables -A INPUT -p tcp --dport 443 -j DROP
# 保存规则
iptables-save > /etc/iptables/rules.v4验证：从其他服务器 curl 源站IP，应该返回 403 或连接超时。
curl -I http://源站IP
# 预期结果：403 Forbidden 或连接失败六、第四步：Cloudflare DNS与SSL配置
DNS记录调整：
A记录：yourdomain.com → 雷池中转机新IP（不要指向源站）SSL/TLS模式：
- 选择「灵活」或「完全」
- 回源使用HTTP 80，不经过443
关键设置：
- 开启"始终使用HTTPS"
- 开启"自动HTTPS重写"
- 安全级别：中等（避免CF WAF与雷池双重拦截）
- 关闭"浏览器完整性检查"（避免与雷池冲突）
七、第五步：消除历史泄露痕迹
-
清理DNS历史记录
- 检查所有子域名解析，确保没有A记录直接指向源站
- 删除不再使用的子域名
-
邮件服务脱敏
- 使用第三方邮件服务（如SendGrid、Amazon SES）发送邮件
- 或配置Postfix隐藏源站IP：
# /etc/postfix/main.cf
smtp_header_checks = regexp:/etc/postfix/header_checks# /etc/postfix/header_checks
/^Received: .*/ IGNORE-
SSL证书处理
- 源站不再独立申请证书
- 所有证书由Cloudflare统一管理
- 如历史证书已泄露，申请新证书后撤销旧证书
-
第三方服务回调地址
- 所有Webhook、API回调指向域名，不要写IP
- 检查支付接口、监控告警、CI/CD等配置
八、第六步：获取真实客户端IP
由于流量经过 Cloudflare → 雷池 → 源站，源站看到的IP是雷池中转机的IP。需要配置Nginx获取真实客户端IP。
雷池侧配置：
- 在雷池后台开启"获取真实IP"
- 填入Cloudflare回源IP段白名单
源站Nginx配置：
# 在http块中定义
set_real_ip_from 雷池中转机IP;
real_ip_header X-Forwarded-For;
real_ip_recursive on;
# 或者使用Cloudflare的CF-Connecting-IP头
set_real_ip_from 173.245.48.0/20;
set_real_ip_from 103.21.244.0/22;
# ... 其他CF IP段
real_ip_header CF-Connecting-IP;Cloudflare完整IP段列表：https://www.cloudflare.com/ips/
九、验证双重隐藏是否生效
测试1：域名访问正常
curl -I https://yourdomain.com
# 预期：200 OK测试2：直连源站IP被拒绝
curl -I http://源站IP
# 预期：403 Forbidden 或连接失败测试3：直连中转机IP（不带Host头）
curl -I http://雷池IP
# 预期：404 或默认页面，不会暴露源站信息测试4：模拟攻击payload
curl "https://yourdomain.com/?id=1'and+1=1--"
# 预期：被雷池拦截，返回403测试5：检查源站日志中的客户端IP
tail -f /var/log/nginx/access.log
# 预期：显示真实用户IP，不是CF节点IP或雷池IP十、常见踩坑
-
源站防火墙规则写反了
- 错误：deny 雷池IP; allow all;
- 正确：allow 雷池IP; deny all;
-
中转机IP也被泄露
- 中转机IP不要在任何公开渠道出现
- 不要在中转机运行邮件服务、爬虫等会暴露IP的服务
-
CF-Connecting-IP未传递
- 雷池必须开启"获取真实IP"并配置CF IP白名单
- 否则雷池会把CF节点IP当成攻击者封禁
-
源站Nginx配置遗漏子域名
- 检查 www、mail、api 等所有子域名的server块
- 每个server块都要加allow/deny限制
-
更换IP后忘记更新雷池上游
- 源站IP变了，雷池上游服务器地址必须同步更新
十一、进阶：三层隐藏架构（高安全需求）
如果安全要求极高，可以再加一层：
用户 → Cloudflare → 雷池WAF → 反向代理层（如Nginx Stream） → 源站
↑
中转机A（公网IP）
↑
中转机B（仅内网IP）- 中转机A：公网IP，跑雷池WAF
- 中转机B：无公网IP，通过内网或专线与中转机A通信
- 源站：仅与中转机B内网互通
这样即使中转机A被攻破，攻击者也无法直接访问源站。
十二、总结
源站IP泄露不是末日，关键是切断"知道IP就能打"的链条。通过 Cloudflare 隐藏第一层、雷池WAF中转第二层、源站防火墙拒绝直连第三层，即使攻击者手握源站IP，也无法绕过防护。
核心 checklist：
- 源站IP已更换或防火墙已严格限制
- DNS所有记录指向中转机，无A记录直连源站
- 邮件、Webhook、证书等无IP泄露
- 雷池获取真实IP已配置
- 源站仅允许雷池IP访问80端口
- 443端口完全关闭
- 验证测试全部通过
这套方案适合已经泄露源站IP、需要紧急加固的站长，也适合新建站点时直接采用，从源头避免IP暴露。
