IPv6 改造在国内推进了多年，不少站点已经上线 AAAA 记录。但很多站长没意识到：开了 IPv6 之后，防护体系会出现一个新的缺口——原来的高防、清洗节点、限速策略可能压根不支持 IPv6。本文用 9 个问答讲清 IPv6 环境下的真实 DDoS 风险、AAAA 记录泄露源站这个最大的坑、IPv6 独有的攻击面和对应的加固配置。
Q：开了 IPv6 之后，DDoS 风险是变大还是变小？
整体判断是：攻击者能打的入口变多了，而你的防护覆盖度下降了，所以实际风险是上升的。
原因不复杂。IPv6 部署明显滞后于防护能力：很多老旧高防设备、部分 CDN 节点、不少自建限速规则都只写了 IPv4 逻辑。当你的域名同时解析出 A 和 AAAA 两条记录时，攻击者只要发现 IPv6 这条路上没有清洗，就会优先从那里打——这叫防护降级绕过，是 IPv6 场景下最常见的实战问题。
另外要纠正一个常见误解：IPv6 本身没有任何抗 DDoS 能力。地址空间大只是让全端口扫描变得不现实，跟“能不能扛住流量型攻击”完全是两件事。
Q：IPv6 没有 NAT，是不是更容易被打？
要分开看，结论和直觉相反。
一个真实的好消息：IPv6 取消 NAT 后，内网终端不再被地址转换隐藏，这确实让终端暴露面变大；但反过来，没有 NAT 意味着服务端收到的源地址更少被改写，很多依赖源地址伪造的反射放大攻击在 IPv6 下的成功率反而更低——因为大量运营商的 IPv6 边界会做源地址校验（BCP 38 的 IPv6 版本）。
但真正的麻烦在别处：IPv6 单个子网通常是 /64，一个 /64 里有约 1.8×1019 个地址。如果攻击者（或分布式爬虫）拥有一个 /64，它可以在整段里随意换地址发起请求，你按单个 IP 做的 limit_req 限频直接形同虚设——每个地址只发一次就换下一个，永远碰不到阈值。
这才是 IPv6 环境最需要重新设计的防护逻辑：限速维度要从“单 IP”升级为“前缀”。
Q：为什么说「AAAA 记录泄露源站」是 IPv6 最大的坑？
因为这是绕过全部前端防护最简单的一条路。
典型事故长这样：站点主域名接了 CDN，A 记录指向 CDN 节点，防护正常；但运维在源站上顺手开了一条 AAAA 记录，直接指向源站服务器的 IPv6 地址。攻击者只要解析出 AAAA，就看到源站真实地址，接下来无论 CC 还是 DDoS，全部直奔源站——CDN、WAF、高防全部失效。
更隐蔽的是，泄露往往不只来自主域名的 AAAA。这些地方都会漏：
- 历史遗留的子域名（比如 old、test、dev、mail）单独配了 AAAA 记录指向源站
- 域名曾用过第三方服务，当时留下的解析记录没清理
- 证书透明度日志（CT log）暴露了子域名，顺藤摸瓜找到解析记录
- 邮件服务、监控探针、旧版管理后台的上线记录
处置办法只有一个：源站 IP（含 IPv6）永远不出现在公网 DNS 里。所有对外解析都必须指向 CDN / 高防节点，源站只允许节点回源。
Q：怎么查自己的网站有没有暴露源站 IPv6 地址？
三步自查，五分钟能做完。
第一步，查主域名和常见子域名的 AAAA：
for h in example.com www.example.com old.example.com test.example.com dev.example.com; do
echo "== $h =="; dig AAAA $h +short
done第二步，做全网子域名爆破式核对，把历史遗留的子域名翻出来（CT 日志是最好用的入口）：
curl -s "https://crt.sh/?q=%25.example.com&output=json" \
| python -c "import sys,json;print('\n'.join(sorted({x['name_value'] for x in json.load(sys.stdin)})))" \
| sort -u第三步，逐个解析出来的地址做归属确认：
dig AAAA old.example.com +short | while read ip; do
echo -n "$ip "; curl -s "https://ipinfo.io/$ip/org"; echo
done判断标准很简单：解析出来的 IPv6 如果归属是你的服务器所在地域 / 机房，那就是源站泄露；如果归属是 CDN 厂商，才是正常配置。
Q：IPv6 有哪些独有的攻击面？
有四类需要单独防，很多防护设备默认不检查：
- IPv6 分片攻击。IPv6 的分片由扩展头实现，很多设备解析扩展头的能力弱，攻击者用大量碎片包消耗目标的重组资源。要确认你的防护设备是否具备 IPv6 分片重组与异常检测能力。
- 扩展头滥发。攻击者可以在包上串联大量或超长的扩展头，未做上限校验的设备会消耗大量 CPU。建议在边界直接丢弃携带异常扩展头的包。
- ICMPv6 洪水。ICMPv6 是 IPv6 的必要协议（邻居发现依赖它），不像 ICMP 可以粗暴全封。正确做法是限速而不是拒绝，否则会破坏正常的地址解析。
- RA / NDP 欺骗类攻击。在二层网络里伪造路由通告或邻居发现报文，抢走网关身份，常见于 IDC 内网和云上同网段环境。这类攻击要靠交换机端口安全和网段隔离解决，服务器侧基本无能为力。
Q：高防 / CDN 不支持 IPv6 怎么办？
这是国内站点最常碰到的现实问题，三个处理层次，按优先级选。
第一，优先换支持 IPv6 的防护节点。接入前一次性问清三件事：高防节点是否支持 IPv6 回源、清洗策略是否对 IPv6 同样生效、日志里能不能看到 IPv6 客户端地址。只买“支持 IPv6 访问”但不做 IPv6 清洗的方案，等于没防。
第二，如果暂时换不了，就干脆不给公网 IPv6 解析。只保留 A 记录，把 AAAA 全部清掉。国内 IPv6 改造的合规要求通常针对政务、教育、门户类站点，一般企业站和电商站并非强制；在防护能力跟上之前，“先不开”比“开了没防”安全得多。
第三，必须同时提供 IPv6 访问时，走分层架构。让源站只保留 IPv4 回源，对外 IPv6 全部由 CDN / 云 WAF 处理，源站 IPv6 地址完全不对外、不入 DNS。这样即使 CDN 的 IPv6 清洗能力弱，源站至少不会被直接打穿。
Q：源站 IPv6 侧怎么加固？
按边界、内核、应用三层做。
边界层：ICMPv6 限速，不放任也不全封。
# 允许必要的邻居发现与差错报文（限速），其余 ICMPv6 丢弃
ip6tables -A INPUT -p ipv6-icmp --icmpv6-type 128 -m limit --limit 50/s --limit-burst 100 -j ACCEPT
ip6tables -A INPUT -p ipv6-icmp --icmpv6-type 135 -m limit --limit 100/s -j ACCEPT
ip6tables -A INPUT -p ipv6-icmp --icmpv6-type 136 -m limit --limit 100/s -j ACCEPT
ip6tables -A INPUT -p ipv6-icmp -j DROP
# 丢弃带分片的异常包（按业务实际情况调整，别一律关掉分片）
ip6tables -A INPUT -f -j DROP内核层：同步队列与连接跟踪防护。注意 TCP syncookies 在 Linux 里是 IPv4 / IPv6 共用的，不需要单独开，但连接跟踪表要单独关注 IPv6：
sysctl -w net.ipv4.tcp_syncookies=1 # 同时保护 IPv4 与 IPv6 TCP
sysctl -w net.ipv4.tcp_syn_retries=2
sysctl -w net.core.somaxconn=1024
cat /proc/sys/net/netfilter/nf_conntrack_count # 看连接跟踪表是否被打满如果不打算提供 IPv6 服务，最干净的做法是直接关掉：
sysctl -w net.ipv6.conf.all.disable_ipv6=1应用层：Nginx 明确监听与兜底。建议始终配置一个 default server 兜掉未匹配的 IPv6 请求，避免流量进入默认站点逻辑：
server {
listen [::]:80 default_server;
listen [::]:443 ssl default_server;
server_name _;
return 444; # 直接断开，不返回任何内容
}Q：IPv6 环境下限速和日志要注意什么？
三个必须改的点。
第一，限速维度要从 /32 改成 /64 前缀。Nginx 原生不支持按前缀聚合限速（limit_req_zone 的 key 只能是完整地址或变量），所以推荐两条路并行：
短期在日志侧聚合，找出同一 /64 下的高频请求，人工确认后再封前缀：
awk '{n=split($1,a,":"); print a[1]":"a[2]":"a[3]":"a[4]}' /var/log/nginx/access.log \
| sort | uniq -c | sort -rn | head -20长期靠 支持前缀聚合的云 WAF / CDN 做策略，把“同一 /64 前缀每分钟超过 N 次”作为独立规则，这是 IPv6 场景下唯一可靠的限频方式。
第二，日志格式要能容纳 IPv6 长地址。自建日志解析脚本和正则要确认不会截断 IPv6 地址，否则分析结果全是错的。建议在 log_format 里统一增加 $remote_addr 与 $http_x_forwarded_for，并在有 CDN 时正确还原真实客户端地址。
第三，告警要分协议看。很多监控只统计 IPv4 带宽和连接数，IPv6 流量异常时不告警。接入 CDN 后要单独确认 IPv6 的 QPS 与带宽曲线是否在监控里。
Q：还有什么补充建议？
把 IPv6 的检查动作清单化，接站或改站时逐条过一遍：① 查全部子域名的 AAAA 记录 → ② 确认没有 AAAA 指向源站 → ③ 确认高防 / CDN 对 IPv6 同样生效 → ④ 配置 default server 兜底 → ⑤ ip6tables 限速 ICMPv6 与分片 → ⑥ 限频维度升级到 /64 前缀 → ⑦ 监控补齐 IPv6 曲线。
归根到底一句话：IPv6 不是防护能力，它是一条新增的攻击路径。上线 IPv6 之前，先把防护侧的覆盖度补上；补不上的时候，宁可不解析 AAAA，也不要留一条绕过全部清洗的直连通道。对于同时跑 IPv4 与 IPv6 的站点，最实用的架构是让清洗和识别统一在边缘完成，源站两种协议都只接受节点回源，这样 IPv6 的复杂度就被隔离在边缘层，不会传导到源站。