Nginx可通过error_page 404配合return 302实现404时自动跳转搜索页并携带$request_uri参数，如配置error_page 404 = @search_redirect; location @search_redirect { return 302 /search?q=$request_uri; }。
在 Nginx 中，error_page 本身不直接支持“跳转到搜索页并自动带入原请求路径”这种逻辑，但它可以配合 return 或 rewrite 指令，结合变量（如 $request_uri 或 $uri），实现 404 时重定向到站内搜索页，并将原始路径作为关键词或参数传递过去——这是提升用户体验、降低跳出率的实用技巧。
核心思路：用 error_page 捕获 404，再用 return 302 跳转带参搜索页
关键在于：Nginx 的 error_page 404 可以指向一个自定义 location，该 location 内使用 return 302 发起重定向，并把 $request_uri（含查询参数）或 $uri（不含参数）作为搜索关键词传给你的搜索接口。
-
推荐用
$request_uri：它保留完整请求路径+query，比如访问/blog/abc404 后可跳转到/search?q=/blog/abc - 若搜索页只接受纯路径（如去掉问号后内容），可用
$uri替代 - 确保目标搜索页（如
/search）能正确解析并展示该关键词的结果，这部分由后端或前端实现
配置示例：Nginx 站点中添加 404 自动搜索跳转
在 server 块中加入以下配置：
error_page 404 = @search_redirect;
<p>location @search_redirect {
return 302 /search?q=$request_uri;
}说明：
-
=表示内部重定向（不改变响应状态码为 404，而是执行后续逻辑） -
@search_redirect是命名 location，仅用于内部跳转，不会暴露给客户端 -
return 302发起临时重定向，浏览器地址栏会更新为搜索页链接 - 如果希望永久重定向，改用
301，但注意缓存影响，调试阶段建议用302
进阶技巧：对特定路径做差异化处理
并非所有 404 都适合跳搜索页。例如静态资源（.js/.css/.png）404 应直接返回 404，避免误导用户；而文章路径（如 /post/xxx）才触发搜索跳转。
- 用
location ^~ /post/单独匹配文章路径，内部设error_page 404 = @search_redirect - 在通用 server 块中，把
error_page 404移到更靠后的层级，或用if (!-e $request_filename)+return组合替代 - 也可在
@search_redirect中加判断：if ($request_uri ~* "\.(js|css|png|jpg|gif)$") { return 404; }，但需注意 if 在 location 中的限制
验证与注意事项
配置完成后务必测试：
- 访问一个确定不存在的路径（如
/this-page-does-not-exist），观察是否 302 跳转到/search?q=/this-page-does-not-exist - 检查浏览器地址栏和网络面板中的重定向链，确认无循环（比如搜索页本身又 404 导致再次跳转）
- 确保你的
/search接口能安全接收并解码 URI 参数（如空格、斜杠需 URL 解码） - Nginx 变量在
error_page上下文中可用，但部分变量（如$args）可能需组合使用，优先用$request_uri更稳妥
