Kong测评：部署前后最容易踩的8个坑
这篇 Kong测评不聊参数表上的漂亮话，直接按部署流程复盘那些真会让接口挂掉的坑：镜像能启动却不转发、限流单机有效集群失效、管理端口裸奔、路由优先级抢流量。准备上 Kong 前，照着这条流程过一遍，能少熬几次夜。
第1步：选部署模式时，别把“能跑”当成“能用”
Kong测评里最该先看的不是插件数量，而是部署模式是否贴合团队。单机 Demo 用 DB-less 很省心：配置文件跟着代码走，重启即可加载。可一旦多人频繁在管理界面或 API 改配置，文件、实际状态和发布流程就可能脱节。
踩坑信号很典型：同一个路由，测试环境有、生产环境没有；或者容器重启后，临时加的 Consumer 消失。解决办法不是“再点一次”，而是明确配置来源。要么用 Git 管理声明式配置并走发布，要么建立规范化的管理平面流程，别两套方法混着改。
第2步：连上游前，先验证容器里的网络视角
本机浏览器能打开后端地址，不代表 Kong 容器能打开。Docker 里的 localhost 指向容器自己，不是宿主机。很多人给 Service 配 http://localhost:8080，结果永远 502；如果上游在另一容器，应使用同一 Docker 网络内的服务名。
排查顺序别乱：先进入 Kong 容器，用 curl 请求上游；再检查 Service 的 host、port、protocol；最后看 DNS 和网络策略。502、504 不一定是 Kong 坏了，十有八九是上游不可达、连接超时，或者上游只监听了 127.0.0.1。
第3步：配路由时，先防“规则抢路由”
路由重叠是 Kong 使用体验里最隐蔽的一类坑。你配了 /api 和 /api/users，以为请求必然进入后者；但如果还叠加 host、正则、strip_path 或不同版本的匹配行为，结果可能和脑内预期不一样。
我的做法是给每条关键 Route 建最小回归用例：请求路径、Host、HTTP Method、预期上游各写一条。尤其是迁移旧系统时，别只测 GET；POST、OPTIONS 和带尾斜杠的 URL 都要过。路由配置不是写完就完，它本质上是流量规则。
第4步：上认证插件前，分清“用户身份”和“调用方身份”
拿 key-auth 当完整登录方案，是常见误用。API Key 适合识别调用应用或内部脚本，但它通常不表达用户会话、权限层级和短时失效。面向 C 端用户的登录，往往需要配合 OIDC、JWT 或由统一身份系统处理。
另一个坑是把凭据直接放 URL 查询参数。查询串容易出现在浏览器历史、代理日志和监控平台里。能走请求头就走请求头；密钥要有轮换方案；Consumer 命名也别用员工真实姓名加手机号，日志和导出数据会到处扩散。
第5步：压测限流，再决定它是否真能保护你
Kong测评必须单独测限流。单节点下看见第 11 次返回 429，不代表多副本环境也准确。如果计数存储只在本地内存，两个节点各自都允许 10 次，用户总共可能打进 20 次。这个误差在秒杀、短信接口上足够出事故。
上线前做一个小实验：从两台客户端并发请求，观察不同 Kong 实例的结果和计数一致性；再模拟 Redis 不可用，确认业务是失败关闭还是失败放行。没有“永远正确”的选择，重点是团队知道降级时会发生什么。
推荐阅读
常见问题
Kong返回502怎么排查？
先从 Kong 容器内部请求上游地址，确认 DNS、端口和网络连通；再看 Service 的协议与超时设置；最后检查上游服务日志。容器中配置 localhost 是最常见原因之一。
Kong限流插件适合生产集群吗？
适合，但要选择符合拓扑的计数策略和存储方案。单机本地计数在多节点下会产生偏差；涉及配额、风控、短信等强约束场景，应实测一致性和故障降级行为。
Kong Admin API能直接开放给前端吗？
不能。Admin API 是管理入口，应通过内网、访问控制、认证和审计保护。前端或普通业务客户端只能访问代理入口。