プロキシゲートの統計

ゲートは自分の統計を、サイトキーの 認証統計 とは別に保ちます。認証ページは「本物の人がゲームを通れているか？」に答えます。このページはより狭い問いに答えます。「ゲートが訪問者にチャレンジを出すのは、通過許可のある訪問者を通すのに対してどれくらいの頻度か？」ゲートが配線され調整されていることを確かめる手段であり、まだテスト中の間に プレビューモード が書き込むのと同じサーフェスです。

どこにあるか

ビューは二つあります：

• サイトキーごと：サイトキーの下の プロキシ統計 ページ、ゲートをかけた一つのオリジン向け。
• チームごと：チーム階層の プロキシ統計 ページ、チーム内の各サイトキーにわたって集計。

どちらも Alpha プラン以上が要ります。それ未満では、ページは代わりにアップグレードカードを表示します。

四つのカウント

ゲートの判断はどれも、四種のうちの一つとして記録されます：

• パススルー：リクエストが有効なパスを携えて到着し、許可されました。これが勝利条件です。通過許可のある訪問者がサイトを閲覧すると、これらが生まれます。
• チャレンジ表示：リクエストに有効なパスがなかったので、訪問者はゲームへ送られました。
• パス発行：訪問者がゲームを解き、パスが鋳造されました（それからコールバックが Cookie をセットしました）。
• 拒否：オーソライザーが、パスを確認できない間、fail-closed のポリシーの下でリクエストを拒みました。

パススルー対チャレンジの比

見出しの数字は、チャレンジに対するパススルーです。訪問者がゲートを通過するようになれば、そのリクエストのほとんどは パススルー であるべきで、チャレンジは訪問の初めか、パスが切れた後だけになります。高いパススルー比は、あなたの 通過許可 TTL が仕事をしていること、一度の解答が多くのリクエストを買っていることを意味します。チャレンジがパススルーに対して高いままなら、TTL が短すぎるか（訪問者がセッションの途中で再チャレンジされる）、Cookie がセットされていない（コールバックを確認）かもしれません。

ロールアウト中に読む

プレビューモードがオンの間、一度のテスト訪問で次の並びを見張ってください。まず challenge_served が一つ（まだ Cookie なし）、次に解いた後に pass_issued、そして再読み込みするにつれ passthrough が上っていきます。チャレンジが欠けているのは、オーソライザーのブロックが当たっていない意味です。パススルーに決してならない pass_issued は、Cookie が定着していない意味です。

保持

履歴はプラン階層ごとに保持され、古いバケットは日次のスケジュールで刈られるので、遡って見られる窓はプランとともに広がります。ライブの比と直近の活動は常に利用できます。

ここにないもの

• あなたのプロキシからの fail-open のパススルーはなし。 あなたのプロキシが fail-open に設定され、Caputchin が到達できないとき、プロキシは自分でリクエストを通します。Caputchin はそれを決して見ないので、ここでは数えられません。
• 訪問者ごとのデータはなし。 カウントだけで、IP も、ユーザーエージェントも、リクエストの内容もなく、Caputchin のプライバシーの姿勢に沿っています。

あわせて読む

• 概要：ゲートとは何か、そして通過許可 Cookie。
• プロキシゲートを設定する：プレビューモードは、本番にする前にこのサーフェスに書き込みます。
• ホスト型認証の統計：バックエンドなしの選択肢のための、対応するサーフェス。