# FlareSolverr: a local proxy that solves Cloudflare challenges with a real browser

> FlareSolverr runs a small HTTP API on port 8191, drives an undetected Chrome instance to clear Cloudflare and DDoS-GUARD challenges, and hands back the HTML plus the cookies. It is a companion service for scrapers and indexers, not a general purpose web proxy.

**FlareSolverr/FlareSolverr** — Proxy server to bypass Cloudflare protection

- Repository: https://github.com/FlareSolverr/FlareSolverr
- Stars: 15,720 · Forks: 1,265
- Language: Python
- License: MIT
- Published: 2026-09-21 · Updated: 2026-09-21 · Language: en
- Canonical page: https://hysenlabs.com/projects/flaresolverr-flaresolverr

## The problem FlareSolverr exists to solve

Cloudflare's interstitial challenge is designed to be answered by a browser, not by an HTTP client. A Python script using requests gets a 403 or a JavaScript challenge page, and the script has no way to execute the challenge. FlareSolverr is the piece that sits between the two: it accepts an HTTP request from your client, opens the target URL in a real Chrome instance driven by Selenium and undetected-chromedriver, waits for the challenge to clear, and returns the resulting HTML and cookies. Your client can then either use the returned HTML directly or reuse the cookies with its own HTTP library. The audience is narrow and specific. It is people running scrapers against sites that sit behind Cloudflare, and, judging by the search terms around it, people wiring indexers such as Prowlarr, Jackett and Sonarr into a service that can fetch pages those tools cannot fetch themselves. It is not a browser automation framework and not a general proxy. The README is explicit that it is a proxy server to bypass Cloudflare and DDoS-GUARD protection, and the API surface is small enough to read in one sitting.

## How the request flow actually works

The README describes the mechanism plainly: FlareSolverr starts a proxy server and waits in an idle state using few resources. When a request arrives, it uses Selenium with undetected-chromedriver to create a Chrome browser, opens the URL with the user's parameters, and waits until the Cloudflare challenge is solved or the timeout is reached. The HTML and cookies go back to the caller. Two consequences follow from that design. First, the cost of a request is the cost of launching a browser, and the README warns that browsers consume a lot of memory and that a new browser is launched with each request. Second, there is a session mechanism for callers that want to avoid relaunching. The sessions.create command launches a browser instance that retains cookies until sessions.destroy is called; the README says this speeds up requests and avoids solving the same challenge repeatedly. The trade-off is stated directly: sessions should be closed as soon as you are done with them. A leaked session is a Chrome process that keeps holding memory. The HTTP surface is a single endpoint, /v1, taking a JSON body with a cmd field, a url, and a maxTimeout. The documented commands include request.get, sessions.create and sessions.destroy. The Docker image bundles Chromium and Xvfb, which is why the README recommends Docker over a source install: the external browser dependency is already inside the image.

## Installing FlareSolverr with Docker and making a first request

Docker is the recommended path because the image already contains the browser. The README gives this run command, which publishes the API on port 8191 bound to localhost and sets a log level through the LOG_LEVEL environment variable.

```bash
docker run -d \
  --name=flaresolverr \
  -p 127.0.0.1:8191:8191 \
  -e LOG_LEVEL=info \
  --restart unless-stopped \
  ghcr.io/flaresolverr/flaresolverr:latest
```

If you prefer Compose, the repository ships a docker-compose.yml. It uses the same image, maps ${PORT:-8191} to 8191, mounts /var/lib/flaresolver:/config, and passes LOG_LEVEL, LOG_FILE, LOG_HTML and CAPTCHA_SOLVER as environment variables with defaults. Clone the repository and run docker compose up -d (Compose V2) or docker-compose up -d (Compose V1).

```bash
docker compose up -d
```

Once the container is up, the API answers on http://localhost:8191/v1. The README's example posts a request.get for a URL and waits up to 60 seconds.

```bash
curl -L -X POST 'http://localhost:8191/v1' \
-H 'Content-Type: application/json' \
--data-raw '{
  "cmd": "request.get",
  "url": "http://www.google.com/",
  "maxTimeout": 60000
}'
```

What you should see is a JSON response containing the page HTML and the cookies collected by the browser. If the challenge is not solved before maxTimeout, the request fails instead. On Windows, the README points to the precompiled executable from the releases page as the recommended route; that binary is x64 only, and the same x64 restriction applies to installing from source. On Debian hosts the README calls out one prerequisite: libseccomp2 must be version 2.5.x, checked with sudo apt-cache policy libseccomp2 and updated with sudo apt install libseccomp2=2.5.1-1+deb11u1 before restarting the Docker daemon and the container. The README also states, in capitals, not to expose FlareSolverr to the internet because it can be abused.

## Sessions, memory and the limits of the model

The clearest limitation is resource behaviour, and the project states it rather than hiding it. Each request without a session launches a new browser. On a machine with little RAM, the README advises against making many requests at once. That sentence rules out the obvious use case of a wide parallel crawl: FlareSolverr is a serialisation point, and throughput is bounded by how fast a browser can start and how many can coexist in memory. Sessions help with repeated visits to one site, since cookies are retained and the challenge is not re-solved for every call, but they shift the problem rather than remove it. Sessions that are not destroyed accumulate browser processes. A second limitation is scope. FlareSolverr solves the challenge; it does not make the site's content available in a structured form, and it does not handle sites where the challenge is followed by a login. A third is that the whole mechanism depends on undetected-chromedriver continuing to evade detection, which is an ongoing arms race rather than a settled property; the README does not offer any guarantee about future detection. Finally, the API is unauthenticated by design. The README's warning not to expose it to the internet is not boilerplate: anything that can reach port 8191 can ask this service to launch browsers.

## FlareSolverr compared with Byparr and plain HTTP clients

The most common comparison in search data is FlareSolverr versus Byparr. Both aim at the same problem, and the difference is in the browser layer: FlareSolverr drives Chrome through Selenium and undetected-chromedriver, which is why the Docker image carries Chromium, Xvfb and a set of dummy packages built with equivs to skip heavy dependencies such as libgl1-mesa-dri and adwaita-icon-theme. Byparr is a separate project and this repository says nothing about it, so the honest statement is that the architectures differ and you should read Byparr's own documentation before choosing. The other comparison is against not using a browser at all. A plain HTTP client with the right headers is far cheaper per request and has no memory floor, and for sites that only check headers or a simple cookie it is sufficient. FlareSolverr earns its cost only when the target actually serves a JavaScript challenge that must be executed. If your requests are already succeeding with requests or curl, adding FlareSolverr makes the pipeline slower and heavier for no gain.

## Maintenance, licence and upgrade cost

The repository is not archived, and the last push was on 2026-09-12. The most recent release listed is v3.5.2 on the same date, following v3.5.0 on 2026-05-26 and v3.4.6 on 2025-11-29. That is a slow but real release cadence, and the version in package.json matches the newest tag. The code is Python, with a pinned requirements.txt: bottle and waitress for the HTTP layer, selenium 4.47.0, undetected_chromedriver's supporting packages (requests, certifi, websockets, packaging), func-timeout, prometheus-client, xvfbwrapper on Linux and macOS, and pefile on Windows. Those pins matter for upgrades. Moving to a newer release can mean a newer Chromium in the image and a newer Selenium, and the Dockerfile itself notes that Chromium stack smashing errors inside the container can be tested with xvfb-run -s "-screen 0 1600x1200x24" chromium --no-sandbox. The licence is MIT, which is permissive and places few obligations on how you redistribute or bundle the software; the README also links a Ko-fi page for the author, which is a funding request and not a licence term. None of this is legal advice, and if you ship FlareSolverr inside a product you should read the MIT text in the repository's LICENSE file yourself. One operational cost deserves mention: because the service is stateful across sessions, an upgrade means restarting the container and losing any live sessions, so clients that hold a session ID need to recreate it.

## Conclusion

Adopt FlareSolverr when a scraper or indexer keeps hitting Cloudflare interstitials and you can run a container with a few hundred MB of memory to spare, and keep it bound to 127.0.0.1 as the README instructs. Do not adopt it for high-volume parallel crawling, for pages that need a logged-in human, or on a host where every request launching a browser would exhaust RAM. Before wiring it into Prowlarr or Jackett, verify the exact tag you pull, confirm that port 8191 is the one your client is configured for, and test a single request.get against the target site to see whether the challenge is actually solved or merely timed out.

## FAQ

### How do I use FlareSolverr with Prowlarr?

Prowlarr is not covered in this repository's README, so the only reliable instruction is the one FlareSolverr itself provides: run the container on port 8191 and point the client at http://localhost:8191/v1. The README's example request shows the cmd, url and maxTimeout fields the API expects.

### Why is FlareSolverr disabled in Prowlarr?

The README does not document Prowlarr integration or any reason a client would disable it, so this cannot be answered from the project's own material. What the README does say is that the service should not be exposed to the internet, which is the configuration point most likely to matter when a client cannot reach it.

### How do I install FlareSolverr on Windows?

The README says the recommended way for Windows users is to download the FlareSolverr executable from the releases page, which is available for Windows x64. Docker is the other documented option, and the README gives a Command Prompt or PowerShell variant of the docker run command.

### How do I install FlareSolverr with Docker?

The README recommends Docker because the image already contains the external browser. Either run the documented docker run command publishing 127.0.0.1:8191:8191, or clone the repository and start the shipped docker-compose.yml with docker compose up -d.

### Does FlareSolverr still work?

The repository is not archived and the last push was on 2026-09-12, with v3.5.2 released the same day, so the project is still being updated. Whether it clears a specific challenge depends on the target site and on undetected-chromedriver, and the README gives no guarantee about detection.

## Sources

- [FlareSolverr/FlareSolverr on GitHub](https://github.com/FlareSolverr/FlareSolverr)
- [Issues](https://github.com/FlareSolverr/FlareSolverr/issues)
- [License: MIT](https://github.com/FlareSolverr/FlareSolverr/blob/master/LICENSE)
- [README](https://github.com/FlareSolverr/FlareSolverr/blob/master/README.md)
- [Releases](https://github.com/FlareSolverr/FlareSolverr/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/flaresolverr-flaresolverr