AWS CDN 配置：实现非 www 域名自动跳转到 www.xxx.com

1. 为什么需要将非 www 域名跳转到 www 域名很多网站在运营过程中都会遇到一个经典问题用户可能通过带 www 的域名如 www.example.com访问也可能直接输入不带 www 的域名如 example.com。虽然这两个地址最终都能访问到你的网站但从技术角度来看这其实会带来不少麻烦。首先从 SEO 角度考虑搜索引擎会把 www.example.com 和 example.com 视为两个不同的网站。这意味着你的网站权重会被分散不利于搜索引擎排名。我见过不少案例网站主投入大量精力做优化却因为没处理好这个跳转问题导致效果大打折扣。其次品牌一致性也很重要。想象一下如果你的用户在不同场合看到你的网站时有时带 www 有时不带会给人一种不够专业的感觉。特别是在印刷品或广告中统一的域名格式能增强品牌识别度。最后从技术实现层面看统一域名能简化很多配置工作。比如 SSL 证书管理、CDN 配置、统计分析工具设置等都只需要针对一个主域名进行大大降低了维护成本。2. AWS CloudFront 基础配置在开始配置跳转之前我们需要先完成 CloudFront 的基本设置。CloudFront 是 AWS 提供的全球内容分发网络CDN服务能够加速你的网站内容分发。首先登录 AWS 控制台进入 CloudFront 服务页面。点击创建分发按钮你会看到两个选项Web 和 RTMP。对于大多数网站来说选择 Web 分发即可。在源设置部分你需要填写你的源站地址。这里可以是一个 S3 存储桶适合静态网站也可以是你的服务器 IP 或域名适合动态网站。我建议使用自定义域名而不是直接使用 IP这样后续维护会更方便。缓存行为设置是关键部分。默认情况下CloudFront 会根据 URL 路径缓存内容。对于我们的跳转需求建议将基于选择的请求头设置为包含 Host 头。这样 CloudFront 就能区分来自不同域名的请求。分发设置完成后需要等待约 15-30 分钟让配置生效。你可以在状态列看到进度当显示为已部署时就可以进行下一步操作了。3. 使用 LambdaEdge 实现自动跳转LambdaEdge 是 AWS 提供的一个强大功能允许你在 CloudFront 的边缘节点运行代码。这正是实现我们域名跳转需求的完美工具。首先我们需要创建一个 Lambda 函数。在 AWS 控制台中打开 Lambda 服务选择创建函数。给函数起个有意义的名字比如www-redirect运行时选择 Node.js目前 LambdaEdge 主要支持这个运行时。将以下代码粘贴到函数编辑器中exports.handler (event, context, callback) { const request event.Records[0].cf.request; const headers request.headers; // 获取 Host 头 const hostHeader headers.host[0].value; // 检查是否以 www 开头 if (!hostHeader.startsWith(www.)) { // 构造新的 URL const newHost www. hostHeader; const queryString request.querystring ? ? request.querystring : ; // 返回 301 重定向响应 const response { status: 301, statusDescription: Moved Permanently, headers: { location: [{ key: Location, value: https://${newHost}${request.uri}${queryString} }], cache-control: [{ key: Cache-Control, value: no-cache }] } }; return callback(null, response); } // 如果已经是 www 开头继续正常请求 return callback(null, request); };这段代码的工作原理是检查每个请求的 Host 头如果不是以 www 开头就构造一个新的 URL 并返回 301 重定向响应。301 状态码告诉浏览器和搜索引擎这个跳转是永久性的有利于 SEO。4. 将 Lambda 函数关联到 CloudFront创建好 Lambda 函数后我们需要把它关联到 CloudFront 分发。这一步有几个关键点需要注意。首先在 Lambda 控制台中找到你刚创建的函数在操作下拉菜单中选择部署到 LambdaEdge。这会弹出一个配置对话框你需要选择正确的 CloudFront 分发并指定触发器类型。对于我们的跳转需求应该选择查看器请求作为触发器。这意味着 Lambda 函数会在 CloudFront 收到用户请求的第一时间执行确保重定向尽早发生。部署过程可能需要几分钟时间。我遇到过一些情况特别是在高峰期部署可能需要 10-15 分钟。耐心等待不要重复提交部署请求这可能会导致冲突。部署完成后你可以通过修改本地 hosts 文件来测试效果。将你的域名指向 CloudFront 的域名可以在分发设置中找到然后尝试访问不带 www 的版本看看是否会正确跳转。5. 常见问题排查与优化在实际部署过程中你可能会遇到一些问题。下面我分享几个常见问题及其解决方案。重定向循环这是最常见的问题。表现为浏览器不断在 www 和非 www 版本间跳转最终显示重定向过多错误。这通常是因为 Lambda 函数逻辑有误或者 CloudFront 缓存了重定向响应。解决方法是在重定向响应头中添加 cache-control: no-cache就像我们代码中做的那样。SSL 证书问题如果你的网站使用 HTTPS强烈建议这样做你需要确保 SSL 证书同时覆盖 www 和非 www 版本。在 AWS Certificate Manager 中申请证书时记得同时添加 example.com 和 www.example.com。性能考虑虽然 LambdaEdge 执行速度很快但频繁调用仍会产生成本。建议在函数开头添加简单的缓存控制逻辑比如对已经以 www 开头的请求直接返回减少不必要的处理。测试建议在正式部署前先在测试环境验证功能。你可以创建一个测试用的 CloudFront 分发和 Lambda 函数用 curl 命令检查响应头是否正确curl -I http://example.com应该能看到 301 状态码和正确的 Location 头。6. 高级配置与替代方案除了使用 LambdaEdgeAWS 还提供了其他几种实现域名跳转的方法各有优缺点。S3 重定向如果你的网站是纯静态的并且托管在 S3 上可以配置 S3 存储桶重定向。这种方法简单易用但功能有限无法处理动态内容或复杂的重定向逻辑。Application Load Balancer 重定向如果你使用 ALB 作为源站可以在 ALB 上配置重定向规则。这种方法的优势是不需要额外费用但只能在特定架构下使用。Route 53 别名记录虽然 Route 53 本身不支持 HTTP 重定向但可以通过巧妙的别名记录设置实现类似效果。不过这种方法不够灵活且对 SEO 不友好。相比之下LambdaEdge 方案虽然配置稍复杂但提供了最大的灵活性和控制力。特别是对于已经使用 CloudFront 的网站这是最自然的选择。7. 实际案例与性能影响去年我为一家电商客户实施了类似的配置他们的主要担忧是跳转会不会影响网站性能。经过详细测试我们发现影响微乎其微。在北美地区LambdaEdge 的执行时间通常在 1-3 毫秒之间。即使考虑到网络延迟整个重定向过程也能在 50 毫秒内完成用户几乎感知不到延迟。更重要的是统一域名后他们的 SEO 表现有了明显提升。三个月内自然搜索流量增加了约 15%这主要归功于消除了域名规范化问题。缓存方面我们配置了适当的 TTL 值确保静态资源仍能被有效缓存。动态内容则根据业务需求设置不同的缓存策略。这种精细化的缓存控制是 CloudFront 的一大优势。