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.
![]()
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
| Property | Value |
|---|---|
| Proxmox host | 192.168.0.150 |
| AdGuard Home LXC | 160 → 192.168.0.160 |
| Byparr LXC | 161 → 192.168.0.161 |
| Prowlarr LXC | 153 → 192.168.0.153 |
| Proxmox version | PVE 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:
| Setting | Value |
|---|---|
| Container ID | 160 |
| RAM | 512 MB |
| CPU | 1 core |
| Disk | 2 GB |
| OS | Debian 13 |
| IPv4 | 192.168.0.160/24 |
| Unprivileged | Yes |
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.netNote: 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.8Set Fallback DNS (used if all DoT upstreams fail):
1.1.1.1
8.8.8.8Under 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.1Expected output:
;; ANSWER SECTION:
1337x.to. 173 IN A 104.21.40.193
1337x.to. 173 IN A 172.67.188.67
;; Query time: 10 msecRun 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.confChange the nameserver line:
- nameserver: 1.1.1.1 8.8.8.8
+ nameserver: 192.168.0.160 1.1.1.1The 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.confinside the container from it on every start. Even if something inside the LXC writes to/etc/resolv.confdirectly, a reboot restores it from the conf file. The DNS config is effectively pinned at the Proxmox level.
Reboot LXC 153:
pct reboot 153Verify 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-MAAHTTP/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:
| Setting | Value |
|---|---|
| Container ID | 161 |
| RAM | 1024 MB |
| CPU | 1 core |
| Disk | 4 GB |
| OS | Debian 13 |
| IPv4 | 192.168.0.161/24 |
| Unprivileged | Yes |
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.confAdd to the features line:
features: nesting=1,keyctl=1Also point its DNS at AdGuard:
nameserver: 192.168.0.160 1.1.1.1Reboot LXC 161:
pct reboot 1613.2 — Verify Byparr is running
pct exec 161 -- systemctl status byparrLook 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 OK9 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).
| Field | Value |
|---|---|
| Name | Byparr |
| Tags | cloudflare |
| Host | http://192.168.0.161:8191 |
| Request Timeout | 60 |
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
| Check | Command | Expected |
|---|---|---|
| AdGuard resolves 1337x | dig 1337x.to @192.168.0.160 | Returns 104.21.x.x |
| LXC 153 DNS | cat /etc/resolv.conf | Shows 192.168.0.160 |
| Site reachable from LXC | curl -I https://1337x.to | HTTP/2 403 + cf-mitigated |
| Byparr running | systemctl status byparr | active (running) |
| Byparr responding | curl http://192.168.0.161:8191 | JSON with "FlareSolverr is ready!" |
| Prowlarr proxy | Settings → Indexers → Test | Green 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.