开发者必读接入云waf需要考虑的问题接口和会话保持说明

1.

概述与准备工作

- 目标：将业务接入云WAF（Web Application Firewall），保证安全同时不影响会话和接口可用性。
- 前提：掌握当前架构（DNS、负载均衡、反向代理、后端节点）、有权限修改DNS与证书、能配置后端负载均衡。

2.

架构选型与流量路径确认

- 步骤1：绘制流量图（客户端 -> 云WAF -> 反向代理/负载均衡 -> 应用服务器）。
- 步骤2：确认TLS在哪一端终止（WAF端或业务端）。建议：WAF终止TLS并与后端使用TLS或短途明文视安全策略而定。明确后端端口和协议（HTTP/1.1、HTTP/2、WebSocket）。

3.

DNS与证书配置步骤

- 步骤1：把业务域名的A/AAAA或CNAME指向云WAF提供的地址（遵循云WAF说明）。
- 步骤2：上传或在WAF申请证书：如果WAF支持托管证书，使用托管更便捷；否则上传CSR签发并配置私钥和证书链。
- 步骤3：验证证书在WAF和客户端均可用，使用curl -v或浏览器检查TLS协商及证书链。

4.

真实客户端IP传递与代理协议

- 问题：后端需要得到真实客户端IP用于日志、会话或鉴权。
- 解决：在WAF上开启X-Forwarded-For头或Forwarded头；如果使用负载均衡（如HAProxy、NGINX）可启用Proxy Protocol。
- 操作：后端Web服务器（NGINX/Apache）配置接受并优先使用X-Forwarded-For或proxy_protocol，并在日志格式中记录真实IP。

5.

API接口兼容与请求头保留

- 步骤1：列出敏感或必需的头（Authorization、Cookie、X-Request-ID、Content-Type、Upgrade等）。
- 步骤2：在WAF策略中允许这些头通过，不做不必要的修改或删除。若WAF对某些头做拦截，配置白名单或规则例外。
- 步骤3：测试API：使用Postman或curl模拟常见API调用（含大body、分片上传、长连接），验证响应码与头部一致。

6.

会话保持（Session Affinity）策略选择

- 方法1（Cookie粘性）：WAF生成/插入一个sticky cookie指向后端节点ID。适合短会话且后端无共享session。
- 方法2（IP Hash）：根据客户端源IP做hash分配，适合无NAT或稳定公网IP场景。
- 方法3（应用层Session共享）：推荐方案，在后端使用Redis或数据库共享session，WAF无需粘性。
- 操作建议：优先选3，无法共享时选1，并确保Cookie为HttpOnly且Secure。

7.

实现会话保持的具体配置示例（思路）

- Cookie模式：在WAF控制台开启“会话粘性（sticky session）”，设置Cookie名称（如WAF_STICKY），过期策略（会话或固定时间）。
- IP Hash：在负载均衡器层面开启源IP散列；注意NAT/代理会影响该策略。
- Session共享：后端接入Redis，修改应用读取/写入session的存储驱动，测试故障切换。

8.

WebSocket与长连接的注意事项

- 确认WAF支持Upgrade头并允许Connection: Upgrade和Upgrade: websocket通过。
- 配置长连接超时：在WAF和后端都设置合适的keepalive/timeout，避免中间超时导致断开重连。
- 测试：使用wscat或浏览器长连接，模拟多连接并检查是否出现断连或会话丢失。

9.

健康检查、回源与故障转移配置

- 步骤1：在WAF或LB中配置主动健康检查（HTTP/HTTPS/TCP），路径建议使用轻量且返回200的专用健康接口。
- 步骤2：设置错误阈值（连续失败次数）和恢复阈值，配置流量自动切换到健康节点。
- 步骤3：在后端保证会话在切换后能继续（通过session共享或粘性续接策略）。

10.

测试、监控与故障排查流程

- 测试项：DNS解析结果、证书链、X-Forwarded-For是否传递、头部完整性、粘性是否生效、WebSocket稳定性、接口延时与错误率。
- 监控：开启WAF日志与指标（请求率、拦截率、延迟），后端日志同步记录真实IP与WAF头。
- 排查：先从WAF日志查拦截规则，再看后端接收的头与cookie，使用抓包（tcpdump）和curl对照。

11.

安全与性能优化建议

- 安全：启用WAF推荐规则集、Bot管理、速率限制（rate limiting）、异常行为检测，并对误报做规则调优。
- 性能：开启缓存静态资源、HTTP/2或QUIC（若WAF支持）、连接复用、合理的超时与keepalive，避免WAF成为性能瓶颈。

12.

常见问题与注意事项

- 注意NAT或云提供商LB会改变客户端源IP，影响IP粘性；优先使用X-Forwarded-For并在后端信任WAF IP段。
- 如果使用Proxy Protocol，确保后端服务开启对应解析，否则会报错。
- 对外暴露管理API和仪表盘时要做IP白名单或MFA。

13.

问：接入WAF后为什么日志里看到的都是WAF的IP而不是客户IP？

- 答：通常是因为WAF作为反向代理将请求转发时默认使用自己的源IP到后端。解决方法是在WAF上启用X-Forwarded-For或Proxy Protocol，并在后端Web服务器配置读取该头或解析proxy_protocol。

14.

问：我有Session依赖，会话粘性用Cookie和IP Hash哪个更稳定？

- 答：优先推荐把Session存到共享存储（Redis）以消除粘性需求。如果必须粘性，Cookie模式通常更稳定（受NAT影响小），但要注意Cookie安全配置与过期；IP Hash在有NAT/代理或公网IP变化时不可靠。

15.

问：如何验证WAF不会拦截合法API请求导致接口异常？

- 答：建立完整测试用例集（包含Authorization头、大体积POST、分块上传、WebSocket Upgrade），在WAF上先以“监控/学习”模式运行观察拦截日志并调整规则，确认无误后再启用拦截策略，同时在CI流程中加入集成测试以防回归。