SSL 卸载 + WAF + 抗 D：高防 CDN 一站式解决 HTTPS 性能与安全

**摘要：**HTTPS 已经成为网站标配，但 TLS 握手带来的性能开销、证书管理的复杂度，以及随之而来的 DDoS 与 Web 攻击风险，让很多团队在"安全"和"性能"之间反复权衡。本文从 SSL 卸载、WAF 防护、抗 D 清洗三个维度出发，说明高防 CDN 如何把这三件事收敛到一条链路上，并给出可落地的配置思路与验证方法。

一、为什么 HTTPS 会成为性能与安全的双重负担

启用 HTTPS 之后，一次完整的访问链路会多出 TLS 握手、证书校验、对称加解密等环节。对于单机部署的业务，这些开销直接压在源站服务器上，具体表现为：

握手开销：TLS 握手需要额外的网络往返，高延迟链路下首屏时间明显变长。
CPU 消耗：RSA 解密和对称加密都会占用 CPU，高并发场景下源站 CPU 容易被打满。
连接复用成本：会话票据、会话缓存配置不当，会导致重复握手。
证书运维：证书申请、续期、多域名管理、协议版本与加密套件升级，都需要持续投入。

与此同时，HTTPS 并不能抵御 DDoS 攻击和 Web 层攻击。攻击者依然可以用海量连接耗尽握手资源，或者用 SQL 注入、XSS、恶意爬虫等方式穿透到应用层。也就是说，HTTPS 解决的是传输安全，而不是可用性安全。

二、三个能力各自解决什么问题

2.1 SSL 卸载：把加解密从源站挪走

SSL 卸载（SSL Offloading）的核心思路是：客户端与边缘节点之间完成 TLS 握手和加解密，边缘节点再以 HTTP 或 HTTPS 回源。这样源站不再承担握手与加解密的 CPU 开销，只需专注业务逻辑。

典型收益包括：

源站 CPU 占用下降，同等配置下可承载更高并发。
证书统一托管在边缘，续期和替换不影响源站。
可以在边缘统一收敛 TLS 版本、加密套件和 HSTS 策略。
支持 HTTP/2、HTTP/3 等新协议，而无需改造源站。

注意：如果回源链路走公网，建议回源也启用 HTTPS，避免"边缘加密、回源明文"造成中间链路泄露。

2.2 WAF：拦截应用层攻击

WAF（Web Application Firewall）工作在应用层，主要针对 OWASP Top 10 类攻击，例如 SQL 注入、XSS、命令注入、路径穿越、恶意文件上传等。部署在 CDN 边缘的云 WAF 有几个明显优势：

攻击流量在边缘被拦截，不会打到源站。
规则库集中更新，0day 爆发时可以快速下发虚拟补丁。
支持自定义规则，可针对业务接口做精细化防护。
日志与告警集中，便于溯源和审计。

WAF 的常见模式分为拦截模式 和观察模式。新上线业务建议先跑观察模式，确认误报情况后再切换为拦截，避免正常业务请求被误杀。

2.3 抗 D：清洗大流量攻击

DDoS 防护主要应对流量型攻击（UDP Flood、SYN Flood、ICMP Flood）、连接型攻击和应用层 CC 攻击。高防 CDN 通常具备分布式清洗能力：

流量型攻击：通过 Anycast 或调度把流量牵引到清洗中心，丢弃异常包。
连接型攻击：通过 SYN Cookie、连接限速等手段缓解。
CC 攻击：结合频率控制、人机校验、行为分析进行识别。

抗 D 的关键不只是"扛得住峰值"，还包括清洗的精准度------误杀正常流量和放过攻击流量同样糟糕。

三、高防 CDN 如何把三者串成一条链路

把 SSL 卸载、WAF、抗 D 放在同一条链路上，请求会依次经过以下环节：

这条链路的价值在于顺序合理：先做 TLS 终结，才能解析出 HTTP 层内容供 WAF 检测；先做流量清洗，才能避免攻击流量消耗 WAF 的检测资源；最后才回源，最大限度保护源站。

3.1 关键配置要点

环节	配置要点	建议
TLS 终结	协议版本、加密套件、证书	禁用 TLS 1.0/1.1，优先 TLS 1.2/1.3，开启 OCSP Stapling
回源	回源协议、回源 Host	优先 HTTPS 回源，回源 Host 与证书域名保持一致
抗 D	清洗阈值、黑白名单	按业务基线设置阈值，避免过低导致误清洗
WAF	规则集、观察/拦截模式	先观察后拦截，重点接口单独配置规则
缓存	缓存规则、缓存键	静态资源长缓存，动态接口不缓存或短缓存

3.2 一个 Nginx 侧的 TLS 配置参考

如果源站仍需自行处理 TLS（例如内网回源），可以参考下面的配置，核心是收敛协议版本与加密套件：

nginx 复制代码

server {
    listen 443 ssl http2;
    server_name example.com;
ssl_certificate     /etc/nginx/certs/example.com.pem;
ssl_certificate_key /etc/nginx/certs/example.com.key;
只保留安全的协议版本
ssl_protocols TLSv1.2 TLSv1.3;
ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384;
ssl_prefer_server_ciphers on;
会话复用，减少重复握手
ssl_session_cache shared:SSL:10m;
ssl_session_timeout 10m;
ssl_session_tickets on;
OCSP Stapling
ssl_stapling on;
ssl_stapling_verify on;
add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;
location / {
proxy_pass http://127.0.0.1:8080;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
}
}

其中 X-Forwarded-Proto 很关键：源站应用需要靠它判断原始请求是否为 HTTPS，否则容易出现重定向循环或生成的链接协议错误。

四、落地时容易踩的坑

4.1 真实客户端 IP 丢失

接入 CDN 后，源站看到的 remote_addr 是边缘节点 IP。需要通过 X-Forwarded-For 或厂商提供的真实 IP 头还原客户端地址，并在应用层做可信代理校验，避免伪造头被滥用。

4.2 证书与域名不匹配

多域名、泛域名、多级子域场景下，证书覆盖范围容易出错。建议在接入前用工具逐域名校验证书链完整性，并确认 SNI 配置正确。

4.3 WAF 误杀正常业务

文件上传、富文本提交、JSON 接口等场景容易触发规则误报。建议：

先开启观察模式，收集一周左右的命中日志。
对高频误报规则做白名单或规则调优。
再切换为拦截模式，并保留回滚开关。

4.4 抗 D 阈值设置不合理

清洗阈值过低会把正常促销流量当成攻击清洗掉，过高则起不到防护作用。建议基于历史流量做基线，并配置业务高峰期的临时策略。

五、效果验证与监控

上线后需要从性能和安全两个维度持续验证：

性能：对比接入前后的 TTFB、首屏时间、TLS 握手耗时，观察源站 CPU 与连接数变化。
安全：关注 WAF 拦截量、攻击类型分布、清洗流量峰值、CC 攻击拦截情况。
可用性：配置多节点探测，确保边缘节点异常时能及时切换。

可以用下面的命令快速检查 TLS 配置是否符合预期：

bash 复制代码

# 查看协议版本与加密套件
openssl s_client -connect example.com:443 -servername example.com < /dev/null
检查证书有效期
echo | openssl s_client -connect example.com:443 -servername example.com 2>/dev/null 
| openssl x509 -noout -dates -subject

六、总结

SSL 卸载解决的是性能与证书运维 问题，WAF 解决的是应用层攻击 问题，抗 D 解决的是大流量与连接耗尽问题。三者单独使用都有短板，而高防 CDN 把它们按"TLS 终结 → 流量清洗 → 规则检测 → 缓存回源"的顺序串起来，既减少了源站压力，也让防护更贴近攻击发生的位置。

落地时的建议是：先做 TLS 配置收敛和证书托管，再以观察模式引入 WAF，最后结合业务基线调优抗 D 策略，并建立持续的性能与安全监控。