Nginx 如何在配置文件中实现CORS

跨源资源共享（CORS) 经常成为开发人员在尝试与托管在不同域上的 API 交互时遇到的障碍。当直接服务器配置不可行时，挑战会加剧，将开发人员推向诸如广泛使用的 **cors-anywhere 这样的替代解决方案。然而，NGINX 的 proxy_pass 指令处理不仅局域网域和上游，还包括外部源的能力是相对较少为人所知的，例如：

理解基础和设置

CORS 是一种安全功能，限制了 Web 应用程序向服务其自身的域之外的域发出请求。这是一项至关重要的安全措施，用于防止恶意网站访问敏感数据。然而，在需要合法的跨域请求时，正确配置 CORS 至关重要。

NGINX 代理服务器提供了解决此困境的强大解决方案。通过利用 NGINX 的灵活配置系统，开发人员可以创建一个代理，处理 CORS 预检请求 并操纵标头以确保符合 CORS 策略。以下是操作方法：

变量声明和操纵

通过 map 指令，NGINX 允许基于现有全局变量声明新变量，并为动态处理提供正则表达式支持。例如，可以实现从 URL 中提取特定路径，从而精确控制请求处理。

因此，当请求 http://example.com/api 时，$my_request_path 变量将包含 api。

标头管理

NGINX 通过 add_header 和 proxy_set_header 方便地向响应添加自定义标头，并通过 proxy_hide_header 隐藏来自代理服务器的标头，确保仅将必要的信息传递回客户端。

现在我们有了一个带有 X-Request-Path 标头的 api。

条件处理

通过 if 指令，NGINX 可以根据特定条件执行操作，例如为 OPTIONS 方法请求返回预定响应代码，简化 CORS 预检 的处理。

将所有内容整合在一起

首先，让我们声明 $proxy_uri，我们将从 $request_uri 中提取：

简而言之，它的工作原理如下：当请求 http://example.com/example.com 时，$proxy_uri 变量将包含 https://example.com。

从生成的 $proxy_uri 中提取将与 Origin 标头匹配的部分：

对于 Forwarded 标头，我们需要同时处理两个变量：

处理后的 X-Forwarded-For 标头已经内置在 NGINX 中。

现在我们可以开始声明我们的代理服务器：

我们得到了一个最小限度工作的代理服务器，可以处理 CORS 预检请求 并添加适当的标头。

提升安全性和性能

除了基本设置外，进一步的改进可以提高安全性和性能：

隐藏 CORS 标头

当 NGINX 内部处理 CORS 时，从客户端响应中隐藏这些标头是有益的，以防止暴露服务器内部。

绕过速率限制

将客户端的 IP 传递给某种方式绕过速率限制也是一种好方法，如果有几个用户访问相同的资源，就会出现这种情况。

禁用缓存

最后，对于动态内容或敏感信息，禁用缓存是一种最佳实践，确保数据的新鲜性和隐私。

总结

本指南不仅揭示了配置 NGINX 处理 CORS 请求 的过程，还使开发人员掌握了创建一个强大、灵活的代理服务器的知识，该服务器能够支持各种应用程序需求。通过仔细的配置和对 CORS 策略以及 NGINX 能力的理解，开发人员可以克服跨源限制，提高应用程序性能，并确保数据安全。这种对 NGINX 的高级理解和应用不仅解决了常见的 Web 开发障碍，还展示了在导航 Web 安全和资源共享挑战时可能实现的技能和创新的深度。