リクエスト分析
リクエスト分析 は、ゲートウェイを通過した HTTP リクエストをトレンド、性能、流入元、セキュリティの各観点で集計し、調査用の個別ログも保持します。対象はゲートウェイのリクエストログであり、ログインイベントや HTTP ゲートウェイへ入らない元ポートへの接続は含みません。
リクエスト分析 の 分析、ログ、WAF ログ タブで統計、リクエスト詳細、防御イベントを切り替えます。
データ収集を有効にする
システム設定 → ログ でゲートウェイのリクエストログを有効にし、最短 1 日の保持期間を設定します。Go ゲートウェイはデフォルトで実行ディレクトリ内の logs へ日別の構造化 JSON ファイルを書き込み、リクエスト分析 ページはそれらを直接読み取ります。ログを無効にすると新しい分析データは生成されず、保持期間を過ぎて削除されたファイルは過去の分析にも使えません。ストレージ容量と書き込み負荷を考慮して保持日数を設定してください。
ローカルループバック 127.0.0.1 からのリクエストを記録 はデフォルトで無効です。そのため、ローカルのヘルスチェック、同一ホスト上のリバースプロキシ、その他 127.0.0.1 経由でゲートウェイへ入るリクエストは通常一覧に表示されません。ローカルの呼び出し経路を調査するときだけ有効にしてください。この設定はログの記録範囲だけを変更し、ループバック送信元のアクセス権限は変更しません。
書き込みには非同期キューが使用されます。設定ページに累計の破棄件数が表示されている場合は、キューが混雑し、一部のリクエストログがディスクへ書き込まれなかったことを意味します。ゲートウェイに拒否されたリクエストの件数ではありません。ゲートウェイのリバースプロキシに対するレート制限で直接切断されたリクエストも、アクセスログには記録されません。
ログ保存先を変更する
システム設定 → ログ で保存先を入力するか、フォルダーを選択 でゲートウェイからアクセスできるフォルダーを選んで保存します。リクエストログのタブからも設定へ移動できます。実際の保存先とデフォルトの保存先は別々に表示されます。空欄またはデフォルトに戻す操作の後に保存すると、初期の保存先に戻ります。
参照対象はゲートウェイのファイルシステムです。Docker ではコンテナ内のパスなので、先にストレージをマウントします。ログ用の選択画面では静的コンテンツ用の画面が隠す保護ディレクトリも参照できますが、静的サイトとして公開できるわけではありません。保存時にパスと書き込み権限を検証します。失敗時はエラーを確認し、実際の保存先を再取得してください。
変更しても旧ログは移動しません。保存後の検索、分析、保持期限による削除は現在の保存先だけが対象です。旧ディレクトリは別途保管または整理します。メモリ上のディレクトリは再起動で失われます。外部の永続ストレージは内部 FLASH への書き込み削減に役立ちます。保存後は外部からリクエストを送り、保存先と新しいログを確認します。
「分析」タブを使う
今日、直近 7 日、直近 30 日を選択できます。統計はゲートウェイのタイムゾーンで集計され、最大範囲は連続する 30 暦日です。ログの保持日数が短い場合、古い日付のデータは表示されません。
上部にはリクエスト数、ユニーククライアント、5xx エラー率、P95 応答時間、送信トラフィックを表示します。トレンドグラフでは総リクエスト、4xx、5xx を比較し、詳細を次の観点で確認できます。
- リクエスト先：パス、ルート、Host、アップストリーム
- 流入元：Referrer、UTM Source、Medium、Campaign
- 国と地域：重複を除いた有効なクライアント IP から集計
- クライアント：デバイス種別、ブラウザー、OS
- 応答：ステータスコード、メソッド、レイテンシ帯
- 認証とセキュリティ：認証判定、WAF アクション
地域情報は IP ロケーションキャッシュを利用します。初回は解決中または一部のみと表示される場合があるため、地域情報の更新を開始してから再確認してください。分析 API は集計済みの国・地域バケットだけを返し、集計に使ったクライアント IP 一覧はブラウザーへ返しません。破損または不完全なログは統計から除外され、件数が画面に表示されます。
平均、P95、エラー率は傾向の発見に使う指標であり、アップストリームアプリの完全なトレースではありません。異常を見つけたら ログ タブへ切り替え、Host、パス、時刻、ステータスコードから個別リクエストを特定します。
「ログ」タブを使う
1 件の記録を読み取る
| フィールド | 用途 |
|---|---|
| クライアント IP / 接続元 IP | 実際の利用者とゲートウェイの TCP 接続元を比較し、CDN、リバースプロキシ、Docker の経路を調査します |
| メソッド、Host、パス | リクエストがどのサービスに一致したかを判断します |
| ルート種別、アップストリーム | Host／パスルールが正しい転送先に一致したかを判断します。静的レスポンスでは「静的ファイル」または「静的ディレクトリ」と表示され、アップストリームアドレスはありません |
| 認証状態 | セッション、許可リスト、ローカル除外、高度な認証の一時認証情報、未認証のどれによる結果かを判断します |
| サブドメインルールグループ ID / 一時認証情報の状態 | 高度な認証に一致した場合、具体的なルールグループと、1 回限りの許可、発行済み、更新済み、再利用のどの状態かを確認します |
| ステータスコード、処理時間 | ゲートウェイによる拒否、アップストリームのエラー、応答の遅延を区別します |
リクエストログには、アクセスパス、Query、送信元 IP、User-Agent、認証結果、アップストリームアドレスが含まれる場合があります。機密性の高い運用データとして取り扱ってください。トラブルシューティング用の抜粋を共有する前に、トークン、クエリパラメーター、内部アドレス、個人を特定できる情報を削除してください。
静的ファイルとディレクトリのレスポンスは、ゲートウェイがファイルシステムから直接読み取るため、ログのアップストリームは空です。ルートキーは引き続きサービス用 Host で、Trace ID、認証結果、WAF アクション、ステータスコード、処理時間も通常どおり記録されます。サーバーの絶対パスがリクエストログや WAF イベントへ書き込まれることはありません。設定と調査については静的ファイルとディレクトリのレスポンスを参照してください。
推奨する調査手順
- 外部ネットワークから、問題を再現できるリクエストを 1 回送信します。
- 該当する Host とパスを検索し、リクエストがゲートウェイへ到達したかを確認します。
- クライアント IP を照合し、プロキシのアドレスを利用者の IP として誤認していないか確認します。
- 認証状態とアクセスポリシーを確認します。
- その後で、アップストリームの転送先、ステータスコード、アプリ自身のログを確認します。
Trace ID でチェーン全体を確認する
リクエストログ、WAF ログ、システムイベント、通知配信は共通の Trace ID で関連付けられます。リクエスト分析 または イベントセンター の Trace ID 検索、あるいは記録内の Trace ID からフルチェーントレースを開けます。
トレース画面はリクエスト、WAF、システムイベント、通知トリガーと配信を時系列で表示し、各データソースを検出済み、未検出、一時利用不可として示します。一部が失敗しても取得済みデータは表示されます。未検出は、収集が無効、保持期限切れ、古い記録に統一 Trace ID がない場合もあります。
Trace ID はレスポンスヘッダー、ブロックページ、通知にも表示されることがあります。共有前に Host、パス、送信元 IP、アップストリーム、通知内容を確認してください。Trace ID は関連付けキーであり、匿名化済みの公開情報ではありません。
ログにリクエストがまったくない場合は、まずテストトラフィックが 127.0.0.1 から来たか、ループバックログが有効だったかを確認します。ローカルトラフィックを除外した後は、通常、DNS、CDN、トンネル、ルーター、ポート公開のいずれかに問題があります。最初にマッピングルールを変更しないでください。
一部のリクエストだけが欠けている場合は、ゲートウェイのレート制限で接続が直接切断されていないか、ログ設定ページにキューの破棄警告が表示されていないかを確認します。ステータスコードがアップストリームではなくゲートウェイから返されている場合は、認証、公開範囲、WAF、マッピングを続けて確認します。正しいアップストリーム Target が表示されている場合は、アプリ自身のログを調べます。
管理 Cloudflare Tunnel で Pseudo IPv4 → Overwrite Headers を有効にすると、IPv6 訪問者の最初のエッジヘッダーが 240.0.0.0/4 になることがあります。対応版の fn-knock は専用管理入口で CF-Connecting-IPv6 を検証し、「クライアント IP」を実際の公開 IPv6 に復元します。「接続元 IP」は引き続きローカル Tunnel 経路を表します。更新後も Class E アドレスが記録される場合は、手動オリジンを使っていないか、ヘッダーが欠落または重複していないか確認してください。手動オリジンでは Pseudo IPv4 を Off または Add Header にします。回避策として 240.0.0.0/4 を許可リストへ追加しないでください。
サブドメインの高度な認証を有効にした場合、認証結果の サブドメインルールで許可 は、高度な認証によってリクエストが許可されたことを示します。詳細にあるルールグループ ID から、トリガーされた設定を特定できます。1 回限りのリクエスト許可 は、ルールに一致したものの永続的な許可が作成されなかった状態で、初回の Cookie Probe、Cookie を保存しないクライアント、WebSocket Upgrade、永続化のフォールバックでよく発生します。発行済み は今回永続的な許可が作成された状態、更新済み はアイドル有効期間が更新された状態、再利用 は既存の許可が引き続き使われた状態です。ルールの動作については、サブドメインの高度な認証を参照してください。
不審な IP への対処
実際の攻撃元であることを確認したら、ログから共通ブラックリストまたは IP 許可リストの操作へ移動できます。操作前に、共有の送信元と前段プロキシのアドレスではないことを確認し、日時、Host、パスなどの前後関係を記録してください。