直接回答：识别手段：多 resolver 对比（同一域名分别用运营商 DNS、223.5.5.5、8.8.8.8 查询，结果差异异常即嫌疑）、dig +trace 走权威链验证真实答案、DoH/DoT 加密查询绕过本地劫持做对照。劫持典型症状：解析到陌生 IP（广告注入、钓鱼）、TTL 被篡改；污染典型：随机错误 IP 或 RST 注入（GFW 特征）。
展开解析：CDN 调度的精度困境：权威 DNS 看到的是 local DNS 的 IP 而非用户真实 IP——用户用北京联通的 LDNS，CDN 就把他调度到北京节点，即便人实际在云南；大型公共 DNS（114、阿里）集中出口，全国用户都从少数 IP 段来，地理调度失真——这是 CDN 行业“调度不准”的主要根源。缓解技术：EDNS Client Subnet（ECS）——LDNS 递归时把用户的 /24 子网带给权威，权威按真实用户位置应答，Google/Cloudflare DNS 与国内主流 CDN 支持；HTTP DNS——App 绕过系统 DNS 直连 HTTP 接口查询，同时解决劫持与调度精度（拿真实出口 IP），代价是维护 IP 直连兜底与证书校验；调度的兜底层——DNS 调度只做粗粒度（省级/运营商级），精细调度靠 302 重定向或 HTTPDNS 实时决策，大规模故障切换用 DNS 有 TTL 生效延迟（运营商常无视 TTL 缓存，分钟级不可控），所以关键业务是“DNS 粗调加应用层细调”双层。工程建议：排查 CDN 相关故障先问“用户 LDNS 是什么”——同一服务不同 LDNS 体验天壤之别；自有 DNS 服务开启 ECS 响应；监控按 LDNS 维度分组看延迟。
追问方向：ECS 的隐私争议与 /24 截断的精度损失？HTTPDNS 的降级策略怎么设计？
（约 490 字）