AWS CloudFront作为全球CDN服务，在创建分发（Distribution）时需要配置Viewer Protocol Policy，也就是查看器协议策略。这个选项决定了用户（Viewer）与CloudFront边缘节点之间使用什么协议通信。很多初学者会直接保持默认值，结果导致线上流量以明文HTTP传输，或者配置了HTTPS Only后部分用户访问失败。本文将详细讲解HTTP and HTTPS、HTTPS Only、Redirect HTTP to HTTPS三种模式的原理、配置方法和选型建议。
一、Viewer Protocol Policy的三种模式与工作原理
Viewer Protocol Policy作用于CloudFront与最终用户之间的链路，注意它与Origin Protocol Policy是两个独立的配置项，后者控制CloudForward回源到S3、ALB或自定义源站时的协议。协议策略只能在Cache Behavior级别设置，一个分发可以有多个行为，每个行为可以采用不同策略。
三种模式的含义分别是：HTTP and HTTPS允许用户同时使用HTTP（80端口）和HTTPS（443端口）访问，CloudFront不做任何干预；HTTPS Only表示CloudFront只接受443端口的HTTPS请求，用户用HTTP访问会直接收到403 Forbidden错误；Redirect HTTP to HTTPS则最为常用，用户发起HTTP请求时，CloudFront会返回一个301永久重定向，将用户引导到相同路径的HTTPS地址。
从原理上看，重定向是由边缘节点直接完成的，不消耗回源带宽，也不会命中缓存，响应速度非常快，通常在几十毫秒内完成。这也是为什么绝大多数生产环境都推荐使用Redirect模式——既兼容了用户手动输入http://或点击旧链接的场景，又保证了最终通信全部加密。
二、配置方法：控制台、CLI与CloudFormation
在控制台中配置比较直观。进入CloudFront控制台，选择目标分发，编辑对应的Cache Behavior，在Viewer Protocol Policy下拉框中选择需要的模式即可。修改后需要保存并等待分发状态从Deploying变为Deployed，通常需要几分钟。
使用AWS CLI配置的命令如下：
aws cloudfront get-distribution-config --id E1234ABCDEF > dist.json # 编辑dist.json中的ViewerProtocolPolicy字段 # 将 If-Match 的 ETag 值填入下面的 --if-match 参数 aws cloudfront update-distribution --id E1234ABCDEF \ --distribution-config file://dist.json \ --if-match "ETAG值"
如果用CloudFormation或Terraform管理基础设施，对应字段写在DefaultCacheBehavior中：
{
"DistributionConfig": {
"DefaultCacheBehavior": {
"ViewerProtocolPolicy": "redirect-to-https",
"TargetOriginId": "my-origin"
},
"ViewerCertificate": {
"ACMCertificateArn": "arn:aws:acm:us-east-1:123456789012:certificate/xxx",
"SSLSupportMethod": "sni-only"
}
}
}这里有一个非常关键且容易踩坑的点：给CloudFront使用的ACM证书必须申请在us-east-1（北弗吉尼亚）区域，无论分发本身在哪个区域。如果证书在其他区域，配置时会找不到可用证书。另外，如果没有配置自定义域名（Alternate Domain Name）而使用默认的xxx.cloudfront.net域名，CloudFront会自动提供免费证书，无需自己申请。
三、HTTPS Only与Redirect的选型对比及常见陷阱
很多安全要求严格的场景（例如金融、政务系统）会选择HTTPS Only，理由是301重定向的第一跳仍然是HTTP明文请求，理论上存在被中间人劫持篡改重定向目标的风险。而Redirect模式的优势是对用户更友好，不会因为协议不匹配直接报错。实际选型可以参考下表：
| 模式 | HTTP请求结果 | 适用场景 |
|---|---|---|
| HTTP and HTTPS | 正常返回（明文） | 内部测试、无敏感内容 |
| HTTPS Only | 403错误 | 安全合规要求极高的系统 |
| Redirect HTTP to HTTPS | 301重定向 | 绝大多数生产环境 |
| HTTPS Only（TLS 1.2+） | 403错误 | 支付、账户登录页面 |
配置HTTPS后常见的第二类问题是混合内容（Mixed Content）。页面通过HTTPS加载，但页面内部的js、css或图片仍然指向http://地址，浏览器会阻止这些资源加载，导致样式错乱或功能异常。解决办法是保证所有子资源都使用协议相对或绝对HTTPS地址，必要时开启CloudFront的响应头策略自动升级请求。
第三类陷阱与SEO有关。使用Redirect模式后，搜索引擎收录的旧HTTP链接会被301重定向到HTTPS版本，权重可以传递，一般不会影响排名。但如果源站（例如S3静态网站托管的Endpoint）本身也开启了强制HTTPS重定向，可能出现CloudFront与源站之间循环重定向，浏览器报ERR_TOO_MANY_REDIRECTS错误。排查方法是检查Origin Protocol Policy：如果源站是S3网站托管端点，回源协议应设为HTTP Only；如果是ALB或CloudFront源，则设为Match Viewer或HTTPS Only。
最后建议同时开启Security Policy中的TLS 1.2及以上版本，禁用旧版SSLv3和TLS 1.0，既满足PCI DSS等合规要求，又能避免降级攻击。对于API类接口，还可以在Lambda@Edge或CloudFront Functions中校验请求协议，实现更细粒度的访问控制。综合来看，Redirect HTTP to HTTPS配合TLS 1.2+是最稳妥的通用方案，兼顾安全、兼容和用户体验。
CloudFrontViewer Protocol PolicyHTTPS重定向修改时间：2026-09-03 00:31:04