这种情况确实挺让人挠头的——按道理移除授权器后端点应该是开放访问的，结果还是401，说明问题大概率不在授权器本身，得从API Gateway的其他配置或者请求细节入手。我给你列几个常见的排查方向，你可以一步步试：

• 先确认API是否重新部署：修改授权器（包括移除）之后，一定要记得在API Gateway控制台点击「Deploy」，选择对应的部署阶段（比如prod、dev）。很多人容易忽略这一步，导致旧的授权配置还在生效，自然还是会拦截请求。

• 检查阶段设置里的API Key要求：进入API Gateway的「Stages」页面，找到你正在测试的阶段，查看「Settings」标签下的「API Key Required」选项。如果这个开关是打开的，哪怕你移除了授权器，请求也必须携带x-api-key头，否则就会返回401。这个是非常容易被忽略的坑。

• 验证请求的端点URL是否正确：有没有可能你测试的URL对应是另一个未修改授权器的阶段？比如你在dev阶段移除了授权器，但请求的是prod阶段的URL？或者路径拼写错误，API Gateway找不到对应的资源，也可能返回401（虽然通常是404，但部分配置下会有这种情况）。

• 查看CloudWatch日志找具体原因：这是最有效的排查方式。先开启API Gateway的日志记录：进入阶段的「Logs/Tracing」标签，打开「Enable CloudWatch Logs」，设置日志级别为「INFO」或者「ERROR」，然后重新发起请求，去CloudWatch的日志组里找对应的请求日志。日志里会明确告诉你为什么返回401，比如是「Invalid API key」「Authorization header not present」还是其他原因，一目了然。

• 排查Postman请求的细节：确认Authorization头的格式是否正确——正确的格式是Bearer <access_token>，注意Bearer后面只有一个空格，不要多打或者少打。你可以直接在Postman的「Authorization」选项卡选择「Bearer Token」，然后粘贴token进去，让Postman自动生成正确的请求头，避免手动输入出错。

如果是之前带token时的401问题，还可以额外检查：

• 用JWT解码工具（比如Postman内置的JWT解码器，在「Authorization」选项卡选「JWT」就能解码）查看token的aud（受众）、iss（签发者）是否和授权器配置的一致。比如Cognito的token，aud应该是用户池的客户端ID，iss应该是用户池的地址，要是不匹配，授权器会直接拒绝。
• 确认token有没有过期，exp字段是过期时间戳，转换成时间看看是否在当前时间之后。

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