部署入口防护时，常见问题不是设备不够多，而是流量先经过谁、异常流量在哪里拦截没有说清。云端负载均衡与流量清洗协同方案的核心，是先建立一条可追踪的入口路径，再明确各层的职责和故障切换方式。
误区一：把清洗和均衡看成同一个功能
流量清洗主要识别并处理异常请求，例如明显超出正常模式的连接洪泛；负载均衡则把通过入口的请求分配给多个后端实例。前者偏向风险过滤，后者偏向容量分配，两者不能互相替代。
常见路径是用户请求先到清洗入口，清洗后再进入负载均衡器，最后转发到应用实例。若采用旁路检测或流量牵引架构，实际顺序和回程路径可能不同，必须依据网络接入方式确认，不能只看产品名称推断。
误区二：认为清洗越靠后越安全
如果异常流量已经挤满接入链路，再由应用前的负载均衡器限流，链路拥塞仍可能使正常请求无法到达。对于链路层或传输层攻击，清洗能力通常需要部署在受保护链路之前；针对应用层请求，则可在具备相应解析能力的入口检查。
也要区分能力边界：三、四层过滤主要依据地址、协议和连接特征，七层防护才能结合 HTTP 请求内容识别部分应用风险。加密流量若在入口终止 TLS，需同时设计证书管理、解密后的检查位置和重新加密策略。
误区三：只画正向路径，不检查回程和源地址
路径图至少应标出客户端、清洗节点、负载均衡器、后端和返回方向。若请求从清洗入口进入，却经另一条出口返回，可能造成会话不对称；某些有状态设备会因此无法正确跟踪连接。
经过代理后，应用看到的源地址也可能变成代理地址。可按架构选择可信的转发头或 Proxy Protocol，并只信任已知代理写入的信息；不能让客户端自行提交的转发头被当成真实来源。记录调整前后的地址，有助于排查访问控制和审计偏差。
误区四：用“端口通了”代替后端健康检查
健康检查只确认端口可连接，未必代表应用能正常处理请求。以部署 Nginx 反向代理的服务为例，可以检查专门的就绪状态接口，并确认关键依赖是否达到服务条件；检查频率、超时和连续失败次数应结合故障恢复速度与误摘除风险设置。
新版本发布或实例维护时，还应设置连接排空：先停止分配新请求，再等待已有请求完成或达到可接受的等待上限。否则即使负载均衡器已摘除实例，长连接或正在处理的请求仍可能中断。
误区五：把切换成功等同于防护成功
清洗节点、负载均衡器和后端实例都可能出现故障。应逐项确认健康检查失效时的动作、备用路径是否可达，以及切换后是否仍经过防护。直接切到未受保护的源站，可能让绕过入口成为风险。
按顺序梳理并验证流量路径
- 画出入口图：记录接入方式、清洗位置、均衡器、后端池和回程线路，标明哪些环节会终止加密或修改源地址。
- 定义分工：列清流量清洗的检测范围、负载均衡的分配策略，以及各层拒绝、限流和记录的责任。
- 配置健康检查：选择能反映应用就绪状态的检查目标，设置超时、失败判定和恢复条件，并验证摘除与重新加入流程。
- 做故障演练：在测试环境或约定维护窗口内，分别验证清洗入口不可用、单个后端失效、回程异常等情况；记录正常请求是否仍能到达。
- 核对日志与告警：对照入口、均衡器和应用日志的时间与请求标识，确认异常被拦截的位置、后端选择结果及源地址传递是否一致。
云端负载均衡与流量清洗协同方案不是简单叠加两项服务，而是把检测、转发、回程和故障处置连成闭环。先理清流量路径，再验证每个节点的边界，才能减少误拦正常请求、绕过防护和故障切换失效。
常见问题
清洗入口一定要放在负载均衡器前面吗？
不一定。常见串联部署会先清洗再均衡，但旁路检测、流量牵引等方式可能不同，应依据接入架构和回程设计确认。
清洗后还需要应用层防护吗？
需要视风险和部署能力而定。网络层过滤不能替代针对请求内容的检查，应用层防护也不能解决所有链路拥塞问题。
怎样判断协同路径是否生效？
检查多层日志中的请求去向，并在受控条件下验证后端摘除、入口故障和恢复流程；不要只凭控制台显示“运行中”判断。
后端能否绕过入口直接对外开放？
应限制后端只接受受信任入口的流量，并检查管理访问与业务访问边界，避免外部请求绕过清洗和均衡环节。