---

Zentinel es un proxy inverso de alto rendimiento construido sobre Cloudflare Pingora. Proporciona límites explícitos, comportamiento predecible y valores predeterminados de nivel de producción para entornos donde los operadores necesitan dormir tranquilos.

Rendimiento: La latencia p99 más baja en los benchmarks frente a Envoy, HAProxy, Nginx y Caddy. Pruebas de resistencia de 1M de peticiones con una tasa de éxito del 99.95% y cero fugas de memoria. El motor WAF en Rust puro procesa tráfico limpio a 912K req/s — 30 veces más rápido que la referencia de ModSecurity en C++.

Estado

Núcleo listo para producción (proxy, enrutamiento, TLS, caché, balanceo de carga). Los agentes tienen versionado individual — WAF, Auth y AI Gateway son estables; los demás están en beta o alpha. Consulta zentinelproxy.io/agents para el estado de cada agente.

Flujo de peticiones

   ┌────────┐                                       ┌──────────┐
   │ 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 respuesta recorre la cadena de filtros de vuelta hasta el Cliente. Los logs de acceso y las métricas se emiten al completarse.

El dataplane se ejecuta como un único binario. La lógica de seguridad y políticas que implica mucho parseo o es arriesgada operativamente vive en agentes externos detrás de UDS o gRPC, de modo que un agente defectuoso no puede tumbar el proxy con él. Consulta el Manifiesto para conocer el razonamiento, y crates/proxy/docs/architecture.md para los detalles de cada fase.

Inicio rápido

# 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

En hosts con systemd, el script de instalación también coloca /etc/systemd/system/zentinel.service, un fragmento de sysusers y una configuración inicial en /etc/zentinel/zentinel.kdl. La habilitación y el arranque del servicio son opcionales mediante --enable-service. Consulta crates/proxy/docs/deployment.md.

Guarda esto como zentinel.kdl — hace proxy de localhost:8080 a un backend en el puerto 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

¿Haciendo proxy a un backend HTTPS? Añade un bloque tls al upstream:

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

Sin el bloque tls, Zentinel se conecta con HTTP en texto plano independientemente del puerto.

Más ejemplos: config/examples/ cubre API gateways, balanceo de carga, WebSocket, caché, enrutamiento de inferencia y más. O usa el constructor de configuración para generar una configuración de forma interactiva.

Características

Característica	Descripción
Tipos de servicio	Web, API, Static, Builtin e Inference (LLM/AI)
Balanceo de carga	14 algoritmos: round-robin, weighted, least connections, Maglev, Peak EWMA y más
Seguridad	TLS/mTLS, limitación de tasa, filtrado GeoIP, WAF, protección contra zip bombs
Protocolos agénticos	Conocimiento nativo de MCP y A2A — permitir/denegar por método y por herramienta, resuelto desde el cuerpo JSON-RPC en lugar de confiar en cabeceras replicadas
Protocolo de agentes	Agentes externos para WAF, auth y lógica personalizada — aislados ante fallos, en cualquier lenguaje
Caché HTTP	Caché de respuestas basada en Pingora con prevención de stampede y desalojo LRU (backends en memoria, disco o híbridos)
Proxy WebSocket	Compatible con RFC 6455 con inspección de frames por agente y afinidad de sesión
Observabilidad	Métricas Prometheus, logging estructurado, trazado OpenTelemetry
Recarga en caliente	Actualizaciones de configuración sin tiempo de inactividad mediante SIGHUP con validación e intercambio atómico (rutas, upstreams, agentes; los cambios de listener requieren reinicio)