Lambda中Serverless Express应用返回413错误排查求助

API 探路者

2026-8-21

问题

在AWS Lambda上运行Serverless Express应用时，某响应大小约800KB的请求持续返回错误：

LAMBDA_RUNTIME Failed to post handler success response. Http response code: 413.

最初怀疑是内部逻辑超时，但添加日志后确认所有处理流程最多耗时6秒（远低于Lambda 30秒的超时配置），且日志中无任何报错，返回的数据也正确。响应头信息如下：

x-amz-cf-pop: YTO50-C3
x-amzn-errortype: InternalServerErrorException
x-amzn-requestid: f291230-342-4324-324-cb7df188944c
x-cache: Error from cloudfront

本地环境测试完全正常，想了解：

可能的错误原因
调试建议
如何调试线上运行的Lambda实例

附上更新后的serverless.yml配置：

service: my-service
variablesResolutionMode: 20210326
useDotenv: true

custom:
  serverless-offline:
    useChildProcesses: true
  webpack:
    webpackConfig: ./webpack.config.js
    packager: "yarn"
    includeModules: true
  prune:
    automatic: true
    includeLayers: true
    number: 3
  customDomain:
    domainName: "abc.com"
    basePath: "val"
    stage: ${someval}
    createRoute53Record: true

plugins:
  - serverless-domain-manager
  - serverless-webpack
  - serverless-prune-plugin
  - serverless-webpack-prisma
  - serverless-offline

provider:
  lambdaHashingVersion: "20201221"
  name: aws
  runtime: nodejs14.x
  region: us-east-1
  timeout: 30
  apiGateway:
    minimumCompressionSize: 1024 
  iamRoleStatements:
    - Effect: Allow
      Action: ssm:Get*
      Resource:
        - "abc/${opt:stage}/backend/*"
        - "abc/${opt:stage}/services/*"
    - Effect: Allow
      Action: kms:Decrypt
      Resource: "*"
    - Effect: "Allow"
      Action: s3:PutObject
      Resource: "abc/*"
    - Effect: "Allow"
      Action:
        - sns:Publish
      Resource: "*"

  environment:
    - myvars: 'abc'

functions:
  graphql:
    handler: src/index.graphqlHandler
    events:
      - http:
          path: /graphql
          method: options
      - http:
          path: /graphql
          method: get
      - http:
          path: /graphql
          method: post

可能的错误原因

Lambda Runtime API响应体积溢出：虽然800KB远低于Lambda 6MB的响应限制，但Serverless Express在包装响应时可能额外序列化了请求/响应对象的冗余属性（如未清理的中间件上下文、大对象引用），导致最终提交给Lambda Runtime API的payload超过了隐藏的传输限制。
API Gateway压缩配置未生效：当前设置minimumCompressionSize: 1024，仅对1KB以上的响应启用压缩，但可能存在压缩未正确触发的情况，未压缩的响应在经过CloudFront或API Gateway内部链路时触发了中间节点的大小限制。
CloudFront响应限制：响应头中的x-cache: Error from cloudfront提示错误来自CloudFront，若你手动配置了CloudFront分发的Maximum Response Size，可能该值设置过小，导致800KB响应被拦截。
序列化异常：响应中可能包含无法正确JSON序列化的类型（如Buffer、循环引用对象），序列化过程中产生了体积远超预期的payload。

调试建议

验证序列化后的响应体积：在handler返回响应前，添加日志打印JSON.stringify(响应体).length，确认实际提交给Lambda的payload大小，排查是否存在体积意外膨胀的情况。
强制启用响应压缩：将apiGateway.minimumCompressionSize改为0，强制API Gateway对所有响应进行压缩，压缩后的800KB响应体积会大幅降低，大概率能绕过中间节点的大小限制。
绕过Serverless Express测试：编写极简Lambda handler，直接返回相同的800KB数据，不通过Serverless Express包装，若问题消失，则可定位到Serverless Express的封装逻辑问题，尝试升级serverless-http库或检查其配置。
检查CloudFront配置：登录AWS控制台查看CloudFront分发的限制设置，确认最大响应大小未被设置为小于800KB的值，同时检查缓存行为是否有异常的响应头或内容过滤规则。

线上Lambda调试方法

启用AWS X-Ray追踪：开启X-Ray后，可查看请求在CloudFront、API Gateway、Lambda之间的完整链路，定位413错误发生的具体环节，同时能看到各节点的payload大小和耗时数据。
添加精细化日志：在响应生成的关键节点（如数据处理完成后、Serverless Express封装前）打印响应头数量、响应体原始大小、序列化后大小等信息，必要时可打印响应的完整内容（注意脱敏敏感信息）。
控制台直接测试：在Lambda控制台创建模拟测试事件，复现相同请求，实时查看返回结果和日志，快速验证修改效果。
远程调试Lambda：使用VS Code配合AWS Toolkit插件，配置远程调试，连接到运行中的Lambda实例，单步跟踪响应生成和封装过程，定位代码中的问题。

内容的提问来源于stack exchange，提问作者kvnam