4xx および 5xx HTTP エラーのトラブルシューティング

この記事では、インターネット インフォメーション サービス (IIS) の 4xx および 5xx HTTP 状態コード エラーを解決するためのトラブルシューティング手順について説明します。 4xx 状態コードはクライアント側の問題を示し、5xx 状態コードはサーバー側の問題を示します。 このガイダンスは、これらのエラーの原因を特定し、効果的に解決するのに役立ちます。

4xx エラーを特定する

4xx HTTP 状態コードは、クライアント側の問題が原因でエラーが発生したことを示します。 たとえば、クライアント ブラウザーが存在しないページを要求した場合や、クライアント ブラウザーが有効な認証情報を提供していない可能性があります。

4xx エラーを特定するには、IIS ログとHTTPERR ログを調べます:

  • HTTP 状態コードは IIS ログに記録されます。 このファイルは通常、 C:\inetpub\logs\Logfiles に格納されますが IIS マネージャーの IIS Logging を使用して構成できます。

  • 4xx エラー コードは、 HTTP.sys カーネル ドライバーによって生成できます。つまり、これらの要求が IIS に到達しないため、IIS ログに記録されません。 HTTP.sys は、これらのエラーを、 HTTPERR ログと呼ばれる個別のファイルに記録します。 このファイルは通常、 C:\Windows\System32\LogFiles\HTTPERR に格納されますが、レジストリ HKEY\LOCAL\MACHINE\System\CurrentControlSet\Services\HTTP\Parameters\ErrorLoggingDirを使用して構成できます。

  • 4xx 応答が HTTP.sys から送信されているかどうかを確認する 1 つの方法は、クライアントで HAR トレース ファイルを収集し、応答ヘッダー Microsoft-HttpApi/2.0 を探す方法です。

    ブラウザーと Web サイトの対話を記録する HAR トレース ファイルをキャプチャするには、トラブルシューティングのためにブラウザー トレースを Capture の指示に従います。

IIS ログを調べる

IIS ログでエラーが見つかる場合は、状態コード (sc-status) と副ステータス コード (sc-substatus) をメモし、詳細については HTTP 状態コードの概要 を参照してください。

状態コードに関する詳細情報を取得し、4xx エラーを返したモジュールまたはハンドラーを理解するには、IIS ログに表示される状態コードによってトリガーされる FREB ルールを構成して、問題が発生した時刻Failed Request Trace (FREB) ログを収集します。

HTTPERR ログを確認する

HTTPERR ログでエラーが見つかる場合は、その理由 (s-reason) に注意し、詳細については HTTP Server API によってログに記録されたエラーの種類 を参照してください。

5xx エラーを特定する

5xx HTTP 状態コードは、サーバーが要求の処理中にエラーを検出したため、サーバーが要求を完了できなかったことを示します。 アプリケーションの種類に基づいて、次の手順を使用します。

クラシック ASP で 500 エラーが発生する

クラシック ASP で 500 エラーが発生した場合は、IIS ログの cs-uri-query クエリでエラー コードまたはエラー メッセージを確認します。

詳細については、 Failed Request Trace (FREB) ログ 500 エラーをキャプチャして調べます。

一般的な IIS では 500 エラー

一般的な IIS で 500 エラーが発生した場合は、IIS ログを調べ、状態コード (sc-status) と副ステータス コード (sc-substatus) をメモし、エラーの詳細については HTTP 状態コードの概要 を参照してください。

詳細を取得できる場合は、詳細なエラー メッセージを有効にします。 詳細なエラー メッセージを有効にするには、次の手順に従います。

  1. Run コマンド ウィンドウを開きます。

  2. inetmgr を起動します。

  3. IIS マネージャーのコンソールの左側にある Connections ウィンドウで、コンピューター名を展開し、 Sites を展開して、ターゲット Web サイトを選択します。

    IIS マネージャーのターゲット Web サイトのスクリーンショット。

  4. 中央のウィンドウの Error Pages アイコンをダブルクリックします。

    [エラー ページ] アイコンのスクリーンショット。

  5. 右側の [ Actions ] ウィンドウで、[機能設定 編集を選択します。

    [機能設定の編集] オプションのスクリーンショット。

  6. [ 編集エラー ページの設定 ダイアログ (ローカル要求とリモート要求の両方を送信することを選択) で、2 番目のオプション ボタンを選択して、ローカル要求とリモート要求の両方の詳細なエラーを返す必要があります。 既定では、ローカル要求に対してのみ送信される詳細なエラーを送信する下部オプションが選択されています。

    [エラー ページの設定の編集] ダイアログのスクリーンショット。

    このオプションでは機密情報がインターネットに公開される可能性があるため、リモート要求の詳細なエラーを送信することはお勧めしません。 エラーに関する詳細情報を取得したら、変更を元に戻す必要があります。

詳細については、 Failed Request Trace (FREB) ログ 500 エラーをキャプチャして調べます。

ASP.NET で 500 エラー

ASP.NET で 500 エラーが発生した場合は、次の方法を使用してエラーの根本原因を特定します。

  • アプリケーション イベント ログを確認します。

    問題が発生した時点のアプリケーション イベント ログを確認します。 ASP.NET は、呼び出し履歴を含むエラーの詳細をアプリケーション イベント ログに記録します。

    アプリケーション イベント ログにアクセスするには、次の手順に従います。

    1. スタート メニューを開き、イベント ビューアーを検索して、イベント ビューアーを選択します。
    2. イベント ビューアーで [Windows ログ] ノードを開きます。
    3. Application を選択して、アプリケーション イベント ログを開きます。
    4. 失敗したアプリケーションに関連付けられているエラーを検索します。 エラーの Source 列の値は、IIS AspNetCore Module または IIS Express AspNetCore Module です。

  • メモリ ダンプをキャプチャします。

    場合によっては、特定の例外のメモリ ダンプをキャプチャして、500 HTTP 状態の原因となった例外に関する詳細を調べる必要がある場合があります。

    ダンプをキャプチャするには、「 Collect memory dumps for a first-chance exception when it occursの指示に従ってください。

    収集されたダンプの CrashHangAnalysis ルールと共に DebugDiag 2 分析ツール (DebugDiag スイートの一部) を使用して、呼び出し履歴の確認と根本原因の特定に使用できるレポートを生成します。

    DebugDiag 分析ツールを使用してレポートを生成するには、次の手順に従います。

    1. DebugDiag 2 分析を開きます。
    2. [データ ファイルの追加選択し.dmp ファイルを追加します。
    3. CrashHangAnalysis と PerfAnalysis を選択し、Start Analysis を選択します。

    完了すると、レポート (.mht) が C:\Program Files\DebugDiag\Reports に作成され、結果と推奨事項と共に Internet Explorer に表示されます。

    カスタム DLL を使用する場合は、次の手順に従って、カスタム PDB ファイルのシンボル検索パスを指定できます。

    1. DebugDiag 2 コレクション ツールを開きます。
    2. ツール>オプションと設定>フォルダーと検索パスを選択します。
    3. [デバッグ用の検索パス Symbolで Browse を選択してパスを設定します。

  • Perfview トレースをキャプチャして ExecutionTimeout の問題を特定します。

    ASP.NET ExecutionTimeout を超えたために 500 エラーが発生した場合は、perfView トレースとダンプを して 遅延を特定します。

ASP.NET Core で 500 エラーが発生する

ASP.NET Core で 500 エラーが発生した場合は、次の方法を使用して、エラーの根本原因を特定します。

  • アプリケーション イベント ログを確認します。

    アプリケーション イベント ログにアクセスするには、次の手順に従います。

    1. スタート メニューを開き、イベント ビューアーを検索して、イベント ビューアーを選択します。
    2. イベント ビューアーで [Windows ログ] ノードを開きます。
    3. Application を選択して、アプリケーション イベント ログを開きます。
    4. 失敗したアプリケーションに関連付けられているエラーを検索します。 エラーの Source 列の値は、IIS AspNetCore Module または IIS Express AspNetCore Module です。

  • Developer 例外ページを有効にします。

    ASPNETCORE_ENVIRONMENT環境変数を web.config に追加して、開発環境でアプリケーションを実行できます。 ホスト ビルダーの UseEnvironment メソッドを使用してアプリケーションのスタートアップ コードの環境設定をオーバーライドしない場合、環境変数を使用すると、アプリケーションの実行時に Developer 例外ページ が表示されます。

    <aspNetCore processPath="dotnet"
    arguments=".\MyApp.dll"
    stdoutLogEnabled="false"
    stdoutLogFile=".\logs\stdout"
    hostingModel="InProcess">
  <environmentVariables>
     <environmentVariable name="ASPNETCORE_ENVIRONMENT" value="Development" />
  </environmentVariables>
</aspNetCore>

    ASPNETCORE_ENVIRONMENTの環境変数の設定は、インターネットに公開されていないステージング サーバーとテスト サーバーでのみ推奨されます。 トラブルシューティング後は、必ず web.config ファイルからこの環境変数を削除してください。

  • ASP.NET Core モジュールの stdout ログを有効にします。

    stdoutログを有効にして表示するには、次の手順に従います。

    1. ホスティング システム上のサイトの展開フォルダーに移動します。

    2. logs フォルダーが存在しない場合は、フォルダーを作成します。 MSBuild を有効にしてデプロイ内に logs フォルダーを自動的に作成する方法については、「 ASP.NET Core ディレクトリ構造を参照してください。

    3. web.config ファイルを編集します。 stdoutLogEnabledをtrueに設定し、次のように stdoutLogFile フォルダー (たとえば、.\logs\stdout) を指す パスを変更します。

      <aspNetCore processPath="dotnet"
    arguments=".\App.dll"
    stdoutLogEnabled="true"
    stdoutLogFile=".\logs\stdout">
</aspNetCore>

    4. ファイル名のプレフィックスとして stdout を使用します。 ログの作成時に、タイムスタンプ、プロセス ID (PID)、ファイル拡張子が自動的に追加されます。 一般的なログ ファイル名は、 stdout_<timestamp>_<PID>.log です。

    5. アプリケーション プールの ID に logs フォルダーへの書き込みアクセス許可があることを確認します。

    6. 更新した web.config ファイルを保存します。

    7. アプリケーションに要求を行います。

    8. logs フォルダーに移動します。 最新の stdout ログを見つけて開きます。

    9. ログ内のエラーを調査します。

    トラブルシューティングが完了したときに stdout ログ記録を無効にするには、次の手順に従います。

    1. web.config ファイルを編集します。
    2. stdoutLogEnabled を false に設定します。
    3. ファイルを保存します。

  • ASP.NET Core モジュール デバッグ ログ (IIS) を有効にします。

    ASP.NET Core モジュールのデバッグ ログを有効にするには、アプリケーションの web.config ファイルに次のハンドラー設定を追加します。

    <aspNetCore ...>
   <handlerSettings>
     <handlerSetting name="debugLevel" value="file" />
     <handlerSetting name="debugFile" value="c:\temp\ancm.log" />
   </handlerSettings>
</aspNetCore>

    ログに指定されたパスが存在し、アプリケーション プールの ID に場所への書き込みアクセス許可があることを確認します。

ARR で 502 エラーが発生しました

アプリケーション要求ルーティング (ARR) で 502 エラーが発生した場合は、「 ARR で 502 エラーをトラブルシューティングする」の手順に従。

503 エラー

503 エラーが発生した場合は、IIS ログのサブステータス コード (sc-substatusまたは HTTPERR ログのs-reasonヒントを提供できます。

詳細については、以下を参照してください:

また、次の記事を参照してください。この記事では、503 エラーの原因となる既知の問題が強調表示されています。

HTTP 応答 503 サービスは IIS から利用できません: 一般的な原因の 1 つ

データ収集

FREB ログをキャプチャする手順

重要

FREB ログを構成するには、Tracing 役割サービスが IIS 用にインストールされていることを確認します。

IIS の Tracing 役割サービスをインストールするには、次の手順に従います。

  1. サーバー マネージャーを開き、[ 管理>役割と機能の追加を選択します。
  2. 役割と機能の追加ウィザード ウィンドウで、Server Roles ページに移動するまで Next を選択します。
  3. Web Server (IIS)>Web Server>Health and Diagnostics を展開し、Tracing チェックボックスをオンにします。
  4. 後続の手順で Next を選択し、 Install を選択します。

Tracing ロール サービスがインストールされたら、次の手順に従って FREB をキャプチャします。

  1. Run コマンド ウィンドウを開きます。

  2. inetmgr を起動します。

  3. IIS マネージャーの Connections ペインで、コンピューター名を展開し、 Sites を展開し、ターゲット Web サイトを選択します。

    IIS マネージャーのターゲット Web サイトのスクリーンショット。

  4. [失敗した要求トレースの規則] をダブルクリックします。

    既定の Web サイト ホームのスクリーンショット。

  5. Actions ペインで、Add を選択します。

  6. 失敗した要求トレース規則の追加 ウィザードの トレースするコンテンツの指定 ページで、[すべてのコンテンツ>を選択。

    [失敗した要求トレース ルールの追加] ウィンドウの [トレースするコンテンツの指定] ページのスクリーンショット。

  7. Define トレース条件 ページで、Status コードの フィールドを 400-600 に更新し次へ選択。

    [トレース条件の定義] ページのスクリーンショット。

  8. トレース プロバイダーの選択 ページの Providers で、すべてのチェック ボックスをオンにします。 [ Areas で、各プロバイダーのすべてのチェック ボックスがオンになっていることを確認します。 [詳細] の [詳細] を選択します。 [完了] を選びます。

  9. サイトの Failed 要求トレース を有効にして、ログ ファイル ディレクトリを構成します。

    1. Connections ウィンドウで、コンピューター名を展開し、Sites を展開し、既定の Web サイトを選択します。

    2. Actions ペインの Configure で、Failed Request Tracing を選択します。

      [失敗した要求トレース] オプションのスクリーンショット。

    3. [ Edit Web Site Failed Request Tracing Settings ] ダイアログボックスで、[ Enable ] チェック ボックスをオンにし、[ Directory フィールドを %SystemDrive%\inetpub\logs\FailedReqLogFiles に設定し、トレース ファイル Maximum 数 を 1000 に設定します。

      [Web サイトの失敗した要求トレース設定の編集] ウィンドウのスクリーンショット。

    4. [OK] を選択します。

PerfView トレースとダンプをキャプチャする手順

PerfView トレースとダンプをキャプチャするには、次のセクションの手順に従います。

問題の前に PerfView と Procdump を構成する

問題が発生する前に、次の手順に従って、データ収集用に PerfView と Procdump を構成します。

  1. の ProcDumpをダウンロードします。 これは、インストールを必要とせず、ダンプ収集を自動化する軽量の実行可能ファイルです。

  2. procdump.exe ファイルをサーバー上の特定のフォルダーに抽出します。

  3. サーバー上の PerfView ツールをダウンロードします。 これは、Windows イベント トレーシング (ETW) イベントをキャプチャするプロファイラー ツールです (インストールは必要ありません)。

  4. PerfView で有用な情報を提供するには、IIS の Role Service として Tracing を追加します。 Tracingが有効になっていない場合、ETW トレースにはHTTP.sys情報のみが含まれます。 Tracing ロール サービスがインストールされているかどうかわからない場合は、次の手順に従います。

    1. サーバー マネージャーを開き、[ 管理>役割と機能の追加を選択します。
    2. 役割と機能の追加ウィザード ウィンドウで、Server Roles ページに移動するまで Next を選択します。
    3. Web Server (IIS)>Web Server>Health and Diagnostics を展開し、Tracing チェックボックスをオンにします。
    4. 後続の手順で Next を選択し、 Install を選択します。

  5. PerfView ツールを開き、 Collect メニューを選択し、 Collect オプションを選択します。

  6. 次のスクリーンショットに示すように、 Zip、 Merge、 Thread Time チェックボックスをオンにします。 Circular MB フィールドを 2000 に変更:

    [Zip]、[マージ]、[スレッド時間] の順に選択したスクリーンショット。

  7. 次のスクリーンショットに示すように、 [Advanced オプション ] タブを展開し、[ IIS ] チェック ボックスをオンにします。

    ユーザーが指定した間隔でデータを収集するスクリーンショット。

    ASP.NET Core アプリケーションを実行している場合は、 追加プロバイダーに次の文字列を追加します。

    *Microsoft-Extensions-Logging:4:5,Microsoft-AspNetCore-Server-Kestrel,System.Net.Http,System.Net.Sockets,System.Net.NameResolution,System.Threading.Tasks.TplEventSource::5,Microsoft-System-Net-Http,Microsoft-Windows-Application Server-Applications::Verbose

    Note

    最初にアスタリスク (*) を見逃さないでください。

問題の発生時にデータを収集する

問題が発生している間は、次の手順に従ってデータを収集します。

  1. PerfView の Start Collection ボタンを選択し、問題の前に Configure PerfView と Procdump で設定した構成設定を します。

  2. [インターネット インフォメーション サービス (IIS) マネージャー] を開きます。

  3. サーバー名 (左側) を選択します。

  4. Worker プロセスをダブルクリックして、サービスの Process Id を表示します。 例えば次が挙げられます。

    IIS マネージャーのワーカー プロセスのスクリーンショット。

  5. 管理者として [コマンド プロンプト] を開きます

  6. コマンド プロンプト ウィンドウでcd <path to procdump.exe>を実行して、procdump.exeが抽出されるフォルダーに移動します。

  7. 次のコマンドを実行して、連続するダンプをキャプチャします。

    procdump.exe -accepteula -ma <PID of W3WP.exe)> -s 10 -n 3

    Note

    <PID of W3WP.exe>を、手順 4 で見つけたW3WP.exe プロセスの実際の PID に置き換えます。

    • コマンドの末尾にパスを指定して、ダンプを特定の場所に格納できます。
    • このコマンドは、10 秒間隔で 3 セットのダンプをキャプチャします。

  8. procdump によってダンプが収集されたら、 Stop collection を選択して PerfView を停止するか、自動的に停止するまで 2 分半待ちます。 PerfView に収集されたデータのマージを許可します。時間がかかる場合があります。 また、 Perfview.etl.zip ファイルが生成されます。 シンボルの入力を求めるメッセージが表示されたら、[ Microsoft シンボル サーバーの使用を選択します。

詳細

  • Last updated on