Warum erreiche ich meinen Port nicht?

Du hast eine Website, eine App oder eine Datenbank eingerichtet, und von deinem Laptop aus erreichst du sie nicht. Der Browser lädt endlos. curl läuft in einen Timeout. Auf dem Server sieht intern alles gut aus — der Prozess läuft, die Logs sagen „listening on port 8080“ — aber von außen wirkt es, als wäre der Server gar nicht da.

Das ist eines der häufigsten Probleme, an denen Leute hängen bleiben. Und es ist deshalb so frustrierend, weil drei völlig unterschiedliche Probleme von außen genau gleich aussehen. Solange du nicht weißt, welches davon dich betrifft, kannst du es nicht beheben.

Dieser Artikel führt dich durch die drei Ebenen, in der Reihenfolge, in der du sie prüfen solltest, und zeigt, wie Server Manager jede davon findet und behebt.

Die drei Ebenen, in der richtigen Reihenfolge

Zwischen deinem Browser und dem Programm, das auf deinem Server läuft, gibt es drei Stellen, an denen Datenverkehr blockiert werden kann. Von außen sehen alle drei gleich aus — „Ich erreiche es nicht.“ Intern sind es aber sehr unterschiedliche Probleme mit sehr unterschiedlichen Lösungen.

Die drei Ebenen:

1. Cloud-Provider-Firewall — läuft außerhalb deines Servers bei deinem Anbieter (Hetzner, Oracle, AWS usw.). Verwirft Pakete, bevor sie den Server überhaupt erreichen.
2. Server-Firewall — läuft auf deinem Server. Verwirft Pakete, wenn sie ankommen, bevor irgendein Dienst sie sieht.
3. Dein Dienst — das Programm selbst (Caddy, deine App, deine Datenbank). Es läuft entweder nicht oder lauscht nur lokal.

Stell es dir wie ein Gebäude mit drei Sicherheitskontrollen vor. Das Paket muss alle drei passieren, um dich zu erreichen. Wenn eine einzige davon blockiert, bist du nicht erreichbar — und von außen kannst du nicht erkennen, welche Kontrolle es gestoppt hat.

Ebene 3 — Lauscht dein Dienst überhaupt?

Die einfachste und häufigste Ursache. Bevor du dir Gedanken über Firewalls machst, prüfe, ob auf dem Server überhaupt ein Programm aktiv auf dem erwarteten Port lauscht.

Dabei gibt es zwei typische Fehler:

• Nichts lauscht. Der Container ist abgestürzt. Der systemd-Dienst konnte nicht starten. Die App wurde beim Booten beendet. Von außen sieht das genauso aus wie eine Firewall-Blockade — das Paket kommt an, aber niemand antwortet.
• Der Dienst lauscht nur auf localhost. Das ist tückisch. Viele Programme verwenden standardmäßig „nur Loopback“ (127.0.0.1). Das heißt: Das Programm läuft und nimmt Verbindungen an — aber nur vom Server selbst. Verbindungen von außen erreichen es nicht, selbst wenn jede Firewall komplett offen ist. Häufige Kandidaten: PostgreSQL direkt nach der Installation, MySQL/MariaDB, Redis, Jupyter-Notebooks, Entwicklungsserver, alles, was sinngemäß sagt: „Aus Sicherheitsgründen binden wir standardmäßig nur an localhost.“

So hilft Server Manager:

• Der Serverdetails → Firewall-Tab kann beantworten: „Blockiert meine Server-Firewall das?“ Ebene 3 lässt sich aber besser im Chat prüfen — frag Faro: „Lauscht überhaupt etwas auf Port 8080?“ Dann führt Faro ss -tlnp aus und sagt dir Bescheid.
• Wenn du im Firewall-Tab auf Nicht erreichbar diagnostizieren klickst, prüft die Diagnose alle drei Ebenen — einschließlich dieser — und sagt dir, welche die Ursache ist.

Ebene 2 — Die Server-Firewall (auf dem Server)

Als Nächstes solltest du die Firewall prüfen, die auf dem Server selbst läuft. Auf Ubuntu/Debian ist das meist ufw; auf Fedora/Rocky ist es firewalld; dahinter steckt in beiden Fällen rohes iptables. Egal welche Oberfläche davorliegt: Die Aufgabe ist dieselbe — eingehende Pakete verwerfen, die nicht ausdrücklich erlaubt sind.

Drei Dinge solltest du über diese Ebene wissen:

• Die meisten frisch erstellten Server sind „standardmäßig offen“ — jeder Port ist durch die Server-Firewall erreichbar, weil die Firewall entweder nicht installiert ist oder nichts erzwingt. Server Manager zeigt das deutlich: Im Firewall-Tab erscheint in diesem Fall ein gelbes Banner „Standardmäßig erlauben“.
• Ein „gehärteter“ Server ist „standardmäßig geschlossen“ — eingehender Datenverkehr wird standardmäßig blockiert; nur ausdrücklich erlaubte Ports kommen durch. SSH (Port 22) bleibt immer offen, plus alles, was du während der Einrichtung bestätigt hast.
• Die meisten Hosting-Anbieter aktivieren keine Server-Firewall für dich. Du bekommst entweder einen standardmäßig offenen Server (jeder Port ist auf dieser Ebene offen) oder richtest selbst eine ein.

So hilft Server Manager:

• Serverdetails → Firewall-Tab zeigt dir den aktuellen Zustand auf einen Blick: Backend (ufw / iptables / firewalld / none), aktiv oder standardmäßig offen, sowie die Liste ausdrücklich erlaubter Ports mit Beschriftungen in verständlicher Sprache.
• Port öffnen lässt dich mit einem Klick einen einzelnen Port durch die Server-Firewall freigeben (das Eingabefeld Port plus Protokollauswahl oben im Tab). Der Chat führt dich durch die sichere und dauerhafte Vorgehensweise.
• Firewall dieses Servers härten stellt einen standardmäßig offenen Server sicher auf „standardmäßig geschlossen“ um. Ein Dialog listet alle Dienste auf, die aktuell lauschen, und lässt dich auswählen, welche öffentlich erreichbar bleiben sollen. SSH bleibt immer erhalten (die Schutzfunktion verhindert, dass du dich aussperrst). Docker wird automatisch erkannt, und es wird ein Docker-kompatibler Modus verwendet, damit Container weiter funktionieren.
• Nicht erreichbar diagnostizieren prüft diese Ebene (und die anderen) und meldet, welche davon deinen Port blockiert.

Wichtig: Eine Server-Firewall zusammen mit Docker zu aktivieren, ist heikel. Einfach ufw enable auf einem Docker-Host auszuführen, kann das Container-Netzwerk beschädigen — Docker verwaltet eigene Firewall-Regeln über eine separate Chain (DOCKER-USER), und ufw weiß nichts davon. Wenn du Server Manager die Härtung übernehmen lässt, erkennt er Docker und verwendet automatisch einen Docker-sicheren Weg. Das manuell ohne diese Integration zu tun, ist ein häufiger Grund dafür, dass du die Verbindung zu deinen Containern verlierst.

Ebene 1 — Die Cloud-Provider-Firewall (außerhalb des Servers)

Das ist die kniffligste Ebene. Dein Hosting-Anbieter betreibt eine Firewall vor deinem Server — Pakete werden gefiltert, bevor sie deine VM überhaupt erreichen. Server Manager kann diese Firewall nicht direkt einsehen, weil sie nicht auf deinem Server läuft; ändern kannst du sie nur in der Webkonsole deines Anbieters.

Namen und Verhalten unterscheiden sich stark:

Wichtig ist: Die Server-Firewall und die Cloud-Firewall sind zwei getrennte Firewalls. Beide können blockieren. Beide können durchlassen. Du kannst einen Port auf dem Server öffnen und trotzdem von der Cloud-Seite blockiert werden (sehr häufig). Du kannst auf dem Server gar keine Firewall haben und trotzdem von der Cloud-Seite blockiert werden (ebenfalls häufig).

So hilft Server Manager:

• Server Manager kann Cloud-Firewall-Regeln nicht direkt ändern (dafür bräuchte er API-Schlüssel für jeden Anbieter), aber Faro kennt die Schritt-für-Schritt-Anleitungen für alle großen Anbieter und führt dich durch den Prozess. Nachdem ein Port auf der Serverseite geöffnet wurde, fragt Faro: „Soll ich dich auch durch das Öffnen auf der Cloud-Seite führen?“ und gibt dir genaue Anweisungen für die Webkonsole deines Anbieters.
• Wenn du im Firewall-Tab Nicht erreichbar diagnostizieren ausführst, erkennt die Diagnose, ob die Cloud-Firewall blockiert, und gibt automatisch die passende Anleitung für deinen Anbieter aus.
• Wenn du Firewall dieses Servers härten verwendest, erinnert Faro dich daran, auch die Cloud-Firewall entsprechend einzuschränken (sonst hast du eine asymmetrische Konfiguration — streng auf dem Server, locker in der Cloud).

Wie Server Manager alle drei Ebenen für dich prüft

Der Chat-Weg: Öffne Faro und schreibe „Warum erreiche ich Port 8080 nicht?“ Der Agent prüft alle drei Ebenen der Reihe nach — ob ein Dienst lauscht, ob die Server-Firewall blockiert, ob die Cloud-Firewall blockiert — und sagt dir, welche die Ursache ist. Danach bietet er an, sie zu beheben.

Der UI-Weg: Serverdetails → Firewall-Tab → Nicht erreichbar diagnostizieren. Gib den Port ein und klicke auf den Button. Dieselbe Prüfung über drei Ebenen, dieselbe Diagnose, dasselbe Angebot zur Behebung.

Das Ergebnis nennt immer genau eine Ebene als Ursache und schlägt genau eine konkrete Lösung als Ja/Nein-Frage vor. Keine mehrseitigen generischen Checklisten.

Häufige Szenarien

„Ich habe eine Datenbank bereitgestellt und kann mich von meinem Laptop aus nicht verbinden“

Mit sehr hoher Wahrscheinlichkeit Ebene 3 — die Datenbank **lauscht nur auf 127.0.0.1**. PostgreSQL, MySQL, MariaDB und Redis verwenden standardmäßig localhost. Sie laufen einwandfrei, du erreichst sie nur nicht von außen.

Die Lösung hängt davon ab, was du möchtest:

• Für App→Datenbank auf demselben Server (der Normalfall) — genau so sollte es sein. Verbinde deine App mit localhost:5432 (oder dem jeweiligen Port), und du bist fertig. Keine Firewall-Änderungen nötig. In Server Manager: nichts zu tun — Faro stellt Datenbanken standardmäßig so bereit.
• Für „mein Laptop → Datenbank“ zur Remote-Administration — öffne einen Tunnel: ssh -L 5432:localhost:5432 user@server von deinem Laptop aus, und verbinde deinen DB-Client dann lokal mit localhost:5432. Das ist sicherer, als die DB ins Internet zu stellen. In Server Manager: Frag Faro nach dem genauen Tunnel-Befehl — Faro kennt Benutzer und Host deines Servers.
• Für „Ich will wirklich, dass diese Datenbank öffentlich erreichbar ist“ — ändere die Bind-Adresse in der DB-Konfiguration auf 0.0.0.0, starte die DB neu und öffne den Port anschließend sowohl in der Server-Firewall ALS AUCH in der Cloud-Firewall. Stell unbedingt vorher sicher, dass du ein starkes Passwort gesetzt hast; eine DB ohne starke Authentifizierung öffentlich ins Internet zu stellen, ist ein häufiger Weg, kompromittiert zu werden. In Server Manager: Bitte Faro, alle drei Schritte auszuführen (DB neu binden, Server-Firewall-Port über den Firewall-Tab öffnen, durch die Cloud-Provider-Regel führen). Lass Faro zuerst ein starkes Passwort erzeugen, falls du noch keines gesetzt hast.

„Ich habe den Port in ufw geöffnet und erreiche ihn trotzdem nicht“

Ebene 1 — die Cloud-Provider-Firewall weiß noch nichts davon. Serverseitiges ufw allow 8080/tcp öffnet Ebene 2; das Paket muss aber immer noch Ebene 1 passieren, bevor es deinen Server erreicht. Öffne die passende Regel in der Konsole deines Cloud-Anbieters.

In Server Manager: Bitte Faro, dich durch die Cloud-seitige Regel für deinen Anbieter zu führen — du bekommst Schritt-für-Schritt-Anweisungen für Hetzner / AWS / Oracle / usw., ohne das Dashboard-Layout nachschlagen zu müssen.

„Gestern ging es noch, heute nicht mehr“

Ein paar häufige Ursachen:

• Deine IP hat sich geändert — wenn deine Cloud-Firewall auf „nur meine IP“ eingeschränkt ist und dein Internetanschluss über Nacht eine neue IP bekommen hat (bei den meisten Privatanschlüssen sehr häufig), ist die neue IP jetzt blockiert. Erweitere vorübergehend auf 0.0.0.0/0, melde dich an und schränke danach wieder ein.
• Der Dienst ist abgestürzt — ein Problem auf Ebene 3, das sich tarnt. Prüfe systemctl status <service> oder docker ps.
• Der Server wurde kürzlich gehärtet — wenn jemand die Server-Firewall aktiviert hat, ohne den für dich wichtigen Port einzuschließen, wird dieser Port jetzt auf Ebene 2 blockiert. Öffne den Firewall-Tab, um das aktuelle Regelwerk zu sehen.

In Server Manager: Gib den betroffenen Port im Firewall-Tab ein und klicke auf Nicht erreichbar diagnostizieren — Faro prüft alle drei Ebenen und sagt dir, welche sich verändert hat. Schneller als Raten.

„Vom Server aus kann ich es mit curl erreichen, von außen nicht“

Das ist die diagnostische Trennlinie: Sie zeigt dir, dass der Dienst in Ordnung ist und Ebene 3 nicht das Problem ist. Jetzt ist es entweder Ebene 2 (Server-Firewall) oder Ebene 1 (Cloud-Firewall). Nutze Nicht erreichbar diagnostizieren, um es weiter einzugrenzen.

In Server Manager: Der Button Nicht erreichbar diagnostizieren im Firewall-Tab ist genau für diesen Fall das richtige Werkzeug — er überspringt Ebene 3 (weil du bereits bewiesen hast, dass sie funktioniert) und sagt dir, welche der beiden Firewall-Ebenen das Paket verwirft.

Häufige Fragen

Brauche ich eine Server-Firewall, wenn mein Cloud-Anbieter schon eine hat?

Jein — das hängt von deinem Bedrohungsmodell ab. Eine Cloud-Firewall deckt den Normalfall ab. Eine Server-Firewall ist nützlich, wenn:

• Du Docker verwendest — Container können in manchen Setups eigene Löcher öffnen, die an der Cloud-Firewall vorbeigehen. Eine Server-Firewall fängt Container-Egress ab.
• Du vergisst, temporäre Cloud-Firewall-Regeln zu entfernen — die Server-Firewall ist dein Sicherheitsnetz.
• Du ausgehenden Datenverkehr filtern möchtest — Cloud-Firewalls konzentrieren sich meist auf eingehenden Traffic; Server-Firewalls können beides.

Wenn nichts davon zutrifft, reicht für die meisten Setups eine einzelne gut konfigurierte Cloud-Firewall aus.

Funktioniert Server Manager ohne Server-Firewall?

Ja. Server Manager benötigt keine Firewall-Konfiguration, um zu funktionieren. Der Firewall-Tab dient deiner Sicherheit, nicht der Verbindung zu Server Manager selbst (Server Manager braucht nur SSH, Port 22).

Warum zeigt mir der Firewall-Tab „Standardmäßig erlauben“, obwohl ich nie etwas eingerichtet habe?

Weil das der tatsächliche Zustand ist. Die meisten frisch erstellten Server haben keine Server-Firewall konfiguriert — jeder Port ist auf dieser Ebene erreichbar. Ob tatsächlich etwas deinen Dienst erreicht, hängt von Ebene 1 (Cloud-Firewall) und Ebene 3 (ob der Dienst lauscht) ab. Das gelbe Banner ist ein Hinweis, dass du den Server vielleicht härten solltest.

Sollte ich „Port 22 / SSH öffnen“ jemals schließen?

Nein. Server Manager spricht mit deinem Server ausschließlich über SSH. Wenn du Port 22 schließt, trennst du Server Manager, und du brauchst eine Wiederherstellung über die Provider-Konsole (siehe Wiederherstellung, wenn SSH nicht mehr funktioniert). Der Firewall-Tab bietet deshalb in der SSH-Zeile keinen Schließen-Button an, und der Härtungsdialog sperrt die SSH-Zeile auf „immer offen halten“.

Was hier NICHT behandelt wird

• Probleme mit ausgehendem Datenverkehr (dein Server erreicht das Internet nicht) — das ist ein anderes Setup: meist NAT, DNS oder das ausgehende Netzwerk des Anbieters. Bitte Faro um eine Diagnose.
• HTTPS- / TLS-Fehler — die Erreichbarkeit hat funktioniert, aber der Verschlüsselungs-Handshake ist fehlgeschlagen. Anderer Problembereich; sieh im Abschnitt Domains, HTTPS und E-Mail nach.
• DNS-Probleme („meine Domain zeigt nicht auf den Server“) — behandelt in Domain hierher zeigen lassen. Das Paket ist noch gar nicht bei der Firewall-Frage angekommen — es weiß noch nicht, wo der Server ist.
• Spezifische App-Konfiguration (welche Umgebungsvariable du setzen musst, damit deine App auf 0.0.0.0 statt 127.0.0.1 lauscht) — das unterscheidet sich je nach App. Frag Faro: Faro kennt die gängigen Fälle.