很多用户以为用了高防服务器、高防 IP 或高防 CDN，业务就一定安全了。实际上，高防方案最怕的不是攻击流量大，而是源站 IP 被暴露。一旦攻击者拿到真实源 IP，就可以绕过高防节点，直接攻击后端服务器，这时候前面的清洗、防护、WAF、CDN 基本都会失去作用。

所以，高防服务器真正的核心不是“防御值写得多高”，而是要做到：攻击流量只能打到高防入口，永远打不到真实源站。

一、源 IP 暴露后，最直接的后果是什么？

1. 攻击可以绕过高防，直接打源站

正常架构应该是：

用户访问 → 高防 IP / 高防节点 → 清洗过滤 → 源站服务器

但源 IP 暴露后，攻击路径会变成：

攻击者 → 真实源站 IP

这意味着攻击者不再经过高防入口，而是直接向源站发起 TCP Flood、UDP Flood、CC、SYN Flood 等攻击。哪怕你前面的高防 IP 有 100G、300G、500G 防御，只要源站本身只有 50M、100M、1G 带宽，都可能被瞬间打满。

2. 服务器带宽被打满，网站直接打不开

源站通常不承担大规模攻击流量，它的带宽更多是用于正常业务访问。例如：

很多时候不是服务器 CPU 扛不住，而是入口带宽先被打满，正常用户的请求根本进不来。

3. 机房可能触发封禁或空路由

如果源站 IP 持续被大流量攻击，机房为了保护上游线路，可能会临时封禁该 IP，或者进行空路由处理。

也就是说，这台服务器即使系统没宕机，业务也会从公网完全不可达。对于跨境电商、游戏、支付接口、SaaS后台来说，这种中断影响非常大。

4. 真实服务器配置被进一步摸清

源 IP 暴露后，攻击者可以继续扫描源站开放端口，例如：

22    SSH
80    HTTP
443   HTTPS
3306  MySQL
6379  Redis
8080  后台服务
9200  Elasticsearch

如果源站安全策略做得不好，攻击就不只是 DDoS，还可能变成端口爆破、数据库攻击、后台扫描、漏洞探测。

二、源 IP 一般是怎么暴露的？

源 IP 暴露通常不是高防本身失效，而是业务架构留下了泄漏点。

1. DNS 历史记录泄漏

如果网站之前直接解析过源站 IP，后来才接入高防，攻击者可以通过历史 DNS 记录、子域名记录、旧解析记录找到源站。

例如：

www.example.com      → 高防 IP
old.example.com      → 源站 IP
api.example.com      → 源站 IP
test.example.com     → 源站 IP

主站接了高防，但 API、测试站、后台域名还直连源站，这就是常见漏洞。

2. 邮件、接口、回调暴露源站

很多网站会在源站服务器上直接发邮件、调用第三方接口、对接支付回调。如果服务器主动对外请求时没有隐藏出口 IP，对方日志里就可能记录真实源站 IP。

例如：

支付回调接口
短信接口
邮箱 SMTP
第三方 API
Webhook 通知

这些地方都可能把源 IP 暴露出去。

3. Web 服务返回真实 IP 信息

一些错误页面、调试信息、Nginx配置、PHP报错、接口响应头，也可能暴露源站信息。

常见风险包括：

Server: nginx/1.20.1
X-Origin-IP: 1.2.3.4
X-Real-IP: 1.2.3.4
debug=true
.env 配置泄漏

线上环境一定不能开启调试模式，也不要在响应头里输出内部服务器信息。

4. 源站防火墙没有限制回源 IP

这是最关键的问题。

很多用户接入高防后，只改了 DNS，把域名解析到高防 IP，却没有在源站上限制访问来源。结果是：

高防 IP 可以访问源站
攻击者也可以直接访问源站

正确做法应该是：源站只允许高防节点回源 IP 访问 80/443，其他公网 IP 一律拒绝。

三、高防服务器应该怎么选配置？

高防场景下，服务器配置不能只看 CPU 和内存，还要看三件事：

防御能力
回源质量
源站隔离能力

下面是几种比较常见的配置方案。

如果业务面向国内用户访问，线路还要重点看回程质量，比如 CN2、CMIN2、CU、BGP 多线等。高防不只是“防得住”，还要保证正常用户访问不绕路、不丢包、不高延迟。

四、源 IP 暴露后的正确处理方案

如果源 IP 已经暴露，不建议只是在原服务器上继续加规则。比较稳妥的处理方式是：换源 IP + 封直连 + 清理泄漏点。

方案一：更换源站 IP，重新接入高防

这是最有效的处理方式。

操作流程：

1. 新增或更换源站 IP
2. 域名只解析到高防 IP
3. 高防节点回源到新源站 IP
4. 源站防火墙只放行高防回源 IP
5. 关闭旧源 IP 或限制旧源 IP 访问

如果攻击者已经记录了旧源 IP，继续使用旧 IP 的意义不大。即使你后面加了高防，对方仍然可以直接打旧 IP。

方案二：源站只允许高防回源访问

以 Linux 服务器为例，可以在防火墙层面限制 80 和 443 端口。

示例思路：

允许高防回源 IP 访问 80/443
拒绝其他公网 IP 访问 80/443
SSH 只允许管理 IP 或 VPN 访问
数据库、Redis、后台端口禁止公网访问

例如：

# 示例：只允许高防回源段访问 Web 端口
iptables -A INPUT -p tcp -s 高防回源IP段 --dport 80 -j ACCEPT
iptables -A INPUT -p tcp -s 高防回源IP段 --dport 443 -j ACCEPT

# 拒绝其他来源访问 Web 端口
iptables -A INPUT -p tcp --dport 80 -j DROP
iptables -A INPUT -p tcp --dport 443 -j DROP

实际部署时不要直接照抄，需要根据机房提供的高防回源 IP 段来配置，避免把正常回源也拦掉。

方案三：后台、数据库、管理端全部内网化

高防只应该保护业务入口，不应该让所有服务都暴露在公网。

建议这样划分：

尤其是 MySQL、Redis、Elasticsearch 这类服务，不应该直接暴露到公网。很多业务被打穿，不是因为高防不够，而是后台端口和数据库端口本来就裸露着。

方案四：Nginx 正确获取真实访客 IP

接入高防后，源站看到的访问 IP 往往是高防节点 IP，而不是用户真实 IP。需要正确配置 real_ip，否则日志分析、风控、限流都会失真。

示例：

set_real_ip_from 高防回源IP段;
real_ip_header X-Forwarded-For;
real_ip_recursive on;

这样做的目的不是为了防攻击，而是为了让源站能识别真实用户 IP，方便后续做 CC 防护、登录限制、地区策略和访问日志分析。

五、推荐的高防架构

比较稳的架构可以这样设计：

用户
 ↓
高防 IP / 高防 CDN
 ↓
WAF / CC 防护 / 访问频率限制
 ↓
源站 Web 服务器
 ↓
内网数据库 / 缓存 / 文件存储

关键点有四个：

域名不直接解析源站
源站不直接对公网开放
后台和数据库不暴露公网
所有访问日志要能追踪真实用户 IP

如果是跨境电商、游戏、API业务，可以进一步拆分：

前端静态资源 → CDN
动态请求 → 高防 IP
API接口 → 独立高防入口
数据库 → 内网隔离
管理后台 → VPN / 白名单访问

这样即使某个入口受到攻击，也不会把整个业务系统一起拖垮。

六、源 IP 防泄漏检查清单

上线前建议逐项检查：

高防服务器暴露源 IP 后，最大的问题不是“别人知道了一个 IP”，而是攻击者可以直接绕过高防，把流量打到源站。这样一来，再高的防御值也保护不了真实服务器。

真正可靠的高防方案，一定不是单纯购买一个高防 IP，而是要把架构做好：高防入口负责抗攻击，源站服务器负责业务运行，防火墙负责隔离直连访问，后台和数据库全部隐藏起来。

简单来说，高防的关键不是让源站更能扛，而是让攻击者根本找不到源站。