排查 4xx 和 5xx HTTP 错误

本文提供解决 Internet Information Services （IIS） 中 4xx 和 5xx HTTP 状态代码错误的故障排除步骤。 4xx 状态代码指示客户端存在问题，5xx 状态代码表示服务器端存在问题。 本指南将帮助你识别这些错误的原因并有效地解决这些问题。

识别 4xx 错误

4xx HTTP 状态代码指示由于客户端问题而发生错误。 例如，客户端浏览器可能请求了不存在的页面，或者客户端浏览器可能未提供有效的身份验证信息。

若要识别 4xx 错误，请检查 IIS 日志 和 HTTPERR 日志：

• HTTP 状态代码记录在 IIS 日志中。 此文件通常存储在 C：\inetpub\logs\Logfiles 中，但可以通过 IIS 管理器中的 IIS 日志记录 进行配置。

• 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 的一种方法是在客户端上收集 HAR 跟踪文件，并查找响应标头 Microsoft-HttpApi/2.0。

  若要捕获用于记录浏览器与网站的交互的 HAR 跟踪文件，请按照捕获浏览器跟踪中的 说明进行故障排除。

检查 IIS 日志

如果在 IIS 日志中发现错误，请记下状态代码（sc-status）和子状态代码（sc-substatus），并查看 HTTP 状态代码概述 以了解详细信息。

若要获取有关状态代码的详细信息并了解哪个模块或处理程序返回 了 4xx 错误，请在问题发生时收集 失败的请求跟踪（FREB）日志 ，方法是将 FREB 规则配置为由 IIS 日志中看到的状态代码触发。

检查 HTTPERR 日志

如果在 HTTPERR 日志中找到错误，请记下原因（s-reason）并查看 HTTP 服务器 API 记录的错误类型以了解详细信息。

识别 5xx 错误

5xx HTTP 状态代码指示服务器无法完成请求，因为服务器在处理请求时遇到错误。 根据应用程序类型使用以下说明。

经典 ASP 中的 500 个错误

如果经典 ASP 中出现 500 错误，请检查 IIS 日志查询中的 cs-uri-query 错误代码或错误消息。

有关详细信息，请捕获并检查 500 错误的失败请求跟踪（FREB）日志 。

常规 IIS 中出现 500 个错误

如果一般 IIS 中出现 500 错误，请检查 IIS 日志，记下状态代码（sc-status）和子状态代码（sc-substatus），并查看 HTTP 状态代码概述 ，了解有关失败的详细信息。

如果可行，请启用详细的错误消息以获取更多详细信息。 若要启用详细的错误消息，请执行以下步骤：

1. 打开“运行”命令窗口。

2. 启动“inetmgr”。

3. 在 IIS 管理器中 ，在控制台左侧的“连接 ”窗格下，展开计算机名称，展开 “站点”，然后选择目标网站。

   

4. 双击中间窗格中的 “错误页” 图标。

   

5. 在右侧的“作”窗格中，选择“编辑功能设置”。

   

6. 在 “编辑错误页设置” 对话框中（选择同时发送本地和远程请求），第二个选项按钮是需要选择的选项，以返回本地和远程请求的详细错误。 默认情况下，选择底部选项以仅发送针对本地请求发送的详细错误。

   

   不建议为远程请求发送详细错误，因为此选项可能会向 Internet 公开敏感信息。 在获取有关失败的详细信息后，需要还原更改。

有关详细信息，请捕获并检查 500 错误的失败请求跟踪（FREB）日志 。

ASP.NET 中的 500 个错误

如果在 ASP.NET 中出现 500 错误，请使用以下方法来标识错误的根本原因：

• 检查应用程序事件日志。

  在发生问题时检查应用程序事件日志。 ASP.NET 将记录错误的详细信息，包括应用程序事件日志中的调用堆栈。

  若要访问应用程序事件日志，请执行以下步骤：

  1. 打开“开始”菜单，搜索事件查看器，然后选择事件查看器。
  2. 在“事件查看器”中，打开“Windows 日志”节点。
  3. 选择“应用程序”以打开应用程序事件日志。
  4. 搜索与失败的应用程序关联的错误。 错误的源列中的值是 IIS AspNetCore 模块或 IIS Express AspNetCore 模块。

• 捕获内存转储。

  在某些情况下，可能需要捕获特定异常的内存转储，以检查导致 500 HTTP 状态的异常周围的详细信息。

  若要捕获转储，请按照“收集内存转储”中的 说明在发生时出现首次发生异常。

  将 DebugDiag 2 分析工具（调试调试套件的一部分）与收集的转储上的 CrashHangAnalysis 规则配合使用，生成可用于查看调用堆栈并识别根本原因的报告。

  若要使用 DebugDiag 分析工具生成报表，请执行以下步骤：

  1. 打开 DebugDiag 2 分析。
  2. 选择“ 添加数据文件 ”并添加 .dmp 文件（s）。
  3. 选择 CrashHangAnalysis 和 PerfAnalysis，然后选择“开始分析”。

  完成后，将在 C：\Program Files\DebugDiag\Reports 中创建报表（.mht），并在 Internet Explorer 中显示结果和建议。

  如果使用自定义 DLL，可以按照以下步骤为自定义 PDB 文件指定符号搜索路径：

  1. 打开 DebugDiag 2 集合工具。
  2. 选择>>文件夹和搜索路径。
  3. 在“用于调试的符号搜索路径”下，选择“浏览”以设置路径。

• 捕获 Perfview 跟踪以识别 ExecutionTimeout 问题。

  对于由于超过 ASP.NET ExecutionTimeout 而导致的 500 个错误， 请捕获 PerfView 跟踪并转储 以识别任何延迟。

ASP.NET Core 中的 500 个错误

如果在 ASP.NET Core 中出现 500 错误，请使用以下方法来标识错误的根本原因：

• 检查应用程序事件日志。

  若要访问应用程序事件日志，请执行以下步骤：

  1. 打开“开始”菜单，搜索事件查看器，然后选择事件查看器。
  2. 在“事件查看器”中，打开“Windows 日志”节点。
  3. 选择“应用程序”以打开应用程序事件日志。
  4. 搜索与失败的应用程序关联的错误。 错误的源列中的值是 IIS AspNetCore 模块或 IIS Express AspNetCore 模块。

• 启用“开发人员例外”页。

  ASPNETCORE_ENVIRONMENT可以将环境变量添加到 web.config，以在开发环境中运行应用程序。 如果不使用 UseEnvironment 主机生成器上的方法替代应用程序的启动代码中的环境设置，则环境变量允许 在应用程序运行时显示开发人员异常页 。

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

  ASPNETCORE_ENVIRONMENT建议仅在暂存和测试服务器上不向 Internet 公开环境变量。 在故障排除后从 web.config 文件中删除环境变量。

• 启用 ASP.NET 核心模块 stdout 日志。

  若要启用和查看 stdout 日志，请执行以下步骤：

  1. 在托管系统上导航到站点的部署文件夹。

  2. 如果 logs 文件夹不存在，请创建该文件夹。 有关如何使 MSBuild 自动在部署中创建 日志 文件夹的说明，请参阅 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 和文件扩展名。 典型的日志文件名称是 stdout_<timestamp>_<PID>.log。

  5. 请确保应用程序池的标识具有对日志文件夹的写入权限。

  6. 保存已更新的 web.config 文件。

  7. 向应用程序发出请求。

  8. 导航到 logs 文件夹。 查找并打开最新的 stdout 日志。

  9. 调查日志中的错误。

  若要在故障排除完成后禁用 stdout 日志记录，请执行以下步骤：

  1. 编辑 web.config 文件。
  2. 将 stdoutLogEnabled 设置为 false。
  3. 保存文件。

• 启用 ASP.NET 核心模块调试日志（IIS）。

  若要启用 ASP.NET 核心模块调试日志，请将以下处理程序设置添加到应用程序的 web.config 文件中：

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

  确认为日志指定的路径存在，并且应用程序池的标识对位置具有写入权限。

ARR 中的 502 错误

如果在应用程序请求路由（ARR）中出现 502 错误，请按照 ARR 中 502 错误故障排除中的说明作。

503 错误

如果遇到 503 错误，IIS 日志或 HTTPERR 日志sc-substatus子状态代码 （s-reason） 可以提供一些提示。

有关详细信息，请参阅：

• 503 - 服务不可用
• HTTP 服务器 API 中的错误日志记录

另请参阅以下文章，其中重点介绍了可能导致 503 错误的已知问题：

IIS 中的 HTTP 响应 503 服务不可用：一个常见的通用原因

数据收集

捕获 FREB 日志的步骤

重要

若要配置 FREB 日志，请确保 为 IIS 安装跟踪 角色服务。

若要安装 IIS 的 跟踪 角色服务，请执行以下步骤：

1. 打开服务器管理器，然后选择“管理>添加角色和功能”。
2. 在“添加角色和功能向导”窗口中，选择“下一步”，直到到达“服务器角色”页。
3. 展开 Web 服务器（IIS）>Web 服务器>运行状况和诊断，然后选择“跟踪”复选框。
4. 为后续步骤选择“ 下一步 ”，然后选择“ 安装”。

安装跟踪角色服务后，请按照以下步骤捕获 FREB：

1. 打开“运行”命令窗口。

2. 启动“inetmgr”。

3. 在 IIS 管理器的 “连接 ”窗格中，展开计算机名称，展开 “站点”，然后选择目标网站。

   

4. 双击“失败请求跟踪规则”。

   

5. 在 “作 ”窗格中，选择“ 添加”。

6. 在“添加失败的请求跟踪规则”向导的“指定内容到跟踪”页上，选择“下一步的所有内容>”。

   

7. 在“ 定义跟踪条件 ”页上，将 “状态代码” 字段更新为 400-600 ，然后选择“ 下一步”。

   

8. 在“选择跟踪提供程序”页上的“提供程序”下，选中所有复选框。 在“区域”下，确保为每个提供程序选中所有复选框。 在“详细程度”下，选择“详细”。 选择“完成”。

9. 为站点启用 失败的请求跟踪 并配置日志文件目录：

   1. 在 “连接 ”窗格中，展开计算机名称，展开 “站点”，然后选择“ 默认网站”。

   2. 在“作”窗格中的“配置”下，选择“失败的请求跟踪”。

      

   3. 在“编辑网站失败请求跟踪设置”对话框中，选中“启用”复选框，将目录字段设置为 %SystemDrive%\inetpub\logs\FailedReqLogFiles，并将最大跟踪文件数设置为 1000。

      

   4. 选择“确定”。

捕获 PerfView 跟踪和转储的步骤

若要捕获 PerfView 跟踪和转储，请按照以下部分中的步骤进行作。

在问题之前配置 PerfView 和 Procdump

在出现问题之前，请按照以下步骤为数据收集配置 PerfView 和 Procdump：

1. 下载 ProcDump。 它是一个不需要安装和自动执行转储收集的轻型可执行文件。

2. 将 procdump.exe 文件提取到服务器上的特定文件夹。

3. 在 服务器上下载 PerfView 工具。 它是一个探查器工具，用于捕获 Windows 事件跟踪（ETW）事件（无需安装）。

4. 若要使 PerfView 提供有用的信息，请将跟踪添加为 IIS 的角色服务。 如果未 启用跟踪 ，ETW 跟踪将仅包含 HTTP.sys 信息。 如果不确定是否 安装了跟踪 角色服务，请执行以下步骤：

   1. 打开服务器管理器，然后选择“管理>添加角色和功能”。
   2. 在“添加角色和功能向导”窗口中，选择“下一步”，直到到达“服务器角色”页。
   3. 展开 Web 服务器（IIS）>Web 服务器>运行状况和诊断，然后选择“跟踪”复选框。
   4. 为后续步骤选择“ 下一步 ”，然后选择“ 安装”。

5. 打开 PerfView 工具，选择“收集”菜单，然后选择“收集”选项。

6. 选中“Zip”、“合并”和“线程时间”复选框，如以下屏幕截图所示。 将 “循环 MB ”字段修改为 2000：

   

7. 展开“高级选项”选项卡并选择 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

   备注

   不要错过星号 （*） 开头。

在问题期间收集数据

在问题发生期间，请按照以下步骤收集数据：

1. 选择 PerfView 中的“开始收集”按钮，并在问题部分之前在“配置 PerfView”和“Procdump”中设置的配置设置。

2. 打开“Internet Information Services (IIS)管理器” 。

3. 选择服务器名称（左侧）。

4. 双击“工作进程”以查看服务的进程 ID。 例如：

   

5. 以管理员身份打开命令提示符。

6. 在命令提示符cd <path to procdump.exe>，导航到提取procdump.exe的文件夹。

7. 运行以下命令以捕获连续转储。

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

   备注

   替换为<PID of W3WP.exe>在步骤 4 中找到的W3WP.exe过程的实际 PID。

   • 可以在命令末尾指定一个路径，以将转储存储在特定位置。
   • 此命令将按 10 秒间隔捕获三组转储。

8. 通过 procdump 收集转储后，选择“停止收集”停止 PerfView，或等待两个半分钟自动停止。 允许 PerfView 合并收集的数据，这可能需要一些时间。 它将生成Perfview.etl.zip文件。 如果系统提示输入符号，请选择“ 使用Microsoft符号服务器”。

详细信息

• 4xx 状态代码 - 客户端错误
• 5xx 状态代码 - 服务器错误