API 和 AI 网关
Kong 或 Kong Gateway 是一款云原生、跨平台、可扩展的 API 网关，以其高性能和通过插件实现的可扩展性而闻名。它还提供了先进的 AI 流量功能，支持多种 LLM、语义安全、MCP 流量安全和分析等。通过提供代理、路由、负载均衡、健康检查、身份验证（以及 更多）的功能，Kong 可轻松成为集中管理微服务或传统 API 流量（以及 LLM 和 MCP 流量）的核心层。
Kong 可在 Kubernetes 上本地运行,这要归功于其官方的 Kubernetes Ingress Controller。
我们建议使用以下说明中的 Docker-compose 分发版,但如果您更喜欢在无数据库模式下运行 Kong 网关,还有一个 Docker 安装 过程。无论您是在云端、在裸机上还是使用容器,都可以在我们的 官方安装 中找到所有支持的分发版。
Active-healthcheck 目标在 3.9 dbless 上处于 UNHEALTHY 状态,没有自动恢复(5xx 卸载未恢复;孤儿状态冻结计数器)
速率限制: Redis 同步的 `sync_rate` 不应高于周期
在超过配额且启用 block_on_first_violation 后,响应速率限制会将请求转发到上游
新的 DNS 客户端永久地将收到的具有 TTL 值为 0 的 DNS 记录固定下来,这在查询缓存解析器时可能会发生。
在成功恢复健康检查后的 Buggy 行为
ai-proxy Bedrock: `bedrock.additionalModelRequestFields` 以 JSON 数组的形式发送 (400),而 `bedrock.toolConfig.toolChoice` 被忽略
ai-proxy Bedrock: Claude Opus 5.5 的聊天响应在推理时会丢失 `content` 字段内容是第一个块
ai-proxy-advanced (llm_format: bedrock): 在同一消息中,内容块跟随 toolResult 时,在 bedrock 适配器中出现 500
worker.lua:164: 无法存储事件: 队列溢出导致 mlcache 的无效化损失以及上游目标过时
PostgreSQL TLS 手shake 省略了 SNI,导致 SNI 路由代理后面的 Kong 无法正常工作(捆绑的 pgmoon 传入了空的 server_name)