在DDoS防护体系中，源站隐藏和回源IP白名单设置是两个最核心的安全动作。简单来说，源站隐藏就是不让攻击者直接找到你服务器的真实IP地址，所有流量先经过高防节点清洗，再由高防节点用一个"干净"的回源IP去跟你的源站通信；而回源IP白名单则是在源站防火墙层面，只允许高防节点的回源IP访问你的业务端口，其他一切IP全部拒绝。这两件事做好了，你的源站基本上就从公网上"消失"了，攻击者就算拿到你的域名，也只能打到高防节点上，根本碰不到你的真实服务器。下面我把这两个技术点拆开来，从原理到实操一步步讲清楚。

一、为什么源站隐藏是DDoS防护的第一步

很多人以为接了高防就万事大吉，但如果你的源站IP还暴露在外，攻击者完全可以绕过高防直接打你的源站。这种情况在DNS层面特别常见——如果你的域名解析直接指向源站IP，攻击者通过历史DNS记录、子域名探测、邮件头信息、SSL证书透明度日志等渠道，都能拿到你的真实IP。一旦真实IP泄露，高防就形同虚设，因为流量根本不会走高防节点，而是直接冲向你的源站。所以源站隐藏的本质，就是切断一切能暴露真实IP的路径，让所有流量必须经过高防中转。

二、源站隐藏的具体操作方法

第一，DNS解析必须指向高防节点提供的CNAME或A记录，而不是你源站的真实IP。大部分高防服务商都会给你一个高防域名，你把业务域名CNAME到这个高防域名上就行。注意，不要在DNS里同时存在指向源站IP的A记录，哪怕是一条都不行，否则攻击者做DNS查询时就能拿到真实IP。

第二，源站服务器上不要安装任何会主动对外发起连接的服务，比如邮件服务、FTP服务等，这些服务的外发连接可能会在日志中暴露你的源站IP。如果必须有，就通过高防节点的代理功能来中转。

第三，SSL证书的申请和部署要通过高防节点来做，不要在源站上直接申请证书，因为证书申请过程中的验证邮件、验证记录都可能泄露IP信息。另外，确保你的源站不对外提供任何可以查询到真实IP的接口，比如某些API调试页面、ping测试页面等，全部关掉或者加访问限制。

第四，检查所有历史记录。包括但不限于：网站存档网站上的历史快照、WHOIS信息中的IP记录、以前的邮件头、以前发布的技术文档、代码仓库中的配置文件等。这些都是攻击者收集情报的来源，能清理的尽量清理。

三、回源IP白名单是什么、为什么必须设置

回源IP白名单，就是在你源站服务器的防火墙或安全组里，配置一条规则：只允许高防节点回源时使用的IP地址访问你的业务端口（通常是80、443或者自定义端口），其他所有IP的访问请求一律丢弃。这个设置的意义在于，就算攻击者通过某种方式探测到了你源站的IP，他发过来的流量也会被防火墙直接拦截，因为他的IP不在白名单里。这是最后一道防线，也是最容易被忽略的一道防线。

很多人接了高防之后，源站防火墙还是默认的"允许所有"策略，这就等于把后门敞开了。你花了钱买高防，结果源站自己不设防，这是非常典型的安全失误。回源IP白名单设置正确的话，即使高防节点因为某种原因被绕过（虽然概率极低），你的源站依然是安全的。

四、回源IP白名单的具体配置方法

不同的服务器环境配置方式不同，下面我分几种常见情况来讲。

如果你用的是Linux服务器配合iptables防火墙，配置方法如下：

# 假设高防回源IP是 120.55.xx.xx 和 120.55.xx.yy（具体IP以高防服务商提供为准）
# 先清除现有规则（谨慎操作，确保你有其他方式连接服务器）
iptables -F

# 设置默认策略为丢弃
iptables -P INPUT DROP
iptables -P FORWARD DROP
iptables -P OUTPUT ACCEPT

# 允许本地回环
iptables -A INPUT -i lo -j ACCEPT

# 允许已建立的连接
iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT

# 允许SSH（建议限制来源IP，或者改端口）
iptables -A INPUT -p tcp --dport 22 -s 你的管理IP -j ACCEPT

# 允许高防回源IP访问Web端口
iptables -A INPUT -p tcp --dport 80 -s 120.55.xx.xx -j ACCEPT
iptables -A INPUT -p tcp --dport 443 -s 120.55.xx.xx -j ACCEPT
iptables -A INPUT -p tcp --dport 80 -s 120.55.xx.yy -j ACCEPT
iptables -A INPUT -p tcp --dport 443 -s 120.55.xx.yy -j ACCEPT

# 保存规则
iptables-save > /etc/iptables/rules.v4

如果你用的是云服务器的安全组（比如阿里云、腾讯云等），操作更简单，直接在控制台找到安全组规则，添加入站规则：协议选TCP，端口填80和443，源IP填高防提供的回源IP段，策略选允许。其他所有入站规则全部删除或设为拒绝。注意，安全组是第一层过滤，系统防火墙是第二层，两层都要配，不要只依赖一层。

如果你用的是Windows Server，可以通过Windows防火墙高级设置来配置入站规则，选择"自定义规则"，指定高防回源IP和对应端口，操作为"允许连接"。同样的道理，把其他不必要的入站规则全部禁用。

五、回源IP段的获取和更新注意事项

高防服务商通常会提供一个或多个回源IP地址，有些是单个IP，有些是一个IP段。你需要从高防控制台或者工单系统里准确获取这些IP，不能凭猜测。而且，高防服务商可能会不定期更换回源IP（比如节点扩容、故障迁移等），所以你必须建立一个定期检查和更新的机制。建议每周检查一次高防控制台的回源IP信息，一旦发现变化，立即更新你源站的白名单规则。

这里有个常见的坑：有些高防服务商提供的回源IP是动态变化的，每次配置高防实例时分配的IP可能不同。如果你的业务是通过API对接高防的，一定要确认回源IP的获取方式，是固定的还是动态的。如果是动态的，你需要通过高防的API接口定期拉取最新的回源IP并自动更新防火墙规则，手动维护在这种场景下是不现实的。

六、源站隐藏和白名单配合使用的最佳实践

第一，源站不要直接对外提供任何服务，包括ping、traceroute、telnet测试等。你可以在防火墙层面直接丢弃ICMP协议的入站包，这样别人连ping都ping不通你的源站。

第二，源站的Web服务配置里，检查一下是否有任何地方会泄露真实IP。比如某些反向代理配置、某些CDN回源设置、某些日志输出等。特别是Nginx的配置文件里，如果你配置了real_ip_header，要确保这个header只能由高防节点设置，不要让客户端直接传递X-Forwarded-For之类的头信息。

第三，建议在源站上部署一个轻量级的WAF或者入侵检测系统，作为高防之外的补充。因为高防主要防的是大流量DDoS攻击，对于一些小规模的CC攻击或者应用层攻击，源站自身的防护也很重要。白名单机制本身就是一种WAF策略，但你可以在此基础上再加一层应用层的访问控制。

第四，定期做渗透测试和安全审计。找专业的安全团队或者用自动化工具，模拟攻击者的视角，看看能不能通过各种渠道找到你的源站IP。如果能找到，说明你的源站隐藏做得还不够彻底。

七、常见错误和踩坑总结

错误一：DNS里留了一条指向源站IP的记录，觉得"反正平时不用"。攻击者不需要平时用，他只需要在攻击时查一次DNS就够了。

错误二：白名单只配了一个回源IP，但高防实际用了多个IP回源。结果高防节点切换回源IP后，你的业务就断了。一定要把高防提供的所有回源IP都加进去。

错误三：防火墙规则配好了但没保存，服务器重启后规则丢失。Linux下iptables规则如果不用iptables-save保存，重启就没了。要用systemctl启用iptables服务或者用firewalld的permanent规则。

错误四：只在云安全组配了白名单，没在系统防火墙配。云安全组和系统防火墙是两道独立的防线，缺一不可。有些攻击流量可能绕过安全组（比如内网攻击场景），系统防火墙是兜底的。

错误五：源站IP通过其他渠道泄露了自己不知道。比如你在某个技术论坛发帖时贴了服务器截图，截图里带了IP信息；或者你的邮件服务器配置不当，发出去的邮件头里带了源站IP。这些细节都要注意。

八、总结

源站隐藏和回源IP白名单设置，是DDoS防护中最基础也最关键的两个环节。源站隐藏解决的是"让攻击者找不到你"的问题，回源IP白名单解决的是"就算找到了也打不进来"的问题。两者缺一不可，必须同时做到位。具体操作上，DNS指向高防、清除一切IP暴露渠道、防火墙只放行高防回源IP、定期检查更新回源IP列表，这四步做到了，你的源站安全等级就能提升一个档次。不要觉得这些是小事，大量的DDoS攻击成功案例，都是因为这些基础工作没做好导致的。安全这件事，永远是细节决定成败。