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> 捕获的场景（比如某些模块初始化失败）。这时候连重定向都不可靠，得靠日志+监控提前暴露问题。
