源站暴露风险自查,核心就三件事:找出真实IP、堵住泄露通道、建立持续监控机制。如果你只做CDN却不管源站IP,攻击者绕过高防直接打源站,防护形同虚设,下面这份自查清单,按优先级排列,每一项都有对应的操作路径。
源站暴露风险自查清单:从DNS历史记录开始
DNS历史记录是泄露源站IP最隐蔽的通道,很多站长换CDN后忘了清理旧解析记录,攻击者用在线工具一查就能挖出真实IP。
检查DNS历史解析记录
- 用ViewDNS.info或SecurityTrails查询域名历史A记录
- 重点看接入CDN之前的解析记录,那会儿暴露的就是源站IP
- 检查子域名的历史解析,比如
test.xxx.com、dev.xxx.com这类经常被忽略的条目
如果发现历史记录里有非CDN节点的IP,且该IP还开着80/443端口,基本可以判定源站已暴露。
检查子域名是否有独立解析
子域名是另一个重灾区,很多站点只给主域名套CDN,子域名直接解析到源站。
- 用subfinder或OneForAll做子域名枚举
- 筛选出解析到非CDN段IP的子域名
- 检查这些子域名是否指向同一台服务器
行业共识认为,子域名泄露导致的源站暴露占比相当大,建议把所有子域名统一收口到CDN或WAF后面,内网服务用内网DNS解析。
证书透明度日志里的源站线索
证书透明度(CT日志)是公开的,任何人可以搜索你的域名证书,如果证书信息里包含源站IP或内部主机名,等于给攻击者递刀。
自查SSL证书签发记录
- 去crt.sh搜索你的域名
- 查看证书的Subject Alternative Name字段
- 留意是否有
.internal、server1这类条目
如果你用的是云服务器,有些证书申请工具会默认把服务器的私有IP或内网主机名写进去,发现问题后,重新签发证书,确保证书字段里不出现任何非公网信息。
检查证书指纹是否关联到源站
- 用Censys或Shodan搜索你的证书指纹
- 看搜索结果里是否关联到CDN节点以外的IP
- 如果关联到某个数据中心IP段,且该IP不在CDN厂商的ASN里,就说明源站暴露了

遇到这种情况,需要更换源站IP并重新签发证书,换IP后,记得把旧的SSL配置从服务器上彻底移除。
网站源站IP隐藏方法对比:从配置到运维
自查发现问题后,怎么修复?不同场景下隐藏源站IP的手段差异挺大,这里做个对比。
CDN配置不当导致的泄露
- 回源方式:如果使用IP回源,CDN后台会存你的源站IP,有权限的人能看到
- 建议改用域名回源,并配置回源HOST校验
- 查看CDN日志里的回源记录,确认没有在响应头里暴露真实IP
很多CDN默认在回源时请求头会带上X-Forwarded-For,源站如果把该头直接输出到响应里,访问一次就能看到源站IP,在源站Nginx或Apache里过滤掉这个头,或者让CDN改成X-Real-IP。
邮件头与第三方服务泄露
- 用你的域名注册一个邮箱,发送测试邮件,查看原始邮件头
- 如果邮件头的
Received字段出现非CDN的IP,说明邮件服务器直接暴露了源站IP - 检查网站是否接入了第三方API回调用(比如支付回调、短信通知),回显的IP有时就是源站
修正方法是:邮件服务单独用企业邮局,不跟源站共用一个IP;API回调全部走CDN或专用网关。
主机访问控制与安全组加固
- 在云控制台的安全组里,只放行CDN节点的IP段
- 限制SSH、数据库等管理端口的来源IP,源站IP即使是暴露的,也打不进来
- Linux服务器用iptables或firewalld做同样限制,双保险
这里有个实用技巧:从CDN日志里提取访问源站的节点IP列表,然后用脚本批量导入安全组白名单,即使源站IP泄露,外部流量对源站来说也是不可达的。
源站暴露风险自测方法:用攻击者视角验证

工具检测只能发现问题,最终要站在攻击者角度验证防护是否生效,以下操作步骤可以直接复现。
绕过CDN查找真实IP的常见测试
- 用
fofa或zoomeye搜索你的网站特征,比如页面标题、favicon.ico的哈希值 - 遍历常见子域名,批量请求后分析HTTP响应头里的Server字段
- 利用DNS历史记录里的旧IP,直接访问该IP的80/443端口,看是否返回你的网站
如果以上任一步骤得到源站IP,说明当前防护是失效的,别慌,再补一轮安全组白名单和CDN配置。
验证防护是否生效的具体操作
- 用
curl -I https://你的域名检查响应头,确认Via或X-Cache字段有CDN标识 - 用
ping或nslookup确认域名解析结果全部指向CDN节点 - 直接访问刚才挖到的源站IP,如果超时或返回403,说明安全组白名单生效了
建议每月做一次这样的自测,每次做要留下记录,网站架构调整后(比如换服务器、换CDN服务商),立刻重复一遍。
持续监控:让暴露风险无处遁形
自测是点状的,持续监控才能覆盖变化,免费方案搭配付费方案,基本够用。
- 把源站IP加进简米云云监控或酷番云拨测,定期检查端口连通性
- 用Github的代码扫描功能,防止开发人员把源站IP提交到公开仓库
- 在CDN控制台开启日志分析,定期筛查异常的回源请求
据工信部网络安全威胁信息共享平台的数据,源站暴露是Web类攻击成功的主要前置条件之一,别把自查当一次性任务,建议每季度做一次全面排查。
源站暴露风险排查经常漏掉的三个细节
除了上面提到的,还有几个容易忽略的点,虽然不直接影响判断,但关键时刻能救命。
ICP备案信息里的IP地址
国内网站必须备案,备案系统里登记的接入IP如果就是源站IP,且未及时更新,任何查询备案信息的人都能看到,工信部备案系统目前不直接公开IP,但第三方接口可能泄露,去

www.beianx.cn这类平台查一下,如果显示了旧IP,立刻联系接入商更新。
邮件退信与自动回复内容
发邮件到不存在的邮箱地址,退信内容里可能包含源站邮件服务器的IP,公众号或官网的联系邮箱如果绑定在源站上,攻击者发一篇退信过来就能拿到线索,把企业邮箱迁移到专业服务商,或者在MX记录上挂一层反垃圾网关。
代码仓库的.git目录泄露
如果源站根目录下存在.git目录,通过/.git/config就能读取仓库信息,进而用工具还原源码,从中挖掘数据库地址、服务器IP等敏感配置,用WAF规则拦截.git路径,或者直接修改Nginx配置禁止访问点开头的目录。
Q&A:源站暴露风险自查相关常见问题
CDN设置了源站保护,还用担心DNS历史记录吗?
要担心,DNS历史记录属于第三方存档,CDN的源站保护拦不住查询行为,攻击者从历史记录里拿到旧IP后,可以用批量扫描工具检测该IP当前的开放端口,如果源站安全组没有限制只允许CDN访问,旧IP依然可能成为突破口。
更换源站IP后,之前泄露的IP还能被利用吗?
取决于你能否彻底放弃旧IP,如果旧IP仍绑定在同一台服务器上,且安全组未做限制,攻击者直接访问旧IP依然有效,正确做法是:先在新IP上完成数据迁移和配置,再将旧IP解绑销毁,并在路由器或云控制台上彻底删除该IP的映射关系,之后检查所有DNS记录、证书、邮件头、第三方回调是否已替换为新IP。
小网站直接不用CDN,只靠防火墙能防住源站暴露吗?
不能,防火墙只能过滤已识别的攻击流量,但源站IP一旦暴露,攻击者可以用低频慢速扫描绕过流量特征检测,没有CDN或高防做流量清洗,源站带宽和计算资源会被慢慢耗尽,行业共识是,即使小站点也要至少接入免费CDN,配合安全组白名单,防住绝大多数扫描和探测。