qBittorrent 403 Forbidden Through Your VPN, Even With the Right API Key
· Updated 18 September 2026 · SparkBox team
Prowlarr (or Sonarr, or Radarr) reports a 403 Forbidden from an indexer, your API key is definitely correct, and everything worked fine before you added a VPN. The short version: your VPN's IP address is getting blocked before your API key is ever checked.
Rather not untangle container networking by hand? SparkBox sets up your media stack so only the torrent client sits behind the VPN, keeping Prowlarr, Sonarr, and Radarr on a normal connection by default. See the walkthrough →
The 10-second version: Only qBittorrent's actual torrent traffic needs to go through your VPN. If Prowlarr, Sonarr, and Radarr are also routed through it, the indexer sees your VPN server's address instead of your home address and blocks it — that's the 403. Take the three *arr apps off the VPN route and leave only qBittorrent behind it.
Why this happens
When you set up a VPN for privacy on your torrent traffic, it's easy to route the whole stack — Prowlarr, Sonarr, Radarr, and qBittorrent — through the same VPN connection so everything shares one network path. That's convenient to configure, but it means every outbound request from all four apps now leaves from your VPN provider's IP address, not your home internet connection.
Indexers, and especially the anti-bot services many of them sit behind, actively maintain lists of IP ranges that belong to commercial VPN and hosting providers. When a request comes in from one of those ranges, it gets rejected with a 403 Forbidden immediately, at the network or reverse-proxy level. This happens before your request even reaches the part of the indexer that checks your API key — which is exactly why the key being correct doesn't matter here. The 403 isn't about authentication at all; it's about where the connection is coming from.
Confirm it's the VPN, not the key
- In Prowlarr, open the indexer and use its "Test" button. If it fails with a 403 and the same key works from a browser on your home connection (not through the VPN), that confirms the block is IP-based, not key-based.
- Check whether Prowlarr, Sonarr, or Radarr are configured to use the VPN connection at all — in a lot of setups this happens by accident because everything shares one container network or one system-wide VPN client.
- If you can, temporarily disable the VPN routing for just the *arr apps and retest the indexer. If the 403 disappears, you've found it.
Fix: only route qBittorrent through the VPN
Prowlarr, Sonarr, and Radarr are making ordinary metadata and search requests — there's no torrent traffic to protect there, so there's no reason for them to be behind the VPN. qBittorrent is the only app in the stack that actually needs it, because it's the one making peer-to-peer connections that a VPN is meant to shield.
- Separate the network path so qBittorrent's traffic goes through the VPN, while Prowlarr, Sonarr, and Radarr use your normal connection directly.
- If you're running these apps as containers, this usually means only the qBittorrent container is attached to the VPN's network, and the other three stay on the regular network or route out normally.
- Re-run the indexer test in Prowlarr once the *arr apps are back on a direct connection. The 403 should clear because the indexer now sees your home IP address, not a VPN exit node.
- qBittorrent itself still needs to reach Prowlarr/Sonarr/Radarr for management (adding torrents, reporting status) — make sure that internal communication between the apps still works after you split the routing, since it's a different path than the internet-facing traffic.
Gotcha: If qBittorrent and the *arr apps can no longer talk to each other after splitting the routes, check that they can still reach each other's internal addresses or ports — you only want to remove the *arr apps from the VPN's route to the wider internet, not cut off the local communication between the apps.
If you still see 403s after fixing the routing
- Try a different VPN server or region. If it's qBittorrent's own connection to a tracker or an indexer you're still routing through the VPN for a specific reason, the block may be on that particular exit IP rather than the whole provider. Switching servers can clear it, though it's not permanent — indexer blocklists get updated over time.
- Ask the indexer or check its status page. Some indexers are simply hostile to any VPN or datacenter range, no matter which server you pick, and there's no client-side fix for that beyond not using a VPN for that specific request.
- Double-check nothing else is still riding the VPN. It's easy to miss one app still pointed at the VPN's proxy or gateway address after reconfiguring — go back through Prowlarr's and Sonarr's/Radarr's network or proxy settings to be sure.
Frequently asked
Why does my indexer return 403 even though my API key is correct?
Because the block happens before the API key is ever checked. The indexer, or the anti-bot service sitting in front of it, sees a connection coming from an address that belongs to a commercial VPN provider and rejects it outright. Your key never gets evaluated.
Do Prowlarr, Sonarr, and Radarr actually need to use the VPN?
No. Only qBittorrent's torrent traffic needs VPN protection. Prowlarr, Sonarr, and Radarr are just making ordinary web and API requests, so routing them through the VPN gains you nothing and is usually the direct cause of the 403.
Will switching VPN servers fix a qBittorrent 403?
Sometimes, temporarily. If the block is on the specific exit IP rather than the whole provider's range, a different server can work for a while, but it's not a permanent fix since indexer blocklists get updated.
Is this a qBittorrent bug?
No. qBittorrent isn't doing anything wrong here. The 403 originates from the indexer's own anti-bot or anti-VPN filtering, and it shows up in qBittorrent or Prowlarr logs simply because that's where the failed request lands.
Skip the container networking puzzle
SparkBox wires up your media stack so qBittorrent runs behind your VPN while Prowlarr, Sonarr, and Radarr stay on a direct connection — so your indexers see a normal home IP and this class of 403 doesn't come up in the first place.
Questions, or did this not match your box?
Every guide here came from a real problem someone hit. If yours behaves differently, say so — that is how these get corrected, and how the fix gets prioritised.
We answer there rather than in a comment box, because that is where the people who have already solved it are.