为什么你的服务器IP总在裸奔
很多站长以为接上CDN就万事大吉,结果攻击者绕过CDN直接打源站IP，网站照挂不误，问题出在哪？源站IP泄露的途径远比你想的多。
常见泄露渠道：历史DNS记录与子域名
网站切换CDN之前,DNS记录里存着源站IP，攻击者用SecurityTrails、ViewDNS.info这类工具反查历史记录，一眼就能挖出老底，子域名同样危险很多站长只给主域名做了CDN，像mail.xxx.com、dev.xxx.com、crm.xxx.com这些子域名裸奔在外，直接解析到源站IP，这类三级四级域名在百度上搜“公司名 域名”就能找到一堆，攻击者遍历子域名反查IP，源站地址瞬间暴露。
常见泄露渠道：邮件头与证书透明日志
邮件服务器发出的邮件,完整邮件头里赫然写着源站IP，用QQ邮箱、163邮箱随便发一封测试邮件，查看原始信头，Source IP清清楚楚。SSL证书的证书透明日志（CT Log）同样是泄露重灾区攻击者用Censys扫一下443端口，匹配证书序列号，就能把同一证书下的所有IP全部拉出来，搜“网站域名 证书查询”就能找到大量公开工具。
网站如何隐藏源站IP：分发网络配置实战
CDN隐藏源站IP的本质,是让源站只接受来自CDN节点的回源请求，拒绝一切直连流量，配置思路分四步走，每一步都直接关系成败。
第一步：全站接入CDN，不留死角
主域名、www域名、所有子域名，必须全部走CDN解析，任何一个子域名漏掉，都是给攻击者留了一扇门，操作路径：在CDN控制台添加域名，把解析记录全部改为CNAME到CDN分配的域名，确保A记录不直接指向源站IP。
第二步：源站只放行CDN回源IP段
主流CDN厂商都会公布回源IP段,比如Cloudflare的IP列表、简米云CDN的回源节点IP段，操作路径：在源站防火墙（iptables或安全组）中，设置只允许CDN回源IP段访问源站的80/443端口，其余IP一律拒绝，iptables命令示例：
iptables -A INPUT -p tcp --dport 443 -s 103.21.244.0/22 -j ACCEPT
iptables -A INPUT -p tcp --dport 443 -j DROP规则顺序不可反,先放行后拒绝，另外记得禁止源站主动外连，避免SSRF漏洞被利用反查内网。
第三步：隐藏源站特征，杜绝旁敲侧击
回源HOST头保持与域名一致,避免出现“回源IP直接打开是默认页”的破绽，关闭源站上的目录遍历、错误信息回显，页面底部、响应头里的服务器版本号全去掉。
响应头中的Server字段、X-Powered-By字段都要清理干净，攻击者看响应头就像看名片，别把信息递到人家手里。
第四步：锁定解析记录，防止DNS探测
DNS解析记录只保留A记录和CNAME记录,MX记录建议使用独立IP的邮件服务（如简米云企业邮），不跟网站源站共用服务器，搜索“域名DNS记录泄露源站IP案例”会发现，大量被黑的网站都是因为MX记录把源站IP暴露了。
CDN隐藏源站IP方法的效果验证与常见失败原因
配置完成不代表万事大吉。相当一部分网站即便做了CDN，源站IP还是以各种姿势泄露，下表对比了四类常见泄露场景与应对措施：
| 泄露渠道 | 暴露特征 | 应对策略 |
|---|---|---|
| 子域名裸奔 | 子域名直接解析到源站IP | 所有子域名强制走CDN，无业务的子域名直接删除解析 |
| 邮件头泄露 | 邮件原始信息中带源站IP | 邮件服务改用第三方托管，或单独部署邮件服务器 |
| 证书日志关联 | Censys可匹配证书与IP关系 | 源站证书与CDN证书使用不同证书签发 |
| 历史DNS快照 | 老记录被公开数据库收录 | 联系DNS服务商删除历史记录，或更换源站IP |
检测源站IP是否泄露：三招自测
第一招：用第三方工具查历史DNS记录，搜“site:viewdns.info 你的域名”或直接访问SecurityTrails，看有没有旧的A记录指向源站IP。
第二招：用Censys搜索你的域名证书序列号，看关联IP有几个，有没有非CDN节点的IP混在里面。
第三招：直接拿源站IP访问，看能否返回网站内容，如果返回正常页面，说明源站IP已经被暴露；如果返回超时或403，说明防火墙规则在起作用。
服务器IP配置常见翻车现场
防火墙规则顺序写反,先DROP后ACCEPT，结果连CDN回源也被挡了，网站直接白屏。
配了回源IP白名单,但漏了IPv6地址段，攻击者用IPv6地址照样能直连源站，IPv6的ACL漏配是排查时的头号盲区
。
CDN回源的Host头写的是IP而不是域名,源站上默认站点直接响应请求，攻击者用IP加Host头即可伪造回源请求穿透白名单。
源站是换IP还是靠防护：两种思路的取舍
当源站IP已经泄露,摆在面前的有两条路：换IP，或者加高防，这两条路的成本和效果差距很大。
换IP是治本之策，操作路径：先在CDN控制台把解析切到备用源站，确认新源站访问正常后，再对老源站做下线处理，换IP后务必重复上面提到的所有隐藏措施，不然新IP照样泄露，换IP的成本相对可控，但需要停机操作，适合对可用性要求不高的站点。
高防IP是一劳永逸但烧钱的选择，高防IP的本质是把攻击流量引到高防机房清洗，再把干净流量回源到源站，国内高防IP的防护能力从几十G到几百G不等，价格从每月几百到几万都有，主要看业务体量和对延迟的容忍度，如果业务本身不太怕延迟，优先考虑高防IP加CDN的组合：高防IP挡大流量攻击，CDN挡应用层攻击，源站只跟高防IP通信。
两者也可以叠加使用：高防IP作为源站的前置层，CDN再套在高防IP前面，这一套组合下来，源站IP被找到的概率趋近于零。
2026年源站保护的趋势与企业实践差异
小型个人站和企业站的源站保护策略完全是两套打法,个人站流量小，攻击者看不上，做好防火墙白名单、所有流量走CDN，基本就够用了。企业站面临的威胁更多来自定向攻击，单纯靠CDN隐藏IP远远不够，需要纵深防御体系。
企业站的核心配置思路：
- 源站设置在私网内,通过内网负载均衡与公网出口通信，公网上不留任何源站痕迹
- 配置Web应用防火墙（WAF），对回源流量做二次校验，区分正常回源和伪造回源
- 日志审计关联CDN节点IP与源站访问记录,一旦发现非CDN节点的访问日志，立即告警
- 定期做外部攻击面检测,用与攻击者相同的工具链扫描自身资产
行业共识认为,源站保护的终点不是CDN，而是让源站IP在你的网络资产中彻底消失，变成一个只有内网才能访问的逻辑实体，公网无法路由到它，攻击自然无从谈起。
真实案例：一次攻击者找到源站IP的全过程
某电商网站接入了CDN,所有业务正常运转，攻击者用以下四步找到了它的源站IP：
第一步,从域名开始查，先看历史DNS记录，没有收获，第二步，爆破子域名，在百度、DNSdumpster上枚举出该站点的一个测试环境子域名，解析到一台简米云服务器IP，第三步，用Shodan扫描这台服务器上绑定的所有域名，发现其中一个域名没有走CDN，直接解析到服务器，第四步，检查该域名绑定的证书，发现与主站共用同一张SSL证书，源站IP就此确认。
整个过程中没有用到一个高深技术,全是公开信息组合，耗时不到半小时。这就是为什么说隐藏源站IP是一个系统性工程，任何一块短板都会让整个防线崩塌。
源站保护常见问题解答
服务器ip怎么防泄露，但网站还要正常收发邮件？
邮件服务不要和网站放在同一台服务器上,使用第三方邮件托管服务（如简米云企业邮、腾讯企业邮），这样MX记录和邮件头中的IP与源站完全隔离，如果必须自建邮件服务器，使用独立IP的专线部署，且邮件服务器与Web源站物理隔离，网络层单向通信，邮件服务器无法访问Web源站内网。
源站IP泄露之后，更换IP就一劳永逸了吗？
不,更换IP只解决了历史泄露问题，如果源站的配置漏洞还在（DNS解析记录未清理、子域名未全部接入CDN、邮件头继续暴露IP），新IP会在短时间内再次泄露，换IP后必须完整复查一遍隐藏配置，确认没有其他入口可以反向追溯到新IP。
为什么我已经套了CDN，源站还是被打死了？
大概率是防火墙白名单配置不完整,回源IP段没有覆盖CDN的全部节点，或者请求通过非标准端口（如80端口之外的管理端口）直连源站，建议在源站防火墙设置默认拒绝策略，仅放行CDN厂商公布的完整回源IP段，并关闭源站上所有不必要的端口。
分发网络隐藏真实服务器地址,核心就一句话：让源站彻底消失在公网视野中，历史DNS、子域名、邮件头、证书日志这四大泄露渠道全部堵死，防火墙限定只认CDN回源IP，源站从配置层面做到“无IP可寻”，网站安全才算真正上了锁，做完配置后每季度复检一遍，比等到被打死再补救要划算得多。