网站疑似被 CDN 劫持时，最重要的是先不要急着改一堆配置，而是把现象、链路和证据分开看。很多“被劫持”其实是 DNS 污染、解析配置错误、证书不匹配、缓存回源异常、运营商中间页、CDN 节点被污染缓存，甚至是源站本身被挂马导致的。处理顺序建议遵循一条主线：先确认访问结果是否异常，再定位异常发生在域名解析、HTTPS 握手、CDN 缓存节点还是源站内容层。
第一步是收集现象。你需要记录异常访问的时间、地区、运营商、访问 URL、返回状态码、页面截图、响应头、解析到的 IP、证书信息。不要只说“网站打开不对”，而是要确认异常表现：是否跳转到陌生页面、是否偶发出现广告、是否 HTTPS 证书变成未知机构签发、是否某些地区访问异常、是否只有移动网络异常、是否刷新后恢复。CDN 劫持常见特征是同一域名在不同网络环境下返回不同内容，或者同一 URL 在部分边缘节点返回旧内容、恶意脚本、错误跳转。
第二步检查域名解析。使用本地、公共 DNS、权威 DNS 多方对比，例如查看域名当前 CNAME 是否仍指向你的 CDN 厂商，A 记录是否被改成陌生 IP，TTL 是否异常变短，是否存在未授权的子域名解析。重点核对域名注册商控制台、DNS 服务商控制台、CDN 控制台三处配置是否一致。如果发现权威解析已经被改，优先怀疑 DNS 账号被入侵、API Key 泄露或域名注册商账号被盗。此时应立即修改注册商、DNS、CDN 账号密码，关闭无用 API Token，启用 MFA，并导出最近解析变更日志。
如果权威解析正常，但用户本地解析结果异常，则可能是本地 DNS 缓存污染、运营商 DNS 劫持、路由器 DNS 被改、办公网络代理异常。可以让用户临时切换到可信公共 DNS 或使用 DoH/DoT 验证。如果切换 DNS 后恢复，说明问题大概率不在 CDN 平台本身，而在递归 DNS 链路。此类问题需要保留 nslookup、dig、访问截图和运营商信息，提交给 CDN 厂商或运营商协助处理。
第三步检查 HTTPS 证书。访问异常时，查看浏览器证书详情，确认颁发给的域名、颁发机构、有效期、指纹是否与 CDN 控制台配置一致。如果证书变成陌生证书，可能是中间人代理、非法网关、企业代理证书、恶意 Wi-Fi、客户端被安装根证书，也可能是 CDN 证书配置被替换。若只有部分地区证书异常，要重点检查异常节点 IP 对应的 CDN 边缘节点是否加载了错误证书。此时可以使用 openssl 或在线 SSL 检测工具，对不同地区节点进行证书比对。
证书层还要核对 HSTS、强制 HTTPS、HTTP 到 HTTPS 跳转策略。如果你的网站允许 HTTP 明文访问，那么在不可信网络中更容易被插入广告、跳转代码或被缓存污染。建议全站启用 HTTPS，CDN 到源站也使用 HTTPS 回源，并开启源站证书校验，避免“用户到 CDN 是 HTTPS，CDN 到源站却是 HTTP”的半安全状态。对于登录、支付、后台等敏感路径，应设置不缓存或私有缓存策略。
第四步检查 CDN 缓存节点。很多疑似劫持其实是 CDN 边缘节点缓存了错误内容。比如源站短暂被入侵后返回了恶意 JS，CDN 把它缓存下来；或者某个规则把动态页面错误缓存，导致用户看到别人的页面；又或者缓存键没有包含 Host、协议、查询参数、Cookie，造成缓存串内容。处理时应先对异常 URL 做精准刷新，再视情况全站刷新缓存。不要一上来直接切换 CDN 或清空全部配置，否则可能丢失证据，也会扩大影响。
排查缓存时要重点看响应头，例如 Age、Via、X-Cache、Server、CF-Cache-Status、X-Request-Id 等字段。命中缓存时通常会有 HIT、Age 大于 0 等标识；回源失败可能出现 502、504 或 CDN 自定义错误页。如果异常页面带有明显缓存命中特征，说明问题可能在边缘缓存；如果每次都是 MISS 后返回异常，就要继续查源站或回源链路。建议把异常响应头完整保存，提交给 CDN 厂商定位具体节点。
第五步确认源站是否干净。很多团队只盯着 CDN，却忽略源站已经被篡改。你需要绕过 CDN，用源站 IP 加 Host 头访问，或在安全网络环境中直接检查服务器文件、Nginx/Apache 配置、应用代码、数据库内容、定时任务、WebShell、异常用户和最近部署记录。如果源站直接访问也有异常，那不是 CDN 劫持，而是源站被入侵或应用输出异常。此时应先隔离源站、备份证据、回滚干净版本、修补漏洞，再刷新 CDN 缓存。
第六步检查 CDN 配置是否被恶意修改。登录 CDN 控制台查看近期操作日志，关注源站地址是否被改、回源 Host 是否被改、边缘函数是否新增、重写规则是否新增、301/302 跳转规则是否异常、WAF 是否关闭、证书是否替换、缓存规则是否扩大、访问控制是否被移除。如果 CDN 支持边缘脚本、规则引擎、Workers、Functions，一定要检查是否存在插入脚本、跳转、改写响应体的规则。这类配置层劫持隐蔽性很强，但通常能在操作审计中找到痕迹。
应急处理时，可以按优先级执行：先冻结高危账号和 API Key，修改密码并启用 MFA；然后把 DNS 指向确认无误的 CDN CNAME；再将异常 URL 或全站缓存刷新；同时开启 HTTPS 强制跳转和源站 HTTPS 校验；对后台、登录、接口等路径设置 no-cache；最后联系 CDN 厂商提供异常 IP、请求时间、URL、响应头和 Request ID，请对方排查边缘节点与日志。若影响严重，可以临时切换到备用 CDN 或直接回源，但切换前要评估源站承载能力。
长期防护方面，建议把域名注册商、DNS、CDN、云服务器账号分权管理，不要多人共用同一超级账号。API Token 要最小权限，定期轮换；DNS 变更、CDN 规则变更、证书变更要接入告警；核心域名开启注册商锁、禁止未授权转移；证书建议使用自动化签发但保留变更通知；重要业务配置多地域监测，从不同运营商定时抓取页面标题、证书指纹、解析 IP、状态码和关键响应头。
缓存安全也要制度化。静态资源可以长缓存，但 HTML、用户态页面、接口响应必须谨慎缓存。缓存键应明确包含 Host、协议、必要查询参数，涉及登录态的响应不要被公共缓存保存。源站返回头应规范设置 Cache-Control、Vary、Set-Cookie，避免 CDN 误判。发布系统最好在上线后自动刷新关键资源，并保留版本号资源路径，减少旧缓存污染风险。
我的经验是，处理 CDN 疑似劫持不要只凭浏览器看到的页面下结论，而要把“解析是否正确、证书是否可信、节点是否命中异常缓存、源站是否输出异常、控制台是否被改”逐项验证。真正高效的处置不是反复刷新缓存，而是先锁定异常发生在哪一层。只要证据链清晰，通常可以在较短时间内判断是 DNS 问题、HTTPS 中间人、CDN 节点缓存污染、配置被改，还是源站被入侵，从而采取对应措施，避免误操作扩大故障。
