Kong 0.10.3版本KONG_RESPONSE_LATENCY头返回0且延迟值不符文档

我也曾在Kong 0.10.x版本踩过类似的latencies统计坑，结合当时的排查经验和对Kong早期版本的了解，给你梳理下问题原因和可行的解决方向：

1. Kong延迟显示为0的核心原因 #

Kong 0.10.x版本的latencies统计逻辑存在已知bug：

• 早期版本中，Kong自身延迟（即插件执行时间）的计时点是绑定在插件执行生命周期上的。如果请求没有触发任何自定义插件（或者插件执行耗时极短，低于计时精度），Kong会错误地将这个值记为0，而不是实际的基础处理耗时。
• 举个例子：如果你只是用Kong做简单的反向代理，没有添加auth、rate-limiting这类插件，就很容易出现Kong延迟持续为0的情况。

2. 关于三个延迟值不匹配的问题 #

根据Kong文档描述，理论上request（总延迟）应该约等于Kong + proxy，但在0.10.x版本中：

• request延迟包含了客户端到Kong的TCP连接建立、请求接收等额外网络开销，而Kong延迟仅统计插件执行阶段的时间，proxy是上游API的处理时间，所以三者的数值不会严格相等。
• 如果偏差过大（比如Kong + proxy远小于request），那也是版本的计时逻辑bug导致的，后续版本已经修复了这个统计偏差。

3. 临时排查与验证方法 #

• 开启debug日志：修改kong.conf中的log_level = debug，重启Kong后查看日志，里面会输出每个请求各阶段的详细计时点，你可以手动核对计算三个延迟值是否符合预期。
• 添加测试插件：给测试路由添加几个常用插件（比如rate-limiting或key-auth），再观察Kong延迟是否有数值。如果此时Kong延迟正常显示，就可以确认是无插件场景下的统计bug。

4. 根本解决方案 #

最稳妥的办法是升级Kong版本：0.10.x是比较老旧的版本，后续的0.11+版本不仅修复了latencies统计的多个bug，还优化了计时逻辑，让三个延迟值的统计更符合文档描述，同时也修复了LATENCY响应头的数值错误问题。

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