当你的服务器通过CDN对外提供服务时，攻击者最想做的事情就是找到你的源站真实IP。只要拿到了真实IP，就可以直接对源站发起DDoS攻击或漏洞扫描，CDN的所有防护能力瞬间形同虚设。因此，接入CDN只是第一步，能否做到源站IP的绝对隐匿，才是决定安全水位的关键。
CDN隐藏源站IP的工作原理
CDN的本质是一层反向代理。用户访问网站时，DNS会将域名解析到CDN的边缘节点IP，用户的所有请求都先到达距离自己最近的CDN节点。CDN节点判断缓存命中则直接返回内容，缓存未命中时才通过回源链路向源站请求数据，再把结果返回给用户并缓存起来。
在整个链路中，用户只能看到CDN节点的IP，源站IP从不直接暴露在解析记录里。以Cloudflare为例，使用dig命令查询域名时，返回的A记录全部指向Cloudflare的地址段，例如104.16.x.x或172.67.x.x，而真正的源站可能位于任何一个机房。
同时，CDN在安全侧提供了天然缓冲。攻击流量会先打到CDN节点，由CDN的清洗能力进行吸收，只有正常请求才会回源。这就是为什么隐藏源站IP如此重要：它决定了攻击者能否绕过这层防护直接打击源站。理解了这一点，就明白隐藏IP不是可选项，而是CDN防护体系成立的前提。
常见的真实IP泄露途径与排查方法
很多人以为接入了CDN就万事大吉，实际上IP泄露的途径远比想象中多。第一个也是最常见的是历史DNS解析记录。在接入CDN之前，域名可能直接解析到服务器IP，这些记录会被SecurityTrails、ViewDNS等历史记录平台永久保存，攻击者查询历史解析即可拿到你曾经的IP。只要这个IP没有更换，隐匿就无从谈起。
第二个途径是邮件服务器。如果网站直接用本机发送邮件，例如通过PHP的mail函数或本机Postfix，邮件头部的Received字段会包含源站IP。同理，如果在网页上填写了rDNS为服务器IP的信息，或者SSL证书直接部署在源站IP的443端口上，攻击者通过Censys、Shodan等空间测绘引擎搜索证书指纹也能定位到源站。
第三个途径是子域名疏忽。主域名走了CDN，但某些子域名如mail.ippipp.com、test.ippipp.com可能仍然直接解析到源站IP，成为整个防线的突破口。排查方法是枚举所有子域名的解析记录，逐一确认是否经过CDN。可以使用如下脚本快速检查：
# 检查一批子域名是否解析到CDN网段
for sub in www mail api dev test vpn; do
ip=$(dig +short ${sub}.ipipp.com A | tail -n 1)
echo "${sub}.ipipp.com -> ${ip}"
done
# 如果某个子域返回的IP不在CDN地址段内，就是泄露点此外，还有应用层的泄露：phpinfo页面、错误调试信息、网站程序主动上报的服务器信息、云服务商的元数据接口误暴露等。建议定期在Censys和Shodan上搜索自己的域名和证书指纹，确认源站是否已经被空间测绘引擎收录。
实现源站IP绝对隐匿的实战配置
第一步，处理存量泄露。检查域名的历史DNS记录，如果接入CDN之前的解析记录指向当前服务器IP，最彻底的方案是更换源站IP，把旧IP完全废弃。如果更换成本高，至少要通过防火墙限制旧IP只接受可信来源的访问。
第二步，防火墙只放行CDN回源网段。这是最关键的一道硬防线，即使攻击者知道了源站IP，直接发起的连接也会被防火墙丢弃。以Nginx所在服务器为例，可以先用应用层方式限制：
# 只允许CDN回源，拒绝其他直连 # 以Cloudflare为例，放行其回源网段 allow 173.245.48.0/20; allow 103.21.244.0/22; allow 104.16.0.0/13; allow 172.64.0.0/13; allow 131.0.72.0/22; deny all;
更严格的做法是在系统防火墙层面限制80和443端口只接受CDN网段访问，例如使用iptables：
# 仅允许CDN网段访问Web端口 iptables -A INPUT -p tcp --dport 443 -s 173.245.48.0/20 -j ACCEPT iptables -A INPUT -p tcp --dport 80 -s 173.245.48.0/20 -j ACCEPT iptables -A INPUT -p tcp --dport 443 -j DROP iptables -A INPUT -p tcp --dport 80 -j DROP
第三步，封堵邮件和证书泄露路径。邮件服务不要部署在源站上，改用第三方邮件服务商如企业邮箱API发送，让邮件头部携带的是服务商的IP而非源站。SSL证书方面，让CDN以全代理模式托管证书，源站使用仅限回源链路使用的证书，且绝不要把同一张证书部署到直接暴露在公网的IP上，避免证书指纹被Censys检索到。
第四步，规范DNS和子域名管理。所有对外提供服务的域名和子域名都必须接入CDN，不提供服务的解析记录直接删除，不要保留A记录指向源站。SSH、FTP等管理类服务不要使用任何对外解析的域名，管理入口可以通过跳板机或VPN接入，端口尽量改为非默认值，并结合fail2ban防止爆破：
# SSH使用非常规端口并只允许可信IP iptables -A INPUT -p tcp --dport 2222 -s 10.0.0.0/8 -j ACCEPT iptables -A INPUT -p tcp --dport 2222 -j DROP
第五步，做好回源配置的一致性。配置回源Host和回源SNI时，确保与源站虚拟主机配置匹配，否则可能出现回源失败被误判为源站故障。同时在CDN侧开启回源保持长连接和鉴权，防止回源地址被恶意利用。
最后需要建立持续验证机制。安全不是一次配置就结束的，建议每隔一段时间做一次自查：用历史DNS平台查询域名记录、在空间测绘引擎搜索自己的证书和域名关键字、枚举子域名检查解析指向，确认源站IP没有任何暴露痕迹。只有把接入CDN、防火墙白名单、泄露途径封堵和定期审计形成闭环，才能真正实现源站IP的绝对隐匿。