我们是 Geonode，主要销售代理服务——这通常是此类库推荐搭配使用的产品。坦率地说，我们不会编写绕过指南，而且就这一具体情况而言，该工具本身也已过时。 我们在 2026 年 9 月检查了该软件包：PyPI 上的版本为 1.2.71，上传于 2023 年 4 月，源代码仓库最后一次更新是在 2025 年 6 月，且这些提交仅涉及管理操作而非功能更新。 与此同时，Cloudflare 的机器人检测机制已升级为基于数十亿次请求的机器学习、基于 JavaScript 的无头检测以及标头顺序分析。一个仅通过 requests解决 JavaScript 挑战的库，根本无法应对上述任何一种检测方式。本文有价值的部分在于最后三个章节。
Cloudscraper 的开发初衷
该库的自我描述明确指出了其目标，现在重读这些内容仍颇具启发性。
Cloudscraper 将自身描述为“一个用于绕过 Cloudflare 反机器人页面的简单 Python 模块（也称为‘我正在遭受攻击模式’或 IUAM），使用 Requests 实现”。 它指出：“Cloudflare 的反机器人页面目前仅检查客户端是否支持 JavaScript，尽管未来可能会增加其他技术手段”。
它所解决的机制是经典的插页式验证：
Checking your browser before accessing website.com.
This process is automatic. Your browser will redirect to your requested content shortly.
Please allow up to 5 seconds...
该库的方法是使用“JavaScript引擎/解释器来解决JavaScript验证挑战”，这“使脚本能够轻松伪装成普通网页浏览器，而无需显式地去混淆和解析Cloudflare的JavaScript代码”。 其文档指出，脚本在“首次访问任何启用了 Cloudflare 反机器人功能的网站时会暂停约 5 秒”，此后便不再有延迟。
针对当时存在的问题，这是一种合理的设计。该挑战是一个 JavaScript 谜题；该库运行 JavaScript 引擎并解决了它。
README 文件中还包含一项明确标明项目时间线的承诺：“Cloudflare 会定期更新其技术手段，因此我将频繁更新此代码库。”
维护状况，已核查
基于事实而非主观印象，于2026年9月核实。
PyPI的最新版本为1.2.71，于2023年4月25日上传。 这与作者所描述的“会定期更新”的目标相比，存在超过三年的时间差。
GitHub 仓库的最后一次推送是在 2025 年 6 月，最近的提交标题分别为“修复所有者”、“重新添加 gitignore”和“更正所有者信息”——这些都是日常维护工作，而非检测功能的更新。
该包尚未归档，且仍有约 36 个未解决的问题。
以上内容并非对作者的批评——他编写了一个有用的工具，并以 MIT 许可证的形式免费发布。这仅仅是该包的现状，也是任何打算依赖它的人最需要了解的事实。 一个其全部价值主张仅在于跟上对手步伐的库，其发布日期就是其规格说明。
如果你在某篇文章中看到推荐了 cloudscraper，请检查该文章的发布日期。目前流传的大量建议在撰写时是准确的，但此后并未被重新审视。
当前 Cloudflare 的检测机制
根据 Cloudflare 自身的文档，该方法之所以不再有效，原因如下。
Cloudflare 的 机器人评分 范围为 1 到 99，其中 1 表示“Cloudflare 相当确定该请求是自动生成的”，99 则表示很可能是真人操作。该评分由多个引擎协同工作得出。
机器学习 占检测结果的大部分。Cloudflare 描述了一种“有监督的机器学习方法”，该方法每天分析数十亿次请求，通过考察“请求特征（如请求头和浏览器信号）”来预测客户端为人类的概率。
启发式分析通过比对已知特征签名进行检测，对高可信度的检测结果赋予 1 分的评分。
JavaScript 检测通过“轻量级、不可见的客户端 JavaScript 注入”来识别无头浏览器，Cloudflare 声明该技术“不会收集任何个人身份信息”。
检测 ID 是用于识别可预测行为的静态规则。Cloudflare 的示例颇具启发性：它们能够识别“客户端发送的请求头顺序与其声称使用的浏览器应采用的顺序不一致”的情况。
最后一点正是关键所在。标头顺序并非基于 requests的库所能控制的，且在解决 JavaScript 验证题时也不会发生变化。TLS 握手签名同样如此——这是 Python HTTP 协议栈的属性，而非您发送内容的属性。
因此，模型已经发生了逆转。 2019 年的问题是“该客户端能否运行 JavaScript”，而搭载 JavaScript 引擎的库给出了肯定答案。如今的问题是“该客户端的所有特征是否与其声称的身份一致”，而一个自称是 Chrome 的 Python 进程在多个独立信号上同时失败——这些信号均与挑战解决器无关。
Cloudflare 还添加了刻意设计的对抗性响应。其 AI Labyrinth 系统会向爬虫无限期提供连贯的生成内容，而非直接阻断它们，这意味着爬虫看似成功，却未能收集到任何有价值的信息。我们在 蜜罐陷阱 中探讨过这种模式。
为什么代理无法解决这个问题
这一部分我们将对自家产品提出质疑，因为事实确实如此。
请看上面的检测清单，并注意其中包含的内容：请求头组成与顺序、浏览器信号、机器学习得出的请求特征、JavaScript 执行特征。在 Cloudflare 自身关于机器人评分生成机制的描述中，IP 地址根本没有出现。
IP 地址声誉无疑是 Cloudflare 整体决策的参考因素之一，一个声誉不佳的地址确实无济于事。但这只是众多因素之一，且并非用于识别 Python 客户端是否为自动化请求的关键依据。在 requests 会话前端使用住宅代理，虽然能为客户端提供一个“干净”的地址，但该客户端的真实特征依然清晰可辨。
坦率地说：如果你是因为IP地址位于一个有不良记录的共享数据中心IP段而被标记，那么使用更好的IP地址确实会有帮助。但如果你是因为请求行为与声称的浏览器不符而被标记，那么更换IP地址也无济于事——我们宁愿直言不讳，也不愿以此为由向你兜售带宽。
替代方案
真正有用的部分，按解决问题最多的顺序排列。
查看是否有官方 API。 许多使用 Cloudflare 的网站也会发布官方 API，其目的正是为了让合法用户拥有正规的访问途径。但人们很少去检查这一点，因为他们的第一反应往往是寻找绕过方法，而不是查阅文档。
**查看是否有数据源或合作伙伴计划。**许多行业都会为下游用户发布批量数据。不妨直接询问。
**查看无需受保护路径即可获取的内容。**站点地图、RSS 源、页面中嵌入的 JSON-LD、公开数据集、存档资料等。通常你会发现，你想要的具体内容其实发布在某个未受保护的地方。
直接联系网站。 发送一封邮件说明您的身份、需求以及数据量，这种方式解决问题的成功率往往高于讨论中提到的其他方法。网站运营商的反对通常是出于对不明来源流量的担忧，而非针对您个人。这也是唯一能确保访问权限长期有效的途径。
**使用有授权的数据提供商。**对于常见数据——公司信息、产品目录、市场数据——总有人在出售，且价格往往低于为避免购买而耗费的工程时间。
考虑是否可以减少需求。 许多数据采集行为获取的数据远超实际需求。提出更小、更具体的需求，不仅更容易通过合法途径满足，在申请时也更容易获得批准。
如果您正在运行一个合法的自动化客户端，当前的主流趋势是身份识别而非伪装。 该行业正朝着加密代理身份验证、按代理制定的访问策略，以及在某些情况下对自动化流量实施付费访问的方向发展——我们在关于 DataDome 的文章中曾对此进行过描述。成为网站能够识别并选择允许访问的代理，是唯一一种随着时间推移会变得越来越可靠而非越来越不可靠的方法。
如果您已有使用该功能的现有代码
针对许多人实际面临的情况提供的实用指南：一个基于 CloudScraper 构建且原本正常运行的管道开始出现故障。
首先，弄清楚实际发生了什么。 “无法正常工作”这一表述涵盖了多种不同的故障，且对应的响应各不相同。请输出状态码和请求正文的前一部分，而不是仅仅捕获异常：
import cloudscraper
scraper = cloudscraper.create_scraper()
r = scraper.get(url)
print(r.status_code, r.headers.get("content-type"))
print(r.text[:300])
如果返回 403 并显示 Cloudflare 阻断页面，说明您已被识别。如果返回 200 并显示验证页面，说明未通过验证。 若返回 200 且内容看似合理但与请求无关，则可能陷入“陷阱”（tarpit）。若返回 503 并显示 Cloudflare 插页，则表明旧式验证机制仍在运行，且您的配置中存在其他问题。每种情况都指向不同的问题根源。
随后请检查是网站发生了变化，还是库（library）发生了变化。 分别使用纯文本 requests 和真实浏览器访问同一 URL。如果浏览器能正常访问，而两种 Python 调用方式均以相同方式失败，则说明网站已加强了保护措施，此时无论如何配置该库都无济于事。如果纯文本 requests 能正常访问，则说明 cloudscraper 反而增加了问题而非解决问题——这种情况确实存在，在认定需要使用该库之前，值得先进行核查。
切勿为了恢复原有行为而锁定旧版本。 问题出在连接的另一端，而非该包本身。没有任何早期版本会知道在其编写之后引入的检测方法。
如果它不再发挥作用，请将其移除。 一个曾解决过现已不复存在问题的依赖项，在您的供应链中就成了毫无益处的弃用包。网站会不断启用或停用 Cloudflare 的更激进模式，而在激进时期构建的管道，现在即使不使用该库也可能运行良好。请进行测试。
并将失败视为项目信息，而非需要修复的 bug。 一个需要依赖已不再维护的绕过库才能运行的聚合管道，本身就存在结构性问题，而用于修复它所花费的时间，本可以用来寻找 API、数据源或咨询相关人员。 根据我们的经验，第二次搜索的成功率往往高于第一次。
代理的真正用武之地
为了全面起见，毕竟这是我们的业务，而且确实有实际用途。
将流量分散到多个地址——当您已优化好请求速率，而单个地址成为瓶颈时。这是个吞吐量问题，而代理正是为了解决这一问题而存在的。
访问特定地区的受限内容——此时，伪装成来自某个特定地区正是操作的全部目的。
绕过过滤特定网站的网络，这属于用户端的问题，而非网站本身的问题。
广告验证与品牌监测，用于核查您在已付费区域内的广告支出情况。
以上情况均不属于“绕过”行为。所有这些都是 IP 地址确实是关键变量的场景，在每种情况下，合理的起点都是数据中心带宽——我们的价格从 0.14 美元/GB 起——仅在确有需要时才升级至 0.79 美元/GB 的住宅带宽。 数据来自我们的定价页面，核查于2026年9月。
我们绝不会以“能绕过检查报头顺序的机器学习模型”为噱头来销售套餐。IP地址本身并不具备这种功能。
大家还问
Cloudscraper 还能用吗？
面对现代的 Cloudflare 防护机制，通常已无法奏效。PyPI 上的最后一个版本发布于 2023 年 4 月，而该库的设计初衷是针对那个主要依靠 JavaScript 验证的挑战时代。当前的检测机制采用了基于请求特征的机器学习、请求头顺序分析以及基于 JavaScript 的无头检测，而这些都是挑战解法无法应对的。
cloudscraper 还在维护吗？
该代码库虽未归档，但最后一次发布是在 2023 年 4 月，而最近的提交（2025 年 6 月）仅涉及管理操作，而非功能更新。对于一个价值完全取决于追踪不断变化的目标的库来说，发布日期实际上就是其规格的截止点。
为什么 Cloudscraper 会返回 403 错误？
因为 Cloudflare 通过该库无法控制的信号识别出了客户端。无论是否解决了 JavaScript 挑战，请求头顺序、TLS 握手特征以及基于机器学习的请求特征都指向一个 Python HTTP 客户端。
使用代理能否让 cloudscraper 正常工作？
不能，除非你被标记的原因恰好是 IP 地址声誉问题。Cloudflare 对“机器人评分”的官方描述涵盖了基于请求特征的机器学习、启发式分析、JavaScript 检测以及标头顺序规则——而这些因素在你的 IP 地址发生变化时均不会改变。
除了 Cloudscraper 还能用什么替代方案？
寻找官方 API、合作伙伴的数据源，或是在其他地方未受保护的数据发布渠道。然后考虑直接向网站询问，这种方法解决问题的成功率往往高于人们的预期，且能获得持续有效的访问权限。获得授权的数据提供商通常比为规避限制而花费的工程时间更经济。
绕过 Cloudflare 是否合法？
在大多数司法管辖区，违反服务条款属于合同纠纷而非刑事犯罪，实际后果通常是被封禁。 合法性取决于司法管辖区、涉及的数据以及数据的使用方式。已部署保护措施的网站已表明其立场，无论法律分析结果如何，这一立场都值得权衡。本文不构成法律建议。
为什么我收到 200 状态码响应却没有有用的内容？
您可能遇到了“陷阱”（tarpit）。Cloudflare 的 AI Labyrinth 系统会向爬虫提供连贯且在事实层面看似合理、但与该网站完全无关的生成内容，而非直接将其封锁。虽然所有请求均返回成功，但您实际上无法获取任何有效数据——这正是该机制的设计初衷。
使用无头浏览器效果更好吗？
与基于 requests的库相比，它能捕捉到更多的信号，因为真实的浏览器会产生真实的 TLS 和标头特征。但它消耗的带宽和计算资源也多得多，而且 Cloudflare 的 JavaScript 检测机制专门针对无头浏览器。这是一种不同的权衡，而非解决方案，而“问题”的本质并未改变。
总结
Cloudscraper 很好地解决了一个实际问题，而它所解决的问题已不再以当初设计时的那种形式存在。该库的最后一个功能性版本发布时，另一端已经历了数代更迭，而该库自身的 README 文件中承诺会频繁更新，但这一承诺已逾三年未兑现。
理解其中的原因比寻找替代方案更有意义。过去的问题在于客户端能否运行 JavaScript，而一个带有 JavaScript 引擎的库可以解决这个问题。 而当前的问题在于，客户端的各个方面——包括标头顺序、TLS 特性、浏览器信号以及行为表现——是否与其声称的身份相符。一个自称是 Chrome 的 Python HTTP 会话在上述多个方面同时出现问题，无论它能解决什么问题。
这也是我们不会向您推销代理作为解决方案的原因。Cloudflare 自身关于其机器人评分生成机制的说明中，完全没有提及客户端地址。更好的地址仅能解决地址相关的问题，除此之外毫无用处。
真正有效的方法虽然不显眼却经久耐用：找到 API，找到数据源，查找在其他地方发布的数据，或者直接询问。尤其是最后一种方法，其成功率远高于讨论中提到的水平，而且这是唯一无需在每次有人发布检测更新时都重新验证的途径。