リクエストログ
リクエストログには、ゲートウェイを通過した HTTP リクエストが記録されます。リクエストが fn-knock へ到達したか、どの Host またはパスに一致したか、最終的にどこへ転送されたかを確認できます。ログインログではなく、ゲートウェイへ入らなかった元のポートへの接続も記録されません。
システム設定 → ログ でゲートウェイのリクエストログを有効にし、保持期間を設定します。最短の保持期間は 1 日です。Go ゲートウェイは、実行ディレクトリ内の logs ディレクトリへ、日別の構造化 JSON ファイルを書き込みます。管理画面の リクエストログ ページでは、日付ごとにログを読み込み、検索して詳細を表示できます。ログの記録にはストレージ容量と書き込み処理が必要になるため、トラブルシューティングの完了後は実際の用途に応じた期間だけ保持してください。
ローカルループバック 127.0.0.1 からのリクエストを記録 はデフォルトで無効です。そのため、ローカルのヘルスチェック、同一ホスト上のリバースプロキシ、その他 127.0.0.1 経由でゲートウェイへ入るリクエストは通常一覧に表示されません。ローカルの呼び出し経路を調査するときだけ有効にしてください。この設定はログの記録範囲だけを変更し、ループバック送信元のアクセス権限は変更しません。
書き込みには非同期キューが使用されます。設定ページに累計の破棄件数が表示されている場合は、キューが混雑し、一部のリクエストログがディスクへ書き込まれなかったことを意味します。ゲートウェイに拒否されたリクエストの件数ではありません。ゲートウェイのリバースプロキシに対するレート制限で直接切断されたリクエストも、アクセスログには記録されません。
1 件の記録を読み取る
| フィールド | 用途 |
|---|---|
| クライアント IP / 接続元 IP | 実際の利用者とゲートウェイの TCP 接続元を比較し、CDN、リバースプロキシ、Docker の経路を調査します |
| メソッド、Host、パス | リクエストがどのサービスに一致したかを判断します |
| ルート種別、アップストリーム | Host／パスルールが正しい転送先に一致したかを判断します |
| 認証状態 | セッション、許可リスト、ローカル除外、高度な認証の一時認証情報、未認証のどれによる結果かを判断します |
| サブドメインルールグループ ID / 一時認証情報の状態 | 高度な認証に一致した場合、具体的なルールグループと、1 回限りの許可、発行済み、更新済み、再利用のどの状態かを確認します |
| ステータスコード、処理時間 | ゲートウェイによる拒否、アップストリームのエラー、応答の遅延を区別します |
リクエストログには、アクセスパス、Query、送信元 IP、User-Agent、認証結果、アップストリームアドレスが含まれる場合があります。機密性の高い運用データとして取り扱ってください。トラブルシューティング用の抜粋を共有する前に、トークン、クエリパラメーター、内部アドレス、個人を特定できる情報を削除してください。
推奨する調査手順
- 外部ネットワークから、問題を再現できるリクエストを 1 回送信します。
- 該当する Host とパスを検索し、リクエストがゲートウェイへ到達したかを確認します。
- クライアント IP を照合し、プロキシのアドレスを利用者の IP として誤認していないか確認します。
- 認証状態とアクセスポリシーを確認します。
- その後で、アップストリームの転送先、ステータスコード、アプリ自身のログを確認します。
ログにリクエストがまったくない場合は、まずテストトラフィックが 127.0.0.1 から来たか、ループバックログが有効だったかを確認します。ローカルトラフィックを除外した後は、通常、DNS、CDN、トンネル、ルーター、ポート公開のいずれかに問題があります。最初にマッピングルールを変更しないでください。
一部のリクエストだけが欠けている場合は、ゲートウェイのレート制限で接続が直接切断されていないか、ログ設定ページにキューの破棄警告が表示されていないかを確認します。ステータスコードがアップストリームではなくゲートウェイから返されている場合は、認証、公開範囲、WAF、マッピングを続けて確認します。正しいアップストリーム Target が表示されている場合は、アプリ自身のログを調べます。
サブドメインの高度な認証を有効にした場合、認証結果の サブドメインルールで許可 は、高度な認証によってリクエストが許可されたことを示します。詳細にあるルールグループ ID から、トリガーされた設定を特定できます。1 回限りのリクエスト許可 は、ルールに一致したものの永続的な許可が作成されなかった状態で、初回の Cookie Probe、Cookie を保存しないクライアント、WebSocket Upgrade、永続化のフォールバックでよく発生します。発行済み は今回永続的な許可が作成された状態、更新済み はアイドル有効期間が更新された状態、再利用 は既存の許可が引き続き使われた状態です。ルールの動作については、サブドメインの高度な認証を参照してください。
不審な IP への対処
実際の攻撃元であることを確認したら、ログから共通ブラックリストまたは IP 許可リストの操作へ移動できます。操作前に、共有の送信元と前段プロキシのアドレスではないことを確認し、日時、Host、パスなどの前後関係を記録してください。