判决落在 CDN 那一层：内容阻断有三个落点，代价各不相同
一、同一个动词，三种不同的动作
据公开报道，一起涉及盗版体育直播网站的诉讼里，Cloudflare 的公共域名解析服务 1.1.1.1 没有屏蔽相关网站的域名，而是通过其内容分发服务屏蔽了对应网站；巴黎司法法院站在了这一边，驳回了法国付费电视提供商 Canal+ 提出的按每个盗版网站逐日计罚的请求。金额与结果不是本篇的论据，判决理由也不由一篇工程文章来推断。值得拆出来的是那件在技术上真实发生的事情：同一个“阻断”，被放在了不同的层，而放在哪一层，决定了它影响多少人、误伤怎么发生、事后能不能自证做对了什么。我们做云服务、企业网络和内容平台交付时，经常接到“把这个处理掉”这类要求，这句话的含糊之处正在于它没有指定落点。落点选错，轻则处置无效，重则把一批无关业务一起拖停，而责任还落在执行方身上。
二、DNS 层：便宜、覆盖广，但既不完整也难以解释
DNS 层的实现成本最低，一条解析规则的改动就能覆盖所有使用该解析器的用户，这也是它常被当作首选的原因。但它有两个结构性局限。
一是覆盖面取决于对方用什么解析器。用户侧的解析入口是可选的，换一台公共解析服务就绕开了这条规则；解析结果本身还会被递归缓存和被应用层直连 IP 地址跳过。所以 DNS 层阻断从来不能作为唯一手段，把它当成完整处置，只是让报表上多了一行配置记录。需要说清楚的是，指出这些局限是为了评估处置效果，不是提供绕过方法。
二是误伤的方式很特别。共享同一地址的域名是很多托管形态的常态——反向代理、共享主机、内容分发节点回源到同一入口，都可能出现一个 IP 承载多个域名的情况。按地址或按域名的粗粒度处置一旦下错，连带失败的是同一基础设施上的其他站点，而这些站点与被处置对象毫无关系。更麻烦的是排障体验：受影响方看到的是一个解析错误或超时，不会在任何提示里读到“因为你和别人共用了地址”，所以定位链条长、归属争议大，往往要几方一起查。
三、接入与基础设施层：范围明确，代价在共享设施
第二层是网络接入侧，包括内容分发、主机托管、边界防火墙这类位置。它的特点是对称的：只对经过自己的流量有效，所以作用范围可以精确到具体站点、具体路径甚至具体前缀，不必依赖对方用哪台解析器。这也是为什么在需要“确实让某个对象在自己服务上不可访问”的场合，落在这里比落在解析层可靠。
它的误伤来源也不同。这一层的连带风险不在解析歧义，而在共享基础设施——同一集群、同一租户隔离单元上的其他业务被一并处置；以及配置传播的不确定——规则生效要时间，生效范围要分层看，回滚同样要时间，而这段时间里业务已经停了。所以对这一层的动作有两个硬要求：影响清单必须先算出来再执行，回滚必须先演练再做。这一层的自证能力通常比解析层好，因为请求日志、回源记录、状态码分布都在自己手里，可以回答“哪些请求被拒绝、从什么时候开始、按哪条规则”，这在与权利方和监管方沟通时是关键差别。
四、应用与内容层：范围最窄，但可解释性最好
第三层是应用与内容侧：站内的搜索结果、外链与推荐位、素材索引、支付与广告通道。它的覆盖范围最窄，只对自家生态内的流量有效，也不解决任何外部可达性问题。但它有三项别处拿不到的好处：可以精确到内容条目而不是主机；可以给出面向用户的解释文案；可以留下最完整的处置记录，包括依据来源、执行时间与复核人。
代价是协同成本。这一层的处置通常分散在不同系统里——搜索是一套、链接与推荐是一套、结算通道又是一套，各有一套配置口径和发布流程，需要的授权方也不同。执行“下架”这件事，真正的难点往往在跨团队的执行一致性上：一边做完、一边漏掉，是这类处置最常见的失败方式。
五、三个落点的对照与自证能力清单
| 落点 | 影响范围 | 典型误伤方式 | 可自证内容 | 失效与恢复 |
|---|---|---|---|---|
| 域名解析层 | 走该解析器的全部用户 | 同址多域名连带解析失败 | 规则清单与生效时刻，难以证明覆盖 | 改动即时，缓存滞留期不定 |
| 接入与基础设施层 | 经过自身的流量 | 共享设施上的无关站点被一并处置 | 请求日志、拒绝原因、状态码分布 | 配置传播与回滚都有时延 |
| 应用与内容层 | 自家生态内的条目与通道 | 关联推荐与索引漏项 | 对象标识、依据、复核人、文案 | 发布节奏受各系统流程约束 |
“自证能力”这四个字要落成可回答的问题：能不能给出被处置对象的清单与依据来源；能不能定位并说明误伤；有没有恢复通道与承诺响应时长；对外有没有公示与申诉入口。四问有一个答不上来，这一层就不该作为唯一处置位置，至少在方案里要写明依赖其他层补齐什么。这里还要防一种心态：把“范围越大越安全”当成默认，觉得多铺一层就多一分保险。实际相反——范围越大，误伤概率越高，事后收场越难，因为每多一层就多一批与本案无关的受影响方。
六、企业侧的两组选择与处置记录字段
作为网络管理方时，自己的办公网与机房出口要不要做解析层阻断，是一次有代价的选择。做了要承担三件事：误伤带来的排障成本会转嫁给内部技术支持，而且员工不会知道自己踩的是哪条规则；规则的有效性有限，出口侧无法约束终端自行更换解析入口；审计要求会随之而来——谁配的、依据是什么、什么时候该撤，都要留记录。我们的经验是，出口侧宁可把规则数量压到最小并保持全量可解释，也不要维护一份来源不明的长名单。
作为平台方被要求处置时，顺序应该是先做能精确处置的那一层，再评估是否需要扩到更广的范围，并把扩层的理由单独成文。处置动作的记录字段建议固定下来：对象标识与所在层级、依据来源与来文编号、执行时间与生效范围、影响面评估结论、复核人与复核时间、到期解除时间、解除确认。字段里最容易被省掉、也最出事的是“到期解除时间”——处置默认无限期存在，多年以后没有人记得当初为什么做的这条规则，也撤不掉。
最后把“阻断”和“下架”分开这件事说透。它们在不同系统里，是两套动作、两类记录、两个复核人：阻断是可达性层面的，下架是内容层与商业通道层面的。要求写的是“停止对该内容的支持”，执行只做了一半的情况非常常见。验收时应按落点逐层核对，而不是按“提过需求”打勾。网络治理类需求很难有完美方案，能控制的是范围、依据和可撤回性；把这三件事写下来，是执行方唯一能被证明做对了的方式，也是洹拓在给客户做处置流程设计时坚持留下的那份表。