在 nginx 中处理跨域请求的兜底响应，核心做法是结合 try_files 与 error_page 指令。当静态资源未找到时，nginx 会触发内部重定向至指定的错误页面，此时只需在该错误页面的配置块中设置 cors 响应头（如 access-control-allow-origin），即可确保浏览器接收到的错误响应包含正确的跨域允许信息。
try_files 匹配失败后的内部跳转机制是什么
该机制依赖于 try_files 最后一个参数为 URI 路径而非文件路径的特性。当所有列出的文件都不存在时，Nginx 不会直接返回 404，而是发起一个内部重定向（Internal Redirect）到该 URI。这个特性使得我们可以拦截“资源不存在”的状态，并将其引导至一个统一的逻辑入口，从而有机会注入自定义的 HTTP 响应头。
server {
listen 80;
server_name example.com;
# 定义错误页面处理逻辑
error_page 404 /fallback.html;
location = /fallback.html {
# 关键：在此处添加 CORS 头
add_header Access-Control-Allow-Origin *;
add_header Access-Control-Allow-Methods "GET, POST, OPTIONS";
add_header Access-Control-Allow-Headers "Content-Type";
# 返回实际内容或状态码
return 404 '{"error": "File not found"}';
}
location /api/ {
# try_files 尝试匹配文件，若失败则内部跳转到 /fallback.html
try_files $uri $uri/ /fallback.html;
# 其他业务逻辑...
}
}
在上述配置中，location = /fallback.html 块专门处理由 try_files 触发的内部跳转。由于这是内部重定向，客户端浏览器看到的 URL 可能仍保持原样，但响应头是由这个特定位置块生成的。通过在 add_header 中声明允许的源和方法，解决了跨域场景下错误响应被浏览器拦截的问题。
如何确保 OPTIONS 预检请求也能获得正确的 CORS 响应
对于跨域请求，浏览器通常会先发送 OPTIONS 预检请求。如果预检请求也经过 try_files 流程，或者需要单独处理，必须在对应的 location 块中显式处理 OPTIONS 方法。通常的做法是在主 location 中判断请求方法，如果是 OPTIONS，则直接返回 204 并带上 CORS 头，跳过后续的 try_files 检查，以提高效率并确保预检通过。
location /api/ {
# 处理 OPTIONS 预检请求
if ($request_method = 'OPTIONS') {
add_header Access-Control-Allow-Origin *;
add_header Access-Control-Allow-Methods "GET, POST, OPTIONS";
add_header Access-Control-Allow-Headers "Content-Type";
add_header Access-Control-Max-Age 3600;
add_header Content-Length 0;
return 204;
}
# 处理实际业务请求
add_header Access-Control-Allow-Origin *;
try_files $uri $uri/ /fallback.html;
}
# 兜底响应配置
error_page 404 /fallback.html;
location = /fallback.html {
add_header Access-Control-Allow-Origin *;
return 404 '{"error": "Not Found"}';
}
这段代码展示了完整的处理流程。首先，if 块拦截了 OPTIONS 请求，直接返回 204 No Content 并附带必要的 CORS 头，这满足了浏览器的预检要求。接着，对于非 OPTIONS 请求，try_files 开始工作。如果资源存在，正常返回；如果不存在，内部重定向到 /fallback.html。注意，/fallback.html 的位置块中也必须再次声明 Access-Control-Allow-Origin，因为内部重定向后，响应头是由最终处理该 URI 的 location 块决定的，之前的 location /api/ 中的 add_header 不会自动继承到新的内部请求上下文中。
当 fallback 页面本身也是动态脚本时如何处理
如果 try_files 的最后一个参数指向的是一个 FastCGI 或 Proxy 地址，例如 /index.php?file=$uri，那么 CORS 头的设置需要在 PHP 脚本内部或通过 Nginx 的 fastcgi_param 配合脚本逻辑来实现。在这种情况下，Nginx 不再直接返回静态内容，而是将请求转发给后端应用。后端应用负责生成响应体，同时也必须负责输出 CORS 头。如果在 Nginx 层直接对 location 使用 add_header，它依然有效，但更常见的做法是让后端应用根据业务逻辑动态决定 CORS 策略。
例如，在 PHP 应用中，可以在入口文件顶部添加：
<?php header("Access-Control-Allow-Origin: *");
header("Access-Control-Allow-Methods: GET, POST, OPTIONS");
header("Access-Control-Allow-Headers: Content-Type");
// 模拟 try_files 的逻辑
$file = $_GET['file'] ?? '';
if (file_exists($file)) {
readfile($file);
} else {
http_response_code(404);
echo json_encode(['error' => 'File not found']);
}
?
这种模式下，Nginx 配置简化为：
location /api/ {
try_files $uri $uri/ /index.php?file=$uri;
# 可选：在 Nginx 层统一添加 CORS 头，但需注意与后端冲突
# add_header Access-Control-Allow-Origin *;
}
需要注意的是，如果同时在 Nginx 和 PHP 中都设置了 Access-Control-Allow-Origin，Nginx 的 add_header 可能会覆盖或重复添加头部，导致浏览器解析错误。最佳实践是选择一处统一管理。如果希望 Nginx 统一处理，应确保 PHP 脚本不输出 CORS 头，或者在 Nginx 中使用 always 标志：add_header Access-Control-Allow-Origin * always;，以确保即使在错误响应中也能正确传递头部。
