如何在AWS CloudFront上实现Next.js服务器端渲染加速？

当Next.js应用部署在AWS上时，无论是运行在ECS、EKS还是Lambda上，源站通常位于某个特定区域。对于全球用户而言，直接访问源站会引入高延迟，并且源站服务器需要处理所有请求，无法有效利用边缘缓存。AWS CloudFront作为内容分发网络，可以将静态资源和动态响应缓存到靠近用户的边缘节点，大幅降低延迟并减轻源站压力。但Next.js应用大量使用服务器端渲染，页面的HTML内容会根据用户、请求参数或实时数据动态生成，这给CloudFront缓存配置带来了很大挑战。如果简单地将所有响应缓存，可能导致用户A看到用户B的数据；如果完全不缓存，又失去了加速意义。因此，需要深入理解CloudFront的缓存机制，并结合Next.js的渲染模式设计合理的加速策略。

CloudFront与Next.js SSR集成的基础架构

在典型的部署中，Next.js应用运行在源站（如Application Load Balancer后面的ECS任务、API Gateway + Lambda，或者专门的Node.js服务器）。CloudFront作为反向代理，接收用户请求，根据配置决定是直接返回缓存内容，还是回源获取最新响应。对于Next.js的服务器端渲染页面，每个请求都需要在源站执行React组件的渲染逻辑，生成完整的HTML字符串，再返回给客户端。这些HTML虽然包含动态数据，但很多部分其实是静态的（例如布局、导航、页脚），只有少数区域随用户或请求变化。如果能够将不敏感的内容缓存起来，就能显著减少回源次数。

基础配置的第一步是创建CloudFront分发，将源站设置为Next.js应用所在的服务端点。同时需要配置源站协议、超时时间以及自定义头部转发。这里使用AWS CDK（TypeScript）来定义分发，代码结构清晰且易于版本管理。下面的示例展示了如何创建一个指向ALB的CloudFront分发，并设置默认缓存行为为不缓存动态内容，但允许静态资源缓存。

import * as cloudfront from 'aws-cdk-lib/aws-cloudfront';
import * as origins from 'aws-cdk-lib/aws-cloudfront-origins';
import * as cdk from 'aws-cdk-lib';

const app = new cdk.App();
const stack = new cdk.Stack(app, 'NextJsCdnStack');

// 假设已有ALB
const alb = elbv2.ApplicationLoadBalancer.fromLookup(stack, 'ALB', {
  loadBalancerArn: 'arn:aws:elasticloadbalancing:us-east-1:123456789012:loadbalancer/app/my-alb/1234567890'
});

const distribution = new cloudfront.Distribution(stack, 'NextJsDistribution', {
  defaultBehavior: {
    origin: new origins.LoadBalancerV2Origin(alb, {
      protocolPolicy: cloudfront.OriginProtocolPolicy.HTTPS_ONLY,
      httpPort: 80,
      httpsPort: 443,
      connectionTimeout: cdk.Duration.seconds(10),
    }),
    viewerProtocolPolicy: cloudfront.ViewerProtocolPolicy.REDIRECT_TO_HTTPS,
    cachePolicy: cloudfront.CachePolicy.CACHING_DISABLED, // 默认不缓存动态响应
    originRequestPolicy: cloudfront.OriginRequestPolicy.ALL_VIEWER_EXCEPT_HOST_HEADER,
  },
  priceClass: cloudfront.PriceClass.PRICE_CLASS_100, // 仅北美和欧洲，降低成本
});

上述代码中，默认缓存行为设置为CACHING_DISABLED，这意味着所有到达该行为的请求都不会被CloudFront缓存，而是每次都回源。这是因为Next.js的SSR页面通常包含与用户相关的数据，不适合全局缓存。但随后需要为静态资源（如/_next/static/下的JS、CSS、图片等）添加额外的缓存行为，将这些资源的缓存策略设置为长期缓存，因为这些文件带有内容哈希，内容不变则URL不变，可以安全地缓存很长时间。这样既保证了动态页面的正确性，又让静态资源命中边缘缓存，加速整体加载。

处理动态内容：缓存策略与回源控制

很多Next.js页面虽然是服务器端渲染，但并不是完全个性化的。例如，对于未登录用户展示的首页、文章详情页、产品列表页，这些页面在同一段时间内对所有用户是完全相同的。这种情况下，完全禁用缓存就浪费了CloudFront的能力。我们需要一种更细粒度的控制方法，允许某些页面被缓存，但缓存键中要包含所有可能影响页面输出的因素，比如查询字符串、某些请求头、Cookie中的特定值。

CloudFront提供了缓存策略（Cache Policy）和源站请求策略（Origin Request Policy）来分别控制缓存键和回源请求中携带的信息。缓存策略定义了哪些HTTP方法、哪些头部、Cookie或查询字符串会参与缓存键的构建，以及缓存的TTL。例如，如果Next.js页面根据?page=参数分页，那么查询字符串就需要加入缓存键。如果页面根据Accept-Language头部返回不同语言内容，就需要将该头部加入缓存键。对于基于用户身份的内容，我们通常不应该缓存，但可以通过边缘函数动态判断：如果请求中包含认证Cookie，则绕过缓存；否则使用公共缓存版本。

以下示例展示了如何为公开的SSR页面创建自定义缓存策略，并配置一个CloudFront Function来根据Cookie判断是否绕过缓存。这个函数在请求到达CloudFront边缘节点时运行，检查名为session_token的Cookie是否存在。如果存在，则将请求标记为不缓存；否则允许正常缓存。同时，该函数还会修改缓存键，加入Accept-Language头部，以便为不同语言用户缓存不同版本。

function handler(event) {
  var request = event.request;
  var headers = request.headers;
  var cookies = request.cookies;

  // 检查是否存在身份认证Cookie
  var hasSession = false;
  if (cookies && cookies['session_token']) {
    hasSession = true;
  }

  if (hasSession) {
    // 有SESSION的请求不缓存，直接回源
    request.headers['x-cache-control'] = { value: 'no-cache' };
  } else {
    // 无SESSION的公开请求，将Accept-Language加入缓存键
    var acceptLang = headers['accept-language'] ? headers['accept-language'].value : '';
    request.headers['x-cache-key-lang'] = { value: acceptLang };
  }

  return request;
}

将上述函数通过CloudFront Functions部署，并关联到对应的缓存行为上。在缓存策略中，需要将x-cache-control和x-cache-key-lang这两个自定义头部纳入缓存键，同时设置合适的TTL。这样，公开页面会被缓存，并且不同语言的版本会分开存储；而带有认证Cookie的请求会直接回源，确保用户看到自己的个性化数据。需要注意的是，回源请求中不应将这些自定义头部转发给源站，可以在源站请求策略中排除它们，保持源站收到的请求干净。

增量静态再验证与缓存失效的配合

Next.js提供了增量静态再验证功能，允许在页面构建后按需重新生成静态页面，而无需重新部署整个应用。具体做法是在getStaticProps中设置revalidate参数，或者在API路由中调用res.revalidate()。当CloudFront中的缓存页面过期后，下一次请求会触发回源，源站执行重新生成并返回新内容，同时更新缓存。然而，CloudFront的默认缓存行为是由TTL控制的，不会自动感知Next.js的revalidate时间。为了实现真正的按需更新，需要在源站重新生成页面后，主动向CloudFront发起缓存失效请求。

一种常见的做法是在Next.js应用中配置一个webhook或后台任务，监听内容变化事件（例如CMS内容更新、数据库记录修改），然后调用CloudFront的CreateInvalidation API，指定需要失效的路径。路径可以使用通配符，例如/posts/*。下面的代码演示了一个Node.js脚本，用于触发指定路径的失效操作。该脚本可以部署为Lambda函数，由EventBridge或SNS触发。

const AWS = require('aws-sdk');
const cloudfront = new AWS.CloudFront();

exports.handler = async (event) => {
  const distributionId = process.env.DISTRIBUTION_ID;
  const paths = ['/posts/*', '/', '/_next/data/*'];

  const params = {
    DistributionId: distributionId,
    InvalidationBatch: {
      CallerReference: Date.now().toString(),
      Paths: {
        Quantity: paths.length,
        Items: paths,
      },
    },
  };

  try {
    const result = await cloudfront.createInvalidation(params).promise();
    console.log('Invalidation created:', result.Invalidation.Id);
    return { statusCode: 200, body: 'Invalidation started' };
  } catch (err) {
    console.error('Failed to create invalidation:', err);
    return { statusCode: 500, body: 'Invalidation failed' };
  }
};

除了主动失效，还可以利用CloudFront的Origin Shield功能减少回源压力。Origin Shield是一个额外的缓存层，位于区域边缘节点和源站之间，可以合并来自多个边缘节点的回源请求，避免源站被突发流量打垮。对于Next.js应用，开启Origin Shield后，即使多个边缘节点同时发现缓存过期，也只会有一个请求回源，其余请求等待并复用响应，显著降低源站负载，同时减少重新生成页面的并发冲突。在CDK中，只需在创建源站时指定enableOriginShield: true并选择一个区域即可。

常见问题与排查思路

配置CloudFront加速Next.js SSR应用时，最常见的问题是缓存了不应该缓存的内容。例如，没有正确处理Cookie，导致用户A的购物车数据被缓存并展示给用户B。这通常是因为缓存键没有包含必要的Cookie，或者缓存策略设置得过宽。解决方案是仔细审查每个缓存行为的缓存策略，确保所有影响响应内容的请求特征都包含在缓存键中。对于任何包含用户特定数据的页面，建议将缓存策略设置为CACHING_DISABLED，或者使用边缘函数将带有认证信息的请求标记为不缓存。

另一个常见问题是回源超时。Next.js的服务器端渲染可能耗时较长，特别是在数据获取复杂或代码未优化的情况下。CloudFront对源站的默认响应超时时间通常是30秒，如果源站处理超过这个时间，CloudFront会返回504错误。此时需要检查源站性能，或者调整CloudFront使用的源站请求超时（在源站配置中设置connectionTimeout和socketTimeout）。同时，建议在Next.js中启用增量静态生成或使用缓存层（如Redis）减少渲染耗时。

排查缓存问题时，可以利用CloudFront响应头X-Cache来判断是否命中缓存。值为Hit from cloudfront表示缓存命中，Miss from cloudfront表示未命中并已回源，RefreshHit from cloudfront表示缓存已过期但回源验证通过。此外，开启CloudFront标准日志后，可以分析每个请求的缓存状态、处理时间和回源原因，帮助定位问题。在开发阶段，建议在浏览器中检查响应头，并结合源站日志确认请求是否真正到达源站。通过逐步收紧缓存策略并观察用户反馈，可以找到性能与正确性的最佳平衡点。

CloudFrontNext.js服务器端渲染修改时间：2026-08-22 02:07:11