nginx错误页需综合配置root/alias定位资源、internal限制访问、状态码保留或覆盖、变量透传增强体验、map实现终端差异化响应，缺一不可。
直接用 error_page 指令就能接管错误响应，但真正让页面“稳、准、好”地返回，关键不在写几行配置，而在理解它怎么重定向、状态码怎么留、变量怎么传、资源怎么加载。
确保错误页能被正确服务
只写 error_page 404 /404.html 不够——Nginx 得知道这个 /404.html 文件在哪、能不能读、要不要限制访问。
- 用
root定义根路径时，/404.html会拼成root + /404.html，比如root /var/www;→ 实际找/var/www/404.html - 用
alias更精确：若设alias /usr/share/nginx/html/;，那么location = /404.html { alias /usr/share/nginx/html/404.html; }会直接映射到该文件 - 加
internal是安全习惯：防止用户手动访问/404.html暴露错误页路径，也避免绕过业务逻辑
状态码保留与覆盖要分清场景
默认情况下，Nginx 把 404 交给 /404.html 处理后，仍返回 404 状态码；但你可以主动改，只是得想清楚为什么改。
- 保留原状态码（推荐）：
error_page 404 /404.html;→ 浏览器和搜索引擎看到的仍是 404，利于 SEO 和调试 - 显式保留（更明确）：
error_page 404 =404 /404.html;，语义清晰，适合多人协作环境 - 覆盖为 200（慎用）：
error_page 404 =200 /fallback.html;，仅适用于兜底页需被爬虫收录或前端 SPA 路由降级等特殊场景
把原始请求信息带进错误页
用户看到“页面未找到”，如果还能告诉他“您刚才访问的是 /blog/abc”，体验会明显提升。Nginx 支持在 error_page 后追加查询参数透传。
- 基础写法：
error_page 404 /error.html?uri=$request_uri&status=404; - 变量可用范围广：
$host、$scheme、$args都能用，组合出完整上下文 - 注意编码与安全：参数值自动 URL 编码，但若前端 JS 直接 innerHTML 渲染，仍需做 XSS 过滤
按条件分发不同错误页
API 调用者（如 curl）不需要 HTML 页面，移动端和桌面端的样式也可以不同。用 map + 变量就能实现差异化响应。
- 先定义类型映射：
map $http_user_agent $err_type { ~*curl|wget "text"; ~*mobile "mobile"; default "desktop"; } - 再关联页面：
error_page 404 /err/404_$err_type.html; - 搭配静态资源分离：不同终端的 HTML、CSS、JS 分开放，避免冗余加载
