GPTs 的 Action 调用 API 返回 403 鉴权失败，该先查密钥、Header 还是服务端的来源 IP 策略？

GPTs 调用 API 报 403，绝大多数情况不是密钥填错，而是请求已经被识别出身份、却被服务端的策略拒绝；先分清 401 与 403，能省掉一半排查时间。401 表示凭证缺失或无效，403 表示凭证有效但无权访问目标资源，两者的修复方向完全相反。这条判断适用于 Action 通过 HTTPS 调用的外部接口；如果是在本地对话客户端里直连 API 报 403，属于另一套排查路径，不适用下面的顺序。 GPTs 的鉴权配置在 Action 编辑页的 Authentication 区块，API Key 类只有 Bearer、Basic 和自定义 Header 三种形态，选错形态就会出现「密钥本身没问题是请求没带上」的 403。核对三件事：Header 名的大小写是否与服务端读取的一致，Bearer 前缀是否被重复拼接成「Bearer Bearer xxx」，自定义 Header 场景下后端读 X-API-Key 而配置里写成了 api-key 时，大小写敏感的服务端会直接判为未授权。Basic 形态要求的是 base64 编码后的用户名密码串，把裸密钥填进去同样会失败。 把请求从 GPTs 里摘出来用 curl 复现一遍，是唯一能区分「平台配置问题」和「服务端策略问题」的动作。做法是导出 Action 的 OpenAPI schema，取 servers 里的基地址加上 operation 的 path，带上与配置完全一致的 Header 发一条最小请求。返回 200 说明问题在 GPTs 侧的配置或参数映射；返回 403 且响应体带明确错误码，说明服务端认得这次请求，问题在权限；本地 200、GPTs 里 403，则问题几乎一定出在来源特征或请求头差异上。 路径拼接错误通常返回 404，但请求先穿过网关的鉴权中间件时，常被统一改写成 403，因此不能只看状态码。典型情况是 servers 写成 https://api.example.com/v1，operation path 又写了 /v1/chat/completions，最终请求变成 /v1/v1/…；也可能是基地址结尾少了斜杠导致路径被截断。修正方式是把版本前缀只保留在一处，基地址不带尾部斜杠，path 从资源名写起，改完在 Actions 的预览里重跑一次再发布。 模型权限与 scope 不足是 403 的高频来源，尤其在按密钥分配可用模型的平台上。密钥只授权了部分模型时，调用未授权模型会返回类似 model_not_allowed 的 403；OAuth 形态则常见 insufficient_scope，表示授权范围不包含当前接口。处理方式不是换密钥，而是到平台后台把目标模型或接口加入该密钥的授权列表，或重新发起授权并勾选对应 scope，然后确认 GPTs 侧的 token 已刷新。 来源 IP 与地域策略是自建服务端最常见的 403 原因，因为 GPTs 的请求从境外发起，出口 IP 不固定且无法提前加入白名单。常见触发点是安全组或 WAF 打开了仅允许境内 IP 访问、按 User-Agent 过滤非浏览器请求、或对特定地区做了封禁。可行的做法是关闭地域封禁与 UA 过滤，为 Action 单独放行一条不做 IP 白名单的鉴权通道，或在服务端前置一层接受境外来源的网关，而不是反复去改 Action 里的密钥。 OAuth 类型的 Action 出现 403，先看 token 是否过期、refresh 流程是否配全。授权码换来的 access token 有效期通常很短，若没有配置 refresh token 的换取地址，过期后每次调用都会被判为无权访问；同时要确认 token endpoint 返回的 scope 与接口要求一致，以及服务器时间偏差过大导致 token 被判定为尚未生效或已失效。排查时直接打印 token 前缀与过期时间，比在 GPTs 界面反复重连更有效。 密钥被轮换、被禁用或账户额度耗尽，在不同平台上的表现并不一致，有的返回 401，有的直接返回 403。判断方法是查服务端调用日志：日志里完全没有这次的请求记录，说明请求被拦在网关或 CDN 层，与业务鉴权无关；日志里有记录且响应体带权限类错误码，才算真正落到业务层的权限判断。这一步能把「改密钥」和「改网络策略」两条完全不同的路线分开。 请求方法、Content-Type 与请求体结构写错，多数返回 400、405 或 415，但部分网关会把所有非预期请求统一回成 403，所以不能只盯鉴权。检查 operation 是否声明为 POST、请求头是否带 application/json、必填字段是否在 schema 里标了 required、operationId 是否重复。参数缺失会被服务端当成非法调用，返回的错误码看似权限问题，实际是契约不匹配。 按固定顺序排查，比凭经验猜要快：第一步用 curl 复现，第二步核对鉴权类型与 Header 名，第三步看路径拼接，第四步查模型与 scope 授权，第五步看来源 IP 与地域策略，第六步才怀疑密钥失效。顺序颠倒最常见的后果是把网络层问题当成密钥问题，反复重置密钥却毫无变化。每一步都要留下请求样例和响应体，否则问题会随配置改动而漂移，无法复现。 403 本身不消耗模型的 token 额度，但无脑重试会撞上限流并返回 429，把一次权限问题拖成可用性问题。建议在 Action 的调用逻辑里对 403 直接失败并记录错误码，不做自动重试；对 5xx 才启用有限次退避重试。上线前用预览环境跑一遍带错误路径的用例，确认错误码能被正确区分，比上线后翻日志省事得多。 把密钥写进 OpenAPI schema 的描述字段、或在自定义 Header 里明文回传，是排查完 403 之后必须顺手修掉的合规问题；描述字段会随 GPT 配置一起被读取，并不具备保密性。正确做法是只把密钥保存在 Action 的鉴权配置中，由平台在请求时注入，应用侧再按最小权限分配密钥并对调用做日志留存。这样即便某天再次出现 403，也能从日志里直接定位是被哪条策略拒绝，而不是从头猜。