flaresolverr

Last reviewed Sep 13, 2026 · 763 words

FlareSolverr is not a proxy in the sense the proxy category usually means. It is a small Python HTTP service that, on request, launches a real Chrome with no screen, visits a URL, sits through Cloudflare's "checking your browser" page, and returns the resulting HTML plus the cookies that mark the session as human. That is the entire product. It pays to understand it exactly that narrowly, because the two ways it disappoints people both follow from it: it eats memory like a browser, because it is one, and it fails on any challenge Cloudflare has decided needs a human, because a headless Chrome is not one.

What it solves and what it will never solve

The JavaScript challenge, the five-second "just a moment" page, is the target, and it passes that most of the time. DDoS-Guard's equivalent, too. What it cannot do is an interactive CAPTCHA: when Cloudflare escalates to a Turnstile click or to hCaptcha, FlareSolverr times out and returns an error, and no setting changes that (the CAPTCHA_SOLVER option has had no working value for a long time). Whether a given tracker escalates depends on the site's Cloudflare security level and on how suspicious your server's IP looks. A datacentre VPS address triggers escalation far more often than a home connection does.

A request costs a browser tab

Each request starts Chrome through undetected-chromedriver, waits up to maxTimeout (60 seconds by default), and tears it down. The 512 MB listed as the minimum is a floor: one Chrome instance sits at 300 to 500 MB, and concurrent searches from three arr apps can push the container past 1 GB. On a 2 GB box this is the service that gets OOM-killed first. BROWSER_TIMEOUT and LOG_LEVEL are the environment variables you will actually touch. Sessions (sessions.create) keep a browser open between requests to save the startup cost, at the price of that memory never being freed.

services:
  flaresolverr:
    image: ghcr.io/flaresolverr/flaresolverr:latest
    environment:
      - LOG_LEVEL=info
      - TZ=Etc/UTC
    ports:
      - "8191:8191"
    mem_limit: 1g
    restart: unless-stopped

A plain GET on port 8191 returns a JSON status line, which is all a health check needs. The API itself is one POST /v1 endpoint with cmd: request.get and a url; the response carries the page and a cookies array that you, or more usefully Prowlarr, replay against the tracker with a normal HTTP client. One curl proves the whole thing works before any arr app is involved:

curl -X POST http://localhost:8191/v1 -H 'Content-Type: application/json' \
  -d '{"cmd":"request.get","url":"https://example.com","maxTimeout":60000}'

A status: ok with a solution block means Chrome started and returned a page; anything else is a container problem, not a Cloudflare one.

Wiring it into Prowlarr and Jackett

In Prowlarr it is an Indexer Proxy of type FlareSolverr with a tag; any indexer carrying that tag routes through it, and untagged indexers never touch it. That tag discipline is the difference between a stack that works and one where every search takes 20 seconds. In Jackett it is a single field on the settings page, and every tracker that needs it uses it automatically. Either way, keep the service on the same Docker network and address it by container name, and never expose 8191 outside the host: anyone reaching it gets a free headless browser that runs from your IP.

It will break, and the fix is usually waiting

Cloudflare changes its detection; Chrome updates; undetected-chromedriver catches up; FlareSolverr releases. That cycle repeats every few months, and in the gap the logs fill with "Challenge not detected" or timeouts and every tracker behind Cloudflare goes dark. Pinning an old version does not help, because the challenge changed, not the tool. Watch the GitHub issues, update when a release lands, and in the meantime accept that public trackers behind aggressive protection are a losing game. A private tracker with an API key needs none of this and is the quieter life.

What I'd do

Run it only when a tracker you actually use throws the challenge, and confirm that with Prowlarr's test button before adding a 500 MB browser to the stack. Give it the mem_limit above so a stuck Chrome cannot take the host down, tag exactly the indexers that need it, and treat every outage as expected rather than as something to debug. If you find yourself needing it for five trackers, the better fix is fewer trackers.