starred/Prowlarr

Fork 0

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

IPv4-only indexers disables IPv6 for all indexers #1055

New issue

Open

opened 2026-02-20 10:06:48 -05:00 by deekerman · 8 comments

deekerman commented

2026-02-20 10:06:48 -05:00

Owner

Originally created by @RomLecat on GitHub (Jun 18, 2024).

Is there an existing issue for this?

I have searched the existing open and closed issues

Current Behavior

Follow-up of #2156.

When an indexer is IPv4-only (in my case, not even bogus IPv6, just no IPv6 at all), it triggers this: github.com/Prowlarr/Prowlarr@9f075c09a2/src/NzbDrone.Common/Http/Dispatchers/ManagedHttpDispatcher.cs (L327-L333)

Which disables IPv6 for all indexers on the container.

As explained on #2156, this is an issue because my FlareSolverr runs on IPv6 and Prowlarr needs to have the same IP address.

Expected Behavior

IPv6 should only be disabled for the indexer that does not support IPv6, not for all indexers.

Also, I think re-evaluate IPv6 connectivity periodically would be better, a single failure in IPv6 results in IPv6 permanently disabled for the lifetime of the application, which seems extreme.

Steps To Reproduce

Add an indexer that only supports IPv4 in a dual-stack (IPv4+IPv6 working environment)
Test connectivity to that indexer
IPv6 is disabled for all indexers.

Environment

- OS: Debian 12
- Prowlarr: latest nightly
- Docker Install: Kubernetes 1.28.10 in dual-stack mode
- Using Reverse Proxy: Yes
- Browser: Brave

What branch are you running?

Nightly

Trace Logs?

Trace Logs have been provided as applicable. Reports may be closed if the required logs are not provided.

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 @RomLecat on GitHub (Jun 18, 2024). ### Is there an existing issue for this? - [X] I have searched the existing open and closed issues ### Current Behavior Follow-up of #2156. When an indexer is IPv4-only (in my case, not even bogus IPv6, just no IPv6 at all), it triggers this: https://github.com/Prowlarr/Prowlarr/blob/9f075c09a2c12cedb7e58c9478a7faf4eac8c664/src/NzbDrone.Common/Http/Dispatchers/ManagedHttpDispatcher.cs#L327-L333 Which disables IPv6 for all indexers on the container. As explained on #2156, this is an issue because my FlareSolverr runs on IPv6 and Prowlarr needs to have the same IP address. ### Expected Behavior IPv6 should only be disabled for the indexer that does not support IPv6, not for all indexers. Also, I think re-evaluate IPv6 connectivity periodically would be better, a single failure in IPv6 results in IPv6 permanently disabled for the lifetime of the application, which seems extreme. ### Steps To Reproduce 1. Add an indexer that only supports IPv4 in a dual-stack (IPv4+IPv6 working environment) 2. Test connectivity to that indexer 3. IPv6 is disabled for all indexers. ### Environment ```markdown - OS: Debian 12 - Prowlarr: latest nightly - Docker Install: Kubernetes 1.28.10 in dual-stack mode - Using Reverse Proxy: Yes - Browser: Brave ``` ### What branch are you running? Nightly ### Trace Logs? 2024-06-18 12:22:30.8|Debug|Cardigann|Downloading Feed https://www.ygg.re/engine/search?category=all&do=search&order=desc&sort=publish_date&name=&page=50 2024-06-18 12:22:30.9|Trace|ConfigService|Using default config value for 'logindexerresponse' defaultValue:'False' 2024-06-18 12:22:30.9|Trace|RateLimitService|Rate Limit triggered, delaying 'www.ygg.re' for 0.947 sec 2024-06-18 12:22:31.8|Trace|IndexerHttpClient|Req: [GET] https://www.ygg.re/engine/search?category=all&do=search&order=desc&sort=publish_date&name=&page=50 2024-06-18 12:22:31.8|Trace|ConfigService|Using default config value for 'proxyenabled' defaultValue:'False' 2024-06-18 12:22:32.5|Trace|IndexerHttpClient|Res: HTTP/2.0 [GET] https://www.ygg.re/engine/search?category=all&do=search&order=desc&sort=publish_date&name=&page=50: 200.OK (142022 bytes) (631 ms) 2024-06-18 12:22:32.5|Debug|FlareSolverr|CF Protection not detected, returning original response 2024-06-18 12:22:32.5|Trace|Cardigann|Cardigann (yggtorrent): Parsing response 2024-06-18 12:22:32.5|Trace|ConfigService|Using default config value for 'logindexerresponse' defaultValue:'False' 2024-06-18 12:22:32.8|Trace|Cardigann|Cardigann (yggtorrent): Got 50 releases [...] 2024-06-18 12:22:37.9|Debug|Cardigann|Downloading Feed https://abn.lol/Torrent?SelectedCats=1&SelectedCats=3&SelectedCats=4&SelectedCats=9&YearOperator=%E2%89%A5&RatingOperator=%E2%89%A5&SortOn=Created&SortOrder=desc 2024-06-18 12:22:37.9|Debug|Prowlarr.Http.Authentication.ApiKeyAuthenticationHandler|AuthenticationScheme: API was successfully authenticated. 2024-06-18 12:22:37.9|Trace|ConfigService|Using default config value for 'logindexerresponse' defaultValue:'False' 2024-06-18 12:22:37.9|Trace|Http|Res: 109 [GET] /api/v1/health: 200.OK (8 ms) 2024-06-18 12:22:37.9|Debug|Api|[GET] /api/v1/health: 200.OK (8 ms) 2024-06-18 12:22:37.9|Trace|IndexerHttpClient|Req: [GET] https://abn.lol/Torrent?SelectedCats=1&SelectedCats=3&SelectedCats=4&SelectedCats=9&YearOperator=%E2%89%A5&RatingOperator=%E2%89%A5&SortOn=Created&SortOrder=desc 2024-06-18 12:22:37.9|Trace|ConfigService|Using default config value for 'proxyenabled' defaultValue:'False' 2024-06-18 12:22:38.0|Info|ManagedHttpDispatcher|IPv4 is available: True, IPv6 will be disabled ### Trace Logs have been provided as applicable. Reports may be closed if the required logs are not provided. - [X] 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

labels

2026-02-20 10:06:48 -05:00

deekerman commented

2026-02-20 10:06:50 -05:00

Author

Owner

@Ttfgggf commented on GitHub (Jan 1, 2025):

Facing the same issue here as well.

@Ttfgggf commented on GitHub (Jan 1, 2025): Facing the same issue here as well.

deekerman commented

2026-02-20 10:06:50 -05:00

Author

Owner

@OdinVex commented on GitHub (Jan 18, 2025):

I don't even know why any of the *arrs disable IPv6 to begin with in an environment that has IPv6 addresses to begin with (I don't mean fe80 locals). Unless the end-user disables a stack it should always be enabled, let the user decide to disable one or the other at their choice. Some systems support 6to4, 4to6, Docker dual-stacked cleaned and this disables access to a number of trackers (private custom) just because one Tracker is IPv4-only (and yet I support both stacks).

Edit: I think it'd be easier to just handle private async ValueTask<Stream> onConnect(SocketsHttpConnectionContext context, CancellationToken cancellationToken) by trying IPv6 and falling back to IPv4, each time. For IPv4-only users it should fallback without any issue (and maybe a simple config option to disable IPv6 or IPv4 *arr-wide, just like any other dual-stack capable software.

@OdinVex commented on GitHub (Jan 18, 2025): I don't even know why any of the *arrs disable IPv6 to begin with in an environment that has IPv6 addresses to begin with (I don't mean fe80 locals). Unless the end-user disables a stack it should always be enabled, let the user decide to disable one or the other at their choice. Some systems support 6to4, 4to6, Docker dual-stacked cleaned and this disables access to a number of trackers (private custom) just because *one* Tracker is IPv4-only (and yet I support both stacks). Edit: I think it'd be easier to just handle `private async ValueTask<Stream> onConnect(SocketsHttpConnectionContext context, CancellationToken cancellationToken)` by trying IPv6 and falling back to IPv4, each time. For IPv4-only users it should fallback without any issue (and maybe a simple config option to disable IPv6 or IPv4 *arr-wide, just like any other dual-stack capable software.

deekerman commented

2026-02-20 10:06:50 -05:00

Author

Owner

@RomLecat commented on GitHub (Jan 18, 2025):

"Happy eyeballs" have been there for quite a while now, including in major browsers (which is the feature of fallbacking to IPv4 very quicky in case of buggy/not working IPv6. It was quite common a few years ago when adoption started broadly). It makes less sense now that IPv6 issues are mostly resolved in most environments.

The specific implementation of the *arr is quite bad tho, mostly because of the fact that fallback to IPv4 happens only once and IPv6 is never retried, and that a single tracker without IPv6 makes the *arr assume IPv6 is not working entirely on the client, which is nonsense.

@RomLecat commented on GitHub (Jan 18, 2025): "Happy eyeballs" have been there for quite a while now, including in major browsers (which is the feature of fallbacking to IPv4 very quicky in case of buggy/not working IPv6. It was quite common a few years ago when adoption started broadly). It makes less sense now that IPv6 issues are *mostly* resolved in most environments. The specific implementation of the *arr is quite bad tho, mostly because of the fact that fallback to IPv4 happens only once and IPv6 is never retried, and that a single tracker without IPv6 makes the *arr assume IPv6 is not working entirely on the client, which is nonsense.

deekerman commented

2026-02-20 10:06:50 -05:00

Author

Owner

@OdinVex commented on GitHub (Jan 18, 2025):

"Happy eyeballs" have been there for quite a while now, including in major browsers (which is the feature of fallbacking to IPv4 very quicky in case of buggy/not working IPv6. It was quite common a few years ago when adoption started broadly). It makes less sense now that IPv6 issues are mostly resolved in most environments.

The specific implementation of the *arr is quite bad tho, mostly because of the fact that fallback to IPv4 happens only once and IPv6 is never retried, and that non-IPv6 to a single tracker assumes IPv6 is not working entirely on the client, which is nonsense.

I don't feel Happy Eyeballs should even exist. If one method stack fails software should try the other (excluding scenarios where users disable a stack). Edit: I'd like to note how useless I find HE by stating I've disabled quick-fallback types such as in Firefox via network.http.fast-fallback-to-IPv4. I don't like fast-fallbacking or attempts to reach one or the other "fastest". IPv6, then IPv4 if IPv6 is down, I'm happy with that.

@OdinVex commented on GitHub (Jan 18, 2025): > "Happy eyeballs" have been there for quite a while now, including in major browsers (which is the feature of fallbacking to IPv4 very quicky in case of buggy/not working IPv6. It was quite common a few years ago when adoption started broadly). It makes less sense now that IPv6 issues are _mostly_ resolved in most environments. > > The specific implementation of the *arr is quite bad tho, mostly because of the fact that fallback to IPv4 happens only once and IPv6 is never retried, and that non-IPv6 to a single tracker assumes IPv6 is not working entirely on the client, which is nonsense. I don't feel Happy Eyeballs should even exist. If one method stack fails software should try the other (excluding scenarios where users disable a stack). Edit: I'd like to note how useless I find HE by stating I've disabled quick-fallback types such as in Firefox via `network.http.fast-fallback-to-IPv4`. I don't like fast-fallbacking or attempts to reach one or the other "fastest". IPv6, then IPv4 if IPv6 is down, I'm happy with that.

deekerman commented

2026-02-20 10:06:50 -05:00

Author

Owner

@bakerboy448 commented on GitHub (Jan 18, 2025):

Given that most/many users have ipv6 enabled locally and not for WAN and thus ipv6 connectivity will stall and eventually fail - trying ipv6 every time is not a reasonable approach

@bakerboy448 commented on GitHub (Jan 18, 2025): Given that most/many users have ipv6 enabled locally and not for WAN and thus ipv6 connectivity will stall and eventually fail - trying ipv6 every time is not a reasonable approach

deekerman commented

2026-02-20 10:06:50 -05:00

Author

Owner

@RomLecat commented on GitHub (Jan 18, 2025):

What do you mean by "Ipv6 enabled locally and not for WAN" ?
If you're refering to users having only a link-locale (fe80:: IPv6), it does not have a default route and therefore is using IPv4 by default.

I don't see where "most/many" users having a GUA address does not have proper IPv6 WAN. Either the ISP provides a GUA prefix through SLAAC/DHCPv6 and then it is working, or the ISP does not provide it at all.
"Most/many" users run the *arr suite in Docker, which by default is IPv4-only.

@RomLecat commented on GitHub (Jan 18, 2025): What do you mean by "Ipv6 enabled locally and not for WAN" ? If you're refering to users having only a link-locale (fe80:: IPv6), it does not have a default route and therefore is using IPv4 by default. I don't see where "most/many" users having a GUA address does not have proper IPv6 WAN. Either the ISP provides a GUA prefix through SLAAC/DHCPv6 and then it is working, or the ISP does not provide it at all. "Most/many" users run the *arr suite in Docker, which by default is IPv4-only.

deekerman commented

2026-02-20 10:06:50 -05:00

Author

Owner

@OdinVex commented on GitHub (Jan 18, 2025):

Given that most/many users have ipv6 enabled locally and not for WAN and thus ipv6 connectivity will stall and eventually fail - trying ipv6 every time is not a reasonable approach

If someone doesn't know how IP networking works they shouldn't be hosting a server as they're an unfortunate threat to themselves and others. An option to disable IPv6 and/or IPv4 (some systems/networks have dropped IPv4 entirely, those this is mostly an enterprise situation at the moment) would be best. It'd fix everything. "Got timeouts? Check your IPv6 or disable it if your ISP/networking equipment/OS is still in the stone ages." I'd take "IPv4 default on, IPv6 default off" for containerized images, so long as IPv6 could be enabled and left on, preferred. I feel it's quite reasonable. Again I'd like to note some trackers are IPv6 only, especially custom trackers set up privately for private groups.

@OdinVex commented on GitHub (Jan 18, 2025): > Given that most/many users have ipv6 enabled locally and not for WAN and thus ipv6 connectivity will stall and eventually fail - trying ipv6 every time is not a reasonable approach If someone doesn't know how IP networking works they shouldn't be hosting a server as they're an unfortunate threat to themselves and others. An option to disable IPv6 and/or IPv4 (some systems/networks have dropped IPv4 entirely, those this is mostly an enterprise situation at the moment) would be best. It'd fix everything. "Got timeouts? Check your IPv6 or disable it if your ISP/networking equipment/OS is still in the stone ages." I'd take "IPv4 default on, IPv6 default off" for containerized images, so long as IPv6 could be enabled and left on, preferred. I feel it's quite reasonable. Again I'd like to note some trackers are IPv6 only, especially custom trackers set up privately for private groups.

deekerman commented

2026-02-20 10:06:50 -05:00

Author

Owner

@ldexterldesign commented on GitHub (Jun 28, 2025):

👋

Hope you're well

Thanks for software 😗

I'm currently having to use mobile data instead of a full-fledged ISP, while I finish moving house, and I'm seeing error messages when adding indexers while I'm not using my VPN - my VPN supports ipv6 but my mobile data (ISP) doesn't (ie ipv4-only) so this explains things

It's no big deal to run my VPN 24/7 but without paying for the privilege of a VPN is this resolvable on the prowlarr side?: if yes then I suggest its looked into

progressive enhance &/ graceful degrade 'n' all that 🤷

Hope to hear back

🤞🙏

PS if i'm straying into a new issue here then feel free to say and I'll delete and recreate

@ldexterldesign commented on GitHub (Jun 28, 2025): 👋 Hope you're well Thanks for software 😗 I'm currently having to use mobile data instead of a full-fledged ISP, while I finish moving house, and I'm seeing error messages when adding indexers while I'm not using my VPN - my VPN supports ipv6 but my mobile data (ISP) doesn't (ie ipv4-only) so this explains things It's no big deal to run my VPN 24/7 but without paying for the privilege of a VPN is this resolvable on the prowlarr side?: if yes then I suggest its looked into [progressive enhance] &/ [graceful degrade] 'n' all that 🤷 Hope to hear back 🤞🙏 PS if i'm straying into a new issue here then feel free to say and I'll delete and recreate [graceful degrade]: https://en.wikipedia.org/wiki/Fault_tolerance [progressive enhance]: https://en.wikipedia.org/wiki/Progressive_enhancement