网关的鉴权是怎么过的？从原理到落地

大模型服务一旦对外开放，最先接到每个请求的都是网关，网关鉴权就是这一步里最关键的动作。可以把它想成写字楼前台：访客先报到，前台核对身份、确认能去哪一层，然后才放行。前台放水，楼里再严的门禁也失去意义；前台太慢，整栋楼都会堵在大堂。

类比的边界也要说清：前台认脸，网关认的是请求头里那串机器可读的凭证；前台可以口头放行熟客，网关的每一次判断都必须可复现、可追溯，因为出了问题它要对账。无论是用扣子编排的智能体应用，还是接了豆包、文心一言的客户端，请求都要先过这道关。

网关在整个调用链里的位置

客户端、网关、后端服务三层结构中，网关卡在中间偏外的位置。进来的东西很原始：一条 HTTP 请求，带着凭证和参数。网关先做身份核验，再做额度与频次检查，最后决定转发或拒绝——出去的要么是带上了用户上下文的内部请求，要么是一个明确的 401、403 或 429。后端因此可以完全不关心调用者是谁，只处理业务本身，这是网关存在的根本理由。

把这个位置想清楚，还能解释另一件事：为什么灰度发布、限流、计费埋点都爱挂在网关层，因为这些动作都需要赶在请求进入业务之前完成。比如灰度流量是怎么按比例分的，就是在网关侧完成的分流判断。

一枚凭证的完整通行流程

按步骤拆：第一步，网关从请求头解析出凭证，常见的有三种形态——静态 API Key、有时效的 JWT、以及对请求体整体签名的签名串。第二步，拿凭证去查状态，通常先查内存或 Redis 缓存，未命中再落库。第三步，逐项核对：凭证是否在有效期内、调用方有没有被封禁、这条路由是否在其授权范围内、配额是否已用尽。第四步，输出结果并写日志，日志里只记凭证指纹，不存完整密钥。

全流程的正常耗时一般控制在几毫秒，靠的是缓存扛住绝大多数查询。可带走的判断：如果某类调用突然整体变慢，先查凭证校验链路上的外部依赖，比如缓存抖动或名单同步延迟，而不是急着扩后端。

凭证失效与刷新怎么处理

失效分两类：自然过期与主动吊销。自然过期靠凭证自带的时效字段，客户端在失效前用刷新凭证换新；主动吊销则靠名单，网关侧维护一份被禁用凭证的列表并定时同步。这里有个容易踩的坑：吊销存在传播时延，从名单生成到所有网关节点生效之间，旧凭证可能还能用几十秒，敏感操作要在这段时间内做二次校验。

凭证体系的上限取决于密钥本身的保管水平。密钥在落库前怎么加密、主密钥放在哪，建议接着读密钥是怎么加密存储的？每一步都讲透，两篇合起来才是完整链路。

常见的放行误区

• 只验 key 不验来源：换台机器拿着同一把 key 也能过，等于门禁只看工牌不看人，应叠加来源约束或访问范围声明。
• 把长期凭证下发到前端页面：前端拿到的应是短时效、窄权限的临时凭证，而非主 key 本体。
• 日志打印完整凭证：日志一旦外泄，凭证等于公开，应只记录前几位与指纹。
• 鉴权通过就永久信任：网关放行后，后端对内网调用也应保留最小权限约束，不能全裸奔。

顺带一提，网关也是计费数据的起点，每一笔通过鉴权的调用都会在此产生计量记录，口径怎么定可以看成本分摊的口径是怎么定的？机制细节全梳理一文。

网关鉴权速查表

• 凭证形态：API Key（简单）、JWT（带时效）、签名串（防篡改）
• 核验顺序：解析 → 查缓存 → 核时效与额度 → 放行或拒绝 → 写日志
• 吊销关键点：名单同步有时延，敏感操作需二次校验
• 底线动作：日志只存指纹，前端只发临时凭证

关于网关鉴权再多问三句

• 内网服务之间还需要鉴权吗？：需要，内网只是边界更可信，服务间调用同样要最小权限，否则一处失守全线失守。
• 为什么请求返回 403 而不是 401？：401 表示没认出你是谁，403 表示认出了你但不许去，前者查凭证本身，后者查授权范围。
• 网关实例挂了请求会全部失败吗？：正常是多实例部署，坏节点配合回滚与摘除机制自动下线，过程可参考版本回滚是怎么快速做的？过程拆开看。