Nginx需关闭proxy_intercept_errors并用error_page 404 = @to_search配合internal location实现带原始路径参数的动态重定向，避免静态error_page局限。

nginx 中 proxy_intercept_errors 进阶：如何将后端 404 错误转发至公共搜索页

默认情况下，Nginx 在开启 proxy_intercept_errors on 后，会用自身配置的 error_page 404 拦截后端返回的 404，并停止向客户端透传原始响应。但若想把这类 404 动态重定向到带原始请求路径参数的公共搜索页（例如 /search?q=/article/missing），需绕过静态错误页机制，改用状态码判断 + 内部重写组合实现。

核心思路：不依赖 error_page，改用 proxy_next_upstream 和内部重定向

直接用 error_page 404 只能跳转固定 URL，无法携带原始 URI。更灵活的做法是：让 Nginx 接收后端 404 响应后，不拦截、不替换，而是通过变量捕获状态码，在 location 中做条件判断并内部重定向。

关闭 proxy_intercept_errors（设为 off），确保 404 响应能被 Nginx 正常接收并进入后续处理流程
使用 proxy_pass_request_body off 和 proxy_set_header 确保重定向时不误传原始请求体
借助 $upstream_http_content_type 或 $upstream_status 判断上游响应状态
用 if ($upstream_status = '404') { rewrite ^(.*)$ /search?q=$1? redirect; } 实现动态跳转（注意：if 在 location 中可用，但需配合 proxy_pass 的上下文）

推荐方案：用 named location + internal 重定向避免循环

更健壮的方式是将重定向逻辑分离到一个内部 location，避免在主 proxy location 中直接 if + rewrite 导致潜在循环或 header 冲突：

location / {
    proxy_pass http://backend;
    proxy_intercept_errors off;
<pre class="brush:php;toolbar:false;"># 捕获 404 后跳转到内部命名 location
error_page 404 = @to_search;

}

CPA Update - Secure CLI Proxy API Maintenance

安全更新和维护 CLI Proxy API（CPA）部署与配置。用于 CPA 镜像升级、配置变更、认证目录兼容修复、上线验证与回滚。适用于用户提到“CPA 更新/升级/配置改了/容器重建/回滚”等场景。

下载

location @to_search { internal;

构造搜索参数：原始请求路径作为 q 值，URL 编码由 Nginx 自动处理

return 302 /search?q=$request_uri;

}

该方式安全可靠：internal 保证该 location 只能被内部跳转访问，不会被外部直接请求；return 302 发起浏览器重定向，用户地址栏显示搜索页，且搜索引擎可正常收录跳转意图。

增强体验：保留原始 Accept 头、支持 POST 回退（可选）

若后端 404 常出现在表单提交等场景，直接 302 会丢失 POST 数据。此时可考虑服务端渲染搜索页并预填关键词：

后端搜索页（如 /search）接收 q 参数后，自动展示“未找到 ‘/xxx’，为您搜索相关结果”
Nginx 不强制跳转，改为用 proxy_pass 转发到搜索服务： location @to_search { internal; proxy_pass http://search_service/search?q=$request_uri; }
确保搜索服务能正确解析 $request_uri（含 query string），必要时用 $uri 或 $args 拆分

调试关键点

启用以下配置快速验证是否生效：

log_format debug '$remote_addr - $remote_user [$time_local] "$request" $status $body_bytes_sent "$http_referer" "$http_user_agent" "$upstream_addr" "$upstream_status" "$request_uri"';
查看日志中 $upstream_status 是否为 404，$status 是否变为 302 或 200（取决于是否用 internal）
用 curl -v http://yourdomain/missing-path 观察响应头 Location 或响应体是否来自搜索页