プロキシのページゲートの統計
ゲートは自分の統計を、サイトキーの 認証統計 とは別に保ちます。認証ページは「本物の人がゲームを通れているか？」に答えます。このページはより狭い問いに答えます。「ゲートが訪問者にチャレンジを出すのは、通過許可のある訪問者を通すのに対してどれくらいの頻度か？」ゲートが配線され調整されていることを確かめる手段であり、まだテスト中の間に プレビューモード が書き込むのと同じサーフェスです。
どこにあるか
ビューは二つあります：
- サイトキーごと：サイトキーの下の プロキシ統計 ページ、ゲートをかけた一つのオリジン向け。
- チームごと：チーム階層の プロキシ統計 ページ、チーム内の各サイトキーにわたって集計。
どちらも Alpha プラン以上が要ります。それ未満では、ページは代わりにアップグレードカードを表示します。
四つのカウント
ゲートの判断はどれも、四種のうちの一つとして記録されます：
- パススルー：リクエストが有効なパスを携えて到着し、許可されました。これが勝利条件です。通過許可のある訪問者がサイトを閲覧すると、これらが生まれます。
- チャレンジ表示：リクエストに有効なパスがなかったので、訪問者は検証へ送られました。
- パス発行：訪問者が検証を済ませ、パスが鋳造されました（それからコールバックが Cookie をセットしました）。
- 拒否：有効でないパスを携えたリクエストが到着しました。期限切れ、改ざん、または別のサイトキー向けに発行されたものです。Cookie をまったく持たない初回の訪問はここには 数えません。それはチャレンジとして現れます。
パススルー対チャレンジの比
見出しの数字は、チャレンジに対するパススルーです。訪問者がゲートを通過するようになれば、そのリクエストのほとんどは パススルー であるべきで、チャレンジは訪問の初めか、パスが切れた後だけになります。高いパススルー比は、通過許可 TTL が仕事をしていること、一度の解答が多くのリクエストを買っていることを意味します。チャレンジがパススルーに対して高いままなら、TTL が短すぎるか（訪問者がセッションの途中で再チャレンジされる）、Cookie がセットされていない（コールバックを確認）かもしれません。
ロールアウト中に読む
プレビューモードがオンの間、一度のテスト訪問で次の並びを見張ってください。まず challenge_served が一つ（まだ Cookie なし）、次に検証を通った後に pass_issued、そして再読み込みするにつれ passthrough が上っていきます。チャレンジが欠けているのは、オーソライザーのブロックが当たっていない意味です。パススルーに決してならない pass_issued は、Cookie が定着していない意味です。
カウントは近いが、正確ではない
ゲートの結果は書き込まれる前にまとめられるので、エッジが一秒の途中でリサイクルされると、カウンターがいくつかのイベントを落とすことがあります。比と傾向は信頼できます。個々のカウントは正確というより、とても近い値として扱ってください。とくに静かなサイトではそうです。
保持
履歴はプラン階層ごとに保持され、古いバケットは日次のスケジュールで刈られるので、遡って見られる窓はプランとともに広がります。ライブの比と直近の活動は常に利用できます。
ここにないもの
- プロキシからのフェイルモードのパススルーもブロックもなし。 fail-open と fail-closed は、Caputchin に到達できないときにプロキシが下す判断です。Caputchin はそれらのリクエストを決して見ないので、どちらの結果もここには、どの列にも現れません。
- 訪問者ごとのデータはなし。 カウントだけで、IP も、ユーザーエージェントも、リクエストの内容もなく、Caputchin のプライバシーの姿勢に沿っています。
あわせて読む
- 概要：ゲートとは何か、そして通過許可 Cookie。
- プロキシのページゲートを設定する：プレビューモードは、本番にする前にこのサーフェスに書き込みます。
- ホスト型認証の統計：バックエンドなしの選択肢のための、対応するサーフェス。