TL;DR
- WAF过滤攻击流量；普通反向代理仅负责路由和转发。 网络应用防火墙（WAF）在第七层检查HTTP/HTTPS请求，并阻止如SQL注入和跨站脚本等攻击模式，而没有安全模块的反向代理则未对这些流量进行检查。
- 每个WAF在架构上都是一种反向代理，但大多数反向代理不是WAF。 OWASP和F5都将WAF描述为一种专门的反向代理，而NGINX自己的反向代理文档没有提到攻击过滤，并将WAF模块列为单独的补充产品。
- 反向代理解决性能和可用性问题；WAF解决安全问题。 负载均衡、缓存、SSL/TLS终止和源IP掩蔽是反向代理的核心功能，WAF之所以具有这些功能，仅仅是因为它的架构，而不是因为其目的。
- 托管在云中的WAF通过DNS更改在几分钟内部署；自我管理的反向代理和本地WAF设备需要更长时间才能建立，以换取更多控制权。 牺牲的是设置速度和供应商锁定与配置深度和基础设施所有权之间的权衡。
- 大多数生产环境在一起运行反向代理和WAF，而不是只选择其一。 反向代理处理路由、缓存和TLS；WAF（独立或作为模块捆绑）在其上处理攻击过滤层。
- 仅从您的办公网络测试WAF规则和反向代理路由会隐藏地理特定的误报。 针对一个地区的流量调整的规则可能会静默地阻止或错误路由其他地方的真实用户，直到从多个观察点检查。
WAF和反向代理的实际功能
反向代理是一个位于客户端和后端服务器之间的服务器，拦截每一个请求并决定哪个后端来处理它，按照Cloudflare的反向代理词汇表。它将传入的流量分配到多个服务器，以防止任何一台服务器超载，缓存响应以减轻后端负载，终止SSL/TLS以使源服务器无需承担此任务，并隐藏源服务器的真实IP地址。NGINX自己的管理员指南将这一核心工作描述为分配负载、无缝地从不同站点提供内容或将请求转发到应用服务器——该描述中没有提及检查有效载荷以发现恶意意图，并且同一指南将F5的WAF列为与NGINX的单独产品，而非内置特性。
WAF是一种安全控制，过滤和监控Web应用程序与互联网之间的HTTP流量，操作在应用层（第7层），能够读取请求内容而不仅仅是数据包头部，按照Cloudflare的WAF词汇表。它应用规则集来阻止SQL注入、跨站脚本、跨站请求伪造和文件包含尝试——OWASP的十大应用层威胁分类——并可以限流或在攻击中阻止流量。OWASP自己的定义明确指出“WAF可以被视为反向代理”，因为它必须位于请求路径中才能执行其工作；F5的WAF词汇表也提出了相同的观点。这种共享架构是这两个术语被混淆的原因：WAF建立在反向代理使用的同一定位基础上，但它增加了一个普通反向代理没有的安全决策层。