常见问题

SSLcat ist ein quelloffener SSL-Reverse-Proxy-Server der Enterprise-Klasse, geschrieben in Go. Er vereint nginx + Caddy + Web-UI + GitOps in einer einzigen Binärdatei: automatische Ausstellung und Erneuerung über Let's Encrypt, intelligentes Domain-Routing, Load Balancing, WAF, Docker- / Runner-App-Hosting sowie ein modernes Web-Admin-Panel. Ab v2.1 ist außerdem ein MCP-Server integriert, sodass Claude / Cursor und andere KI-Clients seine Tools direkt aufrufen können.

MCP (Model Context Protocol) ist ein offenes Protokoll, das KI-Clients mit externen Tools verbindet. Ab v2.1 ist SSLcat selbst ein MCP-Server, und seit v2.3.0-rc1 stellt es 22 Tools (CRUD für Site / Cert / Proxy-Route, Upstream-Health-Check, Abfragen langlaufender Aufgaben sowie `error_log_list` / `error_log_tail` zur Einsicht aktueller Fehler) plus 5 Ressourcen (redigierte aktuelle Konfiguration, Snapshot der Laufzeitmetriken, Tail des Access-Logs, Fehlerprotokollquellen, Fehlerprotokollinhalt) bereit. Trage ein Token in Claude Desktop / Cursor / Cherry Studio / Continue.dev ein, und die KI kann Sites auflisten, Zertifikate ausstellen, Routen ändern und Access- / Fehlerprotokolle einsehen – destruktive Aktionen laufen weiterhin über eine zweistufige Bestätigung.

Ein Befehl unter macOS / Linux: `curl -fsSL https://raw.githubusercontent.com/xurenlu/sslcat/main/install.sh | bash`. Du kannst auch Binärdateien von der GitHub-Releases-Seite beziehen (linux-amd64 / linux-arm64 / darwin-arm64 / darwin-amd64). Die vollständige Dokumentation liegt unter `docs/` und auf der Website.

Ja. SSLcat integriert Let's Encrypt (ACME). Das Hinzufügen einer Domain löst die automatische Ausstellung aus, und Zertifikate werden 30 Tage vor Ablauf ohne Ausfallzeit erneuert. Sowohl HTTP-01- als auch DNS-01-Challenges werden unterstützt; DNS-01 in Kombination mit AWS Route53 (und anderen Anbietern) ermöglicht die Ausstellung von Wildcard-Zertifikaten wie `*.example.com`.

Im Vergleich zu nginx: SSLcat liefert standardmäßig ein Web-Admin-Panel, automatisches SSL, GitOps-Deployment, Echtzeit-Monitoring und KI-gestützte Sicherheit – kein manuelles Editieren von Konfigurationsdateien mehr. Im Vergleich zu Caddy: SSLcat bietet 6 Load-Balancing-Algorithmen, Mehrbenutzerverwaltung, Deployment per Docker-Image und Runner, ein API-Token-System, Live-Log-Streaming über WebSocket sowie ab v2.1 die integrierte MCP-Anbindung.

Vollständige Unterstützung für HTTP/1.1, HTTP/2 und HTTP/3 (QUIC), mit erzwungenem TLS 1.3. Langlebige WebSocket- und SSE-Verbindungen werden besonders behandelt, und langlaufende ACME-Aufgaben verwenden Heartbeats, Ausnahmen vom Write-Timeout sowie eine pro Domain isolierte Nebenläufigkeit, damit sie sich nicht gegenseitig ausbremsen.

Sechs Algorithmen sind integriert (Round-Robin, gewichtetes Round-Robin, Least-Conn, IP-Hash, Random, schnellste Antwort), kombiniert mit TCP-Health-Checks und Session-Stickiness. Du kannst auf Routenebene einer einzelnen Domain eine Liste gewichteter Backends zuweisen.

Füge SSLcat als Git-Remote hinzu und führe dann `git push sslcat main` aus, um zu deployen – im Stil von Dokku/Heroku. Der Einstieg in Runner-Deployments ist gestaffelt: ein Verzeichnis hochladen, eine Binärdatei hochladen, ein Docker-Image direkt ziehen, per `git push` bauen oder eine Vorlage nutzen. Alle Wege münden in derselben einheitlichen Runner-Spezifikation (Umgebungsvariablen, Ports, Mounts, Startbefehl).

Runner ist die integrierte App-Hosting-Schicht von SSLcat. Sie kann Docker-Container ausführen, hochgeladene Binärdateien starten, aus `git push` gebaute Images betreiben oder aus Vorlagen deployen. Wenn SSLcat selbst neu startet, gleicht es lediglich den Status der Runner-Container ab – deine Geschäftsanwendungs-Container werden niemals neu gestartet, sodass Produktionsverkehr nie versehentlich unterbrochen wird.

WAF-Regelabgleich (das Scannen des Request-Bodys ist auf 1 MB begrenzt, um den Speicherverbrauch im Rahmen zu halten), DDoS-Schutz, Brute-Force-Abwehr, Sperr- und Whitelisten nach IP / UA / TLS-Fingerabdruck, fein granulare API-Token, TOTP-MFA, Audit-Logs, Konfigurationsversionierung sowie ein auf Isolation Forest basierender KI-Anomalie-Detektor mit Online-Training, persistierten JSON-Modellen und Inferenz auf Echtverkehr.

Bevorzugt über den integrierten Reset-Befehl: `sslcat users password -username admin -new-password 'NewStrongPass123!'`. Aus einem Quellbaum kannst du auch ausführen: `go run tools/cmd/reset_password/main.go admin 'NewStrongPass123!'`. Ab v2.0.0-rc22 kannst du außerdem per Einmal-Wiederherstellungscode zurücksetzen. Um einen bcrypt-Hash manuell mit Ruby zu erzeugen: installiere bcrypt mit `gem install bcrypt` und führe dann `SSL_PASS='NewStrongPass123!' ruby -rbcrypt -e 'puts BCrypt::Password.create(ENV.fetch("SSL_PASS"), cost: 10)'` aus. Mit Python: `python3 -m pip install bcrypt`, anschließend `SSL_PASS='NewStrongPass123!' python3 -c 'import bcrypt, os; print(bcrypt.hashpw(os.environ["SSL_PASS"].encode(), bcrypt.gensalt(rounds=10)).decode())'`. Schreibe den Hash in `admin.password_file` (üblicherweise `/opt/sslcat/data/admin.pass` oder `./data/admin.pass`) mit Modus `600`. Eine Wiederherstellung über die Passwortdatei erfordert in der Regel keinen Neustart von SSLcat – die nächste Anmeldung liest den neuen Hash.

`http://<your-host>:8080/sslcat-panel/`, Standardkonto `admin`, Standardpasswort `admin*9527` (bei der ersten Anmeldung ändern). Sowohl das URL-Präfix des Admin-Panels als auch der Management-Port sind konfigurierbar.

Ja. SSLcat stellt Wildcard-Zertifikate wie `*.example.com` über die DNS-01-Challenge von Let's Encrypt aus. Wildcard-Domains werden automatisch auf DNS-01 umgestellt und können mit AWS Route53 sowie anderen DNS-Anbietern zur Verifikation kombiniert werden.

Füge unter „Sites“ im Admin-Panel eine Domain, einen Ziel-Host und einen Port hinzu. Um mehrere Backends hinzuzufügen, aktiviere `load_balancer_enabled`, wähle den Algorithmus (round_robin / least_conn / ip_hash usw.), schalte Health-Checks ein und liste die Backends auf. Du kannst die JSON-Konfiguration auch direkt bearbeiten (SSLcat verwendet JSON, nicht YAML).

Ja. Die v2.0-Reihe härtet die Produktionspfade weiter ab: atomare Schreibvorgänge für Zertifikate, Schlüssel, Konfigurationsversionen, Token und Sessions; idempotentes Stop / Close in jeder Komponente; sichereres Upstream-Caching unter Nebenläufigkeit; durchsatzstarke WAF; absolut stabile langlebige HTTP/2- / HTTP/3- / WebSocket-Verbindungen. Aktuelle Optimierungen haben die CPU-Last im Leerlauf von 50–100 % auf <1 % reduziert und Setups mit mehreren Runnern um etwa 97 %.

1) MCP aktivieren: `sslcat mcp enable`. 2) Token erstellen: `sslcat mcp token create --name claude-desktop --scopes read,site:write,cert:write`. Das Klartext-Token wird nur einmal angezeigt – sicher aufbewahren. 3) Claude Desktop mit dem Streamable-HTTP-Endpunkt (standardmäßig `https://your-domain/sslcat-panel/mcp/stream`) und dem Bearer-Token konfigurieren. Vollständige Konfigurationen für Cursor, Cherry Studio, Continue.dev und das Debuggen mit curl findest du in `docs/mcp-client-setup.md`.

Ja. Jedes destruktive Tool nutzt eine zweistufige Bestätigung: Der erste Aufruf liefert eine Dry-Run-Vorschau mit Auswirkungsinformationen (z. B. markiert `cert_delete`, ob das Zertifikat von einer Proxy-Regel referenziert wird und wie viele Tage es noch gültig ist; `proxy_route_delete` listet Präfixe und Backends auf) plus einem `confirm_token` mit 60 Sekunden TTL. Die KI muss dieses Token im Argument `confirm` eines zweiten Aufrufs zurückgeben, um die Aktion tatsächlich auszuführen. Token sind an (token_name, tool, args hash) gebunden, sodass sie nicht über Tools oder Argumente hinweg wiederverwendet werden können.

Ein Isolation Forest ist in SSLcat integriert. Ein `RequestSampler` extrahiert aus jeder echten Anfrage Merkmale in einen Ringpuffer mit 5.000 Slots; das Training zieht Stichproben direkt aus dem Ring und persistiert den Wald als JSON unter `${data_dir}/ml/isolation_forest.json` (wird beim nächsten Start automatisch geladen). Inferenzen landen in einem Ringpuffer mit 200 Slots, sodass die Registerkarte „Letzte Erkennungen“ im Admin-Panel echten Verkehr widerspiegelt und keine fest codierten Mock-Daten.

Linux (alle gängigen Distributionen), macOS und Windows; sowohl amd64- als auch arm64-Binärdateien werden veröffentlicht. Für die Produktion empfehlen wir, SSLcat unter Linux mit systemd zu betreiben.

Minimum: 512 MB RAM, 100 MB Speicherplatz. Empfohlen: 2 GB RAM, 1 GB Speicherplatz. Für den Bau aus dem Quellcode ist Go 1.21+ erforderlich.

Alle drei. WebSocket wird transparent an den Upstream weitergeleitet; SSE über HTTP/2 / HTTP/3 ist so abgestimmt, dass Write-Timeouts langlaufende Streams nicht beenden können; PHP-Sites laufen über ein FastCGI-Backend.

Das Admin-Panel liest Logs mit begrenztem Tailing (große Protokolldateien werden nie in den Speicher gezogen). Du kannst die konfigurierte Logdatei auch direkt taillen. Über MCP können KI-Clients den Tail mit einer Ressource wie `sslcat://logs/access?since=10m&domain=foo.com&limit=200` abrufen.

SSLcat setzt standardmäßig auf Let's Encrypt – eine kostenlose öffentliche CA, die existiert, um HTTPS zum Standard zu machen. Du kannst weiterhin kommerzielle Zertifikate über `cert_upload` hochladen; SSLcat validiert das Parsen des PEM, die Paarung von Zertifikat und Schlüssel sowie die Abdeckung von CN/SAN.

1) `sslcat doctor --json` führt einen Ein-Klick-Selbsttest über Konfiguration, Ports, Zertifikatsverzeichnis, Site-Roots, Upstreams und MCP-Token-Status aus. 2) `sslcat status --json` gibt Version, Listen-Parameter sowie eine Übersicht über Site / Cert / MCP aus. 3) Lies das Fehlerprotokoll von SSLcat und `${data_dir}/mcp_audit.YYYYMMDD.log`, oder lass die KI sie über die MCP-Tools `error_log_list` / `error_log_tail` lesen (deckt SSLcat selbst sowie jede Proxy- / Static- / PHP-Site ab). 4) `sslcat proxy health-check --domain foo.com --include-routes --json` prüft das Haupt-Backend und jedes PathPrefixRule-Backend parallel. 5) Der Server gibt seine Version über die Response-Header `X-App-Version` / `X-Server-Version` aus, sodass du bestätigen kannst, welches Image den Verkehr tatsächlich bedient.

v2.2.0-rc1 ergänzt CLI-Ops-Befehle: `sslcat status [--json]` (Laufzeitübersicht), `sslcat doctor [--json]` (Selbsttest über Konfiguration / Ports / Zertifikate / Site-Roots / Upstreams / MCP-Token), `sslcat site list/add/update/delete/enable/disable` (CRUD für statische und PHP-Sites – das Löschen erfordert explizit `--yes`) sowie `sslcat proxy health-check [--domain] [--include-routes] [--json]` (TCP-Probe). Globales `-config` kann vor dem Unterbefehl platziert werden. v2.3.0-rc1 ergänzt die MCP-Tools `error_log_list` und `error_log_tail` sowie die Ressourcen `sslcat://logs/error-sources` und `sslcat://logs/error{?id,kind,domain,since,keyword,limit,max_bytes}`, sodass KI-Clients aktuelle Fehler von SSLcat selbst und von einzelnen Sites auflisten und lesen können. Unter der Haube ist `internal/mcp/logview` ein begrenzter Log-Reader (standardmäßig die letzten 1 MB, maximal 4 MB), damit große Protokolldateien den Request-Pfad nicht blockieren können.

Bereits ausgeliefert: vollständige MCP-Integration P1–P5 (v2.1.0), CLI-Ops- und Selbsttest-Befehle (v2.2.0-rc1), MCP-Lesen von Fehlerprotokollen plus der begrenzte Log-Reader (v2.3.0-rc1). Geplant: Kubernetes-Integration, Multi-Cluster-Unterstützung, fortgeschrittene Caching-Strategien, ein Plugin-System und eine GraphQL-API.

MIT. Code, Issues und Releases liegen alle auf GitHub: https://github.com/xurenlu/sslcat . Issues, PRs und zusätzliche Anwendungsfälle unter `docs/` sind sehr willkommen.