上面的代理规则详细说明了Kong如何将传入的请求转发给上游服务。下面，我们将详细说明在Kong用注册路由匹配HTTP请求和请求的实际转发之间发生了什么。

负载均衡

Kong实现了负载平衡功能，可以跨上游服务的实例池分发代理请求。

有关配置负载平衡的更多信息，请参阅负载均衡https://docs.konghq.com/2.2.x/loadbalancing/。

插件的执行

Kong可以通过“插件”进行扩展，这些插件将自己与被代理请求的请求/响应生命周期挂钩。插件可以在您的环境中执行各种各样的操作对代理请求进行转换。插件可以配置为全局运行(对于所有代理的流量)或者在特定的路由和服务上运行。在这两种情况下，您必须通过Admin API创建插件配置。

一旦路由被匹配(及其关联的服务实体)，Kong将运行与这些实体关联的插件。配置在路由上的的插件会在服务上配置的插件之前运行，但在其他情况下，应用插件关联的一般规则。

这些配置好的插件将运行它们被访问的阶段，您可以在插件开发指南中找到更多的信息https://docs.konghq.com/2.2.x/plugin-development。

代理和上游的超时时间

一旦Kong执行了所有必要的逻辑(包括插件)，它就准备好将请求转发给你的上游服务。这是通过Nginx的ngx_http_proxy_module完成的。您可以通过以下服务属性为Kong和给定上游之间的连接配置所需的超时时间：

• connect_timeout：以毫秒为单位定义建立上游服务连接的超时。默认为60000。
• write_timeout：定义两个连续写操作之间的超时时间(以毫秒为单位)，用于将请求传输到上游服务。默认为60000。
• read_timeout：定义从上游服务接收请求的两个连续读取操作之间的超时时间(以毫秒为单位)。默认为60000。

Kong将通过HTTP/1.1发送请求，并设置以下请求头：

• Host：<your_upstream_host>，如本文前面所述。
• Connection：keep-alive，允许重用上游连接。
• X-Real-IP： <remote_addr>，其中$remote_addr是由ngx_http_core_module提供的同名变量。请注意，$remote_addr可能被ngx_http_realip_module覆盖。
• X-Forwarded-For: <address>，其中<address>是ngx_http_realip_module提供的$realip_remote_addr的内容，附加到同名的请求头中。
• X-Forwarded-Proto： <protocol>，其中 <protocol>是客户端使用的协议。在$realip_remote_addr是受信任地址之一的情况下，如果提供了同名的请求头，则会被转发。否则，将使用ngx_http_core_module提供的$scheme变量的值。
• X-Forwarded-Host：<host>，其中<host>是客户端发送的主机名。在$realip_remote_addr是受信任地址之一的情况下，如果提供了同名的请求头，则会被转发。否则，将使用ngx_http_core_module提供的$host变量的值。
• X-Forwarded-Port：<port>，其中<port>是接受请求的服务器的端口。在$realip_remote_addr是受信任地址之一的情况下，如果提供了同名的请求头，则会被转发。否则，将使用ngx_http_core_module提供的$server_port变量的值。
• X-Forwarded-Prefix：<path>，其中<path>是Kong接受的请求的路径。在$realip_remote_addr是受信任地址之一的情况下，如果提供了同名的请求头，则会被转发。否则，将使用ngx_http_core_module提供的$request_uri变量的值(去掉了查询字符串)。注意：Kong将返回“/”作为空路径，但它不会对请求路径进行任何其他规范化操作。

所有其他的请求头都由Kong按原样转发。

在使用WebSocket协议时出现了一个例外。

如果是Kong设置以下请求头信息，以允许升级客户端和上游服务之间的协议：

• Connection: Upgrade
• Upgrade: websocket

错误和重试

无论代理过程中出现什么错误，Kong都会使用底层的Nginx重试机制将请求传递给下一个上游。

这里有两个可配置的元素：

1. 重试次数：可以使用retries属性为每个服务配置重试次数。有关这方面的更多细节，请参阅管理API。
2. 错误的定义：这里Kong使用Nginx默认值，这意味着在与服务器建立连接、向其传递请求或读取响应头时发生错误或超时。

第二个选项基于Nginx的[proxy_next_upstream][proxy_next_upstream]指令。这个选项不能通过Kong直接配置，但可以通过自定义Nginx配置添加。

响应

Kong接收来自上游服务的响应，并以流方式将其发送回下游客户端。此时，Kong将执行添加到路由或服务的后续插件，这些插件在header_filter阶段实现了一个钩子。

一旦所有已注册插件的header_filter阶段执行完毕，Kong将添加以下请求头，并将完整的请求头发送给客户端：

• Via：kong/x.x.x，其中x.x.x 是Kong的版本。
• X-Kong-Proxy-Latency：<latency>，其中<latency>是Kong从客户端收到请求到发送请求到上游服务之间的时间，以毫秒为单位。
• X-Kong-Upstream-Latency：<latency>，其中<latency>是Kong等待上游服务响应第一个字节的时间(以毫秒为单位)。

一旦响应头被发送到客户端，Kong将开始执行为实现body_filter钩子的路由或服务注册的插件。由于Nginx的流特性，这个钩子可能被调用多次。此类body_filter钩子成功处理的上游响应的每个块都被发送回客户端。