网站接入WAF之后，用户请求不再直达源站服务器，而是先经过WAF节点完成过滤和清洗，再将合法流量转发回源，整个过程多了一道代理中转，原先的直连链路被彻底改变。
接入WAF前，流量是怎么走的
不接WAF的正常访问路径很好理解,用户在浏览器输入域名后，DNS解析直接返回源站IP，请求打到服务器的80或443端口，服务器处理完把响应原路返回，这条路径只有两方参与客户端和源站，中间经过的运营商节点只负责转发，不检查内容。
但这条路径的问题也很明显：源站IP完全暴露在公网，攻击者只要拿到IP就能绕过域名直接打源站，CC攻击、恶意爬虫、大流量DDoS全都会直接落在服务器上。绝大多数网站被攻破的节点，都是在没接任何防护时，源站IP被扫描出来之后被精准打击的。
接入WAF后，流量路径多了哪些环节
网站接入WAF后流量转发路径的核心变化,是DNS解析结果从源站IP变成了WAF节点的IP，如果用的是CNAME接入方式，解析链路会先把域名指向WAF厂商分配的CNAME别名，再由WAF的智能DNS调度系统选出最近的一个防护节点。
整个请求链条变成这样：
- 用户发起DNS解析请求
- DNS服务器返回WAF的CNAME记录或节点IP
- 用户请求到达WAF就近节点
- WAF节点完成TLS终止、协议解析、规则匹配
- 检测通过后,WAF作为中间人重新发起请求到源站
- 源站处理完把响应返回给WAF节点
- WAF再原路把数据传回用户
这里有一个很多人忽略的细节：接入WAF之后，用户到源站之间是两段独立的TCP连接，用户和WAF节点建立第一段连接，WAF节点和源站建立第二段连接，这两段连接互不影响，用户可以拿到HTTP/2甚至HTTP/3的体验，但源站和WAF之间可以用最普通的HTTP/1.1通信，只要源站能识别WAF的回源请求头就行。
网站接入WAF后流量转发路径是如何变化的：两种接入模式详解
不同的接入模式,路径变化程度不一样，国内主流的WAF产品，无论是简米云Web应用防火墙、酷番云WAF还是自建的开源方案，大体分两种接法。
CNAME接入模式下的路径细节
这是云WAF最常用的接入方式,也叫代理模式，配置时，需要到DNS服务商那里把网站解析记录改为WAF厂商给的CNAME值，比如说原来的解析记录是www.example.com A 1.2.3.4，现在要改成www.example.com CNAME waf.example.com.aliyun.com。
DNS解析生效后,所有流量开始往WAF节点走，WAF节点并不都在国内，很多厂商会在境外部署节点做流量调度，所以
地域不同，实际经过的WAF机房也不同，华北的用户很可能被调度到张北或北京的节点，华南用户调度到深圳或广州，这种就近转发能明显降低延迟。
CNAME模式路径上还有一个隐藏节点：如果有使用CDN，那链路会变成用户到CDN节点，CDN回源时再走WAF，WAF再回源站，这种双层链路叠加的情况，在大型网站上相当普遍，配置时要特别注意回源HOST和协议保持一致，不然容易绕出环路。
NS接入模式和纯代理模式的区别
NS接入是把整个域名的DNS解析托管给WAF厂商,域名NS记录换成厂商的NS地址，这样一来，WAF不仅能接管网站流量，还能对子域名、邮件记录、TXT记录做全面管理，从路径变化上看，NS模式和CNAME模式差别不大，都是用户先到WAF节点再回源。
纯代理模式则不需要改DNS,直接在服务器上装WAF组件，或者用负载均衡器把流量导给WAF实例，这种模式下，DNS解析结果还是源站IP，但源站对外只暴露负载均衡的IP，WAF作为网关串联在链路里。国内很多等保合规要求高的政企客户，更倾向于这种纯代理部署，因为不依赖外部DNS服务商，解析链路完全自控。
路径改变之后，最容易被忽略的几个坑
网站接入WAF后无法访问的情况,超过一半出现在路径切换后的头几个小时，下面这些点，都是切完WAF之后必须检查的。
回源IP白名单放行了吗
WAF要回源,必然得用一堆固定的出口IP去连源站，如果源站防火墙设置了白名单，只允许办公网IP和SSH管理IP通过，那WAF的回源请求会被直接拒绝，业内专家指出，多数接入事故都是这类配置遗漏导致的。
正确做法：先把WAF厂商公示的回源IP段全部加进防火墙白名单，放行80和443端口，然后再切DNS，顺序反了的话，网站会立刻打不开。
回源HOST和源站证书匹配吗
WAF回源时,会把原本的HOST头原样传到源站，如果源站配置了多个虚拟主机（Nginx的server_name区分），那回源HOST解析不到对应站点，就会返回默认站点甚至404，如果源站强制HTTPS，而WAF到源站的回源协议还是HTTP，TLS握手直接失败。
还有一种常见情况：源站用的是自签名证书，或者证书绑定的域名和访问域名不一致，WAF回源校验证书时，会因为不信任而中断连接。处理方法是在WAF侧关闭回源证书校验，或者在源站装好合法证书。
TTL缓冲期内流量走了老路径
DNS记录从A切换到CNAME后,全球DNS节点刷新需要时间。
只要还有缓存节点在返回旧的源站IP，就有一部分用户直连源站，这部分流量处于裸奔状态。 建议切换前把原记录的TTL改小到60秒，等24小时缓存刷新完再切正式记录。
WAF和其他安全设备串联部署有什么不同
很多中大型网站不只有WAF这一层防护,前面还挂着Nginx、SLB负载均衡、甚至硬件防火墙，流量路径从原来的单一链路变成多层串联，这时要问自己一个问题：WAF到底串在哪个位置。
- 如果WAF串在SLB之前,WAF是入口，后端SLB和服务器全部隐藏在WAF后面，防护效果最好。
- 如果WAF串在SLB之后,只保护部分后端服务器，路径上多一跳转发，但其余服务器不受WAF影响，业务风险小。
有几类场景不建议把WAF串在链路中间：WebSocket长连接业务、上传下载大文件的服务、对延迟极度敏感的实时扣费接口。WAF对这类流量做深度检测会额外消耗时间，路径变长之后延迟感会非常明显。 可以考虑只对核心API接口单独拉一条WAF防护链路，其余流量走直连。
从成本角度看,企业网站接入WAF多少钱一直是需求方最关心的问题，云厂商的WAF按QPS和域名数计费，小型站点一年几千元，电商大促场景按弹性峰值计费的要好几万。买了WAF不把流量全量切过去的行为最不划算相当于给门口装了闸机却只让一半人走正门。 既然路径已经改过来了，就让所有流量都过一遍，把WAF的检测能力用满。
WAF回源IP设置和路径排查实操
路径变更后,验证链路是否正确的方法其实不难，下面这几个步骤，从上到下照着做一遍就能定位问题。
第一,先看解析结果，在本地终端执行dig www.example.com或nslookup www.example.com，确认解析结果指向的是WAF节点IP而不是源站IP，如果还是源站IP，说明DNS还没切好或缓存没刷新。
第二,看回源是否通，登录源站服务器，执行curl -H "Host: www.example.com" https://WAF回源IP -k -I，如果返回200状态码，说明回源链路通畅，如果超时或报错，检查防火墙和回源配置。
第三,开启WAF的日志功能，查看每条请求的详细链路耗时，在WAF日志里能看到客户端IP、WAF节点ID、源站响应耗时几个字段，如果源站响应耗时突然变大，可能回源网络链路有抖动。
第四,观察TCP连接状态，在源站上执行netstat -an | grep :443，看看有没有来自WAF回源IP段的ESTABLISHED连接，如果连接数很少或没有，流量可能还没走到WAF节点，检查解析记录或负载均衡配置。
安全组策略要不要跟随路径变化调整
这是一道送分题,但很多人会做错，接入WAF之后，源站理论上不再需要直接对公网开放80端口，安全组规则应当收紧，只允许WAF回源IP段访问源站的80/443端口，SSH管理端口尽量只对办公网IP开放或使用堡垒机。
按照行业共识,这是WAF接入后必须做的一步收敛动作，很多云厂商的控制台里可以直接选择“只允许WAF回源IP访问”的一键加固选项。
这里特别提一下防护模式的选择：WAF可以工作在观察模式和拦截模式，刚接入时先跑几天观察模式，让WAF学习正常流量基线，同时确认业务没有误报，再切到拦截模式，路径切换和防护策略切换分开做，出了问题也好定位。
WAF流量转发路径的常见问答
WAF会降低网站访问速度吗
多数情况下影响很小,WAF节点本身做了网络优化，加上就近接入，用户到WAF节点的延迟通常比直接连源站更低。真正影响速度的环节在回源链路，如果WAF机房和源站机房跨地域较远，比如WAF解析到了华北节点但服务器在华南，每跳一次回源就多一次地域往返，延迟会增加20-50毫秒，建议选WAF产品时看有没有源站就近回源的功能。
网站接入WAF后无法访问，从哪里开始排查
按优先级做三件事：先确认DNS解析结果是否指向WAF节点，再用telnet 源站IP 443测试源站端口可达性，最后登录WAF控制台查看回源日志有无五类典型报错连接超时、TLS握手失败、HOST不匹配、协议解析错误、触发频率限制，绝大多数接入故障都在这三个环节里。
免费WAF和付费WAF的流量转发路径有区别吗
底层链路逻辑没有本质区别,都是DNS指向WAF节点再回源，核心差异在于节点覆盖规模和回源线路质量，免费WAF通常是共享节点，高防能力有限，高峰期可能出现排队；付费WAF会分配独立实例，回源走BGP专线链路，延迟和稳定性更有保障，如果业务对可用性要求高于99.9%，建议选择付费独享实例，据中国信通院发布的云安全服务评估报告，国内主流云WAF的回源链路可用性均能达到电信级标准。
回到最初的问题：网站接入WAF之后流量转发路径会发生变化，本质上就是把源站从公网前台上撤下来，让WAF站到台前，DNS解析结果变了、数据链路变成了两段TCP连接、源站IP不再暴露在公网、安全策略需要针对新链路重新收敛，这四个变化是每一位站长在接入WAF前后必须想清楚的事，链路变了不怕，怕的是人没跟着变。
首发原创文章，作者：王坚，如若转载，请注明出处：https://idctop.com/article/632914.html
