
Un proxy inverse axé sur la sécurité, conçu pour protéger le web libre.
Un proxy inverse axé sur la sécurité, conçu pour protéger le web libre.
Des opérations sereines en périphérie.
Documentation • Playground • Benchmarks • Discussions • Contributing
Zentinel est un proxy inverse haute performance construit sur Cloudflare Pingora. Il offre des limites explicites, un comportement prévisible et des valeurs par défaut de qualité production pour les environnements où les opérateurs ont besoin de dormir tranquilles.
Performance : la latence p99 la plus faible dans les benchmarks face à Envoy, HAProxy, Nginx et Caddy. Tests de résistance de 1 M de requêtes avec un taux de réussite de 99,95 % et aucune fuite mémoire. Le moteur WAF en Rust pur traite le trafic propre à 912 K req/s — 30 fois plus rapide que la référence C++ ModSecurity.
Cœur prêt pour la production (proxy, routage, TLS, mise en cache, équilibrage de charge). Les agents sont versionnés individuellement — WAF, Auth et AI Gateway sont stables ; les autres sont en bêta ou alpha. Consultez zentinelproxy.io/agents pour le statut de chaque agent.
┌────────┐ ┌──────────┐
│ 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 réponse retrace la chaîne de filtres jusqu'au Client. Les journaux d'accès et les métriques sont émis à la fin.
Le plan de données s'exécute comme un binaire unique. La logique de sécurité et de politique, gourmande en analyse syntaxique ou risquée sur le plan opérationnel, réside dans des agents externes derrière UDS ou gRPC, afin qu'un agent défectueux ne puisse pas entraîner le proxy dans sa chute. Consultez le Manifeste pour le raisonnement, et crates/proxy/docs/architecture.md pour les détails par phase.
# 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
Sur les hôtes systemd, le script d'installation dépose également /etc/systemd/system/zentinel.service, un extrait sysusers et une configuration de démarrage dans /etc/zentinel/zentinel.kdl. L'activation et le démarrage du service sont optionnels via --enable-service. Consultez crates/proxy/docs/deployment.md.
Enregistrez ceci sous zentinel.kdl — il fait proxy de localhost:8080 vers un backend sur le port 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
Vous faites proxy vers un backend HTTPS ? Ajoutez un bloc tls à l'upstream :
upstreams {
upstream "backend" {
target "api.example.com:443"
tls {
sni "api.example.com"
}
}
}
Sans le bloc tls, Zentinel se connecte en HTTP en clair quel que soit le port.
Plus d'exemples : config/examples/ couvre les passerelles API, l'équilibrage de charge, WebSocket, la mise en cache, le routage d'inférence, et plus encore. Ou utilisez le générateur de configuration pour générer une configuration de manière interactive.