Estadísticas de la puerta de proxy
La puerta lleva sus propias estadísticas, separadas de las estadísticas de verificación de una clave de sitio. La página de verificación responde "¿la gente real está pasando el juego?"; esta página responde una pregunta más estrecha: "¿con qué frecuencia la puerta está retando a los visitantes frente a dejar pasar a un visitante despejado?" Es como confirmas que la puerta está cableada y afinada, y es la misma superficie a la que escribe el modo vista previa mientras aún estás probando.
Dónde vive
Hay dos vistas:
- Por clave de sitio: la página Estadísticas de proxy bajo una clave de sitio, para un origen con puerta.
- Por equipo: la página Estadísticas de proxy a nivel de equipo, agregada a través de cada clave de sitio en el equipo.
Ambas necesitan el plan Alpha o superior; por debajo de eso la página muestra una tarjeta de mejora en su lugar.
Los cuatro conteos
Cada decisión de la puerta se registra como una de cuatro clases:
- Paso libre: una petición llegó con un pase válido y fue permitida. Esta es la condición de victoria; un visitante despejado navegando el sitio genera estas.
- Reto mostrado: una petición no tenía un pase válido, así que el visitante fue enviado al juego.
- Pase emitido: un visitante resolvió el juego y se acuñó un pase (el callback luego fijó la cookie).
- Denegado: el autorizador rechazó la petición bajo una política de fallo cerrado mientras no podía confirmar un pase.
La razón de paso libre frente a reto
El número principal es el paso libre relativo a los retos. Una vez que los visitantes despejan la puerta, la mayoría de sus peticiones deberían ser paso libre, con un reto solo al inicio de una visita o después de que un pase expira. Una razón de paso libre alta significa que tu TTL de paso libre está haciendo su trabajo, una sola resolución está comprando muchas peticiones. Si los retos se mantienen altos relativos al paso libre, el TTL puede ser demasiado corto (visitantes re-retados a media sesión) o la cookie no se está fijando (revisa el callback).
Leyéndolo durante el despliegue
Mientras el modo vista previa está encendido, vigila la secuencia en una sola visita de prueba: un challenge_served (aún sin cookie), luego un pass_issued después de que resuelves, luego passthrough subiendo mientras recargas. Retos ausentes significan que el bloque del autorizador no se está alcanzando; un pass_issued que nunca se convierte en paso libre significa que la cookie no se está pegando.
Retención
El historial se retiene por nivel de plan y los buckets más viejos se podan en un horario diario, así la ventana sobre la que puedes mirar atrás se ensancha con tu plan. La razón en vivo y la actividad reciente están siempre disponibles.
Qué no está aquí
- Sin pasos libres por modo-fallo-abierto desde tu proxy. Cuando tu proxy está configurado en fallo abierto y Caputchin es inalcanzable, el proxy deja pasar la petición por su cuenta; Caputchin nunca la ve, así que no se puede contar aquí.
- Sin datos por visitante. Solo conteos, ni IP, ni user agent, ni contenidos de la petición, en línea con la postura de privacidad de Caputchin.
Véase también
- Panorama: qué es la puerta y la cookie de paso libre.
- Configura la puerta de proxy: el modo vista previa escribe a esta superficie antes de que salgas en vivo.
- Estadísticas de verificación alojada: la superficie equivalente para la opción sin backend.