Port 5007 (Downloader) hangs indefinitely on Newznab proxy requests (/api?t=*)

[yeathn]

Version: v1.0-beta.12 Docker image: pcjones/mediathekarr:beta (pulled 2026-02-21)

Description

The MediathekArrDownloader on port 5007 accepts TCP connections and logs incoming requests for /api?t=caps and /api?t=search, but never sends an HTTP response back to the caller. The connection hangs until the client times out.

This causes Prowlarr to repeatedly time out when fetching indexer capabilities, eventually marking MediathekArr as "disabled due to recent failures" and returning 429 to Radarr/Sonarr.

Setup

• MediathekArr runs behind gluetun (network_mode: service:gluetun)
• Prowlarr also uses network_mode: service:gluetun (shared network namespace)
• Prowlarr configured with http://<host-ip>:5007 as per documentation

Steps to Reproduce

# From inside Prowlarr container (shares network namespace with MediathekArr):
curl -v --max-time 15 "http://localhost:5007/api?t=caps"

Expected: HTTP 200 with XML caps response Actual: TCP connects, request is sent, connection closes without any HTTP response

Log Evidence

The Downloader receives the request and starts proxying to the Server, but never completes:

[MediathekArrDownloader] info: Program - Incoming Request: GET /api?t=caps
[MediathekArrDownloader] info: HttpClient.Default.LogicalHandler - Start processing HTTP request GET http://localhost:5008/api/?*
[MediathekArrDownloader] info: HttpClient.Default.ClientHandler - Sending HTTP request GET http://localhost:5008/api/?*

No "Finished processing" or response log follows. The request hangs indefinitely.

Additional Findings

Endpoint | Port | Result -- | -- | -- /download/api?mode=... (own endpoint) | 5007 | ✅ responds instantly /api?t=caps (direct) | 5008 | ✅ HTTP 200, correct XML /api?t=caps (via proxy) | 5007 | ❌ no response, timeout /api?t=search&q=test (via proxy) | 5007 | ❌ no response, timeout

Port 5008 (MediathekArrServer) works correctly and returns valid Newznab responses. The Downloader's own /download/api endpoints work fine. Only the proxy to port 5008 for Newznab requests is broken.

Workaround

Configure Prowlarr with http://localhost:5008 instead of port 5007. Since both Prowlarr and MediathekArr share the same network namespace (gluetun), port 5008 is directly accessible without needing to expose it via port mapping.

Suspected Cause

The Downloader's HttpClient proxy appears to receive the response from the Server (port 5008) but fails to forward it back to the caller — possibly a keep-alive / connection termination handling issue in the proxy code.

[Maulwurf16]

This bug is affecting my workflow. However I am not able to create a pull request due to my very limited understanding of C.
I asked Claude about this bug and a possible bugfix. This is the result. @PCJones possibly this helps?

# Bug-Analyse: Issue #78 – Proxy-Requests hängen auf Port 5007

## Betroffene Datei

**[TProxyController.cs](file:///Users/markus/Documents/Coding/from_git/mediathekarr/MediathekArr/Controllers/TProxyController.cs)** — der Reverse-Proxy im Downloader, der Requests von Port 5007 an den Server auf Port 5008 weiterleitet.

## Ursache(n)

Ich habe **zwei zusammenhängende Probleme** in `TProxyController.Proxy()` identifiziert:

### Problem 1: Host-Header wird an den Upstream weitergeleitet

```csharp
// Zeilen 40-43 – ALLE Request-Header werden blind kopiert
foreach (var header in Request.Headers)
{
    requestMessage.Headers.TryAddWithoutValidation(header.Key, [.. header.Value]);
}

Der Code kopiert alle eingehenden Request-Header 1:1 in die Proxy-Anfrage, einschließlich:

Header	Problem
Host	Wird auf den eingehenden Host gesetzt (z.B. localhost:5007), der Upstream erwartet aber localhost:5008
Transfer-Encoding	Kann Konflikte mit der neuen Anfrage erzeugen
Connection	Hop-by-hop Header darf nicht geproxied werden
Content-Length	Kollidiert ggf. mit StreamContent

Important

Der Host-Header ist das Hauptproblem. Kestrel auf Port 5008 könnte die Anfrage ablehnen oder gar nicht routen, weil der Host localhost:5007 nicht zum Binding passt.

Problem 2: HttpClient wird im Konstruktor erstellt (nicht über Factory)

// Zeile 9
private readonly HttpClient _httpClient = httpClientFactory.CreateClient();

Der HttpClient wird einmalig im Konstruktor erstellt, aber TProxyController ist transient (Standard in ASP.NET Core). Das bedeutet:

• Jeder Request erzeugt eine neue HttpClient-Instanz
• Kein Connection-Pooling, kein Socket-Reuse
• Mögliche Socket-Exhaustion unter Last
• Der Client hat keine der in Program.cs konfigurierten Handler (Logging, gzip-Decompression), da er CreateClient() statt CreateClient("MediathekClient") aufruft

Warning

Ohne den konfigurierten AutomaticDecompression-Handler kann es passieren, dass der Server eine gzip-komprimierte Antwort sendet, der HttpClient diese aber nicht dekomprimiert — was dazu führt, dass ReadAsStringAsync() hängt oder Müll zurückgibt.

Vorgeschlagene Lösung

Fix in TProxyController.cs

 [ApiController]
 [Route("api")]
-public class TProxyController(IHttpClientFactory httpClientFactory) : ControllerBase
+public class TProxyController(IHttpClientFactory httpClientFactory, ILogger<TProxyController> logger) : ControllerBase
 {
-    private readonly HttpClient _httpClient = httpClientFactory.CreateClient();
+    private readonly IHttpClientFactory _httpClientFactory = httpClientFactory;
+    private readonly ILogger<TProxyController> _logger = logger;
+
+    // Hop-by-hop Header die NICHT weitergeleitet werden dürfen
+    private static readonly HashSet<string> HopByHopHeaders = new(StringComparer.OrdinalIgnoreCase)
+    {
+        "Connection", "Keep-Alive", "Transfer-Encoding",
+        "TE", "Trailer", "Upgrade", "Host"
+    };
 
     // Route when there is no path
     [HttpGet("")]
@@ -28,7 +35,7 @@
     public async Task<IActionResult> Proxy(string path)
     {
         var queryString = Request.QueryString.Value;
-        var targetUrl = $"http://localhost:5008/api/{path}{queryString}";
+        var targetUrl = $"http://localhost:5008/api/{path.TrimStart('/')}{queryString}";
 
         var requestMessage = new HttpRequestMessage
         {
@@ -38,13 +45,27 @@
         };
 
         foreach (var header in Request.Headers)
         {
-            requestMessage.Headers.TryAddWithoutValidation(header.Key, [.. header.Value]);
+            if (!HopByHopHeaders.Contains(header.Key))
+            {
+                requestMessage.Headers.TryAddWithoutValidation(header.Key, [.. header.Value]);
+            }
+        }
+
+        var httpClient = _httpClientFactory.CreateClient();
+
+        try
+        {
+            var responseMessage = await httpClient.SendAsync(requestMessage, HttpCompletionOption.ResponseHeadersRead);
+            var responseContent = await responseMessage.Content.ReadAsStringAsync();
+
+            return new ContentResult
+            {
+                Content = responseContent,
+                StatusCode = (int)responseMessage.StatusCode,
+                ContentType = responseMessage.Content.Headers.ContentType?.ToString()
+            };
+        }
+        catch (Exception ex)
+        {
+            _logger.LogError(ex, "Proxy request to {TargetUrl} failed", targetUrl);
+            return StatusCode(502, $"Proxy error: {ex.Message}");
         }
-
-        var responseMessage = await _httpClient.SendAsync(requestMessage);
-
-        var responseContent = await responseMessage.Content.ReadAsStringAsync();
-        return new ContentResult
-        {
-            Content = responseContent,
-            StatusCode = (int)responseMessage.StatusCode,
-            ContentType = responseMessage.Content.Headers.ContentType?.ToString()
-        };
     }
 }

Zusammenfassung der Änderungen

#	Was	Warum
1	Hop-by-hop Header filtern (Host, Connection, Transfer-Encoding, …)	Verhindert, dass der falsche Host-Header an den Upstream gesendet wird und Kestrel die Anfrage nicht korrekt routed
2	HttpClient pro Request aus Factory erstellen statt im Konstruktor	Sauberes Lifecycle-Management durch die Factory, vermeidet Socket-Exhaustion
3	HttpCompletionOption.ResponseHeadersRead verwenden	Schnellere Response-Verarbeitung, verhindert Deadlocks bei großen Antworten
4	Try/Catch mit Logging und 502-Antwort	Statt dass der Request endlos hängt, wird bei Fehlern eine klare Fehlermeldung zurückgegeben
5	Path-Trimming (path.TrimStart('/'))	Verhindert doppelte Slashes in der Proxy-URL

Tip

Der Bug-Reporter hat als Workaround bereits empfohlen, Prowlarr direkt auf Port 5008 zu zeigen. Das funktioniert, umgeht aber den Downloader komplett. Der eigentliche Fix sollte in TProxyController erfolgen.