starred/Prowlarr

Fork 0

mirror of https://github.com/Prowlarr/Prowlarr.git synced 2026-03-02 22:57:22 -05:00

Prowlarr not using Proxy Response Content for YTS #1261

New issue

Open

opened 2026-02-20 10:09:03 -05:00 by deekerman · 7 comments

deekerman commented

2026-02-20 10:09:03 -05:00

Owner

Originally created by @AperionAus on GitHub (Dec 2, 2025).

I attest that there is not an existing issue for this?

I have searched the existing open and closed issues

I confirm this is not related to a Cardigann YML Indexer

Current Behavior

Byparr is returning the YTS JSON just fine, trace log shows a success response and the correct/solved Response Content JSON being provided to prowlarr.
Prowlarr seems to then completely ignore the correct/solved Response Content and sends another request without Byparr which then obviously returns a Cloudflare issue which Prowlarr then registers as a cloudflare issue for the whole index, despite it already having received the correct/solved Response Content from Byparr.

Expected Behavior

Byparr returns correct/solved Response Content JSON.
Prowlarr then uses this JSON and doesn't submit another HttpClient|Req: [GET] request.
Prowlarr doesn't register the index request as failed since it has already received the correct/solvved Response Content JSON.

Steps To Reproduce

YTS Index with Byparr proxy tag

Environment

- OS: Windows 10
- Prowlarr:2.3.0.5236
- Docker Install: 4.48.0 (207573)
- Using Reverse Proxy: No
- Browser: Chrome Version 142.0.7444.176

What branch are you running?

Master

Trace Logs?

Prowlarr Trace Log - YTS Issue.txt

I attest that Trace Logs have been provided as applicable. Reports will be closed if the required logs are not provided.

I attest that I have read and followed the steps in the wiki link above and provided the required trace logs - the logs contain trace - that are relevant and show this issue.

Originally created by @AperionAus on GitHub (Dec 2, 2025). ### I attest that there is not an existing issue for this? - [x] I have searched the existing open and closed issues ### I attest this is not related to a Cardigann YML Indexer. - [x] I confirm this is not related to a Cardigann YML Indexer ### Current Behavior Byparr is returning the YTS JSON just fine, trace log shows a success response and the correct/solved Response Content JSON being provided to prowlarr. Prowlarr seems to then completely ignore the correct/solved Response Content and sends another request without Byparr which then obviously returns a Cloudflare issue which Prowlarr then registers as a cloudflare issue for the whole index, despite it already having received the correct/solved Response Content from Byparr. ### Expected Behavior Byparr returns correct/solved Response Content JSON. Prowlarr then uses this JSON and doesn't submit another HttpClient|Req: [GET] request. Prowlarr doesn't register the index request as failed since it has already received the correct/solvved Response Content JSON. ### Steps To Reproduce YTS Index with Byparr proxy tag ### Environment ```markdown - OS: Windows 10 - Prowlarr:2.3.0.5236 - Docker Install: 4.48.0 (207573) - Using Reverse Proxy: No - Browser: Chrome Version 142.0.7444.176 ``` ### What branch are you running? Master ### Trace Logs? [Prowlarr Trace Log - YTS Issue.txt](https://github.com/user-attachments/files/23892730/Prowlarr.Trace.Log.-.YTS.Issue.txt) ### I attest that Trace Logs have been provided as applicable. Reports will be closed if the required logs are not provided. - [x] I attest that I have read and followed the steps in the wiki link above and provided the required trace logs - the logs contain `trace` - that are relevant and show this issue.

deekerman added the

Type: Bug

Status: Needs Triage

labels

2026-02-20 10:09:03 -05:00

deekerman commented

2026-02-20 10:09:04 -05:00

Author

Owner

@DevMan01 commented on GitHub (Dec 2, 2025):

Same here, almost identical, except I'm using Flaresolverr

@DevMan01 commented on GitHub (Dec 2, 2025): Same here, almost identical, except I'm using Flaresolverr

deekerman commented

2026-02-20 10:09:04 -05:00

Author

Owner

@AperionAus commented on GitHub (Dec 2, 2025):

After further investigation, it seems that Prowlarr usually only uses the cookies provided by Byparr, not the actually response content.
Prowlarr then uses the provided cookies to run it's own request like normal.

If you check the trace logs for another indexer that correctly uses Byparr (or Flaresolverr) then you'll see the correct cookies being returned (titled cf_clearance).

However, it seems that Byparr doesn't get presented with a cloudflare prompt, so it can't return the cf_clearance cookies.

Unsure why prowlarr is presented with the cloudflare prompt but Byparr isn't...

I've temporarily found success by using one of the other listed YTS URLs within prowlarr, which always prompts Byparr with the cloudflare prompt and proceeds to provide the required cookies etc

@AperionAus commented on GitHub (Dec 2, 2025): After further investigation, it seems that Prowlarr usually only uses the cookies provided by Byparr, not the actually response content. Prowlarr then uses the provided cookies to run it's own request like normal. If you check the trace logs for another indexer that correctly uses Byparr (or Flaresolverr) then you'll see the correct cookies being returned (titled cf_clearance). However, it seems that Byparr doesn't get presented with a cloudflare prompt, so it can't return the cf_clearance cookies. Unsure why prowlarr is presented with the cloudflare prompt but Byparr isn't... I've temporarily found success by using one of the other listed YTS URLs within prowlarr, which always prompts Byparr with the cloudflare prompt and proceeds to provide the required cookies etc

deekerman commented

2026-02-20 10:09:04 -05:00

Author

Owner

@ilike2burnthing commented on GitHub (Dec 3, 2025):

I can't reproduce this, but it's likely a combination of IP and Prowlarr UA triggering the challenge, so then when it's passed over to FlareSolverr/Byparr there's no challenge to solve, and so no cookies to pass back to Prowlarr.

You'll likely see this in Prowlarr and FlareSolverr/Byparr logs.

This can't be solved.

@ilike2burnthing commented on GitHub (Dec 3, 2025): I can't reproduce this, but it's likely a combination of IP and Prowlarr UA triggering the challenge, so then when it's passed over to FlareSolverr/Byparr there's no challenge to solve, and so no cookies to pass back to Prowlarr. You'll likely see this in Prowlarr and FlareSolverr/Byparr logs. This can't be solved.

deekerman commented

2026-02-20 10:09:04 -05:00

Author

Owner

@quaintops commented on GitHub (Feb 10, 2026):

Seems to be a bug in the FlareSolverr integration, and not a FlareSolverr/Byparr configuration issue. I have a fix (thanks Claude) and will shoot over a PR.

Root Cause

In FlareSolverr.cs → PostResponse(), after FlareSolverr/Byparr successfully solves the Cloudflare challenge and returns the full page HTML + cookies, Prowlarr discards the response body and makes a second HTTP request using only the returned cookies:

// FlareSolverr.cs, PostResponse()
InjectCookies(newRequest, result);

// This second request gets 403'd:
var finalResponse = _httpClient.Execute(newRequest);
return finalResponse;

This second request fails because Cloudflare's cf_clearance cookie is bound to the TLS fingerprint of the browser that solved the challenge (FlareSolverr/Byparr's headless Chrome). .NET's HttpClient has a completely different TLS fingerprint, so Cloudflare rejects the cookie and returns 403.

This affects every indexer that uses Cloudflare's managed challenge, not just YTS. The "workaround" of trying different URLs only works when the alternate URL doesn't trigger a challenge at all.

@ilike2burnthing — the issue isn't that there's no challenge to solve. The trace logs clearly show FlareSolverr solving successfully (200 OK, full HTML body returned). The problem is that Prowlarr throws away that solved response and retries with cookies that can't work from a different TLS stack.

Fix

The solved HTML body from FlareSolverr already contains everything Prowlarr needs. The fix is to use it directly instead of making the second request:

InjectCookies(newRequest, result);

// Use FlareSolverr's response body directly — a second HTTP request would
// get 403'd because cf_clearance is bound to the solver's TLS fingerprint
if (result.Solution.Response.IsNotNullOrWhiteSpace())
{
    return new HttpResponse(
        response.Request,
        response.Headers,
        response.Cookies,
        result.Solution.Response,
        response.ElapsedTime,
        HttpStatusCode.OK);
}

// Fallback: if FlareSolverr returned no body, try cookies (original behavior)
var finalResponse = _httpClient.Execute(newRequest);
return finalResponse;

There's also a minor existing bug on the error handling line — it reports response.StatusCode (the original Cloudflare 403) instead of flaresolverrResponse.StatusCode (the actual FlareSolverr response status).

Verification

In my own environment I've deployed this as a patched DLL overlay on linuxserver/prowlarr:latest (v2.3.0.5236) using Byparr. Tested with LinuxTracker (Cloudflare-protected). Byparr solves the challenge in ~7s and Prowlarr uses the response directly — no second request, no 403.

@quaintops commented on GitHub (Feb 10, 2026): Seems to be a bug in the FlareSolverr integration, and not a FlareSolverr/Byparr configuration issue. I have a fix (thanks Claude) and will shoot over a PR. ## Root Cause In `FlareSolverr.cs` → `PostResponse()`, after FlareSolverr/Byparr successfully solves the Cloudflare challenge and returns the full page HTML + cookies, Prowlarr **discards the response body** and makes a second HTTP request using only the returned cookies: ```csharp // FlareSolverr.cs, PostResponse() InjectCookies(newRequest, result); // This second request gets 403'd: var finalResponse = _httpClient.Execute(newRequest); return finalResponse; ``` This second request fails because Cloudflare's `cf_clearance` cookie is bound to the **TLS fingerprint** of the browser that solved the challenge (FlareSolverr/Byparr's headless Chrome). .NET's `HttpClient` has a completely different TLS fingerprint, so Cloudflare rejects the cookie and returns 403. This affects **every** indexer that uses Cloudflare's managed challenge, not just YTS. The "workaround" of trying different URLs only works when the alternate URL doesn't trigger a challenge at all. @ilike2burnthing — the issue isn't that there's no challenge to solve. The trace logs clearly show FlareSolverr solving successfully (200 OK, full HTML body returned). The problem is that Prowlarr throws away that solved response and retries with cookies that can't work from a different TLS stack. ## Fix The solved HTML body from FlareSolverr already contains everything Prowlarr needs. The fix is to use it directly instead of making the second request: ```csharp InjectCookies(newRequest, result); // Use FlareSolverr's response body directly — a second HTTP request would // get 403'd because cf_clearance is bound to the solver's TLS fingerprint if (result.Solution.Response.IsNotNullOrWhiteSpace()) { return new HttpResponse( response.Request, response.Headers, response.Cookies, result.Solution.Response, response.ElapsedTime, HttpStatusCode.OK); } // Fallback: if FlareSolverr returned no body, try cookies (original behavior) var finalResponse = _httpClient.Execute(newRequest); return finalResponse; ``` There's also a minor existing bug on the error handling line — it reports `response.StatusCode` (the original Cloudflare 403) instead of `flaresolverrResponse.StatusCode` (the actual FlareSolverr response status). ## Verification In my own environment I've deployed this as a patched DLL overlay on `linuxserver/prowlarr:latest` (v2.3.0.5236) using Byparr. Tested with LinuxTracker (Cloudflare-protected). Byparr solves the challenge in ~7s and Prowlarr uses the response directly — no second request, no 403.

deekerman commented

2026-02-20 10:09:04 -05:00

Author

Owner

@ilike2burnthing commented on GitHub (Feb 10, 2026):

There are two common issues people using Prowlarr have experienced:

FlareSolverr finds no challenge, because CF is seemingly flagging the Prowlarr UA
FlareSolverr does get a challenge, but the cookie is invalid for Prowlarr

Jackett doesn't seem to have either of these issues, but it uses FlareSolverrSharp.

How does your PR handle semi-/private indexers, where there might be a need to relogin first, so you're dealing with a bunch of redirects.

@ilike2burnthing commented on GitHub (Feb 10, 2026): There are two common issues people using Prowlarr have experienced: 1) FlareSolverr finds no challenge, because CF is seemingly flagging the Prowlarr UA 2) FlareSolverr does get a challenge, but the cookie is invalid for Prowlarr Jackett doesn't seem to have either of these issues, but it uses FlareSolverrSharp. How does your PR handle semi-/private indexers, where there might be a need to relogin first, so you're dealing with a bunch of redirects.

deekerman commented

2026-02-20 10:09:04 -05:00

Author

Owner

@quaintops commented on GitHub (Feb 10, 2026):

@ilike2burnthing, I don't think I have an example of a [semi]private that triggers the CF block to test with. If I recall correctly, Prowlarr only invokes Byparr after a positive detection. The tag I believe is insufficient for this scenario unfortunately. If you're curious and can test it yourself, feel free to try out the binaries I've built here: https://github.com/quaintops/Prowlarr/releases/tag/v2.3.0.5236-flaresolverr-fix

@quaintops commented on GitHub (Feb 10, 2026): @ilike2burnthing, I don't think I have an example of a [semi]private that triggers the CF block to test with. If I recall correctly, Prowlarr only invokes Byparr after a positive detection. The tag I believe is insufficient for this scenario unfortunately. If you're curious and can test it yourself, feel free to try out the binaries I've built here: https://github.com/quaintops/Prowlarr/releases/tag/v2.3.0.5236-flaresolverr-fix

deekerman commented

2026-02-20 10:09:04 -05:00

Author

Owner

@ilike2burnthing commented on GitHub (Feb 11, 2026):

Tried the Windows binaries, the UI folder was missing, transplanting it from the official release didn't work.

As for semi-/private trackers that require FS (might be a little outdated, but you'll have options) - https://github.com/search?q=repo%3AProwlarr%2FIndexers+flaresolverr+private+language%3AYAML&type=code

@ilike2burnthing commented on GitHub (Feb 11, 2026): Tried the Windows binaries, the UI folder was missing, transplanting it from the official release didn't work. As for semi-/private trackers that require FS (might be a little outdated, but you'll have options) - https://github.com/search?q=repo%3AProwlarr%2FIndexers+flaresolverr+private+language%3AYAML&type=code