买了防护却接不上去，或者接上去以后发现解析被架空、回源全挂，问题多数出在接入方式上。DDoS防护接入方式决定了流量走哪条路、切换有多快、回退有多难。本文用 10 个问答对比 CNAME 代理、NS 托管、高防 IP 直挂与本地清洗四种方式的切换与回退路径。
Q：DDoS防护的接入方式一共有哪几种？
- 市面上所有方案都可以归到四类，区别只在流量在哪一层被改变路径：
- CNAME 代理：域名解析指向防护节点域名，流量先到防护节点再回源。改一条记录即可上线，中小站点最常用。
- NS 托管：把整个域名的解析交给防护服务商，所有记录（含泛解析与邮件）都经过它。控制力最强，切换成本也最高。
- 高防 IP 直挂：域名 A 记录直接指向高防 IP。适合需要指定 IP、或者业务不走 HTTP 的场景。
- 本地清洗设备：在自有网络里串联或旁路部署清洗设备，配合 BGP 会话牵引异常流量。适合有自建机房与自有 IP 段的团队。
Q：CNAME 代理接入是怎么工作的，适合谁？
- 原理是把「域名解析结果」从源站 IP 换成防护节点域名，回源的源站地址只在防护平台侧配置。
- 优点是接入快、不动源站网络、源站 IP 不出现在任何解析记录里，HTTPS 证书可在防护平台托管，源站只需放开防护节点的回源段。
- 缺点：受 TTL 与递归缓存影响，切换不是瞬间生效；很多解析服务商不允许在裸域名上做 CNAME，apex 记录要另找方案；只覆盖 HTTP 与 HTTPS，邮件与数据库等端口不经过防护。业务以网站为主、源站没有固定 IP 需求时，CNAME 代理是最稳的起点。
# 接入后确认解析是否真的指到防护节点
dig +short www.example.com
dig CNAME www.example.com +short
# 查看解析生效范围（多地递归对照）
for r in 223.5.5.5 119.29.29.29 8.8.8.8; do echo "$r:"; dig +short @$r www.example.com; doneQ：什么情况下该用 NS 托管接入？
- 当域名下记录多、存在泛解析、或者不止一个入口需要防护时，NS 托管比逐条改 CNAME 更可控：解析权整体交给服务商，新增子域名、调整记录都在防护平台完成，不会再出现「漏改一条记录就打回源站」。
- 代价是：接入要改注册商的 NS，生效时间长于改 A 记录；回退同样要改回 NS，存在窗口期；全部解析权交给一家服务商本身也是一次风险集中。切换前要把原有记录完整导入并在防护平台核对一遍（尤其 MX 与 SPF），切换后先验证邮件收发，再验证网站。
Q：高防 IP 直挂和 BGP 牵引怎么选？
- 两者都属于「在 IP 层改变路径」，区别在业务入口 IP 是否要变：
- 高防 IP 直挂：域名 A 记录改指高防 IP，入口 IP 会变；适合单线线路、或业务不属于 HTTP 的场景（如游戏长连接端口）。
- BGP 牵引：入口 IP 不变，靠路由公告把流量引到清洗中心，被打时对外地址无感；适合自有 IP 段与自建 BGP 机房的团队。
- 判断标准：需要保持入口 IP 不变的选牵引；能接受改解析、只需挡 HTTP 攻击的选直挂或 CNAME 代理。直挂模式下源站必须只放行高防回源段。
Q：本地清洗设备串联还是旁路部署？
- 串联：所有流量都要穿过设备，防护效果确定，但设备本身是单点：它挂了业务直接断，容量必须覆盖业务峰值。
- 旁路：设备不承载正常流量，只在检测到异常时通过 BGP 牵引过来。前提是具备与上游建立 BGP 会话的能力，规模小的团队通常做不到。
- 折中做法：日常用旁路加告警，容量不足的部分交给云端防护兜底。
Q：四种接入方式怎么对比着选？
- 按关键维度对比，可以直接对照自己的情况打分：
CNAME 代理 | 切换：慢（受 TTL 影响） | 源站：隐藏 | 端口：仅 HTTP/HTTPS | 回退：低
NS 托管 | 切换：最慢（改 NS） | 源站：隐藏 | 端口：全记录类型 | 回退：中
高防 IP 直挂| 切换：中 | 源站：隐藏 | 端口：任意 | 回退：低
本地清洗 | 切换：最快（路由牵引） | 源站：不变 | 端口：任意 | 回退：中- 常见的组合方式：网站用 CNAME 代理接入云防护，游戏或长连接业务用高防 IP 指定端口，自建机房再用本地设备做第一层过滤。选型的核心是哪种方案的失败路径你能承受。
Q：接入过程最容易踩哪些坑？
- 按出现频率排序，前五项覆盖了绝大多数上线故障：
- 回源白名单没配：源站只允许防护节点回源这一条没做，等于大门敞开。证书没上传会告警且回源走明文，放行规则太严又会挡掉防护平台的探测源。
- 拿不到真实客户端 IP：接入后日志里全是防护节点地址，限流与封禁全部失效。需要按服务商要求读取对应头部并校正。
- 邮件与其他记录被带走：NS 接入时漏了 MX 与 SPF，网站正常但邮件全挂，第二天才发现。
# 让源站日志拿到真实客户端 IP（Nginx 示例，头部名称以服务商文档为准）
set_real_ip_from 203.0.113.0/24; # 可信回源段，不要写成 0.0.0.0/0
real_ip_header X-Forwarded-For;
real_ip_recursive on;
# 验证：源站日志里应当出现真实用户 IP，而不是防护节点 IP
tail -n 20 /var/log/nginx/access.log | awk '{print $1}' | sort | uniq -c- 特别提醒：
set_real_ip_from一定要写具体的回源段，写成任意来源等于允许任何人伪造客户端 IP。
Q：切换接入方式时怎么做到业务不中断？
- 核心是把「切换」拆成「准备、灰度、观察、收尾」四步，每一步都可回退：
- 准备：提前 24 小时把相关记录 TTL 降到 60 至 300 秒，备份当前全部解析记录，把回退操作写成可复制的命令。
- 灰度：先切一个非核心子域名（例如 static 或测试域名），确认回源、证书、真实 IP、健康检查正常，再切主域名。
- 观察：对比切换前后的错误率、首字节时间、回源成功率与下单成功率，至少观察一个完整业务高峰，再清理旧记录与旧 IP 残留。
# 不依赖 DNS 直接验证防护节点回源是否正常（绕过解析缓存）
curl -sI --resolve www.example.com:443:203.0.113.10 https://www.example.com/ | head -5
# 对比直连源站与经防护节点访问的响应差异
curl -so /dev/null -w 'via armor: %{http_code} %{time_total}\n' https://www.example.com/
curl -so /dev/null -w 'direct : %{http_code} %{time_total}\n' -H 'Host: www.example.com' https://198.51.100.20/- 回退方案必须写在工单里并且演练过一次，别等出事时才发现没人记得原来的记录长什么样。
Q：怎么验证防护真的生效了？
- 四个验证角度，缺一个都不算接好：
- 解析侧：多地递归解析结果一致指向防护节点，裸域名与主要子域名全覆盖，无漏网记录。
- 回源侧：用源站 IP 直连并伪造 Host 头，应当被拒绝或返回非业务内容，说明回源已收口。
- 数据侧：防护平台显示有流量经过，同时源站日志看不到攻击流量——两个条件同时成立，才叫防护生效。
# 源站收口自查：直连源站应当拿不到正常业务响应
curl -sI -m 5 -H 'Host: www.example.com' https://198.51.100.20/ | head -3Q：还有什么补充建议？
- 按规模给优先级：小站先把 CNAME 代理加源站收口做扎实，成本最低、覆盖最广；中等规模再考虑多线路多入口；只有自有 IP 段与自建机房的团队才值得上牵引与本地清洗。
- 最后一句判断标准：防护供应商的数据漂亮不算数，源站的日志干净才是真的接好了。接入路径也要画进架构图并标注责任人，多数应急混乱的根源是没人说得清流量怎么走。