一篇被Cloudflare拦截的文章，暴露了内容平台的傲慢

「Enable JavaScript and cookies to continue」——这是Medium上某篇标题为《Tornado》的文章给我看的全部内容。没有正文，没有摘要，只有一个旋转的验证框和一行冷冰冰的提示。我花了三分钟尝试绕过，最后发现：这篇文章可能根本不存在，或者存在，但被锁在了一道我永远打不开的门后面。

这不是我第一次遇到这种情况。作为科技从业者，我们习惯了各种"技术门槛"——验证码、登录墙、地区限制、付费订阅。但当这些门槛叠加到荒谬的程度时，我开始怀疑：内容平台到底是在保护内容，还是在保护它们自己的数据收集生意？

第一道墙：Cloudflare的"保护"成了内容黑洞

原文链接指向Medium的一个子域名，路径包含「no-time/tornado-9eeb93e3b340」。从URL结构看，这是一篇发布于Medium的内容，可能属于某个名为「No Time」的Publication（出版物）。但点击之后，迎接我的是标准的Cloudflare托管挑战页面。

页面源码显示，这是一个「managed」类型的挑战，配置了完整的浏览器完整性检查（cFPWv: 'g'）。代码中的cH值、cRay值、cN值都是Cloudflare的验证令牌，用于追踪这次特定的验证会话。页面还设置了360秒的自动刷新，以及一个指向特定挑战脚本的nonce令牌。

问题在于：我已经启用了JavaScript和cookies。我用的是标准Chrome浏览器，没有开隐私模式，没有屏蔽脚本。但页面依然只显示那个红色的错误图标和「Enable JavaScript and cookies to continue」。

这意味着什么？Cloudflare的验证系统要么出现了误判，要么——更可能的情况是——它根本不在乎真实用户能否通过。它的设计目标不是让真人通过，而是让机器流量无法通过。至于误伤多少真人，那是可接受的损耗。

我检查了请求头。页面返回的是200状态码，但内容是一个几乎空白的HTML壳，真正的内容需要执行挑战脚本后才能加载。而挑战脚本托管在challenges.cloudflare.com，需要额外的网络请求和浏览器环境验证。

在某些网络环境下，这些请求会被拦截或超时。结果是：用户看到的是一个永远转圈的页面，或者一个永远提示"启用JavaScript"的页面——尽管JavaScript已经启用。

第二道墙：Medium的RSS陷阱

注意到URL里的参数了吗？「source=rss------self_improvement-5」。这说明我是通过RSS订阅发现这篇文章的，来源是Medium的「self_improvement」分类频道。

RSS的设计初衷是开放、去中心化的内容分发。你订阅一个feed，获取最新文章的标题和摘要，点击后阅读全文。但Medium的RSS实现是一个典型的"开放诱饵"：它慷慨地提供标题、摘要、甚至完整的内容预览，但当你点击链接想要阅读时，却把你扔进Cloudflare的验证迷宫。

更讽刺的是，RSS阅读器通常不会执行复杂的JavaScript挑战。这意味着：如果你在Feedly、Inoreader或任何传统RSS阅读器里订阅了Medium的内容，你看到的永远是一个无法打开的链接。

Medium知道这一点。它依然提供RSS，因为RSS有助于SEO和内容分发。但它不保证RSS链接是可访问的。这是一种精心计算的妥协：既享受开放协议带来的流量红利，又不承担真正开放的成本。

URL中的「__cf_chl_tk」参数是Cloudflare的挑战令牌，有效期极短。这意味着即使我通过某种方式绕过了验证，这个链接也无法分享或存档。内容被锁在一个瞬时生成的密钥后面，过期即失效。

第三道墙：我们失去了什么

让我们回到那篇叫《Tornado》的文章。从标题看，它可能讨论的是 tornado（龙卷风）作为自然现象，或者Tornado作为某个技术项目（比如Python的Tornado Web框架），或者某种隐喻——情绪的风暴、思维的漩涡。

我永远不会知道。因为Medium和Cloudflare联手，在我和这篇文章之间筑起了一道无法逾越的墙。

这不是技术问题，这是权力问题。平台决定谁能看、谁不能看、在什么条件下看。这些决定是黑箱的、即时的、不可申诉的。你今天能看，明天可能因为IP变动、浏览器更新、或者Cloudflare的算法调整而被拒之门外。

更隐蔽的损失是链接的死亡。Web的基石是URL——统一资源定位符，一个地址对应一份内容，可以引用、可以存档、可以讨论。但Cloudflare的挑战链接是反Web的：它们是一次性的、绑定的、不可复制的。

当我在Twitter上分享这个Medium链接时，我分享的其实是一个抽奖券：有些人能打开，有些人不能，取决于他们的网络环境、设备配置、和运气。这不是链接，这是彩票。

第四道墙：内容平台的商业模式悖论

Medium的困境在于：它想同时做两件事，而这两件事互相矛盾。

它想做开放的出版平台，吸引写作者和读者。开放意味着低门槛、易访问、可分享。所以它保留RSS，允许未登录用户浏览部分文章，在社交媒体上生成漂亮的预览卡片。

但它也想做付费订阅生意。Medium Partner Program（合作伙伴计划）要求读者付费才能阅读完整内容，写作者按阅读时长获得分成。付费墙意味着限制、追踪、身份验证。所以它需要知道你是谁，看了多久，是否值得付费。

Cloudflare是这两件事的粘合剂。它提供"安全"服务——阻止爬虫、减少欺诈、保护基础设施。但它的副作用是：它把"开放"变成了一种表演。你可以看到门，但打不开；你可以订阅feed，但读不了文；你可以分享链接，但不知道对方能否访问。

这种模式对平台有利：SEO流量进来了，广告展示了，付费转化追踪了，而内容本身被层层包裹，成为平台资产而非公共知识。

对写作者呢？他们获得了一个"潜在的巨大读者群"的承诺，但实际上，这个读者群被切割成无数碎片，每个碎片都困在自己的验证迷宫里。一个印度读者可能因为Cloudflare的CDN节点问题无法加载页面；一个使用隐私浏览器的德国读者可能被误判为机器人；一个通过RSS发现文章的老派用户可能永远不知道内容存在。

第五道墙：我们能做什么

面对这个系统，个人选择是有限的。你可以停用JavaScript（然后发现90%的Web无法使用），你可以使用Tor（然后触发更严格的验证），你可以自建博客（然后面对零读者和零收入的现实）。

但识别问题本身是第一步。当我看到那个「Enable JavaScript and cookies to continue」的提示时，我不再把它当作技术故障或用户错误。我把它当作一个信号：这个内容被设计为不可访问的，或者至少，访问成本被故意提高了。

这种设计是有意图的。它不是bug，是feature。它筛选用户，收集数据，训练模型，优化转化率。每一个被挡在门外的真人，都是这个系统的可接受损耗；每一个成功通过验证的用户，都是额外的数据点和潜在付费者。

《Tornado》这篇文章，如果它真的存在，可能讨论的是混乱中的秩序，或者秩序中的混乱。讽刺的是，它的传播方式完美演绎了这个主题：一个关于风暴的文本，被困在一场由平台、算法、和商业利益构成的风暴中心。

我最终没有读到它。但我学到了一些东西：关于Web如何死去，关于开放如何被表演，关于我们如何在点击"同意"和刷新页面之间，逐渐放弃了对信息的控制权。

下次当你看到一个转圈的加载图标时，不妨停下来想想：你是在等待内容加载，还是在等待被允许查看内容的许可？这两者之间的区别，可能比你想的更大。