サーバレベルのオプションは、モニタ対象サーバごとに設定するか、すべてのサーバに対してグローバルに設定するか、またはサーバ リストに対して設定することができます。また、事前定義のサーバー プロファイルを使用してこれらのオプションを設定するか、またはご使用の環境のニーズに合わせて個別に設定することができます。これらのオプション、またはこれらのオプションを設定するデフォルト
プロファイルの 1 つを使用して、トラフィックを正規化する HTTP サーバ ポート、正規化するサーバ応答ペイロードの量、および正規化するエンコードのタイプを指定します。
以下の説明でプリプロセッサ ルールが言及されていない場合、オプションにはプリプロセッサ ルールが関連付けられていません。
ネットワーク
1 つ以上のサーバーの IP アドレスを指定するには、このオプションを使用します。1 つの IP アドレスまたはアドレス ブロックを指定するか、そのいずれかまたは両方から成るカンマで区切ったリストを指定できます。
デフォルト プロファイルを含めてプロファイルの合計数は最大 255 ですが、さらに、HTTP サーバー リストに最大 496 文字（約 26 エントリ）を含めることができ、すべてのサーバー プロファイルに対して合計 256 のアドレス エントリを指定できます。
デフォルト ポリシーの default 設定では、別のターゲットベース ポリシーでカバーされていないモニター対象ネットワーク セグメントのすべての IP アドレスが指定されることに注意してください。したがって、デフォルト ポリシーの IP アドレスまたは CIDR ブロック/プレフィックス長は指定できず、また指定する必要もありません。また、別のポリシーでこの設定を空白にしたり、any を表すアドレス表記（0.0.0.0/0 または ::/0）を使用したりすることはできません。
ポート
プリプロセッサ エンジンが HTTP トラフィックを正規化するポート。ポート番号が複数ある場合は、カンマで区切ります。
サイズ超過のディレクトリ長（Oversize Dir Length）
指定された値よりも長い URL ディレクトリを検出します。
指定された長さよりも長い URL の要求をプロセッサが検出した場合にイベントを生成し、インライン展開では、違反パケットをドロップします。するには、ルール 119:15 を有効にします。
クライアント フローの深さ（Client Flow Depth）
[ポート（Ports）] で定義されているクライアント側 HTTP トラフィックについて、ルールで検査される raw HTTP パケットのバイト数（ヘッダーとペイロード データを含む）を指定します。ルール内の HTTP コンテンツ ルール オプションによって要求メッセージの特定の部分が検査される場合は、[クライアント
フローの深さ（Client Flow Depth）] は適用されません。
次のいずれかを指定します。
-
正の値によって、最初のパケットで指定のバイト数が検査されます。最初のパケットのバイト数が指定のバイト数よりも少ない場合は、パケット全体が検査されます。指定された値は、セグメント化されたパケットと再構成されたパケットの両方に適用されることに注意してください。
また、値 300 を指定すると、通常は、多くのクライアント要求ヘッダーの終わりにある大きな HTTP Cookie のインスペクションが排除されることにも注意してください。
-
0 を指定すると、すべてのクライアント側トラフィックが検査されます。これにはセッション内の複数のパケットが含まれ、必要な場合にはバイトの上限を超えることもあります。この値はパフォーマンスに影響する可能性があることに注意してください。
-
-1 を指定すると、クライアント側のすべてのトラフィックが無視されます。
サーバー フローの深さ（Server Flow Depth）
[Ports] で指定されたサーバー側 HTTP トラフィックで、ルールにより検査される raw HTTP パケットのバイト数を指定します。[HTTP 応答の検査（Inspect HTTP Responses）] が無効である場合は raw ヘッダーとペイロードが検査され、[HTTP 応答の検査（Inspect HTTP Response）] が有効である場合は、raw 応答ボディのみが検査されます。
Server Flow Depth は、[Ports] で定義されているサーバー側 HTTP トラフィックで、ルールにより検査されるセッション内の raw サーバー応答データのバイト数を指定します。このオプションを使用して、HTTP サーバー応答データのインスペクションのレベルとパフォーマンスのバランスを調整できます。ルール内の
HTTP コンテンツ オプションによって要求メッセージの特定の部分が検査される場合は、Server Flow Depth は適用されません。
クライアント フローの深さ（Client Flow Depth）とは異なり、サーバ フローの深さ（Server Flow Depth）では、ルールが検査するバイト数を、HTTP 要求パケットごとではなく、HTTP 応答ごとのバイト数として指定します。
次のいずれかの値を指定できます。
-
正の値：
[HTTP 応答の検査（Inspect HTTP Responses）] が有効である場合、raw HTTP 応答ボディのみが検査され、raw HTTP ヘッダーは検査されません。また、[圧縮データの検査（Inspect Compressed Data）] が有効である場合は、圧縮解除データも検査されます。
[HTTP 応答の検査（Inspect HTTP Responses）] が無効である場合、raw パケット ヘッダーとペイロードが検査されます。
セッションの応答バイト数が指定の値よりも少ない場合は、そのセッションで、ルールにより（必要に応じて複数パケットにわたって）すべての応答パケットが完全に検査されます。セッションの応答バイト数が指定の値よりも多い場合、そのセッションで、ルールにより（必要に応じて複数パケットにわたって）指定のバイト数だけが検査されます。
フローの深さ（Flow Depth）の値が小さいと、[ポート（Ports）] で定義されているサーバー側トラフィックを対象とするルールで、検出漏れが発生する可能性があります。これらのルールのほとんどは HTTP ヘッダーまたはコンテンツ（通常、非ヘッダー データの先頭の約 100 バイト以内）を対象とします。通常見出しの長さは
300 バイト未満ですが、見出し サイズは異なることがあります。
指定された値は、セグメント化されたパケットと再構成されたパケットの両方に適用されることにも注意してください。
-
0 を指定すると、[ポート（Port）] で定義されているすべての HTTP サーバー側トラフィックでパケット全体が検査されます。これにはセッションでの 65535 バイトよりも大きな応答データも含まれます。
この値はパフォーマンスに影響する可能性があることに注意してください。
-
-1
[Inspect HTTP Responses] が有効な場合、raw HTTP 見出しだけが検査され、raw HTTP 応答ボディは検査されません。
[HTTP 応答の検査（Inspect HTTP Responses）] が無効である場合、[ポート（Ports）] で定義されているすべてのサーバー側トラフィックは無視されます。
Maximum Header Length
[HTTP 応答の検査（Inspect HTTP Responses）] が有効である場合は、HTTP 要求、および HTTP 応答で、指定されている最大バイト数よりも長いヘッダー フィールドを検出します。値 0 を指定すると、このオプションが無効になります。これを有効にするため正の値を指定します。
ルール 119:19 を有効にすることができます。イベントを生成し、インライン展開では、このオプションの違反パケットをドロップします。侵入ルール状態の設定 を参照してください。
最大ヘッダー数（Maximum Number of Headers）
HTTP 要求でヘッダー数がこの設定を超えている場合にそのことを検出します。値 0 を指定すると、このオプションが無効になります。これを有効にするため正の値を指定します。
ルール 119:20 を有効にすることができます。イベントを生成し、インライン展開では、このオプションの違反パケットをドロップします。侵入ルール状態の設定 を参照してください。
最大スペース数（Maximum Number of Spaces）
折りたたみ行のスペースの数が HTTP 要求のこの設定と等しいか、超えている場合にそのことを検出します。値 0 を指定すると、このオプションが無効になります。これを有効にするため正の値を指定します。
ルール 119:26 を有効にすることができます。イベントを生成し、インライン展開では、このオプションの違反パケットをドロップします。侵入ルール状態の設定 を参照してください。
HTTP クライアント ボディの抽出の深さ（HTTP Client Body Extraction Depth）
HTTP クライアント要求のメッセージ ボディから抽出するバイト数を指定します。侵入ルールを使用して抽出データを検査するには、content または protected_content キーワードを [HTTP クライアント ボディ（HTTP Client Body）] オプションと共に選択します。
クライアント ボディを無視するには、-1 を指定します。クライアント ボディ全体を抽出するには、0 を指定します。抽出対象のバイト数を指定すると、システム パフォーマンスが向上することがある点に注意してください。また、侵入ルールで [HTTP
クライアント ボディ（HTTP Client Body）] オプションが機能するためには、0 か 0 より大きい値を指定する必要があることに注意してください。
小さいチャンク サイズ（Small Chunk Size）
チャンクが小さいとみなされるサイズの最大バイト数を指定します。正の値を指定します。値 0 を指定すると、異常な小さなセグメントの連続の検出が無効になります。詳細については、[連続する小さいチャンク（Consecutive Small Chunks）] オプションを参照してください。
連続する小さいチャンク（Consecutive Small Chunks）
チャンク転送エンコードを使用するクライアント トラフィックまたはサーバ トラフィックで異常に大量であるとみなされる、連続する小さなチャンクの数を指定します。[小さいチャンク サイズ（Small Chunk Size）] オプションは、小さなチャンクの最大サイズを指定します。
たとえば、10 バイト以下のチャンクが 5 つ連続していることを検出するには、[小さいチャンク サイズ（Small Chunk Size）] に 10 を設定し、[連続する小さいチャンク（Consecutive Small Chunks）] に 5 を設定します。
大量の小さなチャンクが検出される場合に イベントを生成し、インライン展開では、違反パケットをドロップします。 するには、クライアント トラフィックの場合はプリプロセッサ ルール 119:27 を有効にし、サーバ トラフィックの場合はルール 120:7 を有効にします。[小さいチャンク サイズ（Small Chunk Size）] が有効であり、このオプションが 0 または 1 に設定されている場合にこれらのルールを有効にすると、指定されたサイズ以下のすべてのチャンクでイベントがトリガーとして使用されます。
HTTP メソッド（HTTP Methods）
システムがトラフィックで検出すると予期される、GET および POST 以外の HTTP 要求メソッドを指定します。複数の値はカンマで区切ります。
侵入ルールでは、HTTP メソッドのコンテンツを検索するために、content または protected_content キーワードが HTTP Method 引数と共に使用されます。GET、POST、およびこのオプションで設定されているメソッド以外のメソッドがトラフィックで検出される場合に イベントを生成し、インライン展開では、違反パケットをドロップします。するには、ルール 119:31 を有効にします。侵入ルール状態の設定を参照してください。
アラートなし（No Alerts）
関連するプリプロセッサ ルールが有効である場合に、侵入イベントを無効にします。
（注）
|
このオプションは、HTTP の標準テキスト ルールと共有するオブジェクト ルールを無効にしません。
|
HTTP ヘッダーの正規化（Normalize HTTP Headers）
[HTTP 応答の検査（Inspect HTTP Responses）] が有効な場合は、要求ヘッダーと応答ヘッダーの非 cookie データの正規化が有効になります。[Inspect HTTP Responses] が有効ではない場合は、要求見出しと応答見出しで cookie を含む HTTP 見出し全体の正規化が有効になります。
HTTP Cookie の検査（Inspect HTTP Cookies）
HTTP 要求見出しからの cookie の抽出を有効にします。また、[HTTP 応答の検査（Inspect HTTP Responses）] が有効な場合は、応答ヘッダーからの set-cookie データの抽出も有効になります。cookie の抽出が不要な場合は、このオプションを無効にするとパフォーマンスが向上します。
Cookie: および Set-Cookie: のヘッダー名、ヘッダー行の先頭のスペース、およびヘッダー行の末尾の CRLF は、cookie の一部ではなくヘッダーの一部として検査されます。
HTTP ヘッダーの Cookie の正規化（Normalize Cookies in HTTP headers）
HTTP 要求見出しの cookie の正規化を有効にします。[HTTP 応答の検査（Inspect HTTP Responses）] が有効な場合も、応答ヘッダーの set-cookie データの正規化を有効にします。このオプションを選択する前に、[Inspect HTTP Cookies] を選択する必要があります。
HTTP プロキシの使用を許可（Allow HTTP Proxy Use）
モニタ対象 Web サーバを HTTP プロキシとして使用できるようにします。このオプションは、HTTP 要求のインスペクションでのみ使用されます。
URI のみの検査（Inspect URI Only）
正規化された HTTP 要求パケットの URI 部分のみを検査します。
HTTP 応答の検査（Inspect HTTP Responses）
HTTP 応答の拡張インスペクションが有効になり、プリプロセッサは、HTTP 要求メッセージのデコードと正規化の他に、ルール エンジンによるインスペクションのために応答フィールドを抽出します。このオプションを有効にすると、応答ヘッダー、ボディ、ステータス
コードなどがシステムにより抽出されます。また [HTTP Cookie の検査（Inspect HTTP Cookies）] が有効な場合は、set-cookie データも抽出されます。
イベントを生成し、インライン展開では、違反パケットをドロップします。するには、ルール 120:2 と120:3 を次のように有効にします。
表 6. HTTP 応答ルールのインスペクション
|
ルール
|
以下の場合にトリガーする
|
|
120:2
|
無効な HTTP 応答のステータス コードが発生します。
|
|
120:3
|
HTTP 応答にはコンテンツ長または転送エンコーディングは含まれません。
|
UTF エンコードの UTF-8 への正規化（Normalize UTF Encodings to UTF-8）
[HTTP 応答の検査（Inspect HTTP Responses）] が有効である場合、HTTP 応答で UTF-16LE、UTF-16BE、UTF-32LE、および UTF32-BE エンコードが検出され、UTF-8 に正規化されます。
UTF 標準化が失敗した場合に イベントを生成し、インライン展開では、違反パケットをドロップします。 するには、ルール 102:4 を有効にします。
圧縮データの検査（Inspect Compressed Data）
[HTTP 応答の検査（Inspect HTTP Responses）] が有効な場合は、HTTP 応答ボディ内の gzip および deflate 互換圧縮データの圧縮解除と、正規化された圧縮解除データのインスペクションが有効になります。システムは、チャンク HTTP 応答データと非チャンク HTTP 応答データを検査します。システムは、必要に応じて複数のパケットにわたり圧縮解除データをパケット単位で検査します。つまり、システムが異なるパケットの圧縮解除データをインスペクションのために結合させることはありません。[圧縮データの最大深さ（Maximum
Compressed Data Depth）]、[圧縮解除データの最大深さ（Maximum Decompressed Data Depth）]、または圧縮データの終わりに到達すると、圧縮解除が終了します。[無制限の圧縮解除（Unlimited Decompression）] を選択していない場合は、[サーバー フローの深さ（Server Flow Depth）] に到達すると、圧縮解除データのインスペクションが終了します。圧縮解除データを検査するには、file_data ルール キーワードを使用できます。
イベントを生成し、インライン展開では、違反パケットをドロップします。 するには、ルール 120:6 と120:24 を次のように有効にします。
表 7. 圧縮された HTTP 応答ルールのインスペクション
|
ルール
|
以下の場合にトリガーする
|
|
120:6
|
圧縮された HTTP 応答の圧縮が失敗しました。
|
|
120:24
|
圧縮された HTTP 応答の部分的な圧縮が失敗しました。
|
無制限の圧縮解除（Unlimited Decompression）
[圧縮データの検査（Inspect Compressed Data）]（および任意で、[SWF ファイルの圧縮解除（LZMA）（Decompress SWF File（LZMA））]、[SWF ファイルの圧縮解除（Deflate）（Decompress SWF File（Deflate））]、または [PDF ファイルの圧縮解除（Deflate）（Decompress PDF File（Deflate））]）が有効な場合、複数のパケットにわたって [圧縮解除データの最大深さ（Maximum Decompressed Data Depth）] がオーバーライドされます。つまり、このオプションにより、複数のパケットにわたる無制限の圧縮解除が有効になります。このオプションを有効にしても、単一パケット内での [圧縮データの最大深さ（Maximum Compressed Data Depth）] または [圧縮解除データの最大深さ（Maximum Decompressed Data Depth）] には影響しないことに注意してください。また、このオプションを有効にすると、変更のコミット時に、[圧縮データの最大深さ（Maximum Compressed Data Depth）] と [圧縮解除データの最大深さ（Maximum Decompressed Data Depth）] が 65535 に設定されることにも注意してください。
Javascript の正規化（Normalize Javascript）
[HTTP 応答の検査（Inspect HTTP Responses）] が有効な場合、HTTP 応答ボディ内での Javascript の検出と正規化を有効にします。プリプロセッサは unescape 関数や decodeURI 関数、String.fromCharCode メソッドなどの難読化 Javascript
データを正規化します。プリプロセッサは、unescape、decodeURI、および decodeURIComponent 関数内の次のエンコードを正規化します。
-
%XX
-
%uXXXX
-
0xXX
-
\xXX
-
\uXXXX
プリプロセッサは連続するスペースを検出し、1 つのスペースに正規化します。このオプションが有効である場合、設定フィールドでは、難読化 Javascript データで許容する連続スペースの最大数を指定できます。入力できる値は、1 ～ 65535
です。値 0 を指定すると、このフィールドに関連付けられているプリプロセッサ ルール（120:10）が有効かどうかに関係なく、イベントの生成が無効になります。
プリプロセッサは、Javascript の正符号（+）演算子も正規化し、この演算子を使用して文字列を連結します。
file_data 侵入ルール キーワードを使用して、正規化された Javascript データに対し侵入ルールを指し示すことができます。
イベントを生成し、インライン展開では、違反パケットをドロップします。 するには、次に示すように、ルール 120:9、120:10、および 120:11 を有効にします。
表 8. [Javascript の正規化（Normalize Javascript）] オプションのルール（Normalize Javascript Option Rules）
|
ルール
|
以下の場合にトリガーする
|
|
120:9
|
プリプロセッサ内の難読化レベルが 2 以上である。
|
|
120:10
|
Javascript 難読化データで連続するスペースの数が、許容される連続スペースの最大数として設定された値以上である。
|
|
120:11
|
エスケープされたデータまたはエンコードされたデータに、複数のエンコード タイプが含まれている。
|
SWF ファイルの圧縮解除（LZMA）（Decompress SWF File（LZMA））および SWF ファイルの圧縮解除（Deflate）（Decompress SWF File（Deflate））
[HTTP Inspect の応答（HTTP Inspect Responses）] が有効な場合、これらのオプションは、HTTP 要求の HTTP 応答ボディ内にあるファイルの圧縮部分を圧縮解除します。
（注）
|
HTTP GET 応答で見つかったファイルの圧縮部分のみを圧縮解除できます。
|
-
[SWF ファイルの圧縮解除（LZMA）（Decompress SWF File（LZMA））] は、Adobe ShockWave Flash（.swf）ファイルの LZMA 互換の圧縮部分を圧縮解除します。
-
[SWF ファイルの圧縮解除（Deflate）（Decompress SWF File（Deflate））] は、Adobe ShockWave Flash（.swf）ファイルの deflate 互換の圧縮部分を圧縮解除します。
[圧縮データの最大深さ（Maximum Compressed Data Depth）]、[圧縮解除データの最大深さ（Maximum Decompressed Data Depth）]、または圧縮データの終わりに到達すると、圧縮解除が終了します。[無制限の圧縮解除（Unlimited Decompression）] を選択していない場合は、[サーバー フローの深さ（Server Flow Depth）] に到達すると、圧縮解除データのインスペクションが終了します。圧縮解除データを検査するには、file_data 侵入ルール キーワードを使用できます。
イベントを生成し、インライン展開では、違反パケットをドロップします。 するには、次に示すように、ルール 120:12 および 120:13 を有効にします。
表 9. [SWF ファイルの圧縮解除（Decompress SWF File）] オプションのルール
|
ルール
|
以下の場合にトリガーする
|
|
120:12
|
deflate ファイルの圧縮解除に失敗
|
|
120:13
|
LZMA ファイルの圧縮解除に失敗
|
PDF ファイルの圧縮解除（Deflate）（Decompress PDF File（Deflate））
[HTTP Inspect の応答（HTTP Inspect Responses）] が有効な場合、[PDF ファイルの圧縮解除（Deflate）（Decompress PDF File（Deflate）] は、HTTP 要求の HTTP 応答ボディ内にある Portable Document Format（.pdf）ファイルの deflate 互換の圧縮部分を圧縮解除します。システムは、/FlateDecode ストリーム フィルタが付いた PDF ファイルだけを圧縮解除できます。他のフィルタ（/FlateDecode /FlateDecode など）はサポートしていません。
（注）
|
HTTP GET 応答で見つかったファイルの圧縮部分のみを圧縮解除できます。
|
[圧縮データの最大深さ（Maximum Compressed Data Depth）]、[圧縮解除データの最大深さ（Maximum Decompressed Data Depth）]、または圧縮データの終わりに到達すると、圧縮解除が終了します。[無制限の圧縮解除（Unlimited Decompression）] を選択していない場合は、[サーバー フローの深さ（Server Flow Depth）] に到達すると、圧縮解除データのインスペクションが終了します。圧縮解除データを検査するには、file_data 侵入ルール キーワードを使用できます。
イベントを生成し、インライン展開では、違反パケットをドロップします。 するには、次に示すように、ルール 120:14、120:15、120:16、および 120:17 を有効にします。
表 10. [PDF ファイルの圧縮解除（Deflate）（Decompress PDF File（Deflate））] オプションのルール（Decompress PDF File (Deflate) Option Rules）
|
ルール
|
以下の場合にトリガーする
|
|
120:14
|
ファイルの圧縮解除に失敗
|
|
120:15
|
圧縮タイプがサポート対象外のタイプであるため、ファイルの圧縮解除に失敗
|
|
120:16
|
PDF ストリーム フィルタがサポート対象外のフィルタであるため、ファイルの圧縮解除に失敗
|
|
120:17
|
ファイルの解析に失敗
|
元のクライアント IP アドレスの抽出（Extract Original Client IP Address）
侵入検査中の、元のクライアント IP アドレスの調査を有効にします。システムは元のクライアント IP アドレスを、X-Forwarded-For（XFF）、True-Client-IP、または [XFF ヘッダーの優先順位（XFF Header
Priority）] オプションで定義したカスタム HTTP ヘッダーから抽出します。侵入イベント テーブルで、抽出された元のクライアント IP アドレスを表示できます。
イベントを生成し、インライン展開では、このオプションの違反パケットをドロップします。侵入ルール状態の設定 を参照してください。 するには、ルール 119:23、119:29、および 119:30 を有効にします。
XFF ヘッダーの優先順位（XFF Header Priority）
HTTP 要求に複数のヘッダーが存在する場合は、システムが元のクライアント IP ヘッダーを処理する順序を指定します。デフォルトでは、システムはまず X-Forwarded-For（XFF）ヘッダーを、次に True-Client-IP ヘッダーを調査します。各ヘッダー
タイプの横にある上下矢印アイコンを使用して、優先順位を調整します。
このオプションでも、抽出と評価のために、XFF または True-Client-IP 以外の元のクライアント IP ヘッダーを指定できます。[追加（Add）] をクリックして、カスタム ヘッダー名をプライオリティ リストに追加します。システムは、XFF または True-Client-IP ヘッダーと同じ構文を使用するカスタム ヘッダーのみをサポートします。
このオプションを設定する場合は、次の点に留意してください。
-
アクセス コントロールと侵入検査の両方で、システムは元のクライアント IP アドレス ヘッダーを評価するときに、この優先順位を使用します。
-
元のクライアント IP ヘッダーが複数ある場合、システムは優先順位が最も高いヘッダーのみを処理します。
-
XFF ヘッダーには、要求が渡されるプロキシ サーバーを表す IP アドレスのリストが含まれています。スプーフィングを防止するために、システムはリスト内の最後の IP アドレス（つまり、信頼されるプロキシにより追加されたアドレス）を、元のクライアント
IP アドレスとして使用します。
URI のログ（Log URI）
raw URI が存在する場合に、HTTP 要求パケットから raw URI を抽出できるようにし、このセッションで生成されるすべての侵入イベントにこの URI を関連付けます。
このオプションが有効である場合、侵入イベント テーブル ビューの [HTTP URI] 列に、抽出された URI の先頭 50 文字を表示できます。パケット ビューでは、URI 全体（最大 2048 バイト）を表示できます。
ホスト名のログ（Log Hostname）
ホスト名が存在する場合に、HTTP 要求の Host ヘッダーからホスト名を抽出できるようにし、このセッションで生成されるすべての侵入イベントにこのホスト名を関連付けます。複数の Host ヘッダーがある場合は、1 番目のヘッダーからホスト名を抽出します。
このオプションが有効である場合、侵入イベント テーブル ビューの [HTTP ホスト名（HTTP Hostname）] 列に、抽出されたホスト名の先頭 50 文字を表示できます。パケット ビューでは、ホスト名全体（最大 256 バイト）を表示できます。
ルール 119:25 を有効にすることができます。イベントを生成し、インライン展開では、このオプションの違反パケットをドロップします。侵入ルール状態の設定 を参照してください。
有効にすると、このオプションの設定に関係なく、HTTP 要求で複数のホスト ヘッダーが検出された場合、ルール 119:24 がトリガーされます。
プロファイル（Profile）
HTTP トラフィック向けに正規化されたエンコードのタイプを指定します。システムには、ほとんどのサーバに適用できるデフォルト プロファイル、Apache サーバと IIS サーバ用のデフォルト プロファイル、およびモニタ対象トラフィックのニーズに合わせて調整できるカスタムのデフォルト設定があります。
-
すべてのサーバに対して適切な標準のデフォルト プロファイルを使用するには、[すべて（All）] を選択します。
-
システムによって提供される IIS プロファイルを使用するには、[IIS] を選択します。
-
システムによって提供される Apache プロファイルを使用するには、[Apache] を選択します。
-
独自のサーバー プロファイルを作成するには、[カスタム（Custom）] を選択します。
![[編集（edit）] アイコン](/content/dam/en/us/td/i/400001-500000/440001-450000/442001-443000/442546.jpg)
![[表示（View）] ボタン](/content/dam/en/us/td/i/400001-500000/450001-460000/452001-453000/452013.jpg)
）
)![[削除（Delete）] アイコン](/content/dam/en/us/td/i/400001-500000/440001-450000/447001-448000/447585.jpg)
）
フィードバック