エージェントレスポンスコードのトラブルシューティング
- English
- 日本語
リクエスト処理中に異常が発生した場合、Next-Gen WAF エージェントは、問題解決に活用できるエラーエージェントのレスポンスコード (-2、-1、499など) を返します。
-2、-1、および 0 のエージェントレスポンスコードのトラブルシューティング
-2、-1、および 0 のエージェントレスポンスコードは、正しく処理されなかったリクエストに適用されるエラーコードです。これが発生する理由はいくつかありますが、主に 2つのカテゴリーに分類されます。
投稿またはレスポンスがリクエストと一致しなかった
モジュールがエージェントからのレスポンス待機中にタイムアウトした
リクエストとレスポンスが一致しない
エラーエージェントレスポンスコードは、投稿もしくはレスポンスが実際のリクエストに一致しない場合に発生する可能性があります。これは通常、リクエストが Next-Gen WAF モジュールに渡される前に NGINX がリダイレクトした結果です。
特定のサーバーレスポンスコード
次のサーバーレスポンスコードにより、NGINX は通常実行されるフェーズをスキップします。その性質上、NGINX はリクエストを Next-Gen WAF モジュールに渡されずに処理を終了させます。
400 (Bad Request)
405 (Not Allowed)
408 (Request Timeout)
413 (Request Entity Too Large)
414 (Request URI Too Large)
494 (Request Headers Too Large)
499 (Client Closed Request)
500 (Internal Server Error)
501 (Not Implemented)
NGINX の return ディレクティブを探す
カスタム NGINX 設定や Lua コードがリクエストをリダイレクトしている可能性があるか確認してください。これはほとんどの場合、NGINX の設定ファイル内の return ディレクティブによるものです。特定のページを return ディレクティブを使用して、www、https、もしくは新しい URL にリダイレクトすることができます。return ディレクティブはすべての処理を停止し、リクエストが Next-Gen WAF モジュールによって処理されないようにします。例 :
location /oldurl { return 302 https://example.com/newurl/}これらは、リクエストが最初に Fastly のエージェントによって処理されるよう更新する必要があります。rewrite_by_lua_block を直接呼び出すことにより、Next-Gen WAF モジュールを最初に実行し、その後、 NGINX の return ステートメントを実行することができます。
location /oldurl { rewrite_by_lua_block { sigsci.prerequest() return ngx.exit(302 "https://example.com/newurl/") } #return 302 https://example.com/newurl/}エージェントが再起動した
リクエストとレスポンスの不一致は、エージェントの再起動が原因である場合もあります。リクエストが処理された後、レスポンスが処理される前にエージェントが再起動された場合、エージェントはレスポンスを確認できず、リクエストへの紐づけができません。その結果、エラーエージェントレスポンスコードが発生します。
モジュールのタイムアウト
モジュールがリクエストを受信すると、それを処理のためにエージェントに送信します。モジュールはその後、エージェントからの応答 (ブロックするか否か) を一定時間待機します (通常100ミリ秒)。エージェントがその時間内にリクエストを処理しない場合、モジュールはタイムアウトし、デフォルトでフェイルオープンとなり、リクエストを許可します。これらの失敗したオープン状態のリクエストには、エラーエージェントレスポンスコードが適用されます。
モジュールのタイムアウトは、ほとんどの場合、エージェントに割り当てられたリソースが不足していることが原因です。これは、エージェントの CPU コア数が少なすぎるなど、ホストまたはエージェントの設定ミスが原因である可能性があります。
これは、ホストへのトラフィック量が多いことが原因である可能性もあります。エージェントが処理できるよりも早くリクエストが届いた場合、それ以降のリクエストは処理待ちになります。キューに入れられたリクエストがタイムアウト制限に達すると、モジュールはフェイルオープンし、リクエストを許可します。
同様に、ペネトレーションテスト用に特別に設計された特定のルールは、従来のルールよりも実行に時間がかかる場合があります。これにより、リクエストごとの処理時間が長くかかるため、リクエストがキューに蓄積され、タイムアウトが発生する可能性があります。
レスポンス時間を確認する
タイムアウトするリクエストは応答時間が長くなり、デフォルトのタイムアウト値である 100ミリ秒を超過します。
エージェントの指標を確認する
[Agents (エージェント)] ページからは、各エージェントの指標にアクセスできます。これらの指標は、問題の診断に役立ちます。
切断された接続数
接続切断ドロップ指標は、通過を許可された (または「ドロップされた」) リクエスト数を示します。
CPU 使用率
CPU の指標は、ホストが過負荷状態にあり、リクエストを十分に迅速に処理できないことを示します。
ホスト CPU 指標は、すべてのコアの総 CPU 使用率を示します (100%が最大値)。
エージェント CPU 指標は、エージェントが使用しているコア数に対する総 CPU 使用率を示します。たとえば、エージェントが4個のコアを使用している場合、最大値は400%となります。
CPU 割り当てとコンテナ化
コンテナ内で実行されるエージェントには既知の問題があります。cgroups 機能によってコンテナに割り当てられる CPU (コア) 数が少ないため、エージェントがリクエストを処理するのに十分な CPU リソースを持たない可能性があります。
エージェントを実行するコンテナには、少なくとも1個の CPU を割り当てることを推奨します。NGINX とエージェントの両方が同じコンテナで実行されている場合、少なくとも1.5個の CPU を割り当てることを推奨します。
499 エージェントレスポンスコードおよび 504 HTTP ステータスコードのトラブルシューティング
クライアントがリクエストを行い、Cloud WAF アプリケーションロードバランサー (ALB) が TCP 接続確立後60秒以内に最初のヘッダーバイトを受信しない場合、リクエストを行ったクライアントは 504 を受け取り、Next-Gen WAF エージェントは 499. で応答します。これは、リクエストを行ったクライアントがブラウザを通じて長時間のリクエストを行っている場合、ブラウザで 504 エラーを受け取り、コンソールにはリクエストに対して 499 が表示されることを意味します。
長期間使われてきたリクエストは、60秒のしきい値を満たすように最適化される必要があります。リクエストが最適化できない場合は、サポートチームまでお問い合わせください。
クラウド WAF アーキテクチャにおける関連するタイムアウト
クラウド WAF エージェントは、ALB へのレスポンス送信を開始するまでに60秒を要します
クラウド WAF エージェントは、アップストリームと TLS とのネゴシエーションに10秒を要します
クラウド WAF エージェントは、アップストリームへの HTTP 接続を確立するために30秒待機します
