德讯高防云选防护方案时，先看故障发生在哪一层：如果大量连接占满入口，四层防护更直接；如果连接仍能建立，但页面、搜索或登录等功能被异常请求拖慢，七层攻击防护更有针对性。两者不是高低级关系，而是观察对象不同。
所谓“四层”和“七层”通常对应 OSI 参考模型中的传输层与应用层。实际产品的检测范围和能力并不完全相同，不能只凭名称判断效果。下面按防护重点、局限和选择步骤比较。
先分清两种防护看什么
四层防护：关注连接与流量
四层防护主要依据传输协议、端口、连接状态和流量特征作判断，适合在请求进入应用之前过滤异常连接。对于对外开放的文件传输服务、游戏服务器或远程服务入口，它可以帮助限制不符合策略的连接，减轻服务器建立和维护连接的压力。
它的优势是处理位置靠前，通常不必理解网页内容；但它一般无法判断一条连接里的操作是否符合业务逻辑。例如，多个看似正常的连接持续请求同一项昂贵计算，单看连接特征未必能识别其业务意图。
七层攻击防护：关注应用请求
七层攻击防护会进一步分析应用协议和请求特征。网站场景中，它可以按路径、请求方法、访问频率或应用规则识别异常行为；WAF（Web 应用防火墙）是常见的应用层防护类型之一。比如，一个公开的商品目录页面被大量重复查询，连接本身可能正常，但请求频率或访问模式值得限流、验证或拦截。
这一层更接近业务，但检查通常需要更多计算资源。HTTPS 流量经过 TLS 加密后，若要检查加密内容，防护服务需要在合适的位置终止并重新建立加密连接；这会带来证书、隐私、延迟和配置方面的要求。七层防护也不能替代上游对超大流量的清洗能力。
按服务特点选择，而不是只比层数
| 比较项 | 四层防护 | 七层攻击防护 |
|---|---|---|
| 主要观察 | 连接、端口、传输特征 | 应用协议、请求模式和业务规则 |
| 更适合 | 非网页服务、入口连接保护 | 网站、接口及可识别的应用请求 |
| 主要限制 | 难判断请求是否符合业务逻辑 | 需要解析应用流量，配置和资源要求更高 |
| 常见侧重点 | 尽早过滤，降低后端连接压力 | 针对特定路径、频率或规则处置 |
如果服务主要是文件传输或自定义 TCP 服务，四层能力往往更贴合入口保护需求；如果核心是网站、查询功能或应用接口，七层规则更能处理“连接正常但行为异常”的问题。两类服务并存时，可以让四层先处理连接风险，再由七层识别应用请求。预算或架构暂时只能选一层时，应优先覆盖实际暴露的入口和主要故障类型，并确认服务商对协议、加密流量和误拦截的处理方式。
落地前按这几步核对
- 列出公网入口：记录域名、端口、服务类型和实际后端，区分网页与非网页服务。
- 判断故障表现：查看连接数、响应时间、应用日志和资源占用。若入口流量或连接资源先吃紧，优先评估四层；若特定功能被异常请求拖慢，评估七层规则。
- 确认加密处理：询问七层检查是否需要 TLS 终止、证书如何部署、哪些内容会被检查，以及数据保存和访问权限如何管理。
- 先观察再拦截：从告警或记录模式开始，依据正常业务基线逐步设置频率限制和规则；测试误拦截后再扩大范围，并准备回退方式。
- 复核整体链路：确认防护容量、故障切换、源站访问限制和监控告警相互匹配，不能只验证防护平台页面显示正常。
结论：按风险组合配置
没有一种方案适合所有服务。四层防护擅长在连接和传输环节筛选流量，七层攻击防护擅长理解应用请求并针对具体行为处置。若业务同时面临入口压力与应用滥用风险，分层配合通常更完整；若风险集中在单一类型，则优先选择能覆盖该风险、且便于验证和维护的方案。
常见问题
七层防护一定比四层防护强吗？
不一定。七层能分析更多应用信息，但无法自动替代四层入口过滤，也不保证能处理所有大流量问题。
小型网站只做七层防护可以吗？
可以作为重点措施之一，但还应核对上游流量承载、源站暴露和备份处置方式，避免防护只覆盖应用请求。
两种防护同时启用会影响访问吗？
可能增加处理环节或误拦截风险。应先观察规则效果，检查延迟、正常请求通过率和回源行为，再逐步调整。