多年来,FlareSolverr 一直是 "我的爬虫怎么过 Cloudflare?" 这个问题的默认答案。你把它作为一个小型代理服务器运行,向它 POST 一个 URL,它就会启动一个真实浏览器、耗时熬过挑战,然后把 cookies 和 HTML 交还给你。它是无数 Jackett、Prowlarr、Sonarr 配置背后的主力,也支撑着大量自制爬虫。
到了 2026 年,它越来越不管用了。症状都很熟悉:请求超时、返回的是挑战页面而非内容、日志里写着 "Challenge not detected",或者页面上的 Turnstile 小部件压根从未被求解。本文将诚实地解释 FlareSolverr 为何在现代 Cloudflare 上失败、它在哪些场景下仍然好用、真正的替代方案有哪些,以及当你想用一次 HTTP 调用而非照看一个浏览器时,该如何迁移到托管式 API。
FlareSolverr 究竟做了什么
FlareSolverr 是一个自托管的代理服务器,通常以 Docker 运行。你向它发送一个类似 {"cmd": "request.get", "url": "https://target.com"} 的 HTTP 请求,它会在底层驱动一个真实的 Chromium 浏览器(通过 undetected-chromedriver / Selenium)来加载页面。当 Cloudflare 下发旧版的 "I'm Under Attack Mode"(IUAM)拦截页——也就是 "Checking your browser... Just a moment" 页面——FlareSolverr 会等待浏览器运行挑战 JavaScript,收集由此产生的 cf_clearance cookie,然后把 cookies 连同页面 HTML 和 User-Agent 返回给你。
其核心设计假设是:用真实浏览器加载页面并等待就足够了。对于旧式 IUAM 挑战确实如此:浏览器执行 JS 数学谜题,cookie 下发,你就通过了。而恰恰是这个假设崩塌了。
为何 FlareSolverr 在现代 Cloudflare 上失效了
Cloudflare 的防护向前迈进了,而 FlareSolverr 的 "浏览器加等待" 方法已无法覆盖这堵墙如今抛出的东西。它今天失败有四个相互交叠的原因:
- Turnstile —— Cloudflare 的验证码替代品会先运行一个非交互式的工作量证明(proof-of-work)以及浏览器 API 探测,然后才签发一个 cf-turnstile-response token。FlareSolverr 能加载页面,但没有任何逻辑去产生那个 token,因此受 Turnstile 把守的表单或页面永远无法通过——它就那样卡着。
- Managed Challenge(托管挑战)—— 现代挑战会根据访客动态挑选工作量证明 / 空间证明(proof-of-space)、行为信号以及 Web API 探测。FlareSolverr 所驱动的普通 Chromium 是可被检测的,因此挑战常常永远无法通过,你拿回的是拦截页而非你的内容。
- 维护停滞 —— 让一个浏览器自动化工具对 Cloudflare 保持隐形是一场持续的猫鼠游戏,而 FlareSolverr 的开发一直缓慢且断断续续。项目每错过一次 Cloudflare 的更新,往往就会再坏掉一批目标。
- 资源占用重且脆弱 —— 每个请求都会启动一个有头/无头的 Chromium。这意味着每个 worker 占用数百兆内存、冷启动缓慢、高负载下频繁超时,以及一个比普通 HTTP 客户端崩溃或挂起频率高得多的进程。
2026 年 FlareSolverr 的典型错误症状
如果你正在排查问题,失败通常表现为以下几种之一。认出是哪一种,就能判断它是可修复的还是根本性的:
- 返回挑战页面 —— 响应里的 "solution" 包含的是 "Just a moment..." / "Checking your browser" 的 HTML,而非真实内容。Cloudflare 下发了内嵌浏览器无法通过的挑战。
- 超时 —— 请求挂起并最终报错(通常在你设置的 maxTimeout 附近)。在现代托管挑战下,浏览器在等待一个永远不会下发的 cookie。
- "Challenge not detected" —— FlareSolverr 加载了页面,但没有识别出它知道如何处理的挑战,于是提前返回。当墙是 Turnstile 或它并非为之构建的 v3 风格挑战时,这种情况很常见。
- Turnstile 未求解 —— 页面加载了,但 Turnstile 小部件始终处于未验证状态,任何表单提交都会失败,因为流程中根本没有求解 token 的步骤。
FlareSolverr 在哪些场景下仍然好用
公平地说:FlareSolverr 并非毫无用处,你也不该条件反射地把它拆掉。如果你的目标仍然下发旧版的 IUAM JS 数学拦截页——一些较小或较老的站点确实如此——那么一个真实浏览器加载页面并等待仍能通过,而 FlareSolverr 做的正是这件事,且没有任何每次请求的费用。
所以诚实的判断方法是:在浏览器里打开目标站点。如果你看到一个短暂的 "Just a moment..." 页面,它自行通过、没有复选框、没有可见小部件,那么 FlareSolverr(或某个维护中的分支)多半能搞定。如果你看到一个 Turnstile 复选框、一个交互式小部件,或者一个不断循环或卡住的托管挑战页面,那么再怎么调校 FlareSolverr 也无法可靠地通过——那是另一类挑战。
2026 年 FlareSolverr 替代方案的诚实对比
没有哪个单一工具能完胜——这取决于究竟是 Cloudflare 的哪一层在拦你。以下是对现实选项的公正梳理:
- 维护中的分支(如 Byparr)—— 类似直接替换 FlareSolverr 的方案,更积极地跟进 Cloudflare 的变化,并换用更新的隐身浏览器栈。如果你喜欢代理服务器这种模式,这是阻力最小的升级——但它仍然是一个你自己托管的浏览器,而且依然在 Turnstile 和棘手的托管挑战上力不从心。
- nodriver —— undetected-chromedriver 的现代继任者,带有极少的 CDP 痕迹。当你确实需要 JavaScript 运行、又想减少自动化指纹时很合适。代价是:高 CPU/内存占用、启动缓慢、大规模运行时脆弱,而且对托管挑战或 Turnstile 依然没有保证。
- curl_cffi / curl-impersonate —— 模拟真实浏览器的 TLS 与 HTTP/2 指纹,轻量且快速。当唯一障碍是 TLS 指纹、且站点并未实际下发 JS 挑战时堪称完美。但它们不执行任何 JavaScript,也不求解任何验证码,因此单凭自身无法通过托管挑战或 Turnstile。
- 托管式求解 API —— 你把目标详情 POST 到一个 HTTP 端点,然后取回有效的 token 或 cf_clearance cookie。无需浏览器集群、无需照看 Docker 容器、无需追赶 Cloudflare 的更新。你用一小笔每次求解的费用换取可靠性和零基础设施。
什么时候托管 API 才是正确选择,以及为何选 NSLSolver
如果你只是在少数几个低流量目标上通过旧式 IUAM 页面,那就保留 FlareSolverr 或换到 Byparr 这样维护中的分支——它免费,而且够用了。但如果你撞上了 Turnstile 或托管挑战、在生产环境中运行它,或者厌倦了一个吃内存、每次 Cloudflare 更新就崩溃的 Docker 容器,那么自托管浏览器就是一个不该在其上缠斗的层面。
NSLSolver 正是为此而生的开发者 API。它在单一 HTTP 契约背后处理 Cloudflare Turnstile、Cloudflare Challenge(托管/JS 挑战)以及 Kasada——无需托管浏览器,无需维护基础设施。Turnstile 求解平均约 250ms,成功率 99.9%,按成功求解计费,因此求解失败免费,定价为按量付费:Turnstile 每 1,000 次求解 $0.40,Cloudflare Challenge 每 1,000 次 $0.50,Kasada 每 1,000 次 $1.50。新账户注册即送 100 次免费请求——无需信用卡、无需加密货币即可开始。
思路的转变很简单:你不再运行一个加载页面、然后寄希望于挑战能通过的浏览器代理,而是发起一次 HTTP 调用,直接取回你所需要的那个产物——对于挑战是 cf_clearance cookie 和匹配的 User-Agent,对于 Turnstile 则是一个 token——然后在你自己的 requests session 上重放它。
import requests
API = "https://api.nslsolver.com"
HEADERS = {"X-API-Key": "nsl_YOUR_API_KEY"}
TARGET = "https://target-site.com"
# 1) Ask NSLSolver to pass the Cloudflare managed/JS challenge
# (replaces the FlareSolverr request.get round-trip)
resp = requests.post(
f"{API}/solve",
headers=HEADERS,
json={
"type": "challenge",
"url": TARGET,
"proxy": "http://user:pass@host:port",
},
)
data = resp.json()
# 2) Replay the clearance cookie + User-Agent on your own session
session = requests.Session()
session.cookies.update(data["cookies"]) # dict keyed by cf_clearance
session.headers["User-Agent"] = data["user_agent"] # snake_case field
# 3) Now scrape normally — the request looks like a cleared browser
html = session.get(TARGET).text
print(html[:500])直接求解 Turnstile token
如果这堵墙是一个 Turnstile 小部件而非完整的拦截页——例如一个 FlareSolverr 留作未验证状态的受保护登录或注册表单——那就改为请求一个 token。把小部件的 site_key 和页面 url 一起 POST,然后在提交表单时把返回的 token 用作 cf-turnstile-response 的值。
整个迁移就是这样。你不再运行 Docker 代理,保留现有的 requests session,把 FlareSolverr 用浏览器始终无法暴力破解的那部分交给 API 处理。
import requests
API = "https://api.nslsolver.com"
HEADERS = {"X-API-Key": "nsl_YOUR_API_KEY"}
resp = requests.post(
f"{API}/solve",
headers=HEADERS,
json={
"type": "turnstile",
"site_key": "0x4AAAAAAA...",
"url": "https://target-site.com",
},
)
token = resp.json()["token"] # e.g. "0.AAAA..."
# Submit the token as cf-turnstile-response
payload = {"cf-turnstile-response": token, "username": "me", "password": "secret"}
requests.post("https://target-site.com/login", data=payload)