AWS CloudFront 跨域配置（CORS）完整指南

在基于AWS CloudFront（CDN）构建分布式应用时，跨域资源共享（CORS）配置是解决前端跨域请求限制的核心环节。本文将从CORS基本原理出发，详细讲解CloudFront结合不同源站（S3、自定义HTTP服务器）的跨域配置方案、验证方法及常见问题排查，确保前端资源请求流畅运行。

一、核心概念：为什么需要CloudFront跨域配置？

浏览器的同源策略会限制前端页面从不同域名、端口或协议的源站请求资源。当用户通过CloudFront访问源站资源（如S3中的图片、API服务返回的数据）时，若前端页面域名与CloudFront域名不一致，就会触发跨域限制，导致请求失败（常见错误：Access to XMLHttpRequest at 'xxx' from origin 'xxx' has been blocked by CORS policy）。

CloudFront的CORS配置核心是确保：1. 源站能正确返回CORS相关响应头；2. CloudFront能缓存这些响应头并在后续请求中返回给浏览器，二者缺一不可。

二、前提：明确源站类型与CORS配置责任边界

CloudFront作为CDN，本身不直接“处理”CORS逻辑，而是传递和缓存源站的CORS响应头。因此，跨域配置的核心责任在源站，CloudFront仅需配置为“不丢失/正确缓存”这些头信息。不同源站的CORS配置基础不同，需先完成源站配置再处理CloudFront：

源站为S3桶：需通过S3的“跨域资源共享(CORS)”规则配置允许的跨域来源、请求方法等。
源站为自定义HTTP服务器（如EC2、ELB、自建服务器）：需在服务器端（如Nginx、Apache、应用代码）配置返回Access-Control-*系列响应头。
源站为API Gateway/Lambda：需在API Gateway的集成响应或Lambda返回结果中包含CORS响应头。

三、分场景配置：CloudFront + 主流源站方案

场景1：源站为S3（最常见场景）

该场景需“先配置S3 CORS规则，再配置CloudFront缓存策略”，确保CORS头被正确传递和缓存。

步骤1：配置S3桶的CORS规则

登录AWS控制台，进入S3服务，找到目标桶，点击【权限】标签页，下拉至“跨域资源共享(CORS)”模块，点击【编辑】。

根据业务需求输入CORS规则（JSON格式），以下为常见配置示例：

允许特定域名跨域（如仅允许前端域名https://www.your-frontend.com）：
            [
  {
    "AllowedHeaders": ["*"], // 允许的请求头，*表示所有
    "AllowedMethods": ["GET", "HEAD", "POST"], // 允许的HTTP方法
    "AllowedOrigins": ["https://www.your-frontend.com"], // 允许的跨域来源
    "ExposeHeaders": ["ETag"], // 允许前端读取的响应头
    "MaxAgeSeconds": 3000 // 浏览器缓存预检请求结果的时间（秒）
  }
]

允许所有域名跨域（测试环境临时使用，生产环境禁止）：将AllowedOrigins改为"*"。
支持带Credentials的请求（如跨域传递Cookie）：AllowedOrigins不能为*，需指定具体域名，且需添加"AllowCredentials": true字段。
点击【保存更改】，完成S3 CORS配置。
步骤2：配置CloudFront以传递和缓存CORS头

CloudFront默认可能不会缓存CORS相关响应头，需通过“缓存策略”和“源站请求策略”确保头信息正确处理。
进入CloudFront控制台，找到目标分发（Distribution），点击【编辑】。
配置“源站设置”（Origin Settings）：找到目标S3源站，点击【编辑源站】。
若S3桶为“网站托管模式”（静态网站），确保“源站域名”填写S3的网站端点（如your-bucket.s3-website.cn-north-1.amazonaws.com.cn），而非REST端点；若为“对象存储模式”，则使用REST端点。
“源站访问控制设置”：建议使用OAC（Origin Access Control）替代旧版OAI，增强安全性，配置时确保S3桶政策允许OAC访问（参考AWS官方文档配置OAC权限）。
配置“缓存策略”（Cache Policy）：在“默认缓存行为设置”中，找到“缓存策略”，点击【创建缓存策略】（若无合适现有策略）。
策略名称：如CORS-Cache-Policy。
“缓存键设置”： “查询字符串”：根据需求选择（如静态资源选“不包含”，动态资源选“包含所有”）。
“Cookie”：若前端跨域请求不带Cookie，选“不包含”；若带Cookie，选“包含指定Cookie”或“包含所有”（需配合S3的AllowCredentials配置）。
“HTTP头”：关键步骤——在“包含的头部”中添加Origin，因为CORS响应依赖于请求的Origin头来返回对应允许的域名。
“响应头策略”：选择“CORS-With-Preflight”（AWS预定义策略，适用于带预检请求的CORS场景），或自定义策略确保包含以下响应头：
1. Access-Control-Allow-Origin
2. Access-Control-Allow-Methods
3. Access-Control-Allow-Headers
4. Access-Control-Max-Age
5. Access-Control-Expose-Headers（若有）
保存缓存策略，并关联到当前分发的缓存行为。
配置“源站请求策略”（Origin Request Policy）：选择“Include-Origin”（预定义策略），确保CloudFront将客户端的Origin头传递给S3源站，S3才能根据Origin头返回正确的CORS响应。
点击【保存更改】，CloudFront配置生效（通常需要5-10分钟全球同步）。

场景2：源站为自定义HTTP服务器（如EC2/Nginx）

该场景核心是“服务器端返回完整CORS响应头”，CloudFront仅需配置为传递这些头信息。

步骤1：服务器端配置CORS响应头

以Nginx为例，在配置文件（如nginx.conf或站点配置）中添加以下内容：

server {
    listen 80;
    server_name your-server-domain.com;

    location / {
        # 允许的跨域来源（可替换为具体前端域名）
        add_header Access-Control-Allow-Origin "https://www.your-frontend.com";
        # 允许的请求方法
        add_header Access-Control-Allow-Methods "GET, POST, PUT, DELETE, OPTIONS";
        # 允许的请求头
        add_header Access-Control-Allow-Headers "Origin, X-Requested-With, Content-Type, Accept, Authorization";
        # 允许前端读取的响应头
        add_header Access-Control-Expose-Headers "Content-Length, ETag";
        # 支持Credentials（若需要）
        add_header Access-Control-Allow-Credentials "true";
        # 预检请求缓存时间
        add_header Access-Control-Max-Age 3600;

        # 处理OPTIONS预检请求（浏览器跨域复杂请求前会发送）
        if ($request_method = 'OPTIONS') {
            return 204; # 预检请求无需响应体
        }

        # 其他业务配置（如代理、静态资源指向等）
        proxy_pass http://127.0.0.1:8080;
    }
}

配置完成后，重启Nginx（nginx -s reload），并通过Postman测试服务器是否能正确返回CORS头（发送OPTIONS请求或带Origin头的GET请求，检查响应头）。

步骤2：CloudFront配置（类似S3场景）

进入CloudFront分发的编辑页面，配置“源站”为自定义服务器的域名或IP（建议使用ELB作为源站，增强可用性）。
“缓存策略”：确保包含“Origin”头在缓存键中，避免不同Origin的请求共用同一缓存（导致CORS头错误）。
“响应头策略”：选择预定义的“CORS-With-Preflight”或自定义策略，确保CORS响应头被传递。
保存更改，等待CloudFront同步生效。

场景3：源站为API Gateway/Lambda

核心是在API Gateway中配置CORS，CloudFront仅需正常传递请求头即可。

API Gateway配置：进入目标API，点击【操作】-【启用CORS】，设置允许的Origin、Methods等，API Gateway会自动生成OPTIONS方法和CORS响应头。
CloudFront配置：缓存策略中包含“Origin”头，源站请求策略传递“Origin”“Access-Control-Request-Method”等预检请求头，确保API Gateway能正确处理。

四、验证CORS配置是否生效

配置完成后，需通过前端实际请求或工具验证，确保跨域请求正常：

方法1：浏览器开发者工具（最直观）

打开前端页面，触发跨域请求（如加载CloudFront域名的图片、调用API）。
打开浏览器【开发者工具】-【网络】面板，找到对应的请求（如GET请求）。
查看“响应头”：确认存在Access-Control-Allow-Origin，且值为前端页面的域名（如https://www.your-frontend.com）。
若为复杂请求（如POST带JSON数据），会先发送OPTIONS预检请求，需确认OPTIONS请求的响应头包含完整的CORS信息，且状态码为200/204。

方法2：curl命令（快速测试）

在终端执行以下命令，模拟带Origin头的请求，检查响应头：

# 替换CloudFront域名和前端Origin
curl -H "Origin: https://www.your-frontend.com" -I https://your-cloudfront-domain.net/your-resource.jpg

若响应头中包含Access-Control-Allow-Origin: https://www.your-frontend.com，则配置生效。

五、常见问题与排查方案

问题1：CORS错误依然存在，响应头中无Access-Control-*

排查方向：

源站是否正确配置CORS？通过直接访问源站（绕开CloudFront）测试是否返回CORS头（如S3直接访问桶内资源，服务器直接访问IP）。
CloudFront是否传递了Origin头？检查源站请求策略是否包含Origin头，确保CloudFront将Origin头转发给源站。
CloudFront缓存是否命中旧数据？配置变更后，可通过CloudFront的“失效”功能（Invalidations）清除对应路径的缓存（如输入/*清除所有缓存）。

问题2：Access-Control-Allow-Origin为*，但前端仍报错

原因：前端请求为“带Credentials的请求”（如withCredentials: true），此时CORS规则中AllowedOrigins不能为*，必须指定具体域名，且需添加AllowCredentials: true。

解决：修改源站CORS规则，将AllowedOrigins改为前端具体域名，添加AllowCredentials字段，并同步更新CloudFront缓存策略（包含Cookie在缓存键中）。

问题3：OPTIONS预检请求403/404错误