options请求被“误拦”根本原因是nginx自身生成的405/501响应不经过proxy_pass，proxy_intercept_errors对其无效；正确做法是显式处理options预检并返回204。
OPTIONS 请求被 proxy_intercept_errors 错误拦截，根本原因在于：它**不是后端返回的错误响应，而是 Nginx 自身对预检请求的默认处理行为**——而 proxy_intercept_errors 只作用于 proxy_pass 流量中后端返回的 ≥400 状态码，对 Nginx 自己生成的 405、501 等响应完全无效。
为什么 OPTIONS 请求会被“误拦”
常见误解是：开了 proxy_intercept_errors on; 就会拦截所有错误。但事实是：
aperture: the L402 aware reverse proxy
下载
安装并运行 Aperture（Lightning Labs 的 L402 闪电反向代理），用于创建 L402 付费墙、配置付费 API 端点、为其他代理托管付费内容或测试 L402 认证流程。
-
proxy_intercept_errors仅拦截 后端真实返回 的 4xx/5xx（如 MinIO 返回的 404 或 502） - 当 Nginx 配置中没有匹配的
location处理 OPTIONS 请求时，它会自己返回 405 Method Not Allowed 或 501 Not Implemented ——这类响应由 Nginx 内部生成，不经过proxy_pass，因此proxy_intercept_errors完全不生效 - 此时若你又配了
error_page 405 /405.html;，就会意外触发该页面，看起来像“被拦截”，实则是 Nginx 在兜底处理自身错误
真正要解决的是 OPTIONS 预检失败，不是关拦截
跨域预检失败（如报 Access-Control-Allow-Origin missing）通常与 proxy_intercept_errors 无关，关键在三点：
-
必须显式放行 OPTIONS 方法：在代理 location 中加
if ($request_method = 'OPTIONS') { add_header Access-Control-Allow-Origin '*'; add_header Access-Control-Allow-Methods 'GET, POST, PUT, DELETE, OPTIONS'; add_header Access-Control-Allow-Headers 'DNT,User-Agent,X-Requested-With,If-Modified-Since,Cache-Control,Content-Type,Range,Authorization'; add_header Access-Control-Max-Age 1728000; add_header Content-Length 0; add_header Content-Type 'text/plain; charset=utf-8'; return 204; } -
确保 Origin 头透传给后端：加
proxy_set_header Origin $http_origin;，否则 MinIO 等服务无法做 CORS 决策 - 不要让 OPTIONS 走 proxy_pass：预检应由 Nginx 直接响应（204），避免转发给后端再绕回来；若必须转发，需确认后端支持并正确返回 CORS 头
proxy_intercept_errors 相关配置建议
为避免干扰，对 OPTIONS 场景应：
- 在处理静态资源或 API 代理的
location块中，不要无差别开启proxy_intercept_errors on;，尤其当该 location 也匹配 OPTIONS 时 - 如确需拦截后端错误（如 502），请将
proxy_intercept_errors和error_page严格限定在只处理GET/POST/PUT等实际业务方法的子 location 中 - 若发现 OPTIONS 返回了自定义错误页，检查是否误配了全局
error_page 405或error_page 501，这些和代理无关，应单独清理或用if控制作用范围
