Add native HTTP(S) proxy configuration support (instead of relying on environment variables)

[d4s87]

Hi,

I’m using Altmount in a setup where both search and NZB grabbing must originate from the same public IP address. This is required because some Usenet indexers enforce strict IP consistency between search requests and download/grab operations. In my case, NZBHydra2 performs indexing/search, and Altmount performs the final grab step.

Current limitation
At the moment, the only way to enforce outbound routing through a proxy is by using standard Go environment variables: HTTP_PROXY, HTTPS_PROXY.

While functional, this approach has drawbacks:

• It applies globally to the entire process
• It can unintentionally affect internal HTTP calls
• It is difficult to control in containerized environments (VPN/proxy setups)
• It may introduce unexpected networking side effects

Suggested improvement
It would be very helpful if Altmount provided a native proxy configuration option in the UI or config file, similar to how StremThru handles outbound routing.

Ideally:

• Configurable HTTP proxy (host, port)
• Clear separation between application traffic and internal service traffic
• No reliance on global environment variables

Benefits

• More predictable networking behavior
• Easier deployment in Docker/VPN environments (e.g. Gluetun-based stacks)
• Avoids unintended proxying of internal requests
• Better compatibility with strict indexers requiring consistent IP usage

Summary
This feature would significantly improve usability in advanced self-hosted setups where outbound IP consistency is required across multiple services.

Thanks for considering it

[javi11]

I think you can configure nzbhydra as you can do with prowlar to proxy the grab throught the same server as hidra is, wouldn't that be suficient?

[d4s87]

Not entirely, because in this setup NZBHydra2 is only used for search/index aggregation.

The actual NZB retrieval/grab request is still performed later by Altmount itself, not by Hydra.

Additionally, some indexers enforce the use of NZBHydra2 in REDIRECT mode instead of proxying the grab through Hydra itself. In those cases, Hydra only provides the redirect URL, and the final NZB request is executed directly by Altmount.

That means:

• Hydra search/request traffic may originate from one IP
• while the actual NZB grab performed by Altmount may originate from another IP

Some indexers appear to validate:

• search/request IP
• subsequent NZB grab IP

and reject or block the grab if they differ.

[javi11]

Wouldn't make the proxy the same issue as not using redirect in hydra?

[lostgit]

Duplicate of #496

OP, just use gluetun for Altmount in the meantime, or even better, put your hydra and altmount behind the same IP.

[d4s87]

Not exactly — the issue is specifically related to how some indexers behave when Hydra proxies the NZB content itself versus when the client performs the final request directly.

With Hydra proxying the grab:

• the NZB payload is fetched by Hydra and then relayed
• some indexers appear to dislike or restrict this behavior
• therefore they require Hydra to operate in REDIRECT mode instead

In REDIRECT mode:

• Hydra only returns the final NZB URL
• the actual HTTP request is later performed directly by Altmount

That means Altmount becomes the real client from the indexer’s perspective.

So the problem is not “proxy vs no proxy” in general, but rather ensuring that:

• Hydra search traffic
• and the final Altmount grab request

originate from the same public IP address.

At the moment, the only way to achieve this cleanly is by forcing Altmount outbound traffic through the same VPN/proxy path using HTTP_PROXY / HTTPS_PROXY environment variables.

The feature request is mainly about having a cleaner and more controlled application-level implementation for that routing behavior instead of relying on global Go runtime proxy variables.

[lostgit]

I understand how/what indexers want. I opened theotherp/nzbhydra2#1056 but that doesn't seem to be going, so I changed tack and alter my stack instead of asking/waiting the devs.

[d4s87]

That’s actually very similar to what I ended up doing as well.

Initially I tried to rely only on Hydra-side handling, but due to the redirect/IP consistency requirements from some indexers, I eventually had to adapt the container networking instead.

Right now I’m routing both Hydra and Altmount traffic through the same Gluetun VPN path to guarantee identical egress IPs. The workaround functions correctly, but it currently relies on global HTTP_PROXY / HTTPS_PROXY environment variables inside Altmount.

So the feature request is less about solving the indexer behavior itself, and more about having a cleaner/native way to control outbound routing at the application level instead of depending on runtime-wide Go proxy variables.

Totally understand if this is outside the intended scope though 👍

[javi11]

Ok I will Try to add that http proxy headers like configuration in Ui, will that works?

[d4s87]

Yes, that would probably solve the issue for this use case 👍