如何配置服务器端的跨域请求，常见问题有哪些？

服务器端跨域配置步骤，从原理到实践

服务器端配置跨域请求的核心是设置CORS响应头，通过指定允许的源、方法和头信息，浏览器才会放行跨域请求。 跨域问题是浏览器同源策略的产物，服务器端不主动放开，前端无法通过任何手段绕过，理解这一点，你就能抓住配置的本质。

理解CORS机制是前提

CORS全称跨域资源共享,它通过一组HTTP头让服务器声明哪些跨域请求被允许，浏览器在发起跨域请求时，会先判断是否属于简单请求，如果不是，则先发送一个OPTIONS预检请求，拿到服务器支持的来源、方法、头信息后，才发起实际请求，你需要在服务器端正确响应这个预检请求。

加载中

Web服务器-Nginx解决跨域(CORS)问题

运维小路

133320-

原视频地址

• 简单请求：GET、HEAD、POST，且Content-Type为application/x-www-form-urlencoded、multipart/form-data或text/plain，浏览器直接发送请求，并在响应里检查Access-Control-Allow-Origin头。
• 预检请求：所有其他请求，浏览器先发OPTIONS，服务器返回允许的跨域规则，浏览器再发实际请求。

服务器端跨域配置的具体步骤

无论你使用哪种服务器语言或环境,配置逻辑高度一致，核心是拦截所有请求，设置响应头。

1. 判断请求来源,根据业务需求决定是否允许，生产环境不要直接使用，除非是公开API。
2. 设置Access-Control-Allow-Origin为请求的Origin（或允许的特定域名）。
3. 设置Access-Control-Allow-Methods为支持的HTTP方法，如GET, POST, PUT, DELETE, OPTIONS。
4. 设置Access-Control-Allow-Headers为客户端可能携带的自定义头，如Authorization, Content-Type。
5. 设置Access-Control-Max-Age缓存预检结果，避免重复预检。
6. 处理预检请求直接返回200,不再进行后续业务逻辑。
7. 如果需要携带cookie,设置Access-Control-Allow-Credentials: true，同时Origin不能是。

关键点： 预检请求的OPTIONS响应必须包含上述头，且状态码为200，很多配置失败都因为忽略了OPTIONS的处理。

跨域请求CORS配置实战：Nginx与Spring Boot

不同服务器环境的配置方式差异较大,但核心逻辑一致，以下给出两种最常用环境的配置示例，你可以直接套用。

Nginx配置跨域请求

Nginx作为反向代理,常在全局或location块中配置跨域头，以下是一个完整的配置片段，支持任意来源的简单请求和预检请求。

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 'Authorization, Content-Type, X-Requested-With';
        add_header Access-Control-Max-Age 86400;
        add_header Content-Length 0;
        return 200;
    }
    add_header Access-Control-Allow-Origin ;
    add_header Access-Control-Allow-Methods 'GET, POST, PUT, DELETE, OPTIONS';
    add_header Access-Control-Allow-Headers 'Authorization, Content-Type, X-Requested-With';
    # ... 其他配置
}

• 注意：if语句在Nginx中性能损耗低，但不要滥用，生产环境建议将跨域配置单独提取到map或server块。
• 多域名场景：使用map变量动态设置Access-Control-Allow-Origin，只允许白名单域名。

Spring Boot跨域配置

Spring Boot开发中，推荐使用WebMvcConfigurer全局配置，避免在每个Controller重复注解。

@Configuration
public class CorsConfig implements WebMvcConfigurer {
    @Override
    public void addCorsMappings(CorsRegistry registry) {
        registry.addMapping("/")
                .allowedOriginPatterns("")  // 生产环境替换为具体域名
                .allowedMethods("GET", "POST", "PUT", "DELETE", "OPTIONS")
                .allowedHeaders("")
                .allowCredentials(true)
                .maxAge(3600);
    }
}

• 使用allowedOriginPatterns可以支持域名通配，比allowedOrigins更灵活。
• 如果使用Spring Security，需要额外配置CORS过滤器，确保跨域头在安全过滤器之前添加。

其他环境简要说明

• Node.js Express：使用cors中间件，一行代码

  

  app.use(cors())，支持自定义options。

• Apache：通过mod_headers在.htaccess或虚拟主机中添加Header set Access-Control-Allow-Origin ，并处理OPTIONS请求。
• IIS：使用URL Rewrite模块或web.config添加响应头。

跨域请求问题排查：从报错到修复

配置完跨域,浏览器依然报错是常见情况，掌握排查方法比配置本身更重要。

浏览器报错信息解读

浏览器控制台会明确提示跨域失败原因,

• No 'Access-Control-Allow-Origin' header is present：服务器未返回该头，或返回的内容与请求源不匹配。
• Response to preflight request doesn't pass access control check：预检请求响应中缺少必要的头，或状态码不是200，或返回的Allow-Methods不包含实际请求方法。

排查步骤：

1. 打开浏览器开发者工具,查看网络请求，找到跨域请求及其OPTIONS预检请求。
2. 检查OPTIONS请求的响应头,确认是否包含Access-Control-Allow-Origin、Allow-Methods、Allow-Headers。
3. 确认实际请求的响应头是否包含Access-Control-Allow-Origin，如果预检通过但实际请求失败，说明实际请求的响应头没有设置正确。
4. 如果使用allowCredentials，确保Access-Control-Allow-Origin不是，而是明确指定的域名。

多域名场景配置实践

当应用需要支持多个来源时,不能简单使用，因为与allowCredentials冲突，推荐做法：

• 在服务器端维护一个白名单列表,读取请求的Origin头，如果匹配则动态设置Access-Control-Allow-Origin为该来源。
• 在Nginx中,使用map指令实现；在Spring Boot中，自定义CorsConfiguration并设置allowedOrigins列表。

关于凭证携带

如果需要跨域携带cookie（如基于session的认证），必须同时满足三点：

• 服务端设置Access-Control-Allow-Credentials: true。
• 服务端

  

  Access-Control-Allow-Origin不能是，必须是具体域名。

• 客户端请求（如fetch）必须设置credentials: 'include'。

跨域配置后的优化与安全建议

跨域配置不是一次性工作,上线后仍需关注以下细节。

• 合理设置缓存时长：Access-Control-Max-Age建议设置为一天（86400秒），减少预检请求数量，提升性能。
• 避免暴露过多头信息：Access-Control-Expose-Headers控制客户端可以读取的响应头，只暴露必要的头。
• 定期审计白名单：随着业务扩展，及时清理不再需要的跨域来源，防止被恶意站点利用。
• 使用代理方案作为备选：在开发环境，前端可以通过webpack-dev-server的proxy配置，将跨域请求转发到后端，绕过浏览器的跨域限制，但生产环境仍需服务器端CORS配置。

跨域配置常见问题解答

Q1: 跨域请求配置后，部分接口仍然被浏览器拦截，原因有哪些？
A: 检查预检请求是否被正确处理，OPTIONS请求必须返回200且包含所需的跨域头，确认实际请求的响应头也包含了跨域头，尤其是当后端框架对不同路径有不同处理时，如果使用了allowCredentials，检查Access-Control-Allow-Origin是否指定了具体的源。

Q2: 服务器端配置跨域请求时，Access-Control-Allow-Origin设置为`是否安全？ A: 不安全。允许任何来源访问，如果API包含用户敏感数据或需要认证，则存在安全风险，建议仅对公开的、无认证的API使用，其余情况明确指定允许的域名，并配合Access-Control-Allow-Credentials: true时不能使用`。

Q3: 前后端分离项目中，跨域配置是前端处理还是后端处理？
A: 跨域配置必须由服务器端处理，因为CORS响应头是服务器在HTTP响应中设置的，前端无法通过JavaScript添加这些头，前端可以通过代理方式（如webpack）在开发环境绕过跨域，但在生产环境，服务器端配置是唯一可靠的方式。