FlareSolverr Not Working? Every Error Message, What Causes It, and the Fix

When FlareSolverr seems broken, first read which program wrote the error, because FlareSolverr writes some messages and Jackett and Prowlarr write others about it. The project itself is alive: version 3.5.2 came out on 12 September 2026. Most failures have one of three causes. The site blocks the address, FlareSolverr and your app reach the site from two different addresses, or your app cannot reach FlareSolverr at all.

We traced every message below to the line of code that prints it, in FlareSolverr 3.5.2, in FlareSolverrSharp 4.0.0 (the library inside Jackett) and in Prowlarr. We also sorted the 105 issues opened on the FlareSolverr tracker in the year to 25 September 2026 by the message each one quotes.

Is FlareSolverr broken right now?

Probably not for everyone, since the project has shipped seven releases in the past twelve months and the latest, 3.5.2, is from 12 September 2026. Some guides still say otherwise: the TRaSH Guides page for Prowlarr, last updated in October 2025, calls FlareSolverr "currently non-functional" and points to issue #1253. That issue was closed on 3 June 2025, the day version 3.3.22 changed how FlareSolverr ticks the checkbox.

A single site can still break for everyone when Cloudflare changes its page. Before you change your setup, run two checks.

• Open http://<host>:8191/ in a browser. FlareSolverr should answer FlareSolverr is ready! with its version and its User-Agent.
• Run the test from the FlareSolverr wiki. Add the public indexers 0Magnet, BT.etree and Torrent[CORE], search, and watch each request show up in the FlareSolverr log.

If both work and one site fails, the problem is that site or your address. Search the open issues for the site name as well. In our count, 41 of the 105 issues were closed as duplicates of an earlier report.

"Challenge not detected!" and the status that always says 200

This message is not an error. FlareSolverr opened the page, found nothing it knows as a challenge, and sent back the page and its cookies with status ok. It knows a challenge by two page titles, Just a moment... and DDoS-Guard, or by ten page elements. Anything else counts as no challenge.

Three different situations produce it.

• The site does not challenge this address: the page is fine and FlareSolverr had nothing to do. Your app may still be challenged from its own address, which is the handoff problem below.
• The challenge came in another language: the title check is in English. Twice in August and September 2026 the project triager gave the same answer: set LANG=en_US. FlareSolverr passes it to Chrome as the page language.
• The browser never reached the site: some network failures come back as a normal answer.

The last one fools people because of the status. In version 3.5.2 the status inside the answer is always 200, and the headers are always empty. The code sets both by hand, because Selenium does not report them. One user reported a proxy failure that came back as ok and 200, with the Chrome page "This site can't be reached" as the HTML (issue #1582). Other network failures do raise an error, with a Chrome code such as net::ERR_NAME_NOT_RESOLVED in the text.

So instead of trusting the 200, look at what FlareSolverr actually got. Set LOG_LEVEL=debug and LOG_HTML=true to print the HTML in the log. Or add "returnScreenshot": true to a request, and the answer carries a picture of the final page.

"Error solving the challenge. Timeout after 60.0 seconds."

The challenge was still on screen when time ran out. The number is your maxTimeout in seconds, 60 by default. Jackett users see 55.0, because Jackett waits 55,000 milliseconds by default. FlareSolverr puts Error: in front of the line, and Jackett wraps it in its own text, which begins FlareSolverr was unable to process the request.

While it waits, FlareSolverr checks the page again and again, and each round it presses Tab and Space to tick the checkbox. In the debug log every round prints The Cloudflare 'Verify you are human' button not found on the page. That line looks like the cause, and it is not. It shows up on every round, and 10 of the 105 issues in our count quote it.

Work through the causes in this order.

1. Give it more time: the standard answer from the project triager is a timeout of 120 seconds in Jackett or Prowlarr. Prowlarr accepts 1 to 180 seconds.
2. Give each check more time on a slow machine: since 3.5.2, BROWSER_WAIT_TIMEOUT sets how many seconds each check waits. The default is 1, which a small NAS or a busy host can miss.
3. Run fewer browsers: every request without a session starts a new browser. The README warns against many requests at once on a machine with little memory, and Jackett already sends FlareSolverr one request at a time.
4. Update: a fix for a changed Cloudflare page arrives as a new release, not as a setting.
5. Know when time is not the cause: Cloudflare says a managed challenge can ask for more when the browser looks automated. In 2026 the triager also told several reporters that the site was most likely blocking their address. More time does not fix that, and neither does any other setting on this page.

"The cookies provided by FlareSolverr are not valid"

Only Jackett writes this message. Prowlarr has no such line, and its own version is covered below. The message means the handoff failed. Jackett asked the site for a page and got a challenge. It then asked FlareSolverr, whose browser passed the challenge and sent back cookies and its User-Agent. Jackett copied the cookies whose names start with cf_, __cf or __ddg, set the same User-Agent and asked again, and the site challenged it again.

Cloudflare documents its clearance cookie as "securely tied to the specific visitor and device it was issued to, preventing reuse across machines". The FlareSolverr changelog puts it in practical terms: use the same User-Agent and the same proxy as FlareSolverr. Jackett takes care of the User-Agent, and the address is up to you.

The FlareSolverr and Jackett wikis name the usual ways two programs end up on different addresses.

• A VPN or proxy on one side only: Jackett goes out through a VPN container and FlareSolverr does not, or the other way round.
• IPv6 on one side: one reaches the site over IPv6 and the other over IPv4. The Jackett wiki suggests net.ipv6.conf.all.disable_ipv6=1 in every container.
• Two machines or two networks: the FlareSolverr wiki asks for the same device and the same IP. In Docker it asks for both containers on the host network.

The test takes a minute. From inside each container, ask an IP echo service for your address and compare the two answers. If they differ, that is the bug.

A proxy set in Jackett is not a second path: Jackett passes its own proxy setting to FlareSolverr with every request, username and password included. A proxy that changes its address between requests still splits the handoff, because the challenge leaves from one address and the retry from another, and this message comes straight back.

"Empty cookies returned by FlareSolverr"

Jackett and Prowlarr both write this one. In Prowlarr it ends with a full stop and often sits inside Unable to connect to indexer, check the log above the ValidationFailure for more details. It means FlareSolverr answered without a single cookie, so its browser saw a different page from your app. Your app got a challenge, and the browser got a page that set no cookies at all.

Check in this order.

1. The language: on a system in another language, set LANG=en_US for FlareSolverr. The triager gave exactly this answer to two reports in August and September 2026, one of them on version 3.5.2.
2. What the browser got: turn on LOG_LEVEL=debug and LOG_HTML=true. The triager asks for the same thing first, and often finds a blocked address in it.
3. The address: as with the cookie error above, both programs must leave from the same place.

"Challenge detected but FlareSolverr is not configured", and the Prowlarr tags

Jackett found a challenge and has no FlareSolverr address. Enter one in the Jackett dashboard as the FlareSolverr API URL, for example http://flaresolverr:8191 in Docker. Apart from a special case for four Dutch sites, Jackett and Prowlarr only call something a challenge when three things hold. The answer comes from a Cloudflare or DDoS-Guard server, the status is 403 or 503, and the page carries one of five known markers.

Prowlarr has no such message. It uses FlareSolverr only when the FlareSolverr proxy and the indexer carry the same tag and Cloudflare is detected, and a FlareSolverr proxy with no tags is switched off. If the tags do not match, or the challenge is still there after FlareSolverr, Prowlarr reports Unable to access <host>, blocked by CloudFlare Protection. Its log adds Cloudflare protection detected for [indexer], Flaresolverr may be required. Add a tag to the proxy under Settings, Indexers, and the same tag to each indexer that needs it.

"Unable to connect to proxy" in Prowlarr, "Error connecting to FlareSolverr server" in Jackett

In Prowlarr, FlareSolverr is added as an indexer proxy. When its Test button fails, the message says Unable to connect to proxy, and the proxy it means is FlareSolverr. There are two cases, and the text after the colon tells them apart.

Prowlarr cannot reach FlareSolverr when the text names a refused or unknown address. The default Host in Prowlarr is http://localhost:8191/, and inside a container localhost is that container. The Jackett wiki says the same of 127.0.0.1. Put both containers on one Docker network you create yourself, and use the container name, as in http://flaresolverr:8191/. On the default bridge network, containers reach each other only by IP address. If FlareSolverr runs on the host itself, use host.docker.internal, which Docker Desktop provides and --add-host host.docker.internal=host-gateway adds elsewhere.

Prowlarr reached FlareSolverr, and FlareSolverr failed, when the text says HTTP request failed: [500:InternalServerError] [POST]. FlareSolverr answers 500 whenever a command fails. The Test asks FlareSolverr to load https://prowlarr.servarr.com/v1/ping, so a FlareSolverr that cannot look up names fails it. In one such report the log said net::ERR_NAME_NOT_RESOLVED. The triager asked for curl -v https://prowlarr.servarr.com/v1/ping from inside the FlareSolverr container, and the image includes curl.

The same 500 also appears as Unable to connect to indexer, indexer's server is unavailable. The indexer may be fine, because the error came from FlareSolverr, and its log says why. Jackett writes Error connecting to FlareSolverr server when it cannot reach the address at all, and the fix is the same host name check.

"Cloudflare has blocked this request"

This message means what it says. FlareSolverr raises it when the page title starts with Access denied or Attention Required! | Cloudflare, or when the Cloudflare error box is on the page, so there is no challenge to solve. Cloudflare documents blocks by a firewall rule (error 1020), by the network the address belongs to (1005, a ban on the ASN) and by the address itself (1006).

Open the site in a normal browser from the same address, as the message says. If the browser is blocked too, no FlareSolverr setting will change it. Do not retry in a loop, because Cloudflare warns that repeated attempts can extend a block for rate limiting (1015). The block is the site's decision. Our guide to Cloudflare's "Sorry, you have been blocked" page explains what a blocked visitor can do, including asking the site's owner.

Using a proxy with FlareSolverr

FlareSolverr takes a proxy per request, per session, or as a default through PROXY_URL, PROXY_USERNAME and PROXY_PASSWORD. Those three arrived in 3.4.2 and apply only to requests without a proxy of their own. The address needs its scheme: http://, socks4:// or socks5://.

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

The README says a username and password work only in sessions.create. The code of 3.5.2 builds the same thing for a single request, and Jackett and Prowlarr send their proxy that way. Four details decide whether the proxy is really used.

• SOCKS5 with a password cannot work: Chrome offers a SOCKS5 proxy one login method, "no authentication", as the Chromium source shows. In our own test of Chrome 153, every greeting offered that single method. Use the HTTP port of the same proxy instead.
• A request that names a session ignores its own proxy: the proxy of the session applies.
• A session FlareSolverr does not have gets no proxy at all: a request that names an unknown session creates it on the spot, without a proxy. A session rebuilt after session_ttl_minutes loses its proxy too, so create your sessions yourself with sessions.create.
• With a password, an extension carries the proxy: FlareSolverr then writes a small Chrome extension instead of a --proxy-server flag, and nothing else sets the proxy. An open issue (#1751) reports that a quote or a backslash in the password breaks that extension. Google Chrome 137 and later also ignore extensions loaded from the command line. FlareSolverr asks for them back, and its Docker image runs Chromium, where they still load.

After any change, check the exit address. Send FlareSolverr a request.get for an IP echo page through the same session, and read the address in the HTML it returns. Before that, our proxy checker tells you whether the proxy answers, supports HTTPS tunnels and exits where you expect.

FlareSolverr does not start

The Docker image brings its own Chromium and driver. Other installs download the driver from Google on the first browser start, from googlechromelabs.github.io and storage.googleapis.com. A DNS filter, a firewall or a blocked network stops that download, and the start fails with Error starting Chrome. One reporter saw urlopen error [Errno 104] Connection reset by peer on a source install and found that the official Docker image worked.

The README still lists TEST_URL for a startup test, and some advice says to change it, but no source file of 3.5.2 reads it. The startup test only launches the browser and reads its User-Agent. Seven of the 105 issues in our count report a browser that did not start.

Keep FlareSolverr off the internet

FlareSolverr has no password of its own. The README says: "DO NOT expose FlareSolverr to the internet, as it can be abused". Its docker run example binds the port to 127.0.0.1, while the docker-compose.yml of the project publishes 8191 on every interface (issue #1754, open). Docker documents that published ports are routed before ufw rules apply. In July 2026 one operator reported that the older -p 8191:8191 example left FlareSolverr open behind ufw (issue #1746). Strangers used it, and the Chromium processes caused 228 out-of-memory kills.

Two more habits help. At the default log level FlareSolverr prints every request body, proxy username and password included (issue #1753, open), so clean a log before you post it. And take the image only from the GitHub registry or Docker Hub, as the README says. An open issue warns that flaresolverr.org copies the project without being part of it (issue #1703).

What FlareSolverr cannot do

• Captchas: the README says none of its captcha solvers work. It still documents the message Captcha detected but no automatic solver is configured. and the CAPTCHA_SOLVER setting, but no source file of 3.5.2 prints the one or reads the other, and none of the 105 issues in our count quotes that message.
• Other bot protection: the detection lists in FlareSolverr hold Cloudflare, DDoS-Guard and a few single sites. Pages from other vendors come back as "Challenge not detected!".
• Blocked addresses: a block page has nothing to solve.
• Volume: each request without a session is a whole browser.

How we counted

We read every issue opened on the FlareSolverr tracker from 26 September 2025 to 25 September 2026 through the public GitHub API, 105 in all. We matched each title and body against the exact messages above, and one issue can quote several. The 37 that quote none are security reports, packaging problems, requests about the API, questions about proxy handling and failure reports without a known message. Of the 105 reporters, 34 said they run Docker and 39 said they do not.

Sources

• FlareSolverr README, FlareSolverr project. Version 3.5.2 of 12 September 2026, read 26 and 27 September 2026. It covers the proxy, session, timeout and environment settings, and says "DO NOT expose FlareSolverr to the internet" and "At this time none of the captcha solvers work".
• src/flaresolverr_service.py, src/utils.py, src/sessions.py and docker-compose.yml, FlareSolverr 3.5.2, read 26 September 2026. They hold every FlareSolverr message, the fixed status 200, the proxy extension and the session code.
• FlareSolverr changelog and releases, read 26 September 2026. They date each change and say "make sure your client uses the same User-Agent header and Proxy that FlareSolverr uses".
• FlareSolverr wiki, Troubleshooting, last edited 25 August 2026, read 26 September 2026. "FlareSolverr should be running on the same device and using the same IP as the app making the request".
• FlareSolverr issue tracker, read 26 September 2026. Issues #1253, #1361, #1582, #1639, #1664, #1669, #1703, #1731, #1746, #1751, #1753, #1754, #1761 and #1780, and discussion #1565.
• FlareSolverrSharp 4.0.0, ClearanceHandler.cs, 11 August 2026, read 26 September 2026. It holds the Jackett messages and when each one is thrown.
• Jackett source, ServerConfig.cs, read 26 September 2026. It sets "FlareSolverrMaxTimeout = 55000" and the proxy Jackett passes to FlareSolverr.
• Jackett wiki, Troubleshooting, last edited 23 August 2026, read 26 September 2026. "In most cases this error is caused when Jackett and FlareSolverr are on different networks".
• Prowlarr source, the FlareSolverr indexer proxy, 13 September 2026: FlareSolverr.cs, read 26 September 2026, holds "Empty cookies returned by FlareSolverr." and the test page; FlareSolverrSettings.cs, read 27 September 2026, holds the default Host and the timeout range.
• Servarr wiki, Prowlarr FAQ, updated 5 September 2026, read 26 September 2026. "A Flaresolverr proxy is disabled if no tags are used".
• Cloudflare documentation, Clearance, updated 6 July 2026, and Challenge Pages, updated 6 July 2026, read 26 and 27 September 2026. The cookie is "securely tied to the specific visitor and device it was issued to", and on a managed challenge, "if Cloudflare detects non-human attributes from the visitor's browser, they may be required to interact with the challenge to solve it."
• Cloudflare documentation, error 1020, with errors 1005, 1006 and 1015, read 26 September 2026.
• Docker documentation, bridge networks, packet filtering and firewalls and docker container run, read 26 September 2026.
• Chromium source, socks5_client_socket.cc, read 26 September 2026. The SOCKS5 greeting offers "no authentication" only.
• Chromium Extensions announcement on --load-extension, 4 April 2025. The flag stops working in Chrome branded builds from Chrome 137 and keeps working in Chromium.
• Measured by HProxy: the count of 105 FlareSolverr issues on 26 September 2026, and our test of Chrome 153 against a SOCKS5 test proxy on this machine on 15 September 2026. The scripts and results are kept with the research for this page.