ServBay-Websites öffentlich bereitstellen (Reverse Proxy, Tunnel & Portweiterleitung)

Neben der lokalen Entwicklung setzen viele Nutzer ServBay auf einem permanenten Server ein (beispielsweise ein Mac mini im Rechenzentrum, ein Büro-PC oder ein Windows-Server), um diesen als originären Backend-Server zu nutzen und Webseiten im Internet bereitzustellen. Das lässt sich produktiv problemlos umsetzen – zahlreiche Nutzer betreiben ServBay bereits so stabil im produktiven Einsatz.

Fehlendes Verständnis für das Standard-Netzwerkverhalten von ServBay führt jedoch leicht zu Problemen mit Protokollen, Zertifikaten, Host-Headern oder der Netzwerkinfrastruktur – die Folge: „Lokal läuft alles, aus dem Internet gibt es Probleme“. Dieser Leitfaden richtet sich an alle, die ServBay als originären Backend-Server verwenden wollen. Wir erklären zunächst das Standardverhalten und stellen dann – in der Reihenfolge Integrierter Tunnel → Reverse Proxy (Empfehlung) → Portweiterleitung – vollständige Lösungen vor. Am Ende finden Sie eine Checkliste zur Fehlersuche bei Problemen.

Unterstützte Plattformen

Dieser Artikel gilt sowohl für ServBay für macOS als auch ServBay für Windows. Die Protokollmodi, das Listenerverhalten und die Zertifikatspfad-Logik sind identisch, lediglich das Installationsverzeichnis unterscheidet sich (macOS: /Applications/ServBay, Windows: meist C:\ServBay, je nach tatsächlicher Installation). Die Standard-Webserver sind verschieden: macOS nutzt standardmäßig Caddy, Windows Nginx, beide können auf Nginx/Apache/Caddy umgestellt werden.

Das Standard-Netzwerkverhalten von ServBay verstehen

Die meisten Fehler bei Internetzugriffen beruhen auf Missverständnissen im Hinblick auf folgende Standardverhalten:

Websites nutzen standardmäßig HTTP & HTTPS. In diesem Modus werden HTTP-Anfragen (Port 80) ohne Ausnahme per 301 auf HTTPS (443) umgeleitet. Das ist ein bewusst moderner Default – Sie sollten HTTPS unterstützen statt sich auf Port 80 zu beschränken.
HTTPS-Sites werden anhand von SNI ausgewählt. Mehrere Websites auf einer ServBay-Instanz werden bei der TLS-Verhandlung anhand des SNI (entspricht dem Domain-Namen) zugeordnet. Der Reverse Proxy MUSS beim HTTPS-Backend-Request den korrekten SNI senden, sonst bekommen Sie das Default-Zertifikat / die falsche Seite.
Standardmäßig wird auf alle Netzwerkschnittstellen (0.0.0.0) gelauscht, HTTP auf 80, HTTPS auf 443 – so sind die Ports ab Werk aus dem Netzwerk erreichbar, ohne dass Sie die Bind-Adresse ändern müssen.
Lokale HTTPS-Zertifikate werden von der ServBay CA ausgestellt. ServBay bringt eine lokale CA mit (ServBay User CA - ECC Root im System-Schlüsselbund). Damit werden Ihre Site-Zertifikate signiert. Browser fremder Besucher vertrauen diesem CA-Zertifikat nicht – der vorgeschaltete Proxy sollte die CA vertrauen oder die Prüfung deaktivieren, Sie brauchen keine separaten öffentlichen Zertifikate für die Backend-Anbindung.

Typischer Fehler: HTTP & HTTPS + nur Port 80 weiterleiten

Wenn Ihre Site den Modus HTTP & HTTPS nutzt, Sie aber nur Port 80 weiterleiten und 443 ignorieren: Der Client ruft http://domain auf → ServBay antwortet mit 301 https://domain → Der Client versucht 443 zu erreichen → Keine Antwort → Fehlerhafter Seitenaufruf. Browser (und HSTS) cachen das 301-Redirect sogar und erschweren so die Fehlersuche.

Die richtige Lösung ist nicht ein Rückschritt auf HTTP 80, sondern HTTPS ordnungsgemäß durch den Proxy bereitzustellen (siehe folgende Reverse-Proxy-Anleitung).

Drei Veröffentlichungsarten im Vergleich

Methode	Beschreibung	Empfohlen bei
Integrierte Tunnel (frpc / cloudflared)	ServBay erstellt eigenständig einen Tunneldienst, kein Public-IP, keine Portfreigabe nötig	Kein Public-IP, Heim-/NAT-Netze, schnellster Onlinegang
Reverse Proxy (empfohlen)	Nginx/HAProxy/Caddy/Traefik nehmen Anfragen entgegen und reichen sie per HTTPS an ServBay weiter	Public-IP vorhanden, zentrale Verwaltung, Zertifikate, mehrere Backends
Portweiterleitung (NAT)	Das Gateway routet öffentliche Ports direkt auf die ServBay-Maschine	Nur EIN Backend, erfahrene Nutzer

Methode 1: Integrierte Tunnel (am einfachsten, kein Public-IP erforderlich)

Kein Public-IP und keine Lust auf Reverse Proxies und Zertifikatsverwaltung? Dann ist der eingebaute Tunneldienst von ServBay die einfachste Lösung. Dabei stellt ServBay selbst eine Verbindung ins Internet her und umgeht damit NAT, IPv6-Probleme, Portweiterleitungen und Zertifikats-Trusts:

Cloudflare Tunnel (cloudflared) – Publiziert lokale Sites über Cloudflares globales Netzwerk, inklusive automatisch bereitgestelltem, global akzeptiertem HTTPS – ganz ohne Portfreigabe. Perfekt für permanente Domains plus CDN oder WAF.
frp (frpc) – Verbindet zu Ihrem selbstgehosteten frps-Server, vollständig unter eigener Kontrolle.
ngrok / Pinggy – Erzeugen einen temporären öffentlichen URL, ideal für Demos oder z. B. Webhook-Entwicklung.

In den meisten Fällen genügt ein cloudflared-Tunnel, um die lokale Site öffentlich zu machen – oft ist die Lektüre der folgenden Abschnitte (Reverse Proxy / Portweiterleitung) nicht mehr nötig.

Methode 2: Reverse Proxy + HTTPS Backend (empfohlen)

Professionell und bewährt: Ein vorgeschalteter Reverse Proxy stellt zertifikatsgestütztes HTTPS nach außen bereit, leitet Anfragen aber auch zum Backend via HTTPS weiter (d. h. Website bleibt im Modus HTTP & HTTPS) – das garantiert Ende-zu-Ende-Verschlüsselung.

Warum HTTPS ans Backend? Warum NICHT auf HTTP 80 zurückfallen?

Viele Tutorials stellen noch auf das veraltete Paradigma ab: Das Backend ist HTTP, der Reverse Proxy nutzt Klartext-Weiterleitung. Wir raten davon ab (Ausnahmen nur mit exaktem Wissen um die Konsequenzen):

Sichere Ende-zu-Ende-Verschlüsselung: Auch Anfragen zwischen Proxy und ServBay im lokalen Netz bleiben so verschlüsselt – keine Gefahr durch internes Abhören oder Manipulation.
Modernste Protokolle: Nur über HTTPS können Sie HTTP/2 (h2) auf der Frontseite aktivieren und profitieren von Multiplexing, Header-Kompression, Verbindungswiederverwendung und mehr. Mit reinem HTTP 80 sind Sie auf alten Technologiestand stehengeblieben.
Vermeidbare Fehlerquellen: Wechseln Sie das Backend auf HTTP, kämpfen Sie mit 301-Weiterleitungen, HSTS-Caching, falsch generierten https-Links auf Applikationsebene und Redirect-Loops.
ServBay-CA zu vertrauen ist trivial: Sie müssen der ServBay-CA einzig auf dem Reverse Proxy vertrauen (oder die Zertifikatsprüfung abschalten). Einmal eingerichtet hält diese Konfiguration dauerhaft.

Reine HTTP 80-Lösungen siehe Methode 3. Nur Nutzer, die die Auswirkungen genau kennen, sollten diese nutzen.

Wichtige Grundregeln

Diese Hinweise gelten für alle vier Reverse-Proxies; als Beispiel dient hier der Domainname example.com, das ServBay-Backend unter 192.168.1.115:443, und Website im Modus HTTP & HTTPS.

HTTPS ans Backend: Proxy-Pass- bzw. Upstream-Ziel ist https://192.168.1.115:443.
Korrektes SNI mitsenden: Das SNI muss mit dem für ServBay konfigurierten Domain-Namen (example.com) übereinstimmen, sonst stellt ServBay nicht das richtige Zertifikat aus.
ServBay CA vertrauen (empfohlen) oder Prüfung deaktivieren: Wie Sie die CA-Datei bekommen, lesen Sie im nächsten Abschnitt.
Host-Header durchreichen: Host: example.com – so trifft das Request das richtige ServBay-VirtualHost.
Senden von X-Forwarded-Proto: https: Damit backendseitige Applikationen das Protokoll erkennen und keine http-Links oder Redirect-Loops produzieren.
IPv4 / IPv6 Konsistenz: Siehe IPv4/IPv6 Konsistenz.

ServBay CA beziehen (für Zertifikats-Vertrauen im Proxy)

Die Root-CA von ServBay liegt im Installationsverzeichnis:

macOS: /Applications/ServBay/ssl/private/ServBay-Private-CA-ECC-Root.crt
Windows: C:\ServBay\ssl\private\ServBay-Private-CA-ECC-Root.crt (ggf. anpassen)

Kopieren Sie diese .crt-Datei auf Ihren Reverse Proxy (z. B. nach /etc/nginx/servbay-ca/) und hinterlegen Sie sie im Proxy als Vertrauens-CA für Backend-Requests.

Hinweis zur Zertifikatskette

ServBay verwendet eine zweistufige CA-Struktur (Root + Intermediate). Falls das Akzeptieren NUR der Root-CA zu Validierungsfehlern führt, können Sie Root- und Intermediate-Zertifikat (ServBay-Private-CA-ECC-Intermediate.crt im selben Verzeichnis) zu einem CA Bundle zusammenfassen. Oder Sie testen den Ablauf vorerst mit deaktivierter Prüfung.

Nginx Reverse Proxy (HTTPS Backend)

nginx

server {
    listen 443 ssl;
    listen [::]:443 ssl;                 # Für IPv6-Support
    server_name example.com;

    # Öffentlich gültiges Zertifikat (z.B. Let's Encrypt)
    ssl_certificate     /etc/nginx/certs/example.com/fullchain.pem;
    ssl_certificate_key /etc/nginx/certs/example.com/privkey.pem;

    location / {
        proxy_pass https://192.168.1.115:443;                 # HTTPS zum Backend

        # —— Wichtig: SNI & Zertifikatsprüfung ——
        proxy_ssl_server_name on;                             # SNI senden
        proxy_ssl_name        example.com;                    # SNI = ServBay-Domain
        proxy_ssl_trusted_certificate /etc/nginx/servbay-ca/servbay-ca-bundle.crt;
        proxy_ssl_verify      on;                             # Prüfung AKTIVIEREN, falls CA vertraut
        proxy_ssl_verify_depth 2;                             # Root + Intermediate
        # Alternativ (kein CA hinterlegt): proxy_ssl_verify off;

        # —— Host & Protokoll durchreichen ——
        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;
    }
}

# HTTP → HTTPS über den Proxy
server {
    listen 80;
    listen [::]:80;
    server_name example.com;
    return 301 https://$host$request_uri;
}

HAProxy Reverse Proxy (HTTPS Backend)

haproxy

frontend fe_web
    bind :80
    bind :443 ssl crt /etc/haproxy/certs/example.com.pem
    http-request redirect scheme https unless { ssl_fc }
    http-request set-header X-Forwarded-Proto https if { ssl_fc }
    default_backend be_servbay

backend be_servbay
    option forwardfor
    http-request set-header Host example.com
    # HTTPS Backend: ssl + SNI + CA-Trust
    server servbay1 192.168.1.115:443 ssl sni str(example.com) \
        verify required ca-file /etc/haproxy/servbay-ca/servbay-ca-bundle.crt
    # Vereinfachte Variante: server servbay1 192.168.1.115:443 ssl sni str(example.com) verify none

Caddy Reverse Proxy (HTTPS Backend)

Caddy beantragt und erneuert automatisch für example.com ein öffentliches Zertifikat; reverse_proxy reicht Host und X-Forwarded-* standardmäßig durch:

caddy

example.com {
    reverse_proxy https://192.168.1.115:443 {
        header_up Host {host}
        transport http {
            tls_server_name example.com                                  # SNI
            tls_trusted_ca_certs /etc/caddy/servbay-ca/servbay-ca-bundle.crt
            # Vereinfachte Variante: tls_insecure_skip_verify
        }
    }
}

Traefik Reverse Proxy (HTTPS Backend)

Beispiel für file provider Konfiguration:

yaml

# traefik-dynamic.yml
http:
  routers:
    servbay:
      rule: "Host(`example.com`)"
      entryPoints:
        - websecure
      service: servbay
      tls:
        certResolver: letsencrypt
  services:
    servbay:
      loadBalancer:
        passHostHeader: true                 # Host weitergeben
        servers:
          - url: "https://192.168.1.115:443" # HTTPS Backend
        serversTransport: servbay-tls

serversTransports:
  servbay-tls:
    serverName: example.com                  # SNI
    rootCAs:
      - /etc/traefik/servbay-ca/servbay-ca-bundle.crt
    # Vereinfachte Variante: insecureSkipVerify: true

Methode 3: Portweiterleitung (NAT)

Falls Sie nur ein einziges Backend haben, können Sie am Gateway/Router öffentliche Ports direkt auf die ServBay-Maschine weiterleiten (z. B. 192.168.1.115).

Empfehlung: Port 443 weiterleiten und HTTPS beibehalten

Portweiterleitung im Router: Internet 443 → 192.168.1.115:443 (und Internet 80 → 192.168.1.115:80, damit ServBay selbst Redirects auf 443 macht).
DNS-A-Record auf Ihre öffentliche IPv4 zeigen lassen.
Webseite im Modus HTTP & HTTPS belassen. Da Besucher direkt auf ServBay zugreifen, benötigen Sie für diese Domain ein offiziell anerkanntes öffentliches Zertifikat (siehe Hinweis zur Zertifikatsbeantragung), andernfalls erscheinen Warnungen im Browser.
Auf IPv4-/IPv6-Konsistenz achten (siehe nächsten Abschnitt).

Klartext HTTP 80 – nur für Spezialfälle

Nur Port 80 durchzuleiten und die Website auf HTTP umzustellen, hat gravierende Nachteile: Sie verlieren HTTPS und HTTP/2, und laufen Gefahr auf Probleme mit HSTS/Caching zu laufen. Nur empfehlenswert, wenn Sie das Risiko und die Folgen kennen. Dann den Protokollmodus explizit auf HTTP setzen (verhindert 301 auf nicht geöffnetes 443) und ausschließlich Port 80 weiterleiten.

IPv4 / IPv6 Konsistenz

Eine häufige Ursache für sporadische Probleme mit Internetzugriffen. Hat Ihre Domain sowohl einen A-(IPv4) als auch einen AAAA-(IPv6)-Record, so „probieren“ Clients per Happy Eyeballs-Algorithmus manchmal zuerst IPv6. Falls Sie aber nur IPv4 weitergeleitet/proxied haben, schlagen Anfragen über IPv6 fehl. Zwei Möglichkeiten:

Nur IPv4 nutzen: Prüfen mit dig AAAA Ihr-Domainname +short, ggf. nur A-Record aktiv lassen.
IPv6 zusätzlich einrichten: Konfigurieren Sie IPv6-Weiterleitung/Proxy und stellen Sie sicher, dass das Backend über IPv6 erreichbar ist.

Checkliste zur Fehlerdiagnose bei Besuchsproblemen

Probleme wie „Seite nicht erreichbar, Timeout, Zertifikatsfehler, falsche Website“ prüfen Sie wie folgt (Beispiel-Domain example.com, Backend 192.168.1.115):

Wird ein 301 auf ein nicht erreichbares 443er-Port gemacht?
bash
```
curl -I http://example.com
```
1
Gibt es ein 301 mit Location: https://... und ist 443 nicht weitergeleitet → Fehlerursache gefunden. HTTPS ordentlich durch Proxy bereitstellen (empfohlen) oder Protokoll auf HTTP umstellen.

Stört IPv6?

bash

curl -4 -I https://example.com     # Nur IPv4 testen
curl -6 -I https://example.com     # Nur IPv6 testen
dig A example.com +short
dig AAAA example.com +short        # AAAA vorhanden, aber kein IPv6-Zugang? → AAAA entfernen oder IPv6 einrichten

Sind SNI und Zertifikate korrekt? (bei HTTPS-Backend)
bash
```
curl -I --resolve example.com:443:192.168.1.115 https://example.com \
     --cacert /path/servbay-ca-bundle.crt
```
1
2
Gibt es Fehler bzgl. Zertifikat oder Domain-Mismatch, fehlt meist das richtige SNI oder die CA ist nicht vertraut.
Erreichen Requests überhaupt ServBay? Auf der ServBay-Maschine die Zugriffsprotokolle der jeweiligen Site prüfen („Logdatei anzeigen“ in ServBay). Steht kein Request im Log, hakt es im Netzwerk/Gateway/Proxy.
Ist der Host-Header korrekt? (bei Layer-7-Proxies)
bash
```
curl -k -I -H "Host: example.com" https://192.168.1.115/
```
1
Funktioniert der Direktzugriff, aber nicht über den Proxy, wird der Host-Header nicht durchgereicht.

Hinweise zu Zertifikaten und Sicherheit

Backend-Verbindung: Reverse Proxy → ServBay per HTTPS: Lassen Sie Ihren Proxy die ServBay-CA (ServBay-Private-CA-ECC-Root.crt, ggf. gemeinsam mit Intermediate-CA) vertrauen; einmal eingerichtet, bleibt das Vertrauen im lokalen Netz dauerhaft gültig.
Öffentliche Zertifikate: Für Besucher im Internet sind öffentlich valide Zertifikate notwendig. Im Reverse Proxy regelt das Proxy (Caddy / Traefik macht das automatisch); bei direkter Weiterleitung via Port müssen Sie das Zertifikat in ServBay für die entsprechende Domain einrichten – siehe ACME-Zertifikat ausstellen. Das von ServBay selbst erstellte ServBay User CA eignet sich nur lokal oder im LAN und wird von Externen nicht als vertrauenswürdig anerkannt.
Datenbanken nicht versehentlich ins Internet legen: Wenn Sie das Web öffnen, öffnen Sie NICHT MySQL, Redis, Memcached etc. Weitere Sicherheitshinweise: Zugriff im LAN.
Firewall: Nur benötigte Ports öffnen, alles andere absichern.

Häufige Fragen (FAQ)

F: Lokal funktioniert es, im Internet nicht – DNS-Problem?
- A: Meist NICHT ein Namensauflösungsproblem, sondern 301-Redirect auf nicht erreichbares 443, kein korrektes SNI/Zertifikat oder Host-Header-Problem oder IPv4/IPv6-Mismatch. Die Checkliste hilft Schritt für Schritt.
F: Muss ich unbedingt auf HTTP 80 zurück, damit der Proxy funktioniert?
- A: Nein, im Gegenteil – empfohlen wird die Beibehaltung von HTTP & HTTPS. Der Proxy reicht HTTPS ans Backend und vertraut der ServBay CA (oder deaktiviert die Prüfung) – so gibt’s End-to-End-Verschlüsselung und HTTP/2.
F: Proxy weist Zertifikats- oder Domainfehler aus?
- A: Prüfen Sie, dass das korrekte SNI (also die Domain) übertragen und die ServBay CA vertraut wird (ggf. Intermediate-CA ergänzen). Zum Testen Prüfung deaktivieren, dann auf „Prüfung aktiv“ umschalten.
F: Ist ServBay im Rechenzentrum als produktiver originärer Backendserver stabil?
- A: Ja. Viele Nutzer fahren ServBay (Mac mini / Windows-Server) produktiv im Hostingcenter. Essenziell sind korrektes Protokoll, SNI, Host-Header, Zertifikat und IPv4/IPv6-Abgleich.
F: Was tun wenn ich keine öffentliche IP habe?
- A: Siehe Methode 1: Integrierter Tunnel (cloudflared / frpc). Keine öffentliche IP und keine Portweiterleitung nötig!

Fazit

ServBay lässt sich problemlos als originärer Backend-Server öffentlich bereitstellen. Die empfohlene Methode ist: Website-Modus auf HTTP & HTTPS lassen, vorgeschaltete Reverse Proxy-Lösung mit HTTPS-Backend, korrektem SNI und Vertrauen in die ServBay-CA – so profitieren Sie von Ende-zu-Ende-Verschlüsselung und modernen Protokollen wie HTTP/2. Ohne öffentliche IP ist der integrierte Tunnel via cloudflared / frpc am unaufwändigsten. Portweiterleitung ist eine Option für fortgeschrittene Nutzer. Bei Problemen führt die Checkliste zur schnellen Fehlerursache – meist sind Protokoll, SNI/Zertifikat, Host-Header oder IPv4/IPv6 die entscheidende Ursache.

ServBay-Websites öffentlich bereitstellen (Reverse Proxy, Tunnel & Portweiterleitung) ​

Das Standard-Netzwerkverhalten von ServBay verstehen ​

Drei Veröffentlichungsarten im Vergleich ​

Methode 1: Integrierte Tunnel (am einfachsten, kein Public-IP erforderlich) ​

Methode 2: Reverse Proxy + HTTPS Backend (empfohlen) ​

Warum HTTPS ans Backend? Warum NICHT auf HTTP 80 zurückfallen? ​

Wichtige Grundregeln ​

ServBay CA beziehen (für Zertifikats-Vertrauen im Proxy) ​

Nginx Reverse Proxy (HTTPS Backend) ​

HAProxy Reverse Proxy (HTTPS Backend) ​

Caddy Reverse Proxy (HTTPS Backend) ​

Traefik Reverse Proxy (HTTPS Backend) ​

Methode 3: Portweiterleitung (NAT) ​

IPv4 / IPv6 Konsistenz ​

Checkliste zur Fehlerdiagnose bei Besuchsproblemen ​

Hinweise zu Zertifikaten und Sicherheit ​

Häufige Fragen (FAQ) ​

Fazit ​