error_page必须配置在server块内实现虚拟主机级隔离,需确保错误页文件存在、location显式放行且权限正确,否则将触发404套娃或返回默认白页。

能配,但必须同时满足三个条件:错误页面文件存在且路径正确、error_page 指令位置合理、对应 location 块显式放行该 URI —— 少一个都会 404 套娃或返回默认白页。
error_page 指令写在哪?server 还是 http?
优先写在 server 块里,按需下沉到 location;全局统一处理才放 http 块。
-
error_page 404 /404.html;放server内,只影响这个域名 - 若某段路径(如
/api/)想用不同错误页,就写在对应location /api/里 - 放在
http块的配置会被所有server继承,但容易被子块覆盖,调试时难定位 - 别在
if块里写error_page—— Nginx 不支持,会静默忽略
为什么访问 /404.html 仍是 404?location = /404.html 必须配
error_page 404 /404.html 只是“重定向”,不等于“能返回这个文件”。Nginx 还得知道怎么找它、有没有权限读、返回什么 MIME 类型。
Zynq‑7000 / Zynq UltraScale+ 硬件调试技能。适用于 Xilinx Zynq(Cortex‑A9/A53 + FPGA)Linux 环境,调试 I2C、I2S、UART、GPIO 等外设。包括设备树配置、内核驱动、用户空间调试工具、交叉编译和常见问题排查,支持 PetaLinux 开发。
- 必须加
location = /404.html { root /var/www/html; },且root路径要包含该文件(即实际文件是/var/www/html/404.html) - 不能写
location /404.html(少等号)—— 这会匹配所有以/404.html开头的请求,比如/404.htmlxss也中招 - 如果用了
alias,注意末尾斜杠:alias /var/www/errors/;(带斜杠),否则路径拼接出错 - 确保
types { text/html html; }或已include mime.types;,否则浏览器可能下载404.html而不是渲染
反向代理后端返回 404,Nginx 不触发 error_page?
默认情况下,Nginx 把后端返回的 404 当作正常响应透传,不会拦截。必须显式开启拦截开关。
- 在
location块里加proxy_intercept_errors on;,才能让 Nginx 拦住后端返回的 4xx/5xx 并走自己的error_page - FastCGI(如 PHP)场景下,对应指令是
fastcgi_intercept_errors on;,要放在http或location ~ \.php$里 - 如果后端返回的是 200 + 自定义错误 HTML,那
error_page完全无效 —— 它只认 HTTP 状态码,不解析响应体 - 开启
proxy_intercept_errors后,记得确认后端确实返回了标准 404,用curl -I验证状态码
图片、CSS 加载失败?静态资源路径没对齐
错误页面里的 <img src="/img/404-bg.jpg"> 能否加载,取决于它是否落在某个可访问的 location 下,和主站静态资源配置无关。
- 最稳做法:把图片和错误页放同一目录,用相对路径引用(如
<img src="404-bg.jpg">),并确保location = /404.html的root覆盖该目录 - 若用绝对路径(
/img/xxx),就得额外配location /img/,指定其root或alias - 别指望
try_files帮你兜底 —— 它在error_page触发前就执行完了,错误页请求不会进try_files流程 - 浏览器控制台报 404 加载图片?先
curl http://yourdomain/img/404-bg.jpg看是否真返回 404,再查 Nginx access log 定位哪个location拦截了它
最容易被忽略的其实是权限和 MIME 类型:文件 chmod 644、Nginx 工作进程用户(如 www-data)有读取权限、Content-Type: text/html 必须正确返回 —— 这三样缺一不可,否则页面要么打不开,要么被当成附件下载。










