直接拦截 OPTIONS 请求并返回 204 是最高效方案：在 location 块中用 if 判断请求方法，匹配即 return 204，且所有 CORS 头需加 always 参数确保生效，避免透传或后端参与。

直接拦截 OPTIONS 请求，不走 proxy_pass，是最有效避免开销的方式。浏览器预检只看响应头和状态码，不需要后端参与，转发纯属浪费资源。

显式拦截并立即返回 204

在 location 块中用 if 判断请求方法，匹配到 OPTIONS 就 return 204，彻底绕过代理链：

• 写法示例：if ($request_method = 'OPTIONS') { return 204; }
• 必须放在 proxy_pass 之前，否则会被转发出去
• return 204 是最轻量的响应，无 body、低延迟、零后端压力

所有 CORS 头必须加 always 参数

add_header 默认不作用于 return 响应，不加 always 就等于没加：

CPA Update - Secure CLI Proxy API Maintenance

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

下载

• add_header 'Access-Control-Allow-Origin' '*' always;
• add_header 'Access-Control-Allow-Methods' 'GET, POST, OPTIONS' always;
• add_header 'Access-Control-Allow-Headers' 'Content-Type, Authorization' always;
• 漏掉 always，OPTIONS 响应里就看不到这些头，浏览器直接拒绝后续请求

避免 location 冲突或 fallback 触发

OPTIONS 请求若未被显式处理，Nginx 可能走默认流程，导致 405 或透传失败：

• 确认该 location 没有其他限制（如 limit_except、deny）意外拦截 OPTIONS
• 不要依赖后端实现 OPTIONS 路由——既增加延迟，又暴露内部结构
• 若用了正则 location（如 location ~ \.(js|css)$），需确保它不意外匹配 /api/ 这类路径，否则可能因 404 触发 error_page 重定向，间接引发循环

精简配置，不引入冗余逻辑

无需额外 upstream、健康检查或超时设置——OPTIONS 是瞬时响应，跟后端连接池、keepalive 完全无关：

• 不要为 OPTIONS 单独配 proxy_set_header 或 proxy_http_version
• 不必启用 proxy_buffering off 等流式优化，它不适用
• 整个处理应在 1 次 Nginx 内部调度内完成，毫秒级响应