当网站后端应用崩溃或用户访问了不存在的资源时，Nginx若直接返回系统默认的错误页，不仅视觉突兀，还可能泄露版本号与路径结构。借助Nginx自带的error_page指令以及内部重定向机制，我们可以把各类HTTP错误码映射到自行设计的HTML页面，从而实现风格统一、信息友好的优雅显示。
error_page指令的基本用法与匹配逻辑
Nginx的error_page指令用于定义当发生指定状态码时应当如何处理响应。最简单的写法是在server块中声明error_page 404 /404.html;，这表示当请求返回404时，Nginx会在内部将URI重写为/404.html并再次查找该静态文件。这个过程对客户端透明，浏览器地址栏不会变化，但响应内容已经是自定义页面。
该指令支持同时配置多个状态码，例如error_page 500 502 503 504 /50x.html;。如果希望错误页本身由后端动态生成，也可以配合=修饰符与proxy_pass使用，但需注意内部重定向是否会被再次拦截。理解error_page的“内部重定向”本质非常关键：它并非外部302跳转，因此不会额外增加一次请求往返，也不会影响原始状态码的日志记录。
在复杂location结构中，error_page的继承规则遵循Nginx配置的一般层级覆盖原则。如果某个location中重新定义了error_page，那么只有该location内产生的错误会应用新规则。为了避免遗漏，通常建议将通用错误页放在server层级，再针对特定接口做差异化处理。下面是一段基础配置示例：
server {
listen 80;
server_name example.ipipp.com;
root /usr/share/nginx/html;
error_page 404 /custom_404.html;
error_page 500 502 503 504 /custom_50x.html;
location = /custom_404.html {
internal;
root /usr/share/nginx/html/errors;
}
location = /custom_50x.html {
internal;
root /usr/share/nginx/html/errors;
}
}
设计友好的错误页面内容与样式隔离
自定义错误页不仅是换一张图，更需要传递清晰的操作指引。优秀的404页应当告知用户“页面不存在”，并提供返回首页、搜索框或热门链接；50x页则应说明“服务临时不可用，请稍后重试”，降低用户焦虑。页面中尽量避免使用绝对路径引用CSS，而应采用相对路径或内联样式，防止错误页因路径重写而丢失样式。
由于error_page触发的内部重定向可能发生在任意原始URI下，若错误页使用/style.css这类绝对路径，浏览器会基于当前地址栏域名根目录请求，通常可以命中；但若使用相对路径./style.css，在深层路径下可能解析异常。最稳妥的方案是把核心样式直接写入HTML的<style>标签内，或者将静态资源放到独立域名或固定前缀下，并在Nginx中单独放行。
此外，错误页中可借助Nginx变量增强信息密度。例如通过server_name展示站点名，用request_uri回显用户访问路径，帮助排查问题。但要注意不要直接输出未转义的用户输入，避免反射型XSS。以下示例展示了带内联样式的静态错误页结构：
<!DOCTYPE html>
<html lang="zh-CN">
<head>
<meta charset="utf-8">
<title>页面未找到</title>
<style>
body { font-family: sans-serif; text-align: center; padding: 50px; }
.code { font-size: 80px; color: #999; }
a { color: #06f; }
</style>
</head>
<body>
<div class="code">404</div>
<p>抱歉，您访问的页面不存在</p>
<p><a href="/">返回首页</a></p>
</body>
</html>
避免重定向循环与缓存控制的实践要点
配置自定义错误页时最常见的故障是重定向循环。比如将error_page指向某个由PHP渲染的路由，而该路由自身又因异常返回500，此时若500错误页再次指向同一路由，就会形成死循环，最终Nginx返回“500 Internal Server Error”的默认页并写满错误日志。解决办法是为错误页location添加internal修饰符，禁止外部直接访问，同时保证错误页本身是纯静态或独立轻量服务。
另一个容易忽略的点是浏览器对错误响应的缓存。某些情况下，运营商或浏览器会缓存404页，导致资源恢复后用户仍看到旧错误。可以在错误页的location中通过add_header Cache-Control "no-store"禁用缓存。同时，若错误页由Nginx直接返回，原始状态码会保留在响应行，但如果你使用=200写法如error_page 404 =200 /404.html;，则会把状态码改为200，这有利于SEO但可能干扰监控告警，需按业务权衡。
最后，在容器化或多站点环境中，建议把错误页模板纳入配置管理，并通过include指令统一引入。这样新增站点只需引用同一份错误页配置，既能保持体验一致，也方便后续改版。下例展示如何使用include与变量组合，实现一套配置适配多个server：
# 在 /etc/nginx/conf.d/error_pages.conf 中定义
error_page 403 /403.html;
error_page 404 /404.html;
error_page 500 502 503 504 /50x.html;
location ^~ /40x.html {
internal;
root /var/www/error;
}
location ^~ /50x.html {
internal;
root /var/www/error;
}
# 在各server中引入
server {
listen 80;
server_name a.ipipp.com;
include /etc/nginx/conf.d/error_pages.conf;
}
通过上述分层设计与细节把控，Nginx错误页面可以从生硬的默认提示转变为用户体验闭环的一部分。关键在于理解内部重定向机制、隔离样式依赖、规避循环并合理设置缓存与状态码，这样才能在故障时刻依然保持站点的专业度与可用性。
Nginxerror_page自定义错误页修改时间：2026-08-14 20:30:32