Reverse Proxy Benchmark 2025: NPM vs. NPM+ (HTTP/3) vs. Zoraxy

Warum ein Reverse Proxy? Die Grundlagen einfach erklärt

In der Welt der Homeserver und Self-Hosting-Dienste jonglieren wir oft mit vielen verschiedenen Anwendungen, die alle über unterschiedliche Ports erreichbar sind. Sich 192.168.1.10:8080, 192.168.1.10:9000 und 192.168.1.10:3000 merken zu müssen, ist umständlich und unsicher.

Hier kommt ein Reverse Proxy ins Spiel. Er agiert als zentraler Türsteher für alle eingehenden Anfragen. Anstatt sich Dutzende Ports zu merken, rufen wir einfach eine Subdomain wie service.deine-domain.de auf. Der Reverse Proxy nimmt die Anfrage entgegen, kümmert sich um die SSL/TLS-Verschlüsselung (das https in der Adresszeile) und leitet sie intern an den richtigen Dienst und Port weiter.

In einem früheren Video habe ich bereits verschiedene Reverse Proxies verglichen. Heute gehen wir einen Schritt weiter und schauen uns drei moderne, visuell orientierte Kandidaten in einem Performance-Benchmark an:

1. Nginx Proxy Manager (NPM): Der beliebte Klassiker als unsere stabile Baseline.
2. NPM+: Ein Fork von NPM, bei dem wir gezielt HTTP/3 aktivieren.
3. Zoraxy: Ein neuer, aber extrem leistungsfähiger und moderner Herausforderer.

Alle drei werden wir in Docker installieren und ihre Leistung mit den Tools wrk und k6 auf die Probe stellen.

Glossar: Wichtige Begriffe und Technologien

Die Vorbereitung: Unser Test-Setup

Für einen fairen Vergleich benötigen wir eine konsistente Testumgebung.

1. Server-Werkzeuge installieren

Ich miete mir vier Server bei Hetzner. Darauf installiere ich Docker:

# Add Docker's official GPG key:
sudo apt-get update
sudo apt-get install ca-certificates curl
sudo install -m 0755 -d /etc/apt/keyrings
sudo curl -fsSL https://download.docker.com/linux/ubuntu/gpg -o /etc/apt/keyrings/docker.asc
sudo chmod a+r /etc/apt/keyrings/docker.asc

# Add the repository to Apt sources:
echo \
  "deb [arch=$(dpkg --print-architecture) signed-by=/etc/apt/keyrings/docker.asc] https://download.docker.com/linux/ubuntu \
  $(. /etc/os-release && echo "${UBUNTU_CODENAME:-$VERSION_CODENAME}") stable" | \
  sudo tee /etc/apt/sources.list.d/docker.list > /dev/null
sudo apt-get update

Auf dem vierten Server installiere ich wrk und k6:

sudo apt install wrk -y
sudo gpg -k
sudo gpg --no-default-keyring --keyring /usr/share/keyrings/k6-archive-keyring.gpg --keyserver hkp://keyserver.ubuntu.com:80 --recv-keys C5AD17C747E3415A3642D57D77C6C491D6AC1D69
echo "deb [signed-by=/usr/share/keyrings/k6-archive-keyring.gpg] https://dl.k6.io/deb stable main" | sudo tee /etc/apt/sources.list.d/k6.list
sudo apt-get update
sudo apt-get install k6

Alternativ lässt sich das auch mit einer Cloud-Init-Config bewerkstelligen.

2. Ein gemeinsames Netzwerk für alle Container

Damit unsere Proxies mit dem Backend-Dienst kommunizieren können, erstellen wir auf den drei Servern jeweils ein gemeinsames Docker-Netzwerk.

sudo docker network create proxy

3. Der Backend-Dienst: Homepage

Als Zieldienst, den unsere Proxies ansteuern, verwenden wir das Dashboard gethomepage/homepage. Es ist leichtgewichtig und perfekt für unseren Test.

homepage/docker-compose.yml:

services:
  homepage:
    image: ghcr.io/gethomepage/homepage:latest
    container_name: homepage
    environment:
      - HOMEPAGE_ALLOWED_HOSTS=domain.de # HIER ANPASSEN
      - PUID=1000
      - PGID=1000
    volumes:
      - ./config:/app/config
    networks:
      - proxy
    restart: unless-stopped
    deploy:
      resources:
        limits:
          cpus: '1.0'
          memory: 1G

networks:
  proxy:
    external: true

Wir starten diesen Container mit sudo docker compose up -d. Er hat keinen öffentlichen Port – der Zugriff erfolgt ausschließlich über unsere Reverse Proxies.

Die Kandidaten im Detail

1. Nginx Proxy Manager (NPM)

Der Klassiker. Bekannt für seine extrem einfache, webbasierte Konfiguration.

npm/docker-compose.yml:

services:
  app:
    image: 'jc21/nginx-proxy-manager:2.12.6'
    container_name: npm
    restart: unless-stopped
    ports:
      - '80:80'
      - '443:443'
      - '81:81'
    volumes:
      - ./data:/data
      - ./letsencrypt:/etc/letsencrypt
    networks:
      - proxy
    deploy:
      resources:
        limits:
          cpus: '1.0'
          memory: 1G
        
networks:
  proxy:
    external: true
  

Wir erstellen die Ordner data und letsencrypt.

Nach dem Start via docker compose up -d loggen wir uns auf http://<SERVER_IP>:81 ein und erstellen einen Proxy Host, der auf den Dienst homepage und Port 3000 zeigt. Das SSL-Zertifikat wird automatisch über Let’s Encrypt bezogen.

2. NPM+ (mit HTTP/3)

Die modernisierte Version von NPM. Der Clou hier: Wir aktivieren HTTP/3.

npm-plus/docker-compose.yml:

services:
  app:
    image: 'ghcr.io/zoeyvid/npmplus:latest'
    container_name: npm-plus
    restart: unless-stopped
    ports:
      - '80:80/tcp'
      - '443:443/tcp'
      - '443:443/udp'
      - '81:81/tcp'
    environment:
      - 'PUID=1000'
      - 'PGID=1000'
      - 'TZ=Europe/Berlin'
    volumes:
      - ./data:/data
    networks:
      - proxy
    deploy:
      resources:
        limits:
          cpus: '1.0'
          memory: 1G
        
networks:
  proxy:
    external: true

Die entscheidenden Punkte sind die Umgebungsvariable NPM_ENABLE_HTTP3=true und die Freigabe von Port 443 für UDP. Die Konfiguration in der UI ist identisch zu NPM. Das Passwort für das Login befindet sich in den Logs: sudo docker compose logs.

3. Zoraxy

Ein moderner, in Go geschriebener Herausforderer mit Fokus auf Performance und einer sehr aufgeräumten UI. HTTP/3 ist hier standardmäßig aktiv.

zoraxy/docker-compose.yml:

services:
  zoraxy:
    image: tobiaskoch/zoraxy
    container_name: zoraxy
    restart: unless-stopped
    ports:
      - "80:80"
      - "443:443"
      - "443:443/udp" # HTTP/3 ist Standard
      - "8000:8000"
    volumes:
      - ./config/:/opt/zoraxy/config/
      - ./plugin/:/opt/zoraxy/plugin/
      - /etc/localtime:/etc/localtime:ro
    networks:
      - proxy
    deploy:
      resources:
        limits:
          cpus: '1.0'
          memory: 1G
        
networks:
  proxy:
    external: true

Hier erstellen wir die Ordner config und plugin. Nach dem Start erreichen wir die Admin-UI unter http://<SERVER_IP>:8000. Die Einrichtung eines Proxy Hosts ist auch hier mit wenigen Klicks erledigt.

Der Benchmark: Die Ergebnisse

Ich habe zwei Tests vom vierten Server durchgeführt:

1. wrk: Ein roher Stresstest mit 100 gleichzeitigen Verbindungen über 1 Minute, um den maximalen Durchsatz zu messen. (Version 4.1.0)
2. k6: Ein dynamisches Szenario, das die Last langsam aufbaut, hält und Lastspitzen simuliert, um realistisches Verhalten zu testen. (Version 1.1.0)

wrk-Ergebnisse: Rohe Gewalt

wrk -t4 -c100 -d60s --latency domain.de

Die wrk-Ergebnisse sind eindeutig: Zoraxy ist in puncto Geschwindigkeit in einer eigenen Liga. Er verarbeitet 50% mehr Anfragen als der Nginx Proxy Manager bei einem Bruchteil der Latenz. ABER: Unter diesem extremen Dauerfeuer begann Zoraxy, Anfragen abzuweisen (756 Timeouts). NPM und NPM+ blieben absolut stabil.

k6-Ergebnisse: Realistisches Szenario

import http from 'k6/http';
import { check, sleep } from 'k6';

export const options = {
  stages: [
    { duration: '30s', target: 50 },    // Phase 1: Ramp-up -> Langsames Hochfahren auf 50 virtuelle Benutzer über 30 Sekunden.
    { duration: '1m', target: 50 },    // Phase 2: Soak -> Last von 50 Benutzern für 1 Minute halten. Hier messen wir die stabile Leistung.
    { duration: '30s', target: 200 },   // Phase 3: Stress -> Schneller Anstieg auf 200 Benutzer, um die Belastungsgrenze zu testen.
    { duration: '1m', target: 200 },   // Phase 4: Soak -> Stresslast von 200 Benutzern für 1 Minute halten.
    { duration: '30s', target: 0 },     // Phase 5: Ramp-down -> Langsames Herunterfahren auf 0 Benutzer.
  ],

  thresholds: {
    'http_req_duration': ['p(95)<800'],
    'http_req_failed': ['rate<0.01'],
    'checks': ['rate>0.99'],
  },
};

export default function () {
  const targetUrl = __ENV.TARGET_URL || 'https://test.k6.io';

  const res = http.get(targetUrl);

  check(res, {
    'status was 200': (r) => r.status == 200,
  });

  sleep(1);
}
export function handleSummary(data) {
  const summaryPath = __ENV.SUMMARY_PATH || './summary.json';

  const jsonData = JSON.stringify(data, null, 2);
  
  return {
    [summaryPath]: jsonData,
    'stdout': jsonData,
  };
}

Im dynamischen k6-Test zeichnet sich ein anderes Bild. Hier sind alle drei Kandidaten absolut stabil und liefern fehlerfreie Ergebnisse. Zoraxy ist auch hier der schnellste, dicht gefolgt vom klassischen NPM. NPM+ zeigt hier einen leichten Performance-Overhead, vermutlich durch die aktivierte HTTP/3-Verarbeitung für die HTTP/1.1-Anfragen des Test-Tools.

Gesamtfazit und Empfehlung

Welchen Reverse Proxy solltest du also wählen? Es kommt auf deine Prioritäten an.

• Für Einsteiger und Stabilitäts-Fans: Nginx Proxy Manager
  Er ist der Fels in der Brandung. Kinderleicht zu bedienen und absolut zuverlässig in jedem Szenario. Die perfekte, sorgenfreie Wahl.

• Für den modernen Allrounder: NPM+
  Die ideale Weiterentwicklung. Man erhält eine vertraute und moderne Features wie HTTP/3, die sich mit einer einzigen Zeile aktivieren lassen. Der beste Kompromiss aus Stabilität, Features und einfacher Bedienung.

• Für Performance-Jäger: Zoraxy
  Der k6-Test hat gezeigt, dass Zoraxy in realistischen Szenarien auch absolut stabil ist. Das Potenzial von Zoraxy ist unbestreitbar und macht ihn zu einem Kandidaten, den man unbedingt im Auge behalten sollte.