Traefik vs Caddy vs Nginx: Docker Reverse Proxy im Vergleich

11 Min. Lesezeit·Matthieu·docker-composelets-encryptreverse-proxynginxcaddytraefikdocker|

Drei funktionierende Docker-Compose-Stacks für Traefik, Caddy und Nginx als Reverse Proxy auf einem VPS. Gleiches Backend, echte Benchmarks und eine Entscheidungshilfe für die richtige Wahl.

Sie haben Docker-Container auf einem VPS laufen. Sie brauchen HTTPS, Routing nach Domainname und einen einzigen Einstiegspunkt. Traefik, Caddy und Nginx lösen dieses Problem. Sie lösen es unterschiedlich.

Dieser Artikel liefert Ihnen drei funktionierende Docker-Compose-Stacks, die dasselbe Backend hinter jedem Proxy deployen. Kopieren Sie den, der zu Ihrer Situation passt. Die Vergleichstabelle und die Entscheidungshilfe am Ende helfen bei der Wahl.

Alle Beispiele verwenden ein dediziertes Proxy-Netzwerk, HTTP-zu-HTTPS-Weiterleitung und produktionsreife Standardwerte. Die Stacks sind für Ubuntu 24.04 auf einem Virtua Cloud VPS ausgelegt.

Was macht ein Reverse Proxy für Docker-Container auf einem VPS?

Ein Reverse Proxy sitzt zwischen dem Internet und Ihren Docker-Containern. Er terminiert TLS (HTTPS), leitet Anfragen anhand des Hostnamens an den richtigen Container weiter und stellt ein einziges Port-Paar (80/443) bereit, statt eines Ports pro Dienst. Ihre Container kümmern sich nie um Zertifikate und binden sich nie direkt an öffentliche Ports.

Ohne Reverse Proxy bräuchte jeder Container seinen eigenen öffentlichen Port. Besucher würden example.com:3000 für einen Dienst und example.com:8080 für einen anderen aufrufen. Ein Reverse Proxy ermöglicht stattdessen app.example.com und api.example.com auf Standardports.

Alle drei Stacks unten setzen voraus:

Jedes Beispiel deployt dasselbe Backend: das traefik/whoami-Image, das HTTP-Header und Container-Informationen zurückgibt. Ersetzen Sie es später durch Ihre echte Anwendung.

Wie richtet man Traefik als Docker Reverse Proxy mit automatischem HTTPS ein?

Traefik erkennt Container automatisch durch das Lesen von Docker-Labels. Sie fügen Routing-Regeln als Labels an jedem Service hinzu. Wenn ein Container startet, erkennt Traefik ihn, fordert ein Let's-Encrypt-Zertifikat an und beginnt, Traffic zu routen. Kein Neuladen der Konfiguration nötig.

Erstellen Sie das Projektverzeichnis:

mkdir -p ~/traefik-proxy && cd ~/traefik-proxy

Erstellen Sie das Docker-Netzwerk, das alle proxied Services gemeinsam nutzen:

docker network create proxy

Erstellen Sie docker-compose.yml:

services:
  traefik:
    image: traefik:v3.6
    container_name: traefik
    restart: unless-stopped
    command:
      - "--providers.docker=true"
      - "--providers.docker.exposedbydefault=false"
      - "--providers.docker.network=proxy"
      - "--entrypoints.web.address=:80"
      - "--entrypoints.websecure.address=:443"
      - "--entrypoints.web.http.redirections.entrypoint.to=websecure"
      - "--entrypoints.web.http.redirections.entrypoint.scheme=https"
      - "--certificatesresolvers.letsencrypt.acme.email=you@example.com"
      - "--certificatesresolvers.letsencrypt.acme.storage=/acme.json"
      - "--certificatesresolvers.letsencrypt.acme.tlschallenge=true"
      - "--log.level=WARN"
    ports:
      - "80:80"
      - "443:443"
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock:ro
      - ./acme.json:/acme.json
    networks:
      - proxy
    security_opt:
      - no-new-privileges:true

  whoami:
    image: traefik/whoami
    container_name: whoami
    restart: unless-stopped
    labels:
      - "traefik.enable=true"
      - "traefik.http.routers.whoami.rule=Host(`app.example.com`)"
      - "traefik.http.routers.whoami.entrypoints=websecure"
      - "traefik.http.routers.whoami.tls.certresolver=letsencrypt"
    networks:
      - proxy

networks:
  proxy:
    external: true

Erstellen Sie vor dem Start die Zertifikatsspeicherdatei mit eingeschränkten Berechtigungen:

touch acme.json && chmod 600 acme.json

Traefik weigert sich zu starten, wenn acme.json zu offene Berechtigungen hat. 600 stellt sicher, dass nur der Eigentümer die darin gespeicherten privaten Schlüssel lesen kann.

Starten Sie den Stack:

docker compose up -d

Prüfen Sie, ob beide Container laufen:

docker compose ps

Sowohl traefik als auch whoami sollten den Status Up zeigen. Testen Sie jetzt von Ihrem lokalen Rechner (nicht vom Server):

curl https://app.example.com

Die Antwort enthält die whoami-Ausgabe mit den Request-Headern. Der X-Forwarded-For-Header in der Antwort zeigt, dass Traefik den Traffic weiterleitet und TLS terminiert.

Was die Labels bewirken:

  • traefik.enable=true aktiviert diesen Container (da exposedbydefault=false gesetzt ist)
  • traefik.http.routers.whoami.rule=Host(...) filtert Anfragen nach Hostname
  • traefik.http.routers.whoami.tls.certresolver=letsencrypt weist Traefik an, ein Zertifikat für diese Domain zu besorgen

Um einen weiteren Service hinzuzufügen, fügen Sie ihn in einer beliebigen Compose-Datei im selben proxy-Netzwerk mit den passenden Labels hinzu. Traefik erkennt ihn automatisch.

Ist es sicher, den Docker-Socket in Traefik einzubinden?

Das Einbinden von /var/run/docker.sock gibt Traefik vollen Zugriff auf die Docker-API. Wenn ein Angreifer Traefik kompromittiert, kann er Container erstellen, Umgebungsvariablen (einschließlich Secrets) lesen und auf dem Host zu Root eskalieren. Das :ro-Flag verhindert nur Schreibzugriffe auf Dateisystemebene. Es schränkt Docker-API-Aufrufe nicht ein.

Für Produktionsumgebungen verwenden Sie einen Docker-Socket-Proxy. Dieser sitzt zwischen Traefik und dem Docker-Daemon und filtert API-Aufrufe, um nur Leseoperationen auf Container-Metadaten zuzulassen.

Fügen Sie dies zu Ihrer docker-compose.yml hinzu:

services:
  socket-proxy:
    image: tecnativa/docker-socket-proxy:0.4
    container_name: socket-proxy
    restart: unless-stopped
    environment:
      CONTAINERS: 1
      NETWORKS: 1
      SERVICES: 0
      TASKS: 0
      POST: 0
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock:ro
    networks:
      - socket-proxy
    security_opt:
      - no-new-privileges:true

  traefik:
    image: traefik:v3.6
    container_name: traefik
    restart: unless-stopped
    depends_on:
      - socket-proxy
    command:
      - "--providers.docker.endpoint=tcp://socket-proxy:2375"
      - "--providers.docker.exposedbydefault=false"
      - "--providers.docker.network=proxy"
      - "--entrypoints.web.address=:80"
      - "--entrypoints.websecure.address=:443"
      - "--entrypoints.web.http.redirections.entrypoint.to=websecure"
      - "--entrypoints.web.http.redirections.entrypoint.scheme=https"
      - "--certificatesresolvers.letsencrypt.acme.email=you@example.com"
      - "--certificatesresolvers.letsencrypt.acme.storage=/acme.json"
      - "--certificatesresolvers.letsencrypt.acme.tlschallenge=true"
      - "--log.level=WARN"
    ports:
      - "80:80"
      - "443:443"
    volumes:
      - ./acme.json:/acme.json
    networks:
      - proxy
      - socket-proxy
    security_opt:
      - no-new-privileges:true

networks:
  proxy:
    external: true
  socket-proxy:
    driver: bridge
    internal: true

Traefik bindet den Docker-Socket nicht mehr direkt ein. Das socket-proxy-Netzwerk ist internal: true, was bedeutet, dass es keinen ausgehenden Internetzugang hat. Der Socket-Proxy erlaubt nur GET-Anfragen an die Endpoints für Container und Netzwerke.

Wie richtet man Caddy als Docker Reverse Proxy mit automatischem HTTPS ein?

Caddy übernimmt HTTPS automatisch, ohne weitere Konfiguration außer dem Domainnamen. Richten Sie eine Domain auf Ihren Server, tragen Sie sie im Caddyfile ein, und Caddy holt und erneuert Zertifikate von Let's Encrypt. Keine Resolver-Konfiguration, keine ACME-Einstellungen. Das ist der kürzeste Weg zu HTTPS für einen Docker Reverse Proxy.

Erstellen Sie das Projektverzeichnis:

mkdir -p ~/caddy-proxy && cd ~/caddy-proxy

Erstellen Sie das gemeinsame Proxy-Netzwerk (überspringen, falls bereits für Traefik erstellt):

docker network create proxy

Erstellen Sie das Caddyfile:

app.example.com {
	reverse_proxy whoami:80
	encode gzip
	header {
		Strict-Transport-Security "max-age=31536000; includeSubDomains; preload"
		X-Content-Type-Options "nosniff"
		X-Frame-Options "DENY"
		Referrer-Policy "strict-origin-when-cross-origin"
	}
}

Das ist die gesamte Proxy-Konfiguration. Caddy liest den Domainnamen, fordert ein Zertifikat an und leitet an den whoami-Container auf Port 80 weiter. Kein Zertifikatsresolver, keine ACME-E-Mail (Caddy verwendet die Standardadresse Ihrer Maschine, oder Sie setzen sie global), keine Speicherpfade zu verwalten.

Erstellen Sie docker-compose.yml:

services:
  caddy:
    image: caddy:2.11
    container_name: caddy
    restart: unless-stopped
    ports:
      - "80:80"
      - "443:443"
      - "443:443/udp"
    volumes:
      - ./Caddyfile:/etc/caddy/Caddyfile:ro
      - caddy_data:/data
      - caddy_config:/config
    networks:
      - proxy
    cap_drop:
      - ALL
    cap_add:
      - NET_BIND_SERVICE

  whoami:
    image: traefik/whoami
    container_name: whoami
    restart: unless-stopped
    networks:
      - proxy

networks:
  proxy:
    external: true

volumes:
  caddy_data:
  caddy_config:

Der Port 443:443/udp aktiviert HTTP/3 (QUIC), das Caddy von Haus aus unterstützt. cap_drop: ALL mit cap_add: NET_BIND_SERVICE entfernt alle Linux-Capabilities außer der zum Binden an Ports unter 1024.

Starten Sie den Stack:

docker compose up -d

Prüfen Sie den Container-Status:

docker compose ps

Beide Container sollten Up anzeigen. Testen Sie von Ihrem lokalen Rechner mit ausführlicher Ausgabe:

curl -v https://app.example.com

Suchen Sie nach HTTP/2 200 in der Ausgabe. Sie sollten auch die Sicherheits-Header aus dem Caddyfile sehen (Strict-Transport-Security, X-Content-Type-Options usw.).

Um einen weiteren Service hinzuzufügen, fügen Sie einen neuen Block im Caddyfile mit Domain und reverse_proxy-Direktive hinzu und laden neu:

docker compose exec caddy caddy reload --config /etc/caddy/Caddyfile

Kein Container-Neustart nötig. Caddy braucht den Docker-Socket nicht. Es erkennt Container nicht automatisch. Sie verwalten das Routing im Caddyfile.

Wie richtet man Nginx als Docker Reverse Proxy mit Let's Encrypt ein?

Nginx gibt Ihnen volle Kontrolle über jede Proxy-Direktive, jeden Header, jede Buffergröße und Cache-Regel. Der Kompromiss ist manuelle Konfiguration. Nginx besorgt keine TLS-Zertifikate eigenständig. Sie kombinieren es mit Certbot, der ACME-Challenges und die Zertifikatserneuerung übernimmt.

Erstellen Sie das Projektverzeichnis:

mkdir -p ~/nginx-proxy && cd ~/nginx-proxy

Erstellen Sie das gemeinsame Proxy-Netzwerk:

docker network create proxy

Erstellen Sie die Nginx-Konfiguration unter nginx/conf.d/app.conf:

mkdir -p nginx/conf.d

server {
    listen 80;
    server_name app.example.com;

    location /.well-known/acme-challenge/ {
        root /var/www/certbot;
    }

    location / {
        return 301 https://$host$request_uri;
    }
}

server {
    listen 443 ssl;
    http2 on;
    server_name app.example.com;

    ssl_certificate /etc/letsencrypt/live/app.example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/app.example.com/privkey.pem;
    ssl_protocols TLSv1.2 TLSv1.3;
    ssl_ciphers HIGH:!aNULL:!MD5;
    ssl_prefer_server_ciphers off;

    server_tokens off;

    add_header Strict-Transport-Security "max-age=31536000; includeSubDomains; preload" always;
    add_header X-Content-Type-Options "nosniff" always;
    add_header X-Frame-Options "DENY" always;
    add_header Referrer-Policy "strict-origin-when-cross-origin" always;

    location / {
        proxy_pass http://whoami:80;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
    }
}

server_tokens off; verbirgt die Nginx-Version in den Antwort-Headern. Die Offenlegung der Version hilft Angreifern, bekannte Schwachstellen gezielt anzugreifen.

Erstellen Sie docker-compose.yml:

services:
  nginx:
    image: nginx:1.28
    container_name: nginx
    restart: unless-stopped
    ports:
      - "80:80"
      - "443:443"
    volumes:
      - ./nginx/conf.d:/etc/nginx/conf.d:ro
      - certbot_webroot:/var/www/certbot:ro
      - certbot_certs:/etc/letsencrypt:ro
    networks:
      - proxy
    depends_on:
      - whoami

  certbot:
    image: certbot/certbot
    container_name: certbot
    restart: unless-stopped
    volumes:
      - certbot_webroot:/var/www/certbot
      - certbot_certs:/etc/letsencrypt
    entrypoint: "/bin/sh -c 'trap exit TERM; while :; do certbot renew; sleep 12h & wait $${!}; done;'"

  whoami:
    image: traefik/whoami
    container_name: whoami
    restart: unless-stopped
    networks:
      - proxy

networks:
  proxy:
    external: true

volumes:
  certbot_webroot:
  certbot_certs:

Nginx erfordert, dass die Zertifikatsdateien vor dem Start existieren. Die obige Konfiguration referenziert /etc/letsencrypt/live/app.example.com/fullchain.pem, die noch nicht existiert. Für das erste Zertifikat ersetzen Sie app.conf vorübergehend durch eine reine HTTP-Version:

server {
    listen 80;
    server_name app.example.com;

    location /.well-known/acme-challenge/ {
        root /var/www/certbot;
    }

    location / {
        return 301 https://$host$request_uri;
    }
}

Starten Sie Nginx und das Backend:

docker compose up -d nginx whoami

Fordern Sie das erste Zertifikat an:

docker compose run --rm certbot certonly \
  --webroot \
  --webroot-path=/var/www/certbot \
  -d app.example.com \
  --email you@example.com \
  --agree-tos \
  --no-eff-email

Sobald das Zertifikat ausgestellt ist, stellen Sie die vollständige app.conf wieder her (die Version mit dem SSL-Serverblock von oben) und starten den kompletten Stack:

docker compose up -d

Prüfen Sie, ob alle Container laufen:

docker compose ps

Testen Sie von Ihrem lokalen Rechner:

curl -v https://app.example.com

Der server:-Antwort-Header sollte nginx ohne Versionsnummer zeigen, was bestätigt, dass server_tokens off aktiv ist.

Um einen weiteren Service hinzuzufügen, erstellen Sie eine neue .conf-Datei in nginx/conf.d/ und laden neu:

docker compose exec nginx nginx -s reload

Für die Zertifikatserneuerung führt der Certbot-Container alle 12 Stunden certbot renew aus. Nach der Erneuerung laden Sie Nginx neu, damit es die neuen Zertifikate übernimmt. Automatisieren Sie dies mit einem Cronjob oder einem Skript, das die Änderungszeiten der Zertifikate prüft. Für eine vertiefte Behandlung der Nginx-Reverse-Proxy-Konfiguration siehe Nginx als Reverse Proxy konfigurieren.

Wie schneiden Traefik, Caddy und Nginx beim Docker Reverse Proxying ab?

Traefik gewinnt bei der automatischen Erkennung. Caddy gewinnt bei der Einfachheit. Nginx gewinnt bei der Kontrolle. Die folgende Tabelle schlüsselt die Kompromisse auf, die beim Betrieb von Docker-Containern auf einem VPS zählen.

Eigenschaft Traefik v3 Caddy 2.11 Nginx 1.28
Auto-Erkennung Ja (Docker-Labels) Nein (manuelles Caddyfile) Nein (manuelle conf-Dateien)
TLS-Automatisierung Integriertes ACME Integriertes ACME Erfordert Certbot-Sidecar
Konfigurationsmethode Docker-Labels + statisches YAML/CLI Caddyfile oder JSON-API nginx.conf-Dateien
Konfig-Neuladen Automatisch bei Container-Events caddy reload (ohne Downtime) nginx -s reload (ohne Downtime)
Docker-Socket erforderlich Ja (oder Socket-Proxy) Nein Nein
HTTP/3 (QUIC) Experimentell Ja (Standard) Über Drittanbietermodul
Middleware/Plugins Integriert (Rate Limit, Auth, Header) Integriert + Go-Plugins Über Config-Direktiven
Community/Doku Groß, aktiv, gute Doku Kleiner, hervorragende Doku Größte, umfangreiche Doku
Lernkurve Mittel (Labels + statische Config) Niedrig (Caddyfile ist intuitiv) Hoch (viele Direktiven)

Welcher Reverse Proxy verbraucht am wenigsten Speicher?

Der Speicherverbrauch im Leerlauf zählt auf einem VPS, wo jedes Megabyte wertvoll ist. Diese Zahlen stammen von docker stats --no-stream auf einem Virtua Cloud VPS mit 4 vCPU / 8 GB RAM unter Ubuntu 24.04. Jeder Proxy lief im Leerlauf ohne Traffic vor der Messung.

Proxy RAM im Leerlauf Image-Größe
Traefik v3.6 ~17 MB ~242 MB
Caddy 2.11 ~14 MB ~88 MB
Nginx 1.28 ~5 MB ~240 MB
Nginx + Certbot ~5 MB + ~25 MB ~240 MB + ~298 MB

Nginx verbraucht mit Abstand am wenigsten Speicher. Caddy liegt in der Mitte. Der höhere Verbrauch von Traefik kommt daher, dass es den Zustand des Docker-Providers und die Routing-Tabelle im Speicher hält. Alle drei verwenden die Standard-Images (Debian/Alpine-basiert). Alpine-Varianten würden die Image-Größen reduzieren, allerdings auf Kosten möglicher Kompatibilitätsprobleme mit bestimmten Erweiterungen.

Unter leichter Last (100 gleichzeitige Anfragen über wrk) bewältigen alle drei den Traffic ohne nennenswerten CPU- oder Speicheranstieg bei dieser VPS-Größe. Die Unterschiede fallen nur bei großem Maßstab oder auf den kleinsten VPS-Plänen ins Gewicht.

Wie wählt man den richtigen Reverse Proxy für das eigene Docker-Setup?

Die richtige Wahl hängt davon ab, wie viele Services Sie betreiben, wie oft sie sich ändern und was Sie bereits kennen.

Wählen Sie Traefik, wenn:

  1. Sie viele Container betreiben, die sich häufig ändern (wöchentliches Hinzufügen/Entfernen von Services)
  2. Sie Routing ohne manuellen Eingriff wollen: Container mit Labels deployen und er ist live
  3. Sie Docker Swarm nutzen oder Service Discovery über mehrere Nodes brauchen
  4. Sie die Docker-Socket-Exposition akzeptieren (mit Socket-Proxy in Produktion)

Wählen Sie Caddy, wenn:

  1. Sie wenige Services betreiben, die sich selten ändern
  2. Sie den einfachsten Weg zu automatischem HTTPS wollen
  3. Sie den Docker-Socket nicht einbinden möchten
  4. Sie eine kleine Image-Größe und geringen Speicherverbrauch bevorzugen
  5. Sie HTTP/3-Unterstützung ohne zusätzliche Konfiguration wollen

Wählen Sie Nginx, wenn:

  1. Sie die Nginx-Konfiguration bereits kennen
  2. Sie granulare Kontrolle über das Proxy-Verhalten brauchen (Buffer, Caching, benutzerdefinierte Header pro Location)
  3. Sie den geringstmöglichen Speicherverbrauch wollen
  4. Ihr Infrastruktur-Team vorhandene Nginx-Tools und Monitoring hat
  5. Die separate Verwaltung von Certbot Sie nicht stört

Entscheidungshilfe:

  1. Betreiben Sie mehr als 5 Docker-Services, die sich regelmäßig ändern? Ja -> Traefik
  2. Brauchen Sie Feinabstimmung des Proxys oder nutzen Sie bereits Nginx? Ja -> Nginx
  3. Wollen Sie die wenigsten beweglichen Teile und das schnellste Setup? Ja -> Caddy

Für die meisten Indie Hacker, die ein oder zwei Nebenprojekte deployen, ist Caddy der beste Einstieg. Für DevOps-Teams, die eine Flotte von Containern verwalten, zahlt sich Traefiks Auto-Erkennung aus. Für Teams, die Nginx bereits anderswo einsetzen, hält das Beibehalten von Nginx den Stack konsistent Docker-Netzwerke auf einem VPS: Bridge, Host und Macvlan erklärt.

Sicherheitshärtung für alle drei Proxys

Egal welchen Proxy Sie wählen, wenden Sie diese grundlegenden Sicherheitspraktiken an.

Sicherheits-Header. Alle drei Beispiele oben enthalten HSTS, X-Content-Type-Options, X-Frame-Options und Referrer-Policy. Für Traefik fügen Sie sie als Middleware-Labels hinzu:

labels:
  - "traefik.http.middlewares.security-headers.headers.stsSeconds=31536000"
  - "traefik.http.middlewares.security-headers.headers.stsIncludeSubdomains=true"
  - "traefik.http.middlewares.security-headers.headers.contentTypeNosniff=true"
  - "traefik.http.middlewares.security-headers.headers.frameDeny=true"
  - "traefik.http.routers.whoami.middlewares=security-headers"

Rate Limiting. Traefik hat eine integrierte Rate-Limiting-Middleware. Caddy bietet eine rate_limit-Direktive als Plugin an. Nginx verwendet limit_req_zone in der Konfiguration. Rate Limiting schützt Ihr Backend vor Brute-Force-Angriffen und Missbrauch.

Docker-Netzwerkisolierung. Jedes Beispiel verwendet ein externes proxy-Netzwerk. Backend-Services sollten nicht im Standard-Bridge-Netzwerk sein. Nur Container, die proxied werden müssen, treten dem proxy-Netzwerk bei. Datenbank-Container und interne Services bleiben in separaten, internen Netzwerken Docker-Sicherheit härten: Rootless-Modus, Seccomp, AppArmor auf einem VPS.

Firewall. Nur die Ports 80 und 443 sollten öffentlich erreichbar sein. Docker manipuliert iptables direkt, was UFW-Regeln umgehen kann. Siehe Docker umgeht UFW: 4 getestete Lösungen für Ihren VPS für die Lösung.

Logs. Prüfen Sie die Proxy-Logs, wenn etwas schiefgeht:

# Traefik
docker logs traefik -f

# Caddy
docker logs caddy -f

# Nginx
docker logs nginx -f

Für Traefik setzen Sie --log.level=DEBUG vorübergehend, um Routing- oder Zertifikatsprobleme zu diagnostizieren. Für Caddy aktivieren Sie die globale debug-Option im Caddyfile. Für Nginx prüfen Sie error.log im Container unter /var/log/nginx/error.log.

Etwas funktioniert nicht?

Symptom Wahrscheinliche Ursache Lösung
Zertifikat wird nicht ausgestellt DNS-A-Record zeigt nicht auf die VPS-IP Prüfen Sie mit dig app.example.com
Traefik 404 auf allen Routen Container nicht im proxy-Netzwerk Prüfen Sie docker network inspect proxy
Caddy "permission denied" auf Port 80 Fehlende NET_BIND_SERVICE-Capability Fügen Sie cap_add: NET_BIND_SERVICE hinzu
Nginx "no such file" für Zertifikat Certbot wurde noch nicht ausgeführt Führen Sie zuerst certbot certonly aus
ERR_CONNECTION_REFUSED Firewall blockiert 80/443 Prüfen Sie ufw status oder iptables -L
Traefik acme.json-Berechtigungsfehler Dateiberechtigungen zu offen Führen Sie chmod 600 acme.json aus
Proxy funktioniert auf dem Server, scheitert extern Test nur auf localhost Testen Sie mit curl von Ihrem lokalen Rechner

Für Produktionshärtung über Reverse Proxying hinaus siehe Docker Compose Ressourcenlimits, Healthchecks und Neustartrichtlinien für Ressourcenlimits und Health Checks Ihrer Compose-Stacks.

Copyright 2026 Virtua.Cloud. Alle Rechte vorbehalten. Dieser Inhalt ist ein Originalwerk des Virtua.Cloud-Teams. Vervielfältigung, Wiederveröffentlichung oder Weiterverbreitung ohne schriftliche Genehmigung ist untersagt.

Bereit, es selbst auszuprobieren?

Stellen Sie Ihren eigenen Server in Sekunden bereit. Linux, Windows oder FreeBSD. →