FlareSolverr Not Working? Every Error, What It Means, and What a Proxy Fixes

FlareSolverr is a small local service that does one job: when a site behind Cloudflare shows a challenge page instead of content, it opens a real browser, waits for the challenge to pass, and hands back the resulting cookies and HTML so that your own client can carry on. It listens on port 8191, usually inside Docker, and it sits behind a large number of Jackett, Prowlarr, Sonarr, and Radarr setups as well as plenty of scrapers. When people say it is "not working", the log almost always says something more specific, and four messages account for nearly every report.

Each of those messages means a different thing, and two of them are not FlareSolverr failing at all. This guide takes them one at a time, then covers the proxy configuration that fixes the largest group of them, and ends with the honest list of jobs FlareSolverr cannot do no matter how it is configured, because a tool that is asked to do the wrong job looks broken.

1. "Challenge not detected"

FlareSolverr loaded the page, looked for the challenge types it knows, and found none. Two different situations produce this, and they need opposite responses.

In the first, the site is simply not challenging you. The page came back with content, FlareSolverr had nothing to do, and it says so. Requests through FlareSolverr in that state are pure overhead, a full browser launch for every fetch, and the client that fed it the URL could have fetched the page directly. Test by opening the URL in a normal browser from the same connection; if the page loads without any interstitial, drop FlareSolverr for that site.

In the second, the site is challenging you with something FlareSolverr does not recognise. Cloudflare has been retiring its old JavaScript interstitial in favour of managed challenges and the Turnstile widget, and a page that shows a Turnstile box, or a challenge that finishes only after a click, does not match what FlareSolverr is looking for. Updating to the current release is the first move, since detections get added. If the current release still reports no challenge on a page that plainly shows one, you are outside what the tool handles, and section 6 covers the alternatives.

Set LOG_LEVEL=debug and, for a one-off look, HEADLESS=false so the browser window is visible; watching what the page actually shows removes the guesswork.

2. "Error solving the challenge. Timeout after 60000 ms"

Here the challenge was detected and FlareSolverr waited for it to pass, and it did not pass within maxTimeout, which defaults to 60,000 milliseconds. Three causes, in order of how often they turn up.

The machine is slow or overloaded. FlareSolverr's own documentation warns that browsers consume a lot of memory and that a machine with little RAM should not make many requests at once. Every request without a session launches a browser. On a small VPS or a NAS, a handful of parallel requests is enough to push each one past the timeout. Reduce concurrency on the client side, raise maxTimeout (120,000 is a common choice), and use sessions so that a browser is reused rather than launched per request.

The IP is failing the challenge. Cloudflare's challenge is not only a JavaScript puzzle; it weighs the reputation of the address it is talking to. A datacenter or VPS address that Cloudflare has seen abused, or that belongs to a hosting range under suspicion, can sit in the challenge loop indefinitely: the page reloads, re-challenges, and never clears. Raising the timeout does nothing for this. A different kind of address is the answer, which is what section 5 is about.

The browser is out of date. FlareSolverr drives a bundled browser, and a version that Cloudflare has learned to recognise fails challenges it used to pass. Update the container. If you run it outside Docker, make sure the browser and the driver match the versions the release expects.

3. "Cloudflare has blocked this request. Probably your IP is banned for this site"

Of the four messages this one is the clearest, and the one people most often try to fix in the wrong place. Cloudflare did not present a challenge. It answered with a block page for the address FlareSolverr is using, and the message says so: check in your web browser. Do exactly that, from the same machine. If a normal browser gets the same block, no configuration of FlareSolverr will change it, because the decision was made about the IP before any browser behaviour was examined.

Sites under scraping pressure ban whole hosting ranges, which is why this message is so common on a VPS and so rare from a home connection. What works is an address the site has no history with, and for a tool that needs the same address across the challenge and the requests that follow, that means a residential proxy with a sticky session, configured as in section 5. Do not respond by retrying in a loop; a banned range that keeps knocking stays banned.

4. "The cookies provided by FlareSolverr are not valid"

This message comes from Jackett and Prowlarr rather than from FlareSolverr itself, and it describes a handoff failure. FlareSolverr solved the challenge and received a clearance cookie. Jackett or Prowlarr then sent that cookie to the site, and the site rejected it. Cloudflare binds the clearance cookie to the IP address that solved the challenge, and to the user agent, so a cookie solved from one address is worthless from another.

The consumer used a different address than FlareSolverr did. The ways that happens:

• IPv6 on one side. One container reaches the site over IPv6 and the other over IPv4. From the site's point of view those are two unrelated visitors. Disable IPv6 in both containers, or enable it in both.
• A proxy or VPN on one side only. FlareSolverr is routed through a proxy and Jackett is not, or the reverse. Both must exit through the same address: set the same proxy in FlareSolverr's session and in the consumer's own proxy settings.
• Different Docker networks. Two containers on different networks or hosts can have different egress paths, especially where one host has a VPN client running.

The user agent must match too. Jackett and Prowlarr handle that automatically by adopting the user agent FlareSolverr reports; a custom client must copy it from the response.

The test is simple: from inside each container, fetch an IP echo page and compare. If the two addresses differ, that is the bug, and no amount of FlareSolverr configuration fixes a cookie that is being replayed from the wrong place.

5. Using a proxy with FlareSolverr, and getting the session right

The proxy field in a request.get call routes FlareSolverr's browser through a proxy, and it accepts http://, socks4://, and socks5:// addresses:

{
  "cmd": "request.get",
  "url": "https://example.com/",
  "maxTimeout": 120000,
  "proxy": {"url": "http://203.0.113.7:8080"}
}

Two rules from FlareSolverr's own documentation trip people up. First, a username and password are only accepted in sessions.create, not in the per-request proxy. Second, when a request names a session, the per-request proxy is ignored and the session's proxy is used. So an authenticated proxy always goes through a session:

{
  "cmd": "sessions.create",
  "session": "resi-1",
  "proxy": {
    "url": "http://gateway.example:8080",
    "username": "user-session-abc123",
    "password": "pass"
  }
}

Requests then pass "session": "resi-1" and inherit the proxy. The PROXY_URL, PROXY_USERNAME, and PROXY_PASSWORD environment variables set a default for everything, and a request or session proxy overrides them. Destroy sessions with sessions.destroy when you are done, because each one holds a browser open.

The rule that matters more than any of the syntax: the proxy session has to be sticky. The clearance cookie is bound to the IP that solved the challenge. A rotating proxy that changes address on every request gives FlareSolverr a fresh IP for the challenge and your client a different one for the fetch, which reproduces the cookies-not-valid failure from section 4 with a proxy in the loop. Use a session that holds one address for the life of the cookie, and put the same session credentials in the consumer's proxy settings so that FlareSolverr and the client exit together. Our guide to sticky versus rotating sessions explains how a session id in the username keeps the address fixed, and the anti-bot solver proxy setup guide covers the same handoff for hosted solvers.

A few practical points on the proxy leg:

• net::ERR_PROXY_CONNECTION_FAILED in FlareSolverr's log means its browser could not reach the proxy address. Inside Docker, 127.0.0.1 is the container, not your host; use the host's address, or run the container with host networking. SOCKS proxies that work in curl have produced this error inside FlareSolverr's browser in reported cases, so if an HTTP proxy endpoint is available, use it.
• FlareSolverr tests connectivity at startup against TEST_URL, which defaults to a Google page. If the proxy or network cannot reach that, FlareSolverr fails to start; set TEST_URL to a page the route can reach.
• Verify the proxy before you blame FlareSolverr. Our proxy checker confirms that it answers, supports HTTPS tunnels, and exits where you expect.
• Do not expose port 8191 to the internet. FlareSolverr's documentation says so plainly, because an open instance is a free browser farm for anyone who finds it.

6. What FlareSolverr cannot do

A tool asked to do a job outside its design looks broken, and a fair share of "FlareSolverr not working" reports are exactly that.

Interactive captchas. FlareSolverr's documentation states that none of its captcha solvers work at this time, and it returns "Captcha detected but no automatic solver is configured" when it meets one. A Turnstile widget that requires verification, an hCaptcha, or a reCAPTCHA is outside its scope. For those, a solver API takes the challenge and returns a token; our guides on Cloudflare Turnstile and anti-bot solver APIs cover how that works and how to keep the proxy consistent across the handoff.

Other bot-management products. FlareSolverr targets Cloudflare. A site fronted by DataDome, PerimeterX, Akamai, or Kasada shows challenges FlareSolverr has no detection for, and the answer is the specific approach for that vendor. Our scraping past Cloudflare guide has links to each.

IP-based blocks. No browser solves an IP ban. If the address is blocked, the message in section 3 is what you get, and the only fix is a different address.

Volume. Each request is a browser. FlareSolverr at scale means a machine full of Chrome instances, and it is a poor fit for high-throughput scraping. For a job that needs thousands of pages an hour, a residential pool with sessions and a client that reuses the clearance cookie for its lifetime does far more per gigabyte of RAM than a browser per request.

The setup that works

For most FlareSolverr users the working configuration is short. Keep FlareSolverr current. Use sessions so that browsers are reused. Give it a maxTimeout that fits the machine. When challenges loop or the IP is banned, put a residential proxy with a sticky session in sessions.create, and put the same session in the consumer's proxy settings so that both exit from one address. And when the log reports a captcha or a vendor FlareSolverr does not know, stop fighting it and switch tools.

Our residential proxies support session ids in the username for exactly this kind of sticky handoff, and every address in the pool is verified by the same engine that runs our checker before it is handed out, so the IP FlareSolverr solves on is one that a site has no reason to distrust.