负载均衡与高防叠加部署时，正确的顺序是让高防CDN节点先承接业务流量，清洗后再回源至负载均衡，最后分发到后端服务器，先接入高防再接入负载均衡是唯一合理的链路顺序，顺序反了会导致源站IP暴露且高防失去意义。
为什么顺序错了，高防会直接“裸奔”
很多团队第一次做高防接入时,习惯性地把负载均衡当作业务入口，在负载均衡前面再加一层高防CDN，这没错，但真正出问题的，是回源地址的配置方向和DNS解析层级，行业共识认为，高防和负载均衡的叠加部署，实质上是在DNS解析层完成一次“流量改道”，高防负责吸附攻击流量，负载均衡负责正常流量的精细分发。
这里有一个常见的认知误区：以为只要把域名解析到高防IP，然后高防把流量转到负载均衡IP就算完成，实际部署中往往忽略了一个细节高防回源到负载均衡时，负载均衡需要配置白名单，只允许高防的回源IP段访问，否则攻击者只需绕过高防，直接扫到负载均衡的公网IP，就能轻松穿透整条防线。
- 正确顺序：DNS解析 → 高防CDN节点 → 回源到负载均衡（SLB/CLB） → 后端Web服务器
- 错误顺序：DNS解析 → 负载均衡公网IP → 转发到高防 → 再回源（流量绕路且大多无法生效）
如果顺序错了,负载均衡的公网IP将直接暴露在公网环境中，高防节点仅能防护通过解析进来的部分流量，而攻击者可以通过IP直连的方式绕过高防，直接打到负载均衡或源站。
叠加部署时有哪些顺序注意事项
在真实业务场景中,顺序问题往往不是“谁在谁前面”这么简单，还涉及多级清洗、回源限速、证书卸载等多个层面的配合，以下按部署顺序整理关键注意点。
DNS解析顺序：高防必须处于域名解析的最外层
配置流程的第一步,是把业务域名CNAME解析到高防提供的别名记录或直接A记录解析到高防IP，此时负载均衡的IP不要出现在任何公网DNS记录里，最佳实践是将负载均衡的IP仅作为回源地址使用，不暴露在解析记录中。
配置示例（以简米云DDoS高防为例）：
- 域名解析记录：
www.example.com→ CNAME →xxxxx.alicloudddos.com - 高防控制台回源配置：回源地址填写负载均衡VIP或DNS域名（如
slb.example-internal.com） - 负载均衡控制台：添加访问控制策略，仅放行高防回源IP段
这里有一个保护源站的细节,多数负载均衡产品（如SLB、CLB）都有“访问控制”功能，建议在部署时直接开启白名单模式，将高防节点回源IP段全部加入白名单，白名单之外的IP一律拒绝访问，这样即便有人探测到负载均衡IP，也无法直接访问到业务端口。
流量清洗顺序：高防清洗完后才能交给负载均衡
高防的清洗动作包括SYN Flood防护、UDP反射放大过滤、HTTP慢速攻击拦截等基础清洗，现代高防还具备Web应用层防护能力，如CC攻击防护、高频访问限速、人机校验等。
在叠加部署时,建议将高防的CC防护策略调整为“全局防护+精细规则”模式，而不是完全依赖负载均衡的限速或后端WAF，原因是负载均衡设备通常不具备深层报文检测能力，它擅长的是四层分发和七层转发，对HTTP头部的恶意变种识别能力相对有限。
流量路径中的清洗顺序可以拆解为：
- 高防节点进行全网流量清洗（四层+七层基础清洗）
- 高防通过回源策略把干净流量转发至负载均衡
- 负载均衡按权重、哈希或最小连接数分发至后端服务器
- 后端服务器如有安全组件（如云安全中心、主机防护），负责最后一公里的异常检测
TLS证书卸载顺序：证书放高防还是放负载均衡
这个顺序问题经常被忽略,证书放在高防节点，可以实现TLS终止，而后端链路可以使用HTTP回源，减少负载均衡的加解密压力，但大量安全等保要求不允许明文内网传输出现在回源链路上。
实际操作建议如下：
- 如果证书绑定在域名上，优先在高防节点配置SSL证书并开启TLS终止
- 如果证书绑定在负载均衡上，需要保证高防回源端口是443而非80，并配置负载均衡上的证书
- 如果两者都配,负载均衡的证书需要和高防上的证书完全一致，避免证书链断裂导致回源验证失败
行业共识认为,证书尽量只在一个位置配置，避免双向TLS握手导致的回源超时问题。
先加高防还是先挂负载均衡：部署场景与价格对比
在选购服务时,很多团队会在先买高防还是先买负载均衡这件顺序问题上纠结，顺序取决于业务的核心需求优先级。
已有负载均衡，想接入高防
这种场景最典型,业务已在正常运行，负载均衡IP已生效，此时需要新增高防接入，方案如下：
- 在负载均衡控制台新建一个监听端口（如原8443回源端口），不修改现有公网监听
- 在高防控制台添加新的防护域名,回源地址填写负载均衡的内网或公网VIP
- 将现有DNS解析切换至高防别名
- 观察高防回源状态,确认源站流量路径已切换
对于已有负载均衡的场景,不需要重新购买或替换负载均衡实例，只需在现有实例上增加回源监听即可，也基本不涉及额外费用。
新业务上线，高防和负载均衡一起选
新业务建议先开通高防,再创建负载均衡实例，因为高防回源配置只需要域名或IP，不依赖负载均衡的具体规格，创建顺序如下：
- 第一步：先创建高防实例，获得高防IP或别名地址
- 第二步：创建负载均衡实例，暂不绑定公网IP
- 第三步：通过负载均衡的内网地址作为高防回源地址（同地域内网回源延迟更小且无公网流量费）
- 第四步：测试高防回源连通性，再切换DNS
价格对比方面,高防与负载均衡叠加部署的成本主要取决于两处：
- 高防的防护带宽包费用（按保底+弹性峰值计费，各地云厂商价格差异较大，以华东地区为例，保底20Gbps的年付费用通常在数万元上下）
- 负载均衡的实例费+流量费（按LCU或规格计费，公网流量费另算）
叠加部署比单独使用高防多出的成本主要体现在负载均衡实例费和回源流量费，但实际上负载均衡是高防回源的必要组件，无法省略。
叠加部署的回源原理与故障转移顺序
高防与负载均衡叠加后,回源链路的健康状态决定了整个架构的可用性，高防节点在回源时会通过健康检查来判断负载均衡实例是否存活，如果负载均衡后端所有服务器都异常，高防节点将返回错误页面或触发宕机切换。
健康检查的三个建议配置
- 负载均衡对后端服务器的健康检查间隔建议设置为3秒，响应超时时间5秒，连续失败次数3次判定为宕机
- 高防回源的健康检查路径建议使用
/healthz或/ping这类轻量路径，不要使用动态页面 - 高防的回源失败重试策略建议关闭“重试其他负载均衡IP”的选项，让流量保持在当前链路，避免跨地域跳转导致延迟剧烈波动
故障转移顺序说明
故障转移的顺序应该是负载均衡后端节点级故障优先处理,然后才是负载均衡实例级故障，最后才是高防节点故障。
- 后端服务器宕机 → 负载均衡自动摘除异常节点，流量自动转移到健康节点
- 负载均衡实例不可用 → 高防回源失败，高防会触发回源重试或切换备回源地址
- 高防节点自身被攻击瘫痪 → 高防厂商承诺的无限压测或者QPS防护能力触发集群调度，由厂商侧完成节点切换
这里有个细节：高防回源到负载均衡时，建议配置主备两个回源地址，主回源为主负载均衡VIP，备回源为容灾负载均衡VIP或数据面IP，这样即使主负载均衡地域级的故障，高防仍能将流量调度至备用回源。
在保护源站的同时，会话保持与真实IP获取怎么处理
顺序问题延伸到了应用层,高防开启会话保持后，源站需要正确获取用户真实IP，确保日志分析、风控模型和频率限制策略能正常工作。
获取用户真实IP：X-Forwarded-For顺序
高防转发到负载均衡时,默认会携带 X-Forwarded-For 头，其中第一个IP就是用户真实来源IP，如果负载均衡与高防之间还经过了CDN或WAF，需要逐层透传，不能丢弃Header。
需要在负载均衡的监听配置中开启“X-Forwarded-For”透传，同时后端服务器需要支持从该Header读取IP，对于Nginx环境，推荐使用 real_ip 模块，并指定 set_real_ip_from 为负载均衡的内网网段，避免后端应用拿不到真实IP。
会话保持的二级配置
高防上的会话保持和负载均衡上的会话保持是独立的,需要两级都开启才能保证链路持续有效。
- 如果业务依赖Session（例如登录态），负载均衡需开启七层Cookie会话保持
- 高防节点需开启基于Cookie或源IP的会话保持,保持时长建议与负载均衡一致，避免被高防节点重置会话
- 如果使用了WebSocket长连接,需要确认高防和负载均衡均支持WebSocket的Upgrade协议透传
一个容易踩坑的问题：在高防和负载均衡上都配置会话保持，当请求通过高防的A节点进入，高防回源到负载均衡B节点，且负载均衡将请求转发到后端C节点，此时如果C节点重启，会话将失效，因为负载均衡的会话保持表会摘除C节点，建议后端服务器保持无状态设计，会话存放在Redis或Memcached中。
常见问题：高防叠加负载均衡部署能防住大流量攻击吗
这个问题比较实际,高防的核心能力是流量清洗能力，负载均衡本身不具备防DDoS能力，但它能提升架构的扩容弹性和多可用区容灾能力，叠加部署后，大流量攻击的防护思路如下：
- 攻击流量先到达高防节点,高防通过硬防设备或算法进行流量清洗
- 清洗后的正常流量由高防回源至负载均衡
- 负载均衡按后端服务器的能力进行分发,不至于让某一台机器打满负载
需要明确的是,负载均衡并不能提升高防的防护带宽上限，如果攻击流量超过高防的总防护能力，高防会启动黑洞或降级策略，因此高防的防护带宽需要按业务最大流量预估并留有缓冲，这部分预算不能省。
如果业务遭遇高强度UDP Flood攻击，即使高防清洗了一部分，回源链路到负载均衡的带宽也会被占满，导致正常访问超时，建议结合负载均衡的“限速”功能，将单IP回源速率限制在高防承载范围内，避免回源带宽被打满。
残留风险和补充措施
无论部署顺序如何正确,高防与负载均衡叠加架构仍存在一定风险，每个业务配置完后都需要做一个“绕过测试”，即直接访问负载均衡的公网IP，验证是否无法访问业务。
- 确认负载均衡的访问控制白名单只包含高防回源IP
- 确认后端服务器安全组只放行负载均衡内网IP或VIP
- 确认没有其他服务绑定在负载均衡公网IP的相同端口上
- 确认内网DNS没有被污染,外部不知道回源域名具体解析到哪个IP
在完成上述验证后,再登录高防控制台确认回源中状态是否正常，生产中建议每天运行一次“链路探测”，通过高防节点访问业务域名确认回源链路正常。
Q&A：负载均衡与高防叠加部署常见疑问解答
高防回源到负载均衡，回源地址可以用域名吗
可以,高防控制台的回源地址支持填写IP或域名，但建议优先填写负载均衡的内网IP，减少域名解析层带来的额外延迟，如果填写域名，需要确保该域名不是业务对外使用的域名，否则会造成解析循环，部分云厂商的高防回源配置中，域名回源仅支持填写与高防同地域的负载均衡域名，且需要先完成域名备案关联。
负载均衡需要购买公网带宽吗
如果高防回源地址填的是负载均衡的公网IP,那么负载均衡的公网带宽需要购买，且回源流量会占用公网带宽计费，如果回源地址填的是内网IP，则不占用公网带宽费用，但前提是高防与负载均衡在同一地域且使用内网回源模式，不同云厂商对高防内网回源的支持程度有差异，购买前需要确认。
高防回源到负载均衡，超时时间怎么设置
高防回源超时时间建议设置为10秒，连接超时时间5秒，后端负载均衡本身的空闲连接超时时间建议设置为60秒，与高防节点的连接保持时间保持一致，如果业务存在长轮询或上传大文件场景，需要适当延长这两个超时时间，避免请求在回源链路上被中途断开，尤其是文件上传超过预设时间时，后端应用可能已经处理完但响应未返回。