---

Zentinel ist ein hochperformanter Reverse-Proxy, der auf Cloudflare Pingora aufbaut. Er bietet explizite Limits, vorhersehbares Verhalten und produktionsreife Standardeinstellungen für Umgebungen, in denen Betreiber ruhig schlafen müssen.

Performance: Niedrigste p99-Latenz in Benchmarks im Vergleich zu Envoy, HAProxy, Nginx und Caddy. 1M-Request-Soak-Tests mit 99,95 % Erfolgsrate und ohne Speicherlecks. Die reine Rust-WAF-Engine verarbeitet sauberen Traffic mit 912K req/s — 30x schneller als die C++-Referenz ModSecurity.

Status

Produktionsreifer Kern (Proxy, Routing, TLS, Caching, Load Balancing). Agents werden einzeln versioniert — WAF, Auth und AI Gateway sind stabil; andere sind Beta oder Alpha. Siehe zentinelproxy.io/agents für den Status pro Agent.

Request-Flow

   ┌────────┐                                       ┌──────────┐
   │ Client │                                       │ Upstream │
   └────┬───┘                                       └─────▲────┘
        │                                                 │
        ▼                                                 │
   ╔═══════════ Zentinel (core, single binary) ══════════╤════╗
   ║                                                     │    ║
   ║  Listener ─▶ Routing ─▶ Filter chain ─▶ Forward ────┘    ║
   ║  TLS, H2     priority   rate-limit,     LB,              ║
   ║              + LRU      cache, hooks    retries          ║
   ║                              │                           ║
   ╚══════════════════════════════╪═══════════════════════════╝
                                  │ UDS / gRPC (v2 agent protocol)
                                  ▼
          ╔═══════ External agents (separate processes) ═══════╗
          ║   WAF · Auth · Rate-limit · …                      ║
          ║   crash-isolated, any language                     ║
          ╚════════════════════════════════════════════════════╝

Die Antwort durchläuft die Filterkette zurück zum Client. Access-Logs und Metriken werden bei Abschluss ausgegeben.

Die Dataplane läuft als einzelne Binary. Sicherheits- und Richtlinienlogik, die parse-intensiv oder betrieblich riskant ist, lebt in externen Agents hinter UDS oder gRPC, sodass ein fehlerhafter Agent den Proxy nicht mitreißen kann. Siehe das Manifest für die Begründung und crates/proxy/docs/architecture.md für die Details pro Phase.

Schnellstart

# Install (binary only)
curl -fsSL https://get.zentinelproxy.io | sh

# Install and start as a systemd service (Linux, root or sudo)
curl -fsSL https://get.zentinelproxy.io | sh -s -- --enable-service

# Or via Cargo
cargo install zentinel-proxy

# Or via Docker
docker run -v $(pwd)/zentinel.kdl:/etc/zentinel/zentinel.kdl \
  ghcr.io/zentinelproxy/zentinel --config /etc/zentinel/zentinel.kdl

Auf systemd-Hosts legt das Installationsskript außerdem /etc/systemd/system/zentinel.service, ein sysusers-Snippet und eine Startkonfiguration unter /etc/zentinel/zentinel.kdl ab. Das Aktivieren und Starten des Dienstes erfolgt optional über --enable-service. Siehe crates/proxy/docs/deployment.md.

Speichere dies als zentinel.kdl — es leitet localhost:8080 an ein Backend auf Port 8081 weiter:

system {
    worker-threads 0  // auto-detect CPU cores
}

listeners {
    listener "http" {
        address "0.0.0.0:8080"
        protocol "http"
    }
}

routes {
    route "default" {
        matches {
            path-prefix "/"
        }
        upstream "backend"
    }
}

upstreams {
    upstream "backend" {
        target "127.0.0.1:8081"
    }
}

# Run
zentinel --config zentinel.kdl

# Validate config without starting
zentinel test --config zentinel.kdl

Weiterleitung an ein HTTPS-Backend? Füge einen tls-Block zum Upstream hinzu:

upstreams {
    upstream "backend" {
        target "api.example.com:443"
        tls {
            sni "api.example.com"
        }
    }
}

Ohne den tls-Block verbindet sich Zentinel unabhängig vom Port mit Klartext-HTTP.

Weitere Beispiele: config/examples/ deckt API-Gateways, Load Balancing, WebSocket, Caching, Inference-Routing und mehr ab. Oder nutze den Config-Builder, um interaktiv eine Konfiguration zu erzeugen.

Funktionen

Funktion	Beschreibung
Service-Typen	Web, API, Static, Builtin und Inference (LLM/AI)
Load Balancing	14 Algorithmen: Round-Robin, Weighted, Least Connections, Maglev, Peak EWMA und mehr
Sicherheit	TLS/mTLS, Rate Limiting, GeoIP-Filterung, WAF, Zip-Bomb-Schutz
Agentische Protokolle	Native MCP- und A2A-Unterstützung — Allow/Deny pro Methode und pro Tool, aufgelöst aus dem JSON-RPC-Body statt durch Vertrauen auf gespiegelte Header
Agent-Protokoll	Externe Agents für WAF, Auth und benutzerdefinierte Logik — crash-isoliert, jede Sprache
HTTP-Caching	Pingora-basiertes Response-Caching mit Stampede-Prävention und LRU-Eviction (Memory-, Disk- oder Hybrid-Backends)
WebSocket-Proxying	RFC 6455-konform mit Agent-Inspektion pro Frame und Session-Affinität
Observability	Prometheus-Metriken, strukturiertes Logging, OpenTelemetry-Tracing
Hot Reload	Zero-Downtime-Konfigurationsupdates via SIGHUP mit Validierung und atomarem Austausch (Routen, Upstreams, Agents; Listener-Änderungen erfordern einen Neustart)

Siehe die vollständige Funktionsübersicht unter zentinelproxy.io/features.

Anwendungsfälle