If youve used Prowlarr, you might have experienced cloudflare blocking access to certain trackers.

There’s a docker-based solution called cloudsolverr which automatically bypasses these cloudflare challenges by spinning up a headless chromium browser.

Main issue is it’s heavy on resources (I have an rpi4b) and doesn’t have an easy native setup (I’ve not had time to practice with docker stuff yet).

Is there a manual way for me to resolve these cloudflare challenges so I can add the trackers? It’s mainly for public shit like 1337x just to fill out my access to TV shows where my other trackers fail or get rate-limited.

  • CountVon
    link
    fedilink
    English
    arrow-up
    14
    arrow-down
    1
    ·
    edit-2
    2 months ago

    I think you’re referring to FlareSolverr. If so, I’m not aware of a direct replacement.

    Main issue is it’s heavy on resources (I have an rpi4b)

    FlareSolverr does add some memory overhead, but otherwise it’s fairly lightweight. On my system FlareSolverr has been up for 8 days and is using ~300MB:

    NAME           CPU %     MEM USAGE
    flaresolverr   0.01%     310.3MiB
    

    Note that any CPU usage introduced by FlareSolverr is unavoidable because that’s how CloudFlare protection works. CloudFlare creates a workload in the client browser that should be trivial if you’re making a single request, but brings your system to a crawl if you’re trying to send many requests, e.g. DDOSing or scraping. You need to execute that browser-based work somewhere to get past those CloudFlare checks.

    If hosting the FlareSolverr container on your rpi4b would put it under memory or CPU pressure, you could run the docker container on a different system. When setting up Flaresolverr in Prowlarr you create an indexer proxy with a tag. Any indexer with that tag sends their requests through the proxy instead of sending them directly to the tracker site. When Flaresolverr is running in a local Docker container the address for the proxy is localhost, e.g.:

    If you run Flaresolverr’s Docker container on another system that’s accessible to your rpi4b, you could create an indexer proxy whose Host is “http://<other_system_IP>:8191”. Keep security in mind when doing this, if you’ve got a VPN connection on your rpi4b with split tunneling enabled (i.e. connections to local network resources are allowed when the tunnel is up) then this setup would allow requests to these indexers to escape the VPN tunnel.

    On a side note, I’d strongly recommend trying out a Docker-based setup. Aside from Flaresolverr, I ran my servarr setup without containers for years and that was fine, but moving over to Docker made the configuration a lot easier. Before Docker I had a complex set of firewall rules to allow traffic to my local network and my VPN server, but drop any other traffic that wasn’t using the VPN tunnel. All the firewall complexity has now been replaced with a gluetun container, which is much easier to manage and probably more secure. You don’t have to switch to Docker-based all in go, you can run hybrid if need be.

    If you really don’t want to use Docker then you could attempt to install from source on the rpi4b. Be advised that you’re absolutely going offroad if you do this as it’s not officially supported by the FlareSolverr devs. It requires install an ARM-based Chromium browser, then setting some environment variables so that FlareSolverr uses that browser instead of trying to download its own. Exact steps are documented in this GitHub comment. I haven’t tested these steps, so YMMV. Honestly, I think this is a bad idea because the full browser will almost certainly require more memory. The browser included in the FlareSolverr container is stripped down to the bare minimum required to pass the CloudFlare checks.

    If you’re just strongly opposed to Docker for whatever reason then I think your best bet would be to combine the two approaches above. Host the FlareSolverr proxy on an x86-based system so you can install from source using the officially supported steps.

    • merthyr1831@lemmy.mlOP
      link
      fedilink
      English
      arrow-up
      2
      ·
      2 months ago

      Appreciate the detailed info here. Honestly does sound like Docker is the way to do it properly.

      thanks for the info! :)

  • American_Jesus@lemm.ee
    link
    fedilink
    English
    arrow-up
    3
    ·
    edit-2
    2 months ago

    I use a TOR proxy, it requires a little more knowledge.

    Have a docker container running TOR as SOCKS/HTTP proxy.

    NAME       CPU %     MEM USAGE
    torproxy   0.07%     46.78MiB
    

    Added SOCKS proxy to Prowlarr. Added a tag to this proxy.

    Create/modify indexer with TOR/Onion domain, with proxy tag.

    I have that for 1337x and BTdig.

    Instead of connecting to 1337x.to wich requires CloudFlare, it connects to l337xdarkkaqfwzntnfk5bmoaroivtl6xsbatabvlb52umg6v3ch44yd.onion via TOR proxy.

    Also i can use that TOR proxy for other containers/software.

    HOW TO:

    1. Use a TOR proxy docker container.
    1. Add TOR proxy to Prowlarr (Settings -> Indexers), with a tag (ex: TOR)
    2. Create a new Prowlarr indexer
    • Copy indexer from prowlarr/Definitions to prowlarr/Definitions/Custom (ex: 1337x.yml)
    • Change the indexer URL and ID/Name
    id: 1337x-TOR
    name: 1337x-TOR
    ...
    links:
        - http://l337xdarkkaqfwzntnfk5bmoaroivtl6xsbatabvlb52umg6v3ch44yd.onion/
    ...
    
    1. Restart Prowlarr
    2. Add indexer (1337x-TOR) with Base URL .onion URL and with tag from TOR proxy (ex: TOR).

    Other onion torrent sites:

    • TorrentGalaxy: http://galaxy3yrfbwlwo72q3v2wlyjinqr2vejgpkxb22ll5pcpuaxlnqjiid.onion/
    • btdig: http://btdigggink2pdqzqrik3blmqemsbntpzwxottujilcdjfz56jumzfsyd.onion/
    • guybrush_threepwood_MP@lemmy.dbzer0.com
      link
      fedilink
      English
      arrow-up
      1
      ·
      2 months ago

      Turns out, my ISP has silently done a transparent DNS redirection. And their DNS servers are bad. Had to change to DoT to get it working. Something I should have done long ago anyway.