---

Zentinel è un reverse proxy ad alte prestazioni basato su Cloudflare Pingora. Fornisce limiti espliciti, comportamento prevedibile e default di livello produttivo per ambienti in cui gli operatori hanno bisogno di dormire sonni tranquilli.

Prestazioni: Latenza p99 più bassa nei benchmark rispetto a Envoy, HAProxy, Nginx e Caddy. Test di soak da 1M di richieste con un tasso di successo del 99,95% e zero memory leak. Il motore WAF in puro Rust elabora traffico pulito a 912K req/s — 30 volte più veloce del riferimento C++ ModSecurity.

Stato

Core pronto per la produzione (proxy, routing, TLS, caching, load balancing). Gli agenti sono versionati individualmente — WAF, Auth e AI Gateway sono stabili; gli altri sono in beta o alpha. Consulta zentinelproxy.io/agents per lo stato di ciascun agente.

Flusso delle richieste

   ┌────────┐                                       ┌──────────┐
   │ 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                     ║
          ╚════════════════════════════════════════════════════╝

La risposta ripercorre la catena di filtri a ritroso fino al Client. I log di accesso e le metriche vengono emessi al completamento.

Il dataplane viene eseguito come singolo binario. La logica di sicurezza e policy che è intensiva nell'elaborazione o rischiosa dal punto di vista operativo risiede in agenti esterni dietro UDS o gRPC, così un agente difettoso non può abbattere il proxy insieme a sé. Consulta il Manifesto per le motivazioni e crates/proxy/docs/architecture.md per i dettagli fase per fase.

Avvio rapido

# 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

Sui sistemi con systemd lo script di installazione deposita anche /etc/systemd/system/zentinel.service, uno snippet sysusers e una configurazione iniziale in /etc/zentinel/zentinel.kdl. L'abilitazione e l'avvio del servizio sono opt-in tramite --enable-service. Consulta crates/proxy/docs/deployment.md.

Salva questo come zentinel.kdl — inoltra localhost:8080 a un backend sulla porta 8081:

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

Devi inoltrare verso un backend HTTPS? Aggiungi un blocco tls all'upstream:

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

Senza il blocco tls, Zentinel si connette con HTTP in chiaro indipendentemente dalla porta.

Altri esempi: config/examples/ copre API gateway, load balancing, WebSocket, caching, routing per inferenza e altro ancora. Oppure usa il config builder per generare una configurazione in modo interattivo.

Funzionalità

Funzionalità	Descrizione
Tipi di servizio	Web, API, Static, Builtin e Inference (LLM/AI)
Load Balancing	14 algoritmi: round-robin, weighted, least connections, Maglev, Peak EWMA e altri
Sicurezza	TLS/mTLS, rate limiting, filtraggio GeoIP, WAF, protezione zip bomb
Protocolli agentici	Consapevolezza nativa di MCP e A2A — allow/deny per metodo e per tool, risolti dal corpo JSON-RPC invece di fidarsi degli header rispecchiati
Protocollo agent	Agenti esterni per WAF, auth e logica personalizzata — isolati dai crash, in qualsiasi linguaggio
Caching HTTP	Caching delle risposte basato su Pingora con prevenzione delle stampede ed eviction LRU (backend in memoria, su disco o ibridi)
Proxying WebSocket	Conforme a RFC 6455 con ispezione dei frame da parte degli agenti e affinità di sessione
Osservabilità	Metriche Prometheus, logging strutturato, tracing OpenTelemetry
Hot Reload	Aggiornamenti di configurazione senza downtime tramite SIGHUP con validazione e swap atomico (route, upstream, agenti; le modifiche ai listener richiedono un riavvio)

Consulta il dettaglio completo delle funzionalità su zentinelproxy.io/features.

Casi d'uso