Preserve and Forward X-Forwarded-For Header in Outgoing Requests to *arr

[Patrick010]

In many proxied environments (e.g. with Caddy or Nginx), Jellyseerr correctly receives the client’s public IP via the X-Forwarded-For header from a trusted reverse proxy. This works as expected. Jellyseerr logs and uses the correct client IP.

However, when Jellyseerr forwards that request downstream to Radarr or Sonarr, it performs a new outbound HTTP request without preserving or forwarding the original X-Forwarded-For header. As a result, Radarr/Sonarr only see the IP address of the Jellyseerr container or internal host.

Additionally, Jellyseerr can use Jellyfin credentials for authentication, which means login requests originate from Jellyseerr to Jellyfin. Because Jellyseerr does not forward the original client IP downstream, Jellyfin logs see Jellyseerr’s IP instead of the actual user’s public IP.

This breaks IP attribution across the chain; logs, rate limiting, and audit trails lose the original client context. This is especially relevant in setups where multiple services (e.g. Jellyseerr -> Radarr -> Jellyfin) interact and decisions or logs depend on accurate IP tracing.

Why not just add another proxy?

Yes, technically a reverse proxy could be inserted in front of Radarr and/or Sonarr to re-inject the missing headers, but doing so adds unnecessary complexity. It introduces more containers, more moving parts, and more points of failure, just to simulate a behavior that could and should be handled at the application level.

Jellyseerr already has access to the original request and headers. It is in the perfect position to pass that information downstream without relying on an external proxy to patch the gap.

This isn’t about offloading work to a proxy, it’s about maintaining context as a responsible link in a multi-service chain.

Proposal

Jellyseerr should:

1. When receiving a request from a client or reverse proxy, read and store the X-Forwarded-For header, if present.
2. When making API requests to Radarr, Sonarr, or similar services, include the same X-Forwarded-For header to preserve client identity.
3. Optionally, append its own IP to the chain, in standard proxy style.

Example how the header could be assembled:

// Forward X-Forwarded-For header downstream
  const response = await fetch(`http://radarr.internal${apiPath}`, {
    method: 'POST',
    headers: {
      'Authorization': `Bearer ${radarrApiKey}`,
      'Content-Type': 'application/json',
      'X-Forwarded-For': forwardedForHeader,
    },

Why?

1. Accurate IP logging across the media stack
2. Preserves the original client identity across service boundaries
3. Avoids unnecessary proxies just to inject headers
4. Aligns with common web architecture best practices

Suggested config flag

To keep it optional and safe for all environments, this could be gated behind a config option like:

preserve_forwarded_ip: true

Should this for whatever reason already be possible, then disregard this request.

[0xSysR3ll]

Hello,
I think this can be submitted as a feature request :)

[Patrick010]

I thought I already did that ;) Changed the subject in to a FR.

[0xSysR3ll]

I thought I already did that ;) Changed the subject in to a FR.

I meant, opening it as a GitHub issue
Will be better to keep track of it.

[Patrick010]

...right ;)