The request could not be satisfied: CloudFront 源配置错误

Question

当访问 CloudFront 分配时出现“The request could not be satisfied”错误，常见原因是源配置错误。例如，源域名（Origin Domain Name）设置不正确，或指向了一个无法访问的 S3 存储桶或自定义源服务器。若源为 S3，需确保存储桶名称准确且启用了静态网站托管；若为 EC2 或负载均衡器，需验证其 DNS 名称及端口配置是否匹配。此外，源访问控制（OAC）或源访问身份（OAI）权限缺失也会导致此问题。检查 CloudFront 源设置、DNS 解析和后端服务可达性是关键排查步骤。

Answer 1

1. 问题现象与初步定位

当用户访问 CloudFront 分配时，浏览器返回 "The request could not be satisfied" 错误，通常伴随 HTTP 状态码 403 或 5xx。该错误表明 CloudFront 无法从源服务器获取内容。最常见的触发场景包括：

• 源域名（Origin Domain Name）拼写错误或指向不存在的资源
• S3 存储桶未启用静态网站托管模式
• EC2 实例、ALB/NLB 的 DNS 名称配置错误或端口不开放
• OAI（Origin Access Identity）或 OAC（Origin Access Control）权限缺失
• 后端服务防火墙策略阻止了 CloudFront IP 范围

此阶段建议通过 AWS 控制台快速核对 CloudFront 分配的基本配置项。

2. 深入分析：源配置常见错误类型

源类型	常见配置错误	验证方法
S3 存储桶	未启用静态网站托管；OAI/OAC 缺失；存储桶策略限制访问	检查 S3 控制台“属性”页；测试直接访问 s3-website endpoint
EC2 实例	安全组未放行 CloudFront IP；实例未运行 Web 服务	telnet 测试端口连通性；查看 VPC Flow Logs
Application Load Balancer	监听器规则错误；目标组健康检查失败	检查 ALB 监听器配置；确认 EC2 健康状态
自定义源（如 Nginx 服务器）	Host 头校验严格；SSL/TLS 配置异常	使用 curl 模拟 Host 请求；检查证书有效期

3. 排查流程图：系统化诊断路径

```mermaid
graph TD
    A[用户请求 CloudFront] --> B{返回"The request could not be satisfied"?}
    B -- 是 --> C[检查 CloudFront 源设置]
    C --> D[确认 Origin Domain Name 正确]
    D --> E{源为 S3?}
    E -- 是 --> F[是否启用静态网站托管?]
    F -- 否 --> G[启用静态网站托管并更新行为]
    F -- 是 --> H[检查 OAI/OAC 权限及存储桶策略]
    E -- 否 --> I[验证源服务器 DNS 可解析]
    I --> J[测试源服务器端口可达性 (如 80/443)]
    J --> K[检查源服务器防火墙/安全组规则]
    K --> L[确认应用层服务正常响应]
    L --> M[审查 CloudFront 缓存行为与协议策略]
```

4. 技术细节：S3 作为源的权限模型演进

AWS 推荐使用 OAC（Origin Access Control）替代旧版 OAI（Origin Access Identity），特别是在使用 S3 REST API 或需要更强安全性时。以下是两种机制的关键差异：

1. OAI：基于 IAM 用户身份模拟，需在 S3 存储桶策略中显式授权 cano­n­i­cal user ID
2. OAC：支持 Sigv4 签名，兼容更多 S3 功能（如对象锁定、跨区域复制）
3. 若使用 S3 作为静态网站托管源，必须使用网站终端节点（如 mybucket.s3-website-us-east-1.amazonaws.com），而非标准 API 终端节点
4. 错误使用 s3.amazonaws.com 会导致签名不匹配，引发 403 错误
5. 可通过 AWS CLI 验证：aws s3api get-bucket-website --bucket mybucket
6. 确保 CloudFront 行为设置中“Viewer Protocol Policy”与源服务器支持的协议一致
7. 对于 HTTPS 源，需检查 SSL 证书域名是否匹配源主机名
8. 启用 CloudFront 日志记录有助于追溯原始错误来源
9. 利用 Lambda@Edge 可注入调试头信息以辅助排查
10. 定期审计源访问策略，防止因权限变更导致意外中断