小林博客结合 WAF 技术原理与 PCDN 刷流量的特性，这种 IP 统计缺失的现象主要源于二者在技术架构、协议支持及流量特征上的根本性矛盾，具体原因可拆解为以下四类核心因素：
一、流量路径绕开 WAF 监测范围
- CDN 与 WAF 部署层级冲突
多数云 WAF 通过 DNS 解析将流量引流至防护集群（如阿里云盾、百度云加速），而 PCDN 作为分布式内容分发网络，其节点流量通常直接对接源站的 CDN 节点，而非经过 WAF 防护层。例如若您同时使用第三方 CDN 与云 WAF，PCDN 请求可能通过 CDN 的私有链路直达源站，完全脱离 WAF 的流量监控视野。
- 源站 IP 暴露导致直连绕过
部分 PCDN 刷量工具会通过端口扫描、DNS 历史记录等方式获取网站真实 IP，直接向源站发起请求。由于 WAF 仅防护通过 DNS 解析指向的域名流量，这类直连请求自然无法被统计。您举报信中提及的 23 个 IPv6 节点（如 240e:e9:b00c::4:8860）可能正是通过这种方式绕开防护。
二、PCDN 的技术特性规避 WAF 识别
- 分布式动态 IP 池的隐蔽性
PCDN 依赖海量家庭宽带边缘节点，其 IPv6 地址（如您提供的 240e:e9:b00c::4/96 网段）具有动态分配、短时存活的特点，单节点请求量可能低于 WAF 的异常检测阈值（通常单 IP 每秒请求 > 100 次才触发告警）。这种 "低频次、广分布" 的特征会被 WAF 判定为正常用户流量。
- P2P 协议与非标准端口传输
PCDN 大量使用 BitTorrent、WebRTC 等 P2P 协议，部分请求通过 UDP 协议或非标准端口（如 8081、8443）传输。而传统 WAF 主要监控 80/443 端口的 HTTP/HTTPS 流量，对非标准协议及端口的支持不足，导致相关 IP 完全脱离统计范围。
三、WAF 自身的技术局限性
- IPv6 协议兼容性缺陷
多数老旧 WAF 对 IPv6 协议的解析能力不完善，存在字段识别错误、日志记录缺失等问题。您提供的涉案 IP 均为 IPv6 地址，若 WAF 未完成 IPv6 适配升级，可能出现 "流量可见但 IP 字段为空" 的统计断层。
- 请求参数解析上限与过滤盲区
为避免 DDoS 攻击，WAF 通常限制单请求的参数数量（如 nginx+luawaf 默认仅解析前 100 个参数），而 PCDN 刷量工具会构造超量冗余参数，将真实请求特征隐藏在未解析字段中。此外，部分工具通过multipart/form-data协议传输请求，若 WAF 未覆盖该协议检测规则，也会导致 IP 统计遗漏。
四、HTTP 头伪造与代理隐藏真实 IP
- X-Forwarded-For 字段篡改
PCDN 节点会伪造 HTTP 头中的X-Forwarded-For（XFF）字段，将真实 IP 替换为虚假的用户 IP（如 127.0.0.1 或随机公网 IP）。多数 WAF 默认以 XFF 字段作为客户端 IP 来源，而非提取 TCP 连接层的真实 IP，导致统计结果完全失真。
- 多层代理混淆溯源路径
涉案 IP（如 240e:e9:b00c::4:fc14）可能通过 2-3 层透明代理发起请求，WAF 仅能记录最外层代理 IP，而无法穿透代理获取真实的 PCDN 节点 IP。这种代理链设计使得 IP 溯源难度极大，直接造成统计缺失。
解决建议（结合您的举报场景）
- 调整 WAF 部署架构：将 WAF 串联部署在 CDN 与源站之间，确保所有 CDN 节点流量必须经过 WAF 检测；
- 升级 IPv6 防护规则：开启 WAF 的 IPv6 协议解析功能，添加涉案网段 240e:e9:b00c::4/96 至重点监控列表；
- 跨日志关联核验：结合 CDN 服务商提供的原始访问日志（含 TCP 层真实 IP）与 WAF 日志交叉比对，补全缺失的 IP 记录（可作为举报信补充证据）；
- 启用行为分析引擎：通过 WAF 的机器学习模块（如 "魔力象限 APP" 的行为分析算法），基于请求频率、Cookie 一致性等特征识别 PCDN 节点，而非依赖单一 IP 统计。
