Bypassing ISP DNS Blocking for Prowlarr: AdGuard Home + Byparr on Proxmox

June 6, 2026

How I fixed ISP DNS hijacking and Cloudflare Turnstile blocking for Prowlarr indexers — using AdGuard Home for encrypted DNS resolution and Byparr as a modern FlareSolverr replacement.

Bypassing ISP DNS Blocking for Prowlarr

Prowlarr had been working fine with YTS and Knaben — both resolve without issue from India. But 1337x.to was a different story. It simply wouldn't load. No response, no error from Prowlarr, just silence.

The fix turned out to involve two completely separate problems stacked on top of each other. This post walks through how I diagnosed both and solved them — including a detour through FlareSolverr that didn't work and a switch to Byparr that did.


The Diagnosis — Two Problems, Not One

My first instinct was that this was a single blocking issue. It wasn't.

Problem 1 — ISP DNS hijacking. Indian ISPs intercept DNS queries and return their own block page IP for certain domains instead of the real one. When Prowlarr asked "what's the IP for 1337x.to?", the ISP's DNS server answered with a block page address. The site never had a chance to respond.

Problem 2 — Cloudflare Turnstile. Even after fixing DNS, 1337x sits behind Cloudflare's bot protection. Any automated tool — including Prowlarr — gets served a JavaScript challenge page instead of actual content. Without something to solve that challenge, Prowlarr still can't scrape the indexer.

The fix for each is independent:

  • AdGuard Home → encrypted DNS via DNS over TLS, bypassing ISP interception
  • Byparr → modern Cloudflare challenge solver, replacing the older FlareSolverr

System Reference

PropertyValue
Proxmox host192.168.0.150
AdGuard Home LXC160192.168.0.160
Byparr LXC161192.168.0.161
Prowlarr LXC153192.168.0.153
Proxmox versionPVE 8.4.19

Part 1 — AdGuard Home: Encrypted DNS on Your LAN

What AdGuard Home actually does

Every website has a real address made of numbers — like 172.67.188.67. DNS is the phone book that maps human-readable names to those numbers. By default, your ISP runs the phone book, which means they can (and do) return wrong answers for blocked sites.

AdGuard Home is a DNS server that runs inside your homelab. Instead of asking your ISP's phone book, your LXCs ask yours. AdGuard then forwards queries upstream to Cloudflare or Google — but encrypted, over DNS over TLS (DoT). Your ISP can see that a query went out but cannot read what it asked or tamper with the answer.

The real IP for 1337x.to comes back correctly. Problem 1 solved.

1.1 — Spin up the AdGuard LXC

On the Proxmox host shell, run the community script:

bash -c "$(curl -fsSL https://raw.githubusercontent.com/community-scripts/ProxmoxVE/main/ct/adguard.sh)"

Choose Advanced when prompted. Settings used:

SettingValue
Container ID160
RAM512 MB
CPU1 core
Disk2 GB
OSDebian 13
IPv4192.168.0.160/24
UnprivilegedYes

AdGuard idles at ~30–50MB RAM. 512MB is generous headroom. DNS is not CPU-bound — 1 core is plenty even with all LXCs querying it simultaneously (DNS queries are tiny UDP packets, most served from cache after the first lookup).

1.2 — Initial setup wizard

Open http://192.168.0.160:3000 in your browser. Complete the setup wizard — set an admin username and password, leave default ports (DNS on 53, web UI on 3000).

1.3 — Configure upstream DoT servers

Go to Settings → DNS Settings → Upstream DNS Servers and replace the defaults with:

tls://1.1.1.1
tls://1.0.0.1
tls://dns.google
tls://dns.quad9.net

Note: Using IP-based addresses (tls://1.1.1.1) instead of hostnames (tls://cloudflare-dns.com) avoids a bootstrap chicken-and-egg issue where AdGuard can't resolve the DoT hostname before DoT is configured. The IP form works reliably.

Set Bootstrap DNS (used only to resolve DoT hostnames on first start):

1.1.1.1
8.8.8.8

Set Fallback DNS (used if all DoT upstreams fail):

1.1.1.1
8.8.8.8

Under DNS Server Configuration, enable:

  • Parallel requests — queries all upstreams simultaneously, uses the fastest response
  • Cache — repeat queries resolve instantly from local cache (0ms vs 10ms)

Click Test upstreams — all four should return green. Then Apply.

1.4 — Verify resolution from the AdGuard LXC

pct exec 160 -- bash
dig 1337x.to @127.0.0.1

Expected output:

;; ANSWER SECTION:
1337x.to.    173    IN    A    104.21.40.193
1337x.to.    173    IN    A    172.67.188.67
;; Query time: 10 msec

Run it a second time — query time drops to 0ms from cache. Those IPs are Cloudflare CDN addresses — the real site, not your ISP's block page. ✅

1.5 — Point LXC 153 at AdGuard

On the Proxmox host, edit the LXC config:

nano /etc/pve/lxc/153.conf

Change the nameserver line:

- nameserver: 1.1.1.1 8.8.8.8
+ nameserver: 192.168.0.160 1.1.1.1

The second entry is a fallback — if AdGuard is ever down, DNS still resolves via direct Cloudflare. Services never go offline because of this.

How Proxmox handles this: The nameserver: line in the LXC conf is authoritative. Proxmox generates /etc/resolv.conf inside the container from it on every start. Even if something inside the LXC writes to /etc/resolv.conf directly, a reboot restores it from the conf file. The DNS config is effectively pinned at the Proxmox level.

Reboot LXC 153:

pct reboot 153

Verify from inside the LXC:

pct exec 153 -- bash -c "cat /etc/resolv.conf"
# --- BEGIN PVE ---
search local
nameserver 192.168.0.160
nameserver 1.1.1.1
# --- END PVE ---

Then confirm 1337x resolves and is reachable:

pct exec 153 -- bash -c "dig 1337x.to"
pct exec 153 -- bash -c "curl -I https://1337x.to"

The curl should return:

HTTP/2 403
cf-mitigated: challenge
server: cloudflare
cf-ray: a0786cba1e277fab-MAA

HTTP/2 403 with cf-mitigated: challenge is exactly what we want. The site is reachable from LXC 153. The cf-ray ending in MAA (Chennai Cloudflare PoP) confirms traffic is hitting Cloudflare directly — not being intercepted by the ISP. DNS problem is solved. ✅

Now for the Cloudflare challenge layer.


Part 2 — Why FlareSolverr Didn't Work

The obvious tool for solving Cloudflare challenges is FlareSolverr. I installed it in LXC 153 alongside Prowlarr and spent a while debugging why it kept timing out.

The debug logs told the story clearly:

Challenge detected. Title found: Just a moment...
Cloudflare verify checkbox clicked after 1 tabs!
'Verify you are human' button not found on the page.
Waiting for title (attempt N): Just a moment...

FlareSolverr was finding the Cloudflare checkbox and clicking it — correctly — but the page title never changed. Cloudflare's Turnstile was detecting that the click came from an automated browser and silently ignoring it. The challenge was never solved regardless of timeout.

The root cause: FlareSolverr uses undetected-chromedriver to control Chromium, and Cloudflare's current Turnstile implementation scores browser fingerprints deeply enough to identify it as automated. Indian residential IPs also tend to get higher Cloudflare security levels, making challenges harder.

FlareSolverr is effectively dead for modern Turnstile. Time to replace it.


Part 3 — Byparr: The Modern Replacement

Byparr is a drop-in replacement for FlareSolverr — same API, same port (8191), same Prowlarr integration. The difference is under the hood: it uses Camoufox (a modified Firefox) instead of undetected-chromedriver. Camoufox is specifically built to mimic real browser fingerprints at a deeper level, which is why it handles Turnstile where FlareSolverr can't.

It also bundles uBlock Origin, which helps by blocking Cloudflare's bot-detection telemetry scripts during the challenge.

3.1 — Spin up a dedicated Byparr LXC

Byparr gets its own LXC rather than sharing with Prowlarr. Firefox/Camoufox is heavier than Chromium — it needs room to breathe, and keeping it isolated means a Byparr crash doesn't affect the media stack.

The community script handles everything:

bash -c "$(curl -fsSL https://raw.githubusercontent.com/community-scripts/ProxmoxVE/main/ct/byparr.sh)"

Choose Advanced. Settings used:

SettingValue
Container ID161
RAM1024 MB
CPU1 core
Disk4 GB
OSDebian 13
IPv4192.168.0.161/24
UnprivilegedYes

The community script defaults to 2 cores / 2048MB. 1 core / 1024MB is sufficient for typical Prowlarr usage (searches are infrequent, not concurrent). Scale up if you see timeouts.

After creation, enable nesting on the LXC — Camoufox needs proper user namespace support for its internal sandbox:

nano /etc/pve/lxc/161.conf

Add to the features line:

features: nesting=1,keyctl=1

Also point its DNS at AdGuard:

nameserver: 192.168.0.160 1.1.1.1

Reboot LXC 161:

pct reboot 161

3.2 — Verify Byparr is running

pct exec 161 -- systemctl status byparr

Look for these lines in the output — they confirm Camoufox downloaded, the service started, and it's already solving challenges:

INFO:     Done https://1337x.to/cat/Movies/1/ in 9.11s
INFO:     192.168.0.153:57078 - "POST /v1 HTTP/1.1" 200 OK

9 seconds to solve a Turnstile challenge and return 200 OK. Compare this to FlareSolverr timing out at 120 seconds without ever solving it.

3.3 — Expose via Caddy (optional)

If you want the Byparr UI accessible via your Caddy reverse proxy, add to your Caddyfile:

byparr.YOUR_DOMAIN.com {
    tls {
        dns cloudflare {CLOUDFLARE_API_TOKEN}
    }
    reverse_proxy 192.168.0.161:8191
}

Same pattern for AdGuard Home:

adguard.YOUR_DOMAIN.com {
    tls {
        dns cloudflare {CLOUDFLARE_API_TOKEN}
    }
    reverse_proxy 192.168.0.160:80
}

Part 4 — Wire Prowlarr to Byparr

4.1 — Add Byparr as an Indexer Proxy

In Prowlarr → Settings → Indexers → Indexer Proxies → + → select FlareSolverr (Byparr is a drop-in, Prowlarr doesn't need a separate entry type).

FieldValue
NameByparr
Tagscloudflare
Hosthttp://192.168.0.161:8191
Request Timeout60

Click Test — green checkmark. Save.

4.2 — Add 1337x Indexer

Indexers → Add Indexer → search 1337x → select it.

Scroll to the Tags field and add cloudflare. This tag is the critical link — it tells Prowlarr to route requests for this indexer through whichever proxy carries the matching tag. Without it, Prowlarr ignores Byparr entirely for this indexer.

Click Test → ✅. Save.

4.3 — Sync to Sonarr and Radarr

Settings → Apps → Sync App Indexers for both. 1337x will now appear as an available indexer in both apps.


Quick Reference

CheckCommandExpected
AdGuard resolves 1337xdig 1337x.to @192.168.0.160Returns 104.21.x.x
LXC 153 DNScat /etc/resolv.confShows 192.168.0.160
Site reachable from LXCcurl -I https://1337x.toHTTP/2 403 + cf-mitigated
Byparr runningsystemctl status byparractive (running)
Byparr respondingcurl http://192.168.0.161:8191JSON with "FlareSolverr is ready!"
Prowlarr proxySettings → Indexers → TestGreen checkmark

What You End Up With

Two new LXCs, each doing one thing:

  • LXC 160 — AdGuard Home → all DNS queries from LXC 153 go here, forwarded upstream via encrypted DoT. ISP cannot intercept or hijack them.
  • LXC 161 — Byparr → Prowlarr routes Cloudflare-protected indexer requests through here. Camoufox solves Turnstile challenges in ~9 seconds.

1337x works. Prowlarr is happy.

The broader lesson: what looks like one blocking problem is often two different systems doing two different things. DNS hijacking and Cloudflare bot protection are independent layers — and they need independent fixes.