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 的用户体验走向。
