次の方法で共有

IIS での HTTP 400 エラーのトラブルシューティング

  • [アーティクル]

適用対象: インターネット インフォメーション サービス

この記事では、IIS を使用するときのさまざまな HTTP 400 エラーの原因を特定するためのトラブルシューティング手順について説明します。

概要

HTTP クライアント (Microsoft Edge など) が HTTP 要求を IIS サーバーに送信すると、次の種類のエラー メッセージが表示されることがあります。

HTTP 400 - 無効な要求

このシナリオでは、要求がサーバーの HTTP 解析規則を満たしていないか、時間制限を超えているか、IIS またはHTTP.sysが受信要求に準拠する必要があるその他の規則を満たしていないため、IIS はクライアントの HTTP 要求を拒否します。 IIS は、 HTTP 400 - Bad Request 状態をクライアントに送り返し、TCP 接続を終了します。

ツール

トラブルシューティング方法

HTTP 400 条件のトラブルシューティングを行う場合、基になる問題は、クライアントが IIS に要求を送信し、HTTP.sysが適用している 1 つ以上の規則を破ったということです。 これを念頭に置いて、クライアントが IIS に送信している正確な内容を確認する必要があります。 これを行うには、不適切な要求を送信しているクライアントのネットワーク トレースをキャプチャします。 トレースを分析することで、クライアントから IIS に送信された生のデータを確認したり、IIS からクライアントに返された生の応答データを確認したりすることができます。 また、 Fiddler と呼ばれる HTTP スニファ ツールを使用することもできます。これは、クライアントとサーバーが SSL 経由で通信している場合でも HTTP ヘッダーを表示できるため、優れたツールです。

次に使用するデータ項目は、 C:\Windows\System32\LogFiles\HTTPERR\httperr.log ファイルです。 IIS では、HTTP.sys コンポーネントは受信 HTTP 要求を IIS に渡す前に処理し、IIS の要件を満たしていない要求をブロックします。 HTTP.sysが要求をブロックすると、不適切な要求とブロックされた理由に関する情報が httperr.log ファイルに記録されます。

Note

HTTP.sysが提供する HTTP API エラー ログの詳細については、「 HTTP API でのエラー ログ記録を参照してください。

技術的には可能ですが、クライアントが HTTP 400 応答を受け取る可能性は非常に高くはありませんが、 httperr.log ファイルにログ エントリが関連付けられていない可能性があります。 これは、ISAPI フィルターまたは拡張機能、または IIS の HTTP モジュールによって 400 の状態が設定された場合に発生する可能性があります。この場合、IIS ログで詳細を確認できます。 また、プロキシ サーバーやその他のネットワーク デバイスなど、クライアントとサーバーとの間にある何らかのエンティティが IIS からの応答をインターセプトし、独自の 400 状態または "Bad Request (無効な要求)" エラーでオーバーライドした場合にも発生する可能性があります。

Note

この記事では、Web サイトにアクセスする前の一般的な HTTP 400 エラーについて主に説明します。 一部のシナリオでは、カスタム コード ロジックまたはランタイム (ASP.NET など) の構成により、Web サイトがクライアントに HTTP 400 エラーを返す場合もあります。 以降のセクションの手順を実行しても HTTP 400 エラーを解決できない場合は、IIS の Failed Requests Tracing 機能 を使用してトラブルシューティングを試してください。 HTTP 400 エラーが実際に web サイトの対応するランタイム ハンドラー (ASP.NET など) によって設定されている場合は、HTTP 400 エラーの原因を理解するために、Web サイトの関連するコード ロジックとランタイム構成と共に、要求と応答の詳細を調べる必要があります。

シナリオ例

HTTP 400 シナリオの例を次に示します。このシナリオでは、クライアントが IIS に不適切な要求を送信し、サーバーから "HTTP 400 - 無効な要求" メッセージが返されます。

クライアントが要求を送信すると、返されるブラウザー エラーは次のようになります。

Bad Request (Header Field Too Long) (無効な要求 (ヘッダー フィールドが長すぎます))

要求と応答のネットワーク トレースをキャプチャすると、次の出力が表示されます。

依頼：

HTTP: GET Request from Client
HTTP: Request Method =GET
HTTP: Uniform Resource Identifier =/1234567890123456789012345678901234567890/time.asp
HTTP: Protocol Version =HTTP/1.1
HTTP: Accept-Language =en-us
HTTP: UA-cpu =x86
HTTP: Accept-Encoding =gzip, deflate
HTTP: Host =iisserver
HTTP: Connection =Keep-Alive
HTTP: Data: Number of data bytes remaining = 14 (0x000E)

応答：

HTTP: Response to Client; HTTP/1.1; Status Code = 400 - Bad Request
HTTP: Protocol Version =HTTP/1.1
HTTP: Status Code = Bad Request
HTTP: Reason =Bad Request
HTTP: Content-Type =text/html
HTTP: Date =Wed, 14 Nov 2012 20:36:36 GMT
HTTP: Connection =close
HTTP: Content-Length =44
HTTP: Data: Number of data bytes remaining = 63 (0x003F)

応答ヘッダーがブラウザーのエラー メッセージほど多くを伝えないことがわかります。 ただし、応答本文で生データを見ると、次の内容が表示されます。

00000030                                           48 54               HT
00000040 54 50 2F 31 2E 31 20 34 30 30 20 42 61 64 20 52 TP/1.1.400.Bad.R
00000050 65 71 75 65 73 74 0D 0A 43 6F 6E 74 65 6E 74 2D equest..Content-
00000060 54 79 70 65 3A 20 74 65 78 74 2F 68 74 6D 6C 0D Type:.text/html.
00000070 0A 44 61 74 65 3A 20 57 65 64 2C 20 32 38 20 4A .Date:.Wed,.28.J
00000080 61 6E 20 32 30 30 39 20 32 30 3A 33 36 3A 33 36 an.2009.20:36:36
00000090 20 47 4D 54 0D 0A 43 6F 6E 6E 65 63 74 69 6F 6E .GMT..Connection
000000A0 3A 20 63 6C 6F 73 65 0D 0A 43 6F 6E 74 65 6E 74 :.close..Content
000000B0 2D 4C 65 6E 67 74 68 3A 20 34 34 0D 0A 0D 0A 3C -Length:.44....<
000000C0 68 31 3E 42 61 64 20 52 65 71 75 65 73 74 20 28 h1>Bad.Request.(
000000D0 48 65 61 64 65 72 20 46 69 65 6C 64 20 54 6F 6F Header.Field.Too
000000E0 20 4C 6F 6E 67 29 3C 2F 68 31 3E 01 02 03 04 05 .Long).....
000000F0 05 06 0E 94 63 D6 68 37 1B 8C 16 FE 3F D5       ....c.h7....?.

ブラウザーに表示されるエラー メッセージ テキストが、ネットワーク トレース内の生の応答データでも確認できます。

次の手順では、C:\Windows\System32\LogFiles\HTTPERR ディレクトリ内のhttperr.log ファイルで、不適切な要求に対応するエントリを確認します。

#Software: Microsoft HTTP API 1.0
#Version: 1.0
#Date: 2012-11-14 20:35:02
#Fields: date time cs-version cs-method cs-uri sc-status s-reason 
2012-11-14 20:36:36 HTTP/1.1 GET /1234567890/time.asp 400 FieldLength

このシナリオでは、httperr.log ファイルの Reason フィールドに、問題を診断するために必要な正確な情報が表示されます。 この要求の失敗の理由フレーズとしてHTTP.sysログに記録された FieldLength が表示されます。 理由フレーズがわかったら、HTTP API がログに記録するエラーの種類セクションの表を調べて、その説明を取得します。

FieldLength: フィールドの長さの制限を超えました。

そのため、この時点で、ブラウザーのエラー メッセージと HTTP API エラー ログから、要求に許容される長さの制限を超えたいずれかの HTTP ヘッダーにデータが含まれていることがわかっています。 この例では、 HTTP: Uniform Resource Identifier header は意図的に長く、 /1234567890123456789012345678901234567890/time.aspです。

この例のトラブルシューティングの最後の段階では、 IIS のHTTP.sysレジストリ キーと既定の設定を確認します

ヘッダー フィールドの長さが制限を超えている理由フレーズとエラーが示されていることがわかっているため、 Registry Keys テーブルで検索を絞り込むことができます。 ここでの主な候補は次のとおりです。

レジストリ キー 規定値 有効な値の範囲 レジストリ キー関数 警告コード
MaxFieldLength 16384 64 - 65534 (64k - 2) バイト 各ヘッダーの上限を設定します。 以下を参照してください。MaxRequestBytes この制限は、URL では約 32,000 文字に相当します。 1

この例でこのエラーを再現するために、 MaxFieldLength レジストリ キーの値が 2 に設定されました。 要求された URL には 2 文字を超える HTTP: Uniform Resource Identifier header フィールドがあるため、要求は FieldLength 理由フレーズでブロックされました。

もう 1 つの一般的な HTTP 400 シナリオは、HTTP 要求を行うユーザーが多数の Active Directory グループのメンバーであり、Web サイトがユーザー Kerberos 認証に構成されているシナリオです。 このシナリオが発生すると、次のようなエラー メッセージがユーザーに表示されます。

Bad Request (Request Header Too Long) (無効な要求 (要求ヘッダーが長すぎます))

このシナリオでは、クライアントの HTTP 要求の一部として含まれる認証トークンが大きすぎて、http.sysが適用しているサイズ制限を超えています。 この問題については、解決策と共に、 HTTP 400 - HTTP 要求に対する無効な要求 (要求ヘッダーが長すぎます) 応答で詳しく説明。

関連情報