error_page 用于内部重写而非重定向,要实现404跳转搜索页需配合命名location与return 302;例如error_page 404 @to_search,再在@to_search中执行return 302 /search?q=$uri。

error_page 是 Nginx 中用于捕获并处理 HTTP 错误状态码(如 404、500)的核心指令,但它本身不支持直接跳转到外部 URL 或执行重定向(302/301),而是将请求内部重写(internal redirect)到指定的 URI。要实现“404 自动跳转到自定义搜索页”,关键在于配合 location 块与 return 302(或 rewrite ... redirect)完成真正的客户端重定向。
error_page 的本质是内部重写,不是 HTTP 重定向
Nginx 的 error_page 404 /search.html; 并不会让浏览器地址栏变成 /search.html,而是将 404 请求在服务端悄悄转发过去——用户看到的仍是原 URL,状态码也仍是 404(除非 location 中显式改写)。这常被误解为“跳转”,实则只是错误页面渲染。
- ✅ 正确用途:返回友好的静态 404 页面(如
/404.html) - ❌ 无法直接实现:浏览器地址栏变化、发送 302 状态码、携带原始请求参数到新页面
实现真正跳转:用 error_page + named location + return 302
要让访问不存在路径时,浏览器自动跳转到 /search?q=xxx(例如带关键词的搜索页),需借助命名 location(@name)解耦逻辑,并在其中执行重定向:
server {
listen 80;
server_name example.com;
<pre class="brush:php;toolbar:false;"># 捕获 404,转发到命名 location
error_page 404 @to_search;
location @to_search {
# 提取原始请求 URI(可选:提取路径名作为搜索词)
set $search_query $uri;
# 清洗:去掉开头的 /,避免空格或特殊字符问题(生产环境建议用 map 或 Lua 做更安全处理)
if ($search_query ~* "^/(.+)$") {
set $search_query $1;
}
# 执行 302 重定向到搜索页,带查询参数
return 302 /search?q=$search_query;
}
location /search {
# 你的搜索页后端或静态页
try_files $uri /index.html;
}}
这样,当用户访问 /nonexistent-page 时,Nginx 返回 302,浏览器跳转至 /search?q=nonexistent-page,地址栏更新,SEO 友好,且可由前端或后端解析 q 参数做搜索建议。
进阶:根据 Referer 或 User-Agent 做差异化跳转
若希望仅对站内链接 404 跳搜索页,而对爬虫或直接访问返回标准 404,可在命名 location 中加判断:
- 用
$http_referer匹配本站域名,确认来源是站内 - 用
$http_user_agent过滤常见爬虫(如 Googlebot),避免误导搜索引擎 - 示例片段:
location @to_search { if ($http_referer ~* "https?://(www\.)?example\.com") { return 302 /search?q=$uri; } # 否则返回标准 404 页面 return 404; }
注意事项与避坑指南
实际配置中容易忽略以下细节:
- error_page 必须在 server 或 http 块中声明,不能放在普通 location 内(否则作用域受限)
- return 302 后的 URL 最好用绝对路径(以 / 开头),相对路径可能因上下文出错
-
避免循环重定向:确保
/searchlocation 不再触发 404(例如通过try_files或 proxy_pass 落地) -
中文或特殊字符需编码:URI 中含中文时,$uri 已是编码后的,但若手动拼接,建议用
$request_uri或 Nginx 1.11.8+ 的urlencode功能(需配合 Lua 模块)
不复杂但容易忽略:error_page 是入口,真正的跳转动作必须在独立 location 中用 return 或 rewrite 完成。理清“内部重写”和“HTTP 重定向”的边界,就能稳稳控制 404 的用户体验走向。










