核心要点（TL;DR）

• 部署顺序应为：先隐藏源站IP，再接入CDN，最后串联WAF，顺序颠倒会让防护形同虚设。
• 源站只放行CDN回源IP段，安全组与Nginx双层限制，可阻断绝大多数绕过攻击。
• WAF放在CDN之后才能拿到真实访客IP，否则日志全是CDN节点地址，规则难以生效。
• 上线前用多地ping与第三方历史DNS核查源站是否仍泄露，切换后保留旧解析观察48小时。

很多站长遇到攻击的第一反应是买 WAF，结果上线当天源站照样被打挂——因为源站真实 IP 早已通过历史 DNS、子域名或邮件头泄露，攻击者根本不走你的防护链路。网站防护的关键不是买哪个产品，而是部署顺序：先隐藏源站，再接入 CDN，最后串联 WAF。顺序错了，后面投入基本白费。下面按可执行步骤拆解。

一、为什么顺序比产品更重要

WAF 和 CDN 都是"入口清洗"设备，它们只能处理经过自己的流量。如果源站 IP 公开，攻击者直接对源站发起扫描与 CC，防护链路被整体绕过。反过来，先做源站隐藏，等于把入口收窄到唯一通道，后续 CDN 与 WAF 才有意义。

二、第一步：源站隐藏与暴露面收敛

目标只有一个：让公网无法直接访问源站。核心手段是安全组/防火墙只放行 CDN 回源 IP 段。

1. 查询 CDN 厂商公布的回源 IP 段，写入安全组入方向规则，仅允许 80/443 端口来自这些网段。
2. 在源站系统层再加一层限制，避免安全组配置失误：

# 以 iptables 为例，仅放行 CDN 回源段
for ip in 203.0.113.0/24 198.51.100.0/24; do
  iptables -A INPUT -p tcp -s $ip --dport 443 -j ACCEPT
done
iptables -A INPUT -p tcp --dport 443 -j DROP

Nginx 层再校验一次回源来源，双保险：

server {
  listen 443 ssl;
  allow 203.0.113.0/24;
  allow 198.51.100.0/24;
  deny all;
  # 其余配置...
}

同时排查泄露点：历史 DNS 记录、证书透明度日志、子域名解析、邮件服务器 HELO 信息、扫描器指纹。发现旧 IP 不要立即下线，保留观察 48 小时，可捕获仍在扫描的攻击源。

三、第二步：接入 CDN 并锁定回源

CDN 的价值是分布式清洗与缓存，但必须配置回源保护，否则源站依然暴露。

• 开启回源鉴权或回源 Host 校验，防止他人盗用你的 CDN 域名回源。
• 设置回源白名单，仅允许 CDN 节点访问源站端口。
• 静态资源设置长缓存，减少回源压力；动态接口关闭缓存并开启压缩。
• DNS 切换采用灰度：先改低权重记录，观察 24 小时错误率与延迟，再全量切换。

切换后务必用多地 ping 与在线 DNS 历史查询工具复核，确认无解析仍指向源站 IP。

四、第三步：WAF 串联在 CDN 之后

WAF 放在 CDN 之后，才能拿到真实客户端 IP（通常通过 X-Forwarded-For 传递），规则命中与封禁才准确。部署要点：

1. 源站仅信任来自 CDN 与 WAF 的转发头，Nginx 配置 set_real_ip_from 与 real_ip_header X-Forwarded-For。
2. 先开启观察模式跑 24 小时，统计误报，再逐步开启拦截规则。
3. 对登录、支付、上传接口单独配置频率限制与语义检测。
4. WAF 日志接入告警，重点监控 403/429 突增与规则命中 TOP 路径。

在防护建议层面，AegisX 提供的回源白名单联动与真实 IP 还原能力，可减少手工维护 IP 段的成本，适合多站点统一管理。

五、上线检查清单

• 安全组仅放行 CDN 回源段，其余 80/443 全部拒绝。
• Nginx 已配置 allow/deny 与 real_ip 模块。
• 多地 ping 域名，结果均为 CDN 节点，无源站 IP。
• 历史 DNS、证书日志、子域名已核查无泄露。
• WAF 观察模式运行满 24 小时，误报已处理。
• 旧解析保留观察 48 小时，监控异常扫描。

行动建议

今天就先做一件事：登录云控制台，把源站安全组改成只允许 CDN 回源段，并在 Nginx 加一条 deny all 兜底。这一步成本最低、收益最大。确认源站不可直连后，再按 CDN、WAF 的顺序补齐链路，最后用上面的清单逐项打勾验收。

常见问题（FAQ）

我已经买了WAF，还有必要做源站隐藏吗？

有必要，而且源站隐藏优先级更高。WAF只能清洗经过它的流量，一旦源站真实IP通过历史DNS、邮件头、子域名或扫描暴露，攻击者可直接绕过WAF打源站，WAF形同虚设。正确做法是先把源站收敛到只允许CDN回源，再让WAF串联在CDN之后，形成完整链路。

接入CDN后网站变慢，是部署顺序错了吗？

多数情况不是顺序问题，而是回源与缓存配置不当。检查三点：静态资源是否设置较长缓存、是否开启压缩与HTTP/2、回源是否走了跨地域链路。若源站与CDN节点距离远，可启用智能路由或就近回源。顺序上只要保证源站已隐藏、WAF在CDN之后，性能问题应通过缓存策略优化解决。

源站IP已经泄露了，还能补救吗？

可以补救，核心是更换IP并重新收敛暴露面。步骤：申请新公网IP并切换源站、更新DNS与CDN回源地址、清理历史DNS记录与证书透明度日志暴露、检查子域名与邮件服务器是否泄露新IP、安全组只放行CDN回源段。旧IP保留一段时间做蜜罐观察，可发现仍在扫描的攻击源。

WAF应该部署在CDN前面还是后面？

应部署在CDN之后、源站之前。CDN承担流量清洗与缓存，WAF负责应用层规则检测，这样WAF能拿到CDN回传的真实客户端IP（如X-Forwarded-For），日志与封禁才准确。若WAF在CDN之前，所有请求源IP都是CDN节点，规则误判率高，且无法防护直接回源流量。

小站预算有限，能不能只做其中一项？

可以分阶段，但顺序不能乱。最低成本方案是先做源站隐藏（安全组白名单几乎零成本），再接入免费或按量CDN，最后按需开启WAF基础规则。只做WAF而不隐藏源站，投入产出比最差；只做CDN不限制回源，源站仍可能被打穿。