Statistiques de la porte de proxy
La porte tient ses propres statistiques, séparées des statistiques de vérification d'une clé de site. La page de vérification répond "les vraies personnes passent-elles le jeu ?" ; cette page répond à une question plus étroite : "à quelle fréquence la porte défie-t-elle les visiteurs plutôt que de laisser passer un visiteur dégagé ?" C'est ainsi que tu confirmes que la porte est câblée et réglée, et c'est la même surface sur laquelle le mode aperçu écrit pendant que tu testes encore.
Où elle vit
Il y a deux vues :
- Par clé de site : la page Statistiques proxy sous une clé de site, pour une origine protégée.
- Par équipe : la page Statistiques proxy au niveau de l'équipe, agrégée sur chaque clé de site de l'équipe.
Les deux ont besoin du plan Alpha ou supérieur ; en dessous, la page montre une carte de mise à niveau à la place.
Les quatre comptes
Chaque décision de la porte est notée comme l'une de quatre sortes :
- Passage direct : une requête est arrivée avec un laissez-passer valide et a été autorisée. C'est la condition de victoire ; un visiteur dégagé qui parcourt le site en génère.
- Défi affiché : une requête n'avait pas de laissez-passer valide, donc le visiteur a été envoyé au jeu.
- Laissez-passer émis : un visiteur a résolu le jeu et un laissez-passer a été frappé (le callback a ensuite posé le cookie).
- Refusé : l'autorisateur a rejeté la requête sous une politique fail-closed alors qu'il ne pouvait pas confirmer de laissez-passer.
Le ratio de passage direct sur défi
Le chiffre phare, c'est le passage direct relatif aux défis. Une fois que les visiteurs dégagent la porte, la plupart de leurs requêtes devraient être du passage direct, avec un défi seulement au début d'une visite ou après qu'un laissez-passer expire. Un ratio de passage direct élevé veut dire que ta TTL de laissez-passer fait son travail, une seule résolution achète beaucoup de requêtes. Si les défis restent élevés relativement au passage direct, la TTL est peut-être trop courte (visiteurs re-défiés en milieu de session) ou le cookie n'est pas posé (vérifie le callback).
La lire pendant le déploiement
Tant que le mode aperçu est actif, guette la séquence dans une seule visite de test : un challenge_served (pas encore de cookie), puis un pass_issued après que tu résous, puis passthrough qui grimpe pendant que tu recharges. Des défis manquants veulent dire que le bloc de l'autorisateur n'est pas atteint ; un pass_issued qui ne devient jamais du passage direct veut dire que le cookie ne tient pas.
Rétention
L'historique est retenu par palier de plan et les buckets plus anciens sont élagués selon un calendrier quotidien, donc la fenêtre sur laquelle tu peux regarder en arrière s'élargit avec ton plan. Le ratio en direct et l'activité récente sont toujours disponibles.
Ce qui n'est pas ici
- Pas de passages directs en fail-open depuis ton proxy. Quand ton proxy est configuré en fail-open et que Caputchin est injoignable, le proxy laisse passer la requête de lui-même ; Caputchin ne la voit jamais, donc elle ne peut pas être comptée ici.
- Pas de données par visiteur. Des comptes seulement, pas d'IP, pas d'user agent, pas de contenu de requête, en accord avec la posture de confidentialité de Caputchin.
Voir aussi
- Vue d'ensemble : ce qu'est la porte et le cookie de laissez-passer.
- Configurer la porte de proxy : le mode aperçu écrit sur cette surface avant que tu passes en direct.
- Statistiques de vérification hébergée : la surface équivalente pour l'option sans backend.