传统架构里，想给响应加一个自定义Header、根据用户设备重定向URL，或者做一次灰度分流，通常要在源站服务器上写逻辑，或者干脆加一层Nginx转发。这么做的问题很明显：所有请求都得回源，延迟和带宽成本都会上升，而且源站一旦扛不住，整个链路都受影响。AWS CloudFront提供的Lambda@Edge把计算能力下沉到了全球几百个边缘节点，让代码在离用户最近的地方执行，直接在缓存层之前或之后改写请求与响应，既减轻了源站压力，又把处理延迟控制在毫秒级。这篇文章就来完整演示一遍如何在边缘节点运行代码并修改HTTP响应。
一、先搞懂Lambda@Edge的四种触发位置
Lambda@Edge的本质是把Lambda函数关联到CloudFront分发的缓存行为上，函数在边缘站点触发。它支持四个事件位置，理解它们的区别是用好这套方案的前提。第一个是查看器请求，发生在CloudFront收到用户请求之后、检查缓存之前，适合做URL重写、请求头注入；第二个是查看器响应，发生在响应返回给用户之前，无论内容来自缓存还是源站，适合做响应头修改；第三个是源站请求，只在缓存未命中需要回源时触发；第四个是源站响应，发生在源站返回内容之后、写入边缘缓存之前，适合在内容被缓存前统一处理。
举个典型例子：如果要给所有响应加上安全相关的Header，放在查看器响应触发可以保证缓存命中的请求也能被处理，但代价是每个请求都要执行一次函数；放在源站响应触发则只在回源时执行，成本更低，但命中缓存的请求不会再执行函数。如果Header内容对每个用户都一样，优先选源站响应；如果需要按请求动态变化，就只能用查看器响应。这种触发位置的权衡直接决定了成本和正确性，实践中一定要先想清楚。
还有一点容易被忽略：Lambda@Edge函数必须在美东弗吉尼亚区域创建，也就是us-east-1。函数发布后AWS会自动把它复制到各个边缘站点执行，但管理入口始终在us-east-1。如果你在控制台其他区域找Lambda@Edge选项，是找不到关联CloudFront的入口的。
二、实战：在查看器响应中注入自定义响应头
下面通过一个完整案例演示如何在响应中注入Header。场景是这样的：站点需要统一加上一组安全响应头，包括X-Content-Type-Options、X-Frame-Options，以及一个自定义的X-Edge-Processed标记，用来验证函数确实执行过。
首先在us-east-1区域创建Lambda函数，运行时选择Node.js，角色需要带lambda的Edge执行权限（控制台创建时勾选Lambda@Edge角色模板会自动生成）。函数代码如下：
exports.handler = async (event) => {
const response = event.Records[0].cf.response;
const request = event.Records[0].cf.request;
// 注入安全响应头
response.headers['x-content-type-options'] = [{
key: 'X-Content-Type-Options',
value: 'nosniff'
}];
response.headers['x-frame-options'] = [{
key: 'X-Frame-Options',
value: 'DENY'
}];
// 标记此响应经过边缘函数处理
response.headers['x-edge-processed'] = [{
key: 'X-Edge-Processed',
value: 'true'
}];
// 记录来源，便于确认响应来自缓存还是源站
console.log('处理URI: ' + request.uri);
return response;
};代码逻辑很简单：从event对象中取出response结构，直接修改headers字典再原样返回。注意Header的值必须是数组结构，每个元素包含key和value两个小写规范的字段，这是Lambda@Edge事件格式的硬性要求，写成普通字符串会直接报错。
函数写好后先在本地测试一次，确认返回JSON格式正确。然后在函数页面点击Actions下拉菜单，选择部署到Lambda@Edge，选择你要关联的CloudFront分发和缓存行为，触发位置选CloudFront Response，点击部署。之后分发状态会变成InProgress，等它重新部署完成，用curl命令验证响应头：
curl -I https://你的域名.ipipp.com/index.html # 输出中应能看到： # X-Content-Type-Options: nosniff # X-Frame-Options: DENY # X-Edge-Processed: true
看到X-Edge-Processed为true，说明函数已经在边缘节点生效。即使删除源站上的这些Header配置，边缘函数也会把它们补回来，等于多了一层兜底。
三、调试、限制与常见坑
Lambda@Edge的调试体验和普通Lambda不太一样。函数在边缘执行时，日志不会出现在触发区域的CloudWatch里，而是统一写入us-east-1的日志组，日志组名以.amazonaws.com开头，方便区分。如果部署后函数似乎没执行，第一件事就是去us-east-1的CloudWatch Logs里按这个前缀找日志流。
资源限制方面要特别注意：查看器触发的函数内存上限128MB，执行时间最长5秒；源站触发的函数内存512MB，最长30秒。函数代码包压缩后不能超过1MB，这个限制比普通Lambda的50MB严格得多，意味着不能随手打包一堆依赖，能用原生模块就尽量用原生实现。另外函数必须是版本化的，部署到边缘的永远是某个具体版本而不是latest标签，每次修改代码后需要发布新版本再重新关联。
常见报错也有几个高频场景。第一种是5xx错误，多半是函数执行异常，比如Header结构写错触发了运行时报错，CloudFront会把函数错误转换成502返回给用户，这时看CloudWatch日志里的堆栈信息基本能定位。第二种是修改了不该改的字段，例如在查看器响应里直接改body却没处理压缩内容，如果源站返回的是gzip压缩体，直接拼接字符串会产生乱码，正确做法是先判断content-encoding头，压缩内容要么透传，要么解压后处理再重新压缩。第三种是循环触发，在查看器请求里把URL重写后又匹配到了同一个缓存行为，导致函数反复执行，重写时要确保目标路径落在预期的行为规则上。
成本上也需要有概念：Lambda@Edge按请求次数和执行时长计费，查看器响应触发意味着每个请求都计费，高流量站点下这笔费用不能忽视。如果逻辑只跟内容相关而与用户无关，把它挪到源站响应触发，配合CloudFront缓存，执行次数会下降几个数量级，这是最有效的省钱手段。
总结一下，Lambda@Edge把逻辑推到了离用户最近的位置，Header改写、访问控制、URL重写这类轻量逻辑非常适合放在边缘执行。实践中抓住三点：选对触发位置、注意事件结构的数组格式、严格控制在资源限制之内。掌握这套思路后，很多原本需要源站参与的动态逻辑都可以下沉到边缘，架构会清爽不少。
CloudFrontLambda@Edge边缘计算修改时间：2026-09-16 06:02:34