买了高防和 CDN，攻击者却绕过防护直接打源站，这是 DDoS 防护里最常见的失效场景。原因通常只有一个：没有真正隐藏源站IP。本文用 9 个问答讲清攻击者怎么找到源站 IP、怎么自查是否已经泄露、怎么让源站只接受防护节点回源，以及 IP 已泄露后的处置顺序。
Q：为什么源站 IP 藏不住，高防就白买了？
- 高防和 CDN 的原理都是把攻击流量引到防护节点，清洗后再把干净流量回源。这套机制成立的前提是攻击者只知道防护节点的地址。
- 源站真实 IP 一旦暴露，攻击者就直接绕过防护打源站，防护节点上什么都看不见：
- 源站带宽远小于防护节点，几十 Mbps 的小流量就能把源站打到超时。
- 源站没有清洗能力，攻击包直接进内核，连接跟踪表与半开队列会最先被打满。
- 防护平台的报表干净得像没事发生，日志只看到源站自己被打，排查方向很容易被带偏。
- 所以顺序必须是先藏 IP，再谈防护。隐藏源站 IP 是防 DDoS 的第一道门，门没关，后面的锁都只是装饰。
Q：攻击者一般通过哪些途径找到我的源站 IP？
- 常见的有八类，其中前四类最容易被忽略：
- 历史 DNS 记录：接入高防之前的 A 记录会被第三方站点长期收录，改了解析也删不掉。
- 证书透明度日志：给子域名签发过证书，域名就会出现在公开的 CT 日志里，等于给攻击者一份现成的子域名清单。
- 漏掉的子域名：主域名接了防护，mail、oa、test、dev、api 这些可能还在直接解析源站。
- 邮件服务：MX 记录与发信 IP 常常就在同一台服务器上。
- 第三方回调：支付回调、接口对接、图床或统计脚本里填过源站地址。
- 全网扫描：用全网地址扫描配合 SNI 匹配，拿你的域名去比对哪台服务器在响应。
- 同网段比邻：源站与其它暴露业务在同一 C 段，顺藤摸瓜就能定位。
- 站点自身泄露：探针页面、报错输出、接口响应头、配置文件或源码被下载。
Q：怎么自查我的源站 IP 是不是已经泄露了？
- 要用外部视角查，别拿自己电脑的解析结果下结论：
# 1) 多地公共解析器对照，看是否还能解出源站 IP
for r in 223.5.5.5 119.29.29.29 8.8.8.8 1.1.1.1; do dig +short @$r www.example.com; done
# 2) 裸域名单独查：很多站只给 www 接了防护
dig +short example.com
# 3) 反查这个 IP 上还挂着哪些域名
dig -x 1.2.3.4 +short
# 4) 拿 IP 直连并用 Host 头测试：能返回同一个站点，说明源站没做收口
curl -sI -m 5 -H 'Host: www.example.com' https://1.2.3.4/ | head -3- 再补三个外部视角：在证书透明度查询站搜自己的域名看有哪些子域名签过证书、把子域名枚举结果逐个解析、用空间测绘类搜索引擎搜自己的业务指纹。
- 判断标准很简单：凡是能直接访问到源站业务的地址都算泄露，包括 IP 直连和未接防护的子域名。
Q：哪些记录最容易被漏掉？
- 按「漏掉概率」排序，需要逐个核对：
- 裸域名：只给 www 加了 CNAME，apex 记录还指着源站 IP，这是第一位的高频漏项。
- 邮件相关记录：MX 与 SPF 里出现的 IP 常常就是源站。
- 历史遗留记录：已下线的业务、测试域名、临时上线用的记录没删干净。
- 泛解析：一条通配符记录把所有子域名都指向源站。
- 证书里暴露的子域名：CT 日志列出来的域名，往往你自己都不记得存在。
- 核对命令：把全部子域名拉出来逐个解析，凡是解析结果落在源站 IP 上的，全部纳入整改。
# 批量核对：把子域名清单逐个解析，标记落在源站 IP 上的记录
while read d; do ip=$(dig +short "$d" | tail -1); [ -n "$ip" ] && echo "$d -> $ip"; done < subdomains.txt
# 查 NS 与 MX，确认没有指向自建源站
dig NS example.com +short
dig MX example.com +shortQ：怎么让源站只接受防护节点回源？
- 核心原则是默认拒绝、白名单放行，并且不止在应用层做：
# 应用层（Nginx）：只放行防护节点回源段
server {
allow 203.0.113.0/24; # 高防/CDN 回源段，以服务商提供的最新段为准
allow 10.0.0.0/8;
deny all;
}
# 网络层（iptables）：先放行回源段与已建立连接，再丢弃其余新连接
iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A INPUT -p tcp --dport 443 -s 203.0.113.0/24 -j ACCEPT
iptables -A INPUT -p tcp --dport 443 -j DROP- 三个容易搞错的细节：
- 回源段要以服务商公布的最新清单为准，段位会变动，写死了总有一天会断。
- 健康检查与探针来源也要放行，否则防护平台会判定源站不可用。
- 回源最好走独立端口或内部域名，与公网入口分开，避免被顺带扫出来。
Q：源站 IP 已经泄露了怎么办？
- 按这个顺序处理，先止血再收口：
- 第一步换 IP：这是最快也最彻底的手段，新 IP 直接绑定到防护节点回源，不再对外公开。
- 第二步回源收口：按上面配置只放行防护节点，旧 IP 即使被扫到也连不上。
- 第三步清理痕迹：删掉不再使用的 DNS 记录、把第三方收录的历史记录提交更新、检查邮件与第三方回调里是否还写着旧地址。
- 换 IP 的注意点：提前把 TTL 降到 60 至 300 秒再切，切完同步更新所有白名单与监控目标，避免防护平台因为源站地址没更新而回源失败。
- 提醒一句：换 IP 不是终点。如果泄露原因没堵住，新 IP 一两周后照样会被重新找到。
Q：源站本身还要做哪些加固？
- 藏 IP 解决的是「别被直接找到」，源站自身还要扛得住漏网流量：
- 限流与并发限制：用 limit_req 与 limit_conn 限制单 IP 频率与并发，挡住小规模直连试探。
- 只开必要端口：关掉测试端口、数据库与缓存的公网访问，这些端口一旦暴露比被打更危险。
- 收敛指纹：隐藏版本号、关掉目录列表、清理默认页面与示例文件。
- 备份与快照：确保能在被打挂后快速从快照恢复，而不是等重装。
- 监控出向与连接数：源站被直打时，出向带宽与连接数会先异常，比 CPU 更早给出信号。
Q：预算有限的小站怎么防？
- 小站没必要一步到位，按性价比排优先级：
- 先做零成本的部分：清理多余子域名与历史 DNS 记录、源站只放行回源段、关掉不用的公网端口。
- 再上最小防护：域名接入带清洗能力的防护服务，源站 IP 全程不出现在任何公开渠道。
- 静态资源分离：把图片、样式、脚本放到对象存储或 CDN，源站只留动态请求，被打时影响面小很多。
- 问清上游：机房或云厂商是否提供攻击时的 IP 保护与清洗，这往往包含在现有服务里，不用额外花钱。
Q：还有什么补充建议？
- 把「源站 IP 是否泄露」当成一个定期检查项，每季度从站外视角重新自查一遍，别等被打才发现。
- 建立一份资产清单：所有子域名、所有解析记录、所有对外开放的端口，清单不全就没法评估暴露面。
- 记住一条判断标准：防护生效的判断依据不是「高防后台显示有攻击」，而是「源站日志里看不到攻击流量」。
- 如果长期被同一伙人盯着打，把源站与防护节点的回源链路再加密一层，并保留完整攻击日志用于追溯与报案。