Web.config customErrors配置 IIS错误页面的重定向模式

customErrors 的 redirect 模式仅在 iis 集成模式下生效，经典模式下无法处理 iis 层错误；需配合 httperrors 且正确配置 statuscode 子节点与 mode 设置。

customErrors 的 redirect 模式只在 IIS 集成管道下生效

如果你在 IIS 经典模式（Classic Mode）下配置了 <customerrors mode="On" redirect="~/Error/500.aspx"></customerrors>，但 500 错误仍显示默认黄页或空白页，大概率是管道模式不匹配。IIS 集成模式（Integrated Mode）才真正接管 ASP.NET 的错误生命周期，经典模式下 customErrors 仅处理托管异常，对 IIS 层面的 500（比如 web.config 解析失败、权限拒绝）完全无响应。

实操建议：

• 确认应用池管道模式：IIS 管理器 → 应用池 → 右键「高级设置」→ 查看 Managed Pipeline Mode 是否为 Integrated
• 若必须用经典模式，customErrors 无法兜底非托管错误，得靠 <httperrors></httperrors>（IIS 级）配合，且需关闭 existingResponse="auto" 干扰
• redirect 路径必须是相对应用根目录的 URL，不能是物理路径或绝对 URL（如 redirect="http://example.com/error" 会被忽略）

mode=”RemoteOnly” 下本地调试看不到自定义页

开发时经常发现：本地运行时抛出异常，却看到详细的黄页堆栈，而不是预期的 redirect 页面。这是因为 mode="RemoteOnly" 会检测 Request.IsLocal，只要请求来自 127.0.0.1 或本机主机名（包括 localhost），就强制显示详细错误——这是设计行为，不是 bug。

实操建议：

• 调试阶段想预览自定义页，临时改成 mode="On"，上线前务必改回 RemoteOnly（避免泄露敏感信息）
• 不要依赖修改 hosts 把 localhost 指向其他 IP 来绕过，IsLocal 判定逻辑更复杂，可能失效
• 如果用 VS 内置服务器（Cassini）或 Kestrel + IIS express，IsLocal 依然为 true，RemoteOnly 无效

HTTP 状态码不匹配导致重定向失败

配置了 redirect="~/Error/500.aspx"，但 404 请求却跳转到了 500 页面，或者 500 错误反而触发了 404 页面——根本原因是 customErrors 默认只按异常类型（而非 HTTP 状态码）分发，它没有原生支持按状态码路由；你看到的“按状态码跳转”，其实是靠 <error statuscode="404" redirect="..."></error> 子节点实现的，而这个子节点必须和 mode 同级，且只在 mode="On" 或 "RemoteOnly" 下生效。

实操建议：

• 要精确控制不同状态码的页面，必须显式声明 <error statuscode="404" redirect="~/Error/NotFound.aspx"></error> 等条目
• statusCode 值必须是整数（如 404），不能写成 "NotFound" 或 HttpStatusCode.NotFound
• 若同时配置了顶层 redirect 和子 <error></error>，子项优先级更高；但子项未覆盖的状态码会 fallback 到顶层 redirect
• IIS 的 <httperrors></httperrors> 是更底层的机制，当 customErrors 不生效时（如静态文件 404），它才起作用，二者常需协同

customErrors 不捕获 web.config 解析错误或启动异常

最常见的幻觉是：把 customErrors 当作“万能错误兜底”。实际上，它只在 ASP.NET 托管管线中生效。一旦 web.config 格式错误、<compilation></compilation> 引用不存在的 DLL、Global.asax 构造函数抛异常，甚至 Application_Start 中崩溃，请求根本进不到 customErrors 的作用域——IIS 会直接返回 500.19、500.21 等子状态码错误，此时只有 <httperrors></httperrors> 可干预。

实操建议：

• 验证 customErrors 是否生效的最快方式：在某个 .aspx 页面里手动 throw new Exception()，而不是改配置或删文件
• web.config 语法错误 → 查看 IIS 日志中的 0x8007000d 或检查事件查看器里的 ConfigurationErrorsException
• Application_Start 失败 → 错误日志在 windows 事件查看器的 ASP.NET x.x.x 日志源下，customErrors 完全不参与

真正难搞的是那些跨层错误：既不在 ASP.NET 管线内、又没被 IIS <httperrors></httperrors> 捕获的场景（比如某些模块初始化失败）。这时候连重定向都不可靠，得靠日志+监控提前暴露问题。