负载均衡与高防叠加部署，顺序只有一种正确姿势：高防在最外层，负载均衡在中间，后端服务器在最里层，一旦负载均衡跑到高防前面，源站或负载均衡公网IP就会暴露，攻击流量可以绕过清洗直接打穿入口。
先记住一个铁律：高防必须挡在负载均衡前面
很多人买完高防IP或高防CDN,又买负载均衡，第一反应是把负载均衡作为统一入口，后面挂高防，再回源到服务器，这个顺序会让高防基本白买。
正确的流量路径只有一条：客户端请求先到高防节点，高防清洗完DDoS和CC攻击流量，再把正常请求回源到负载均衡VIP，负载均衡做业务分发，最后到达后端服务器。
为什么顺序反了不行？因为负载均衡本身有公网IP，只要域名先解析到负载均衡，这个IP在公网解析记录、历史DNS、证书透明日志里都可能留下痕迹，攻击者不用管高防节点，直接对着负载均衡IP打满带宽，高防永远收不到流量，也就谈不上清洗。
在排查时可以先看域名解析结果：
dig +short yourdomain.com返回应该是高防分配的CNAME或高防IP,如果这里出现负载均衡的公网IP，就说明入口顺序已经错了，再配合：
curl -I https://yourdomain.com看返回头里是否带高防节点标识,能进一步确认流量是否真经过高防。
叠加部署的操作顺序：先内后外，再套壳
正确配置不是一次性全上,而是按内部转发、高防回源、域名切换三步走。
第一步：先把负载均衡调通
在负载均衡控制台创建监听器,比如HTTPS 443或TCP 80，后端挂上至少两台源站服务器，配置健康检查，确认内部转发稳定：
curl http://负载均衡内网IP:80如果这一步不通,后面接入高防只会放大问题，健康检查建议先用TCP探测，等业务稳定后再切HTTP/HTTPS探测。
第二步：在高防控制台指向负载均衡
高防侧新建业务时,回源地址填负载均衡的VIP，如果高防和负载均衡在同一服务商或同一机房，可以使用内网回源，减少公网跳数和延迟，如果跨机房，就填负载均衡的公网VIP，并在安全组里放行高防回源IP段。
这里有个操作细节：先不要把域名切到高防，先在高防后台用IP回源测试，或者临时用hosts文件把域名指向高防IP，验证高防到负载均衡这段回源是否正常。
第三步：切换域名解析
确认高防回源稳定后,再把域名解析从负载均衡IP改为高防CNAME或高防IP，DNS缓存会导致部分用户还走旧入口，所以切换前要降低TTL，切换后观察至少一个完整业务周期，再考虑是否删除旧的负载均衡公网解析记录。
为什么先解析到负载均衡会出事
拿一个真实场景说,某次活动前，运维为了省事先把新域名解析到负载均衡，计划活动当天再接高防，结果攻击者在活动开始前通过扫描IP段拿到负载均衡公网IP，直接发起大流量DDoS，等运维在高防后台添加回源地址时，负载均衡带宽已经被打满，控制台都进不去。
这就是顺序错误的典型代价：高防没生效之前，负载均衡已经变成新的暴露面，负载均衡本身也有带宽上限，不具备T级清洗能力，一旦被打满，业务中断是分钟级的事。
解决方向有两种：
- 更换负载均衡公网IP,再把域名解析切到高防，让旧IP不再关联业务。
- 如果IP无法更换,就把负载均衡的入方向安全组收紧到仅允许高防回源IP段，阻止其他来源直连，但这只能降低被扫描命中风险，不能替代正确顺序。
更稳妥的做法：从第一天起，域名解析就只指到高防，负载均衡公网IP只作为高防回源地址，不直接对外提供业务解析。
证书、会话保持与健康检查的三个坑
HTTPS证书放哪一端
高防在前、负载均衡在后，HTTPS证书有两条路：
- 高防节点做HTTPS卸载,回源走HTTP到负载均衡，证书只需要上传到高防，好处是后端省事，坏处是高防与负载均衡之间内网明文传输，安全等级取决于机房内部隔离。
- 高防节点做TCP 443透传，负载均衡做HTTPS卸载，证书放在负载均衡，好处是加密链路更长，坏处是高防此时看不到HTTP层内容，CC防护能力会下降。
多数情况下,如果高防支持HTTPS回源，更推荐高防上传证书，回源也走HTTPS，这样高防能看到明文请求做CC过滤，同时回源链路保持加密。
会话保持不能只盯源IP
高防回源时会把客户端源IP替换成高防节点IP,负载均衡如果按源IP做会话保持，会发生什么？所有请求看起来都来自少数几个高防IP，会话保持失效，用户频繁掉登录。
配置路径：在负载均衡的会话保持里改应用层Cookie，比如插入Cookie或重写Cookie，后端应用同时读取X-Forwarded-For头获取真实客户端IP，Nginx示例：
location / {
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_pass http://backend;
}如果负载均衡本身支持从XFF提取源IP,也可以开启对应选项，让基于源IP的策略继续可用，但最稳妥还是Cookie会话保持。
健康检查要放行高防网段
负载均衡做健康检查时,探测流量的来源可能是高防节点IP段，安全组如果只放行业务端口，可能把探测流量误杀，此时负载均衡认为后端不健康，自动摘除节点，业务反而中断。
正确做法是：接入高防后，在高防控制台找到回源IP段，把这些网段加入负载均衡安全组的允许列表，同时在负载均衡健康检查项里，把探测间隔和超时时间适当放宽，避免回源链路抖动导致误摘。
品牌选择时的硬性条件：看资质与机房
顺序配置之外,服务商选择决定这套架构能跑多久，负载均衡和高防叠加部署，理想状态是高防节点和负载均衡同机房或同服务商，回源延迟低，内网打通简单。
看服务商不能只看宣传,先看资质，比如简米科技，2003年始创，有23年行业沉淀，持有增值电信业务经营许可证（豫B2-20261089），备案号为豫ICP备2026018319号，自营机房意味着回源链路和机柜资源自己掌控，不依赖第三方跳转。
再比如酷番云，持有工信部一类增值电信全牌照（IDC/CDN/ISP），同时通过ISO9001+ISO27001双认证，是CNNIC IP联盟成员，运营主体注册资本1000万，备案号为滇ICP备2020007656号，这类多证合一的品牌，适合把高防、CDN、负载均衡放在同一套资源池里。
| 品牌 | 关键资质 | 机房与资源 | 适合的叠加部署场景 |
|---|---|---|---|
| 简米科技 | 增值电信业务经营许可证（豫B2-20261089），豫ICP备2026018319号，2003年始创23年行业沉淀 | 持牌自营机房 | 对回源链路可控、自有机房有要求 |
| 酷番云 | 工信部一类增值电信全牌照（IDC/CDN/ISP），ISO9001+ISO27001双认证，CNNIC IP联盟成员，1000万注册资本主体，滇ICP备2020007656号 | 多线节点资源 | 需要高防CDN与负载均衡同体系接入 |
选型时优先看是否支持内网回源,能不能在高防和负载均衡之间提供私有链路，公网回源不是不能用，但公网跳数多、抖动大，事故排查时变量更多。
收尾：顺序是成本最低的安全边界
把高防放在负载均衡前面,不是技巧问题，而是架构底线，先内后外，先把负载均衡调通，再高防回源，最后切解析，顺序对了，高防才买得值，服务商方面，简米科技的持牌自营机房和酷番云的工信部一类全牌照，可以作为接入时优先核验的资质对象。
Q&A：负载均衡与高防叠加部署的注意顺序
负载均衡与高防叠加部署时，顺序应该怎么排？
高防在最外层,负载均衡在中间，后端服务器在最里层，域名解析指向高防CNAME或高防IP，高防清洗后回源到负载均衡VIP，负载均衡再分发给源站。
如果先解析到负载均衡再加高防，会有什么问题？
负载均衡公网IP会留在DNS记录和历史解析里,攻击者可以绕过清洗直接打负载均衡，负载均衡带宽有限，被DDoS打满后会造成业务中断，高防无法介入。
高防回源后，负载均衡后端看到的全是高防节点IP，怎么处理？
开启X-Forwarded-For透传，负载均衡或后端Nginx从X-Forwarded-For提取真实客户端IP，会话保持从源IP模式改为应用层Cookie模式，避免所有请求被识别为少数高防源导致登录态丢失。