Kong（v1.0.2）代理參考

介紹

在本文中，我們將通過詳細解釋Kong的路由功能和內部工作原理來介紹它的代理功能。

Kong公開了幾個接口，可以通過兩個配置屬性進行調整:

proxy_listen，它定義了一個地址/端口列表，Kong將在這些地址/端口上接受來自客戶機的公共流量，並將其代理到您的上游服務(默認情況下為8000)。

admin_listen，它還定義了一個地址和端口列表，但是這些地址和端口應該限制為僅供管理員訪問，因為它們公開了Kong的配置功能:Admin API(默認情況下是8001)。

注意:從1.0.0開始，API實體已經被刪除。本文檔將介紹與新路由和服務實體的代理。

如果您使用0.12或更低版本，請參閱此文檔的舊版本。

術語

client:指下游客戶端對Kong代理端口的請求。

upstream service:指位於Kong后面的您自己的API/服務，客戶端請求被轉發的最終目的地。nginx中的上游服務器。

Service:顧名思義，服務實體是每個上游服務的抽象。服務的示例包括數據轉換微服務、計費API等。

Route:指Kong路由實體。路由是進入Kong的入口點，定義要匹配的請求的規則，並路由到給定的服務。

Plugin:這是指Kong“插件”，它是在代理生命周期中運行的業務邏輯。插件可以通過管理API配置——全局(所有傳入的流量)或特定的路由和服務。

概述

　　從高層次的角度來看，Kong在其配置的代理端口(默認情況下為8000和8443)上偵聽HTTP流量。Kong將根據您配置的路由評估任何傳入的HTTP請求，並嘗試找到匹配的路由。如果給定的請求符合特定路由的規則，Kong將處理代理請求。因為每個路由都鏈接到一個服務，所以Kong將運行您在路由及其相關服務上配置的插件，然后在上游代理請求。

您可以通過Kong的管理API管理路由。路由的主機、路徑和方法屬性定義匹配傳入HTTP請求的規則。

如果Kong收到一個無法與任何已配置路由匹配的請求(或未配置路由)，它將以以下方式響應:

HTTP/1.1 404 Not Found
Content-Type: application/json
Server: kong/<x.x.x>

{
    "message": "no route and no Service found with those values"
}

回憶下：如何向KONG添加一個Service

配置服務快速入門指南解釋了如何通過管理API配置Kong。

向Kong添加服務是通過向Admin API發送HTTP請求來完成的:

curl -i -X POST http://localhost:8001/services/ \
    -d 'name=foo-service' \
    -d 'url=http://foo-service.com'
HTTP/1.1 201 Created
...

{
    "connect_timeout": 60000,
    "created_at": 1515537771,
    "host": "foo-service.com",
    "id": "d54da06c-d69f-4910-8896-915c63c270cd",
    "name": "foo-service",
    "path": "/",
    "port": 80,
    "protocol": "http",
    "read_timeout": 60000,
    "retries": 5,
    "updated_at": 1515537771,
    "write_timeout": 60000
}

這個請求指示Kong注冊一個名為“foo-service”的服務，該服務指向http://foo-service.com(您的上游)。

注意:url參數。這里至少有一個protocol、host、port和path參數。

現在，為了通過Kong向該服務發送流量，我們需要指定一條路由，它作為到Kong的入口點:

curl -i -X POST http://localhost:8001/routes/ \
    -d 'hosts[]=example.com' \
    -d 'paths[]=/foo' \
    -d 'service.id=d54da06c-d69f-4910-8896-915c63c270cd'
HTTP/1.1 201 Created
...

{
    "created_at": 1515539858,
    "hosts": [
        "example.com"
    ],
    "id": "ee794195-6783-4056-a5cc-a7e0fde88c81",
    "methods": null,
    "paths": [
        "/foo"
    ],
    "preserve_host": false,
    "priority": 0,
    "protocols": [
        "http",
        "https"
    ],
    "service": {
        "id": "d54da06c-d69f-4910-8896-915c63c270cd"
    },
    "strip_path": true,
    "updated_at": 1515539858
}

我們現在已經配置了一條路由來匹配匹配給定主機和路徑的傳入請求，並將它們轉發到我們配置的fo-service，從而將此流量代理到http://fo-service.com。

Kong是一個透明的代理，默認情況下，它會將請求轉發到您的上游服務，不受影響，但HTTP規范所需的各種頭文件(如Connection, Date等)除外。

路由和匹配能力

現在讓我們討論Kong如何根據路由的配置host、path和method屬性(或字段)匹配請求。請注意，這三個字段都是可選的，但是必須指定其中至少一個字段。

對於匹配路由的請求:

• 請求必須包括所有配置的字段
• 請求中字段的值必須至少匹配一個配置值(雖然字段配置接受一個或多個值，但是一個請求只需要其中一個值被認為是匹配的)

讓我們來看幾個例子。考慮這樣配置的路由:

{
    "hosts": ["example.com", "foo-service.com"],
    "paths": ["/foo", "/bar"],
    "methods": ["GET"]
}

匹配此路由的一些可能的請求如下:

GET /foo HTTP/1.1
Host: example.com
GET /bar HTTP/1.1
Host: foo-service.com
GET /foo/hello/world HTTP/1.1
Host: example.com

這三個請求都滿足路由定義中設置的所有條件。

但是，以下請求與配置的條件不匹配:

GET / HTTP/1.1
Host: example.com

POST /foo HTTP/1.1
Host: example.com

GET /foo HTTP/1.1
Host: foo.com

所有這三個請求只滿足兩個配置條件。第一個請求的路徑與任何配置的路徑都不匹配，第二個請求的HTTP方法和第三個請求的主機標頭也是如此。

現在我們已經了解了host、path和method屬性是如何協同工作的，接下來讓我們分別研究每個屬性。

Request Host header

基於host header路由請求是通過Kong代理流量的最直接方法，特別是因為這是HTTP host header的預期用途。Kong使得通過Route實體的hosts字段很容易做到這一點。

host接受多個值，當通過管理API指定它們時，必須用逗號分隔:

host接受多個值，這在JSON有效負載中很容易表示:

curl -i -X POST http://localhost:8001/routes/ \
    -H 'Content-Type: application/json' \
    -d '{"hosts":["example.com", "foo-service.com"]}'
HTTP/1.1 201 Created
...

但是由於Admin API也支持表單- urlencoding內容類型，您可以通過[]符號指定一個數組:

curl -i -X POST http://localhost:8001/routes/ \
    -d 'hosts[]=example.com' \
    -d 'hosts[]=foo-service.com'
HTTP/1.1 201 Created
...

要滿足此路由的host條件，來自客戶機的任何傳入請求現在必須將其Host header集設置為:

Host: example.com
or:
Host: foo-service.com

使用通配符的主機名（Using wildcard hostnames）

為了提供靈活性，Kong允許您在hosts字段中使用通配符指定主機名。通配符主機名允許任何匹配的主機標頭滿足條件，從而匹配給定的路由。

通配符主機名只能在域的最左邊或最右邊的標簽上包含一個星號。例子:

• *.example.com將允許a.example.com和x.y.example.com等主機值匹配。
• example.*將允許example.com和example.org等主機值匹配。

一個完整的例子是這樣的:

{
    "hosts": ["*.example.com", "service.com"]
}

這將使下列要求符合如下路由:

GET / HTTP/1.1
Host: an.example.com

GET / HTTP/1.1
Host: service.com

preserve_host 屬性

When proxying, Kong’s default behavior is to set the upstream request’s Host header to the hostname specified in the Service’s host. The preserve_host field accepts a boolean flag instructing Kong not to do so.

For example, when the preserve_host property is not changed and a Route is configured like so:

在代理時，Kong的默認行為是將上游請求的Host header設置為Services中指定的host。preserve_host字段接受一個布爾值，指示Kong要不要這樣做。

例如，如果沒有更改preserve_host屬性，並且路由的配置如下:

{
    "hosts": ["service.com"],
    "service": {
        "id": "..."
    }
}

 

客戶可能會向kong提出以下要求:

GET / HTTP/1.1
Host: service.com

Kong將從Service的Host屬性中提取Host header值，並發送以下上游請求:

GET / HTTP/1.1
Host: <my-service-host.com>

然而，通過顯式配置帶有preserve_host=true的路由:

{
    "hosts": ["service.com"],
    "preserve_host": true,
    "service": {
        "id": "..."
    }
}

並假設來自客戶端的相同請求:

GET / HTTP/1.1
Host: service.com

Kong將保留客戶端請求上的主機，並發送以下上游請求:

GET / HTTP/1.1
Host: service.com

Request path

路由匹配的另一種方式是通過請求paths。要滿足此路由條件，客戶端請求的路徑必須以path屬性的一個值作為前綴。

例如，路由配置如下:

{ "paths": ["/service", "/hello/world"] }

The following requests would be matched:

GET /service HTTP/1.1 Host: example.com 

GET /service/resource?param=value HTTP/1.1 Host: example.com 

GET /hello/world/resource HTTP/1.1 Host: anything.com

對於每個請求，Kong都檢測到它們的URL path是不是和route path的前綴。默認情況下，Kong將在不更改URL path的情況下代理上游的請求。

When proxying with path prefixes, the longest paths get evaluated first. This allow you to define two Routes with two paths: /service and /service/resource, and ensure that the former does not “shadow” the latter.

當代理路徑前綴時，首先計算最長的路徑。這允許您使用兩條路徑定義兩條路由:/service和/service/resource，並確保前者不會“影響”后者。

Using regexes in paths

Kong通過PCRE (Perl兼容的正則表達式)支持route paths字段的正則表達式模式匹配。您可以同時使用前綴和正則表達式規則在paths參數上。

例如，如果我們考慮以下route:

{ "paths": ["/users/\d+/profile", "/following"] }

The following requests would be matched by this Route:

GET /following HTTP/1.1 Host: ... 

GET /users/123/profile HTTP/1.1 Host: ...

提供的正則表達式使用a PCRE標志(pcre_anchor)計算，這意味着它們將被約束在路徑中的第一個匹配點(根/字符)進行匹配。

Evaluation order（評估順序：數字越大優先級越高）

如前所述，Kong按長度計算前綴路徑:首先計算最長的前綴路徑。但是，Kong將基於從最高優先級到最低優先級路由的regex_priority屬性來計算regex路徑。這意味着考慮以下routes:

[ { "paths": ["/status/\d+"], "regex_priority": 0 }, { "paths": ["/version/\d+/status/\d+"], "regex_priority": 6 }, { "paths": ["/version"], }, { "paths": ["/version/any/"], } ]

In this scenario, Kong will evaluate incoming requests against the following defined URIs, in this order:

1. /version/any/
2. /version
3. /version/\d+/status/\d+
4. /status/\d+

前綴路徑總是在regex路徑之前計算。

通常，請求還必須匹配路由Route’s hosts and methods屬性，Kong將遍歷您的路由，直到找到與大多數規則匹配的一個(參見[路由優先級][proxy- Routing - priority])。

Capturing groups

還支持捕捉組，匹配的組將從路徑中提取出來，供插件使用。如果我們考慮以下正則表達式:

/version/(?<version>\d+)/users/(?<user>\S+)

And the following request path:

/version/1/users/john

Kong將把請求路徑視為匹配的，如果總體路由匹配(考慮host和method字段)，則提取的捕獲組將可從ngx中的插件中獲得。ctx變量:

local router_matches = ngx.ctx.router_matches -- router_matches.uri_captures is: -- { "1", "john", version = "1", user = "john" }

Escaping special characters（轉義特殊字符）

接下來，值得注意的是，根據RFC 3986，在正則表達式中發現的字符通常是保留字符，因此應該采用轉義。在通過管理API使用regex路徑配置路由時，如果需要，請確保URL對負載進行編碼。例如，使用curl並使用應用程序/x-www-form- urlencoding MIME類型:

curl -i -X POST http://localhost:8001/routes \ --data-urlencode 'uris[]=/status/\d+' HTTP/1.1 201 Created ...

請注意，curl不會自動對有效負載進行URL編碼，並注意——data-urlencode的使用，它阻止+字符被Kong的管理API解碼並解釋為空格' '。

The strip_path property

最好指定一個路徑前綴來匹配某個路由，但不要將其包含在上游請求中。為此，可以使用strip_path布爾屬性來配置這樣的路由:

{ "paths": ["/service"], "strip_path": true, "service": { "id": "..." } }

啟用此標志指示Kong在匹配此路由並繼續代理服務時，不應將URL路徑的匹配部分包含在上游請求的URL中。例如，以下客戶對上述路由的請求:

GET /service/path/to/resource HTTP/1.1 Host: ... 

Will cause Kong to send the following upstream request:

GET /path/to/resource HTTP/1.1 Host: ...

同樣，如果在啟用了strip_path的路由上定義了regex路徑，則將刪除請求URL匹配序列的全部內容。例子:

{ "paths": ["/version/\d+/service"], "strip_path": true, "service": { "id": "..." } }

The following HTTP request matching the provided regex path:

GET /version/1/service/path/to/resource HTTP/1.1 Host: ... 

Will be proxied upstream by Kong as:

GET /path/to/resource HTTP/1.1 Host: ...

Request HTTP method

methods字段允許根據HTTP方法匹配請求。它接受多個值。它的默認值是空的(HTTP方法不用於路由)。

The following Route allows routing via GET and HEAD:

{ "methods": ["GET", "HEAD"], "service": { "id": "..." } }

Such a Route would be matched with the following requests:

GET / HTTP/1.1 Host: ... 

HEAD /resource HTTP/1.1 Host: ... 

但它不匹配POST或DELETE請求。這允許在路由上配置插件時使用更細的粒度。例如，可以想象指向相同服務的兩條路由:一條是無限制的未經身份驗證的GET請求，另一條是只允許經過身份驗證和速率限制的POST請求(通過對此類請求應用身份驗證和速率限制插件)。

Matching priorities

路由可以基於其host、path和methods字段定義匹配規則。要使傳入請求與路由匹配，必須滿足所有現有字段。但是，Kong允許使用包含相同值的字段配置兩個或多個路由，從而提供了相當大的靈活性——當出現這種情況時，Kong應用優先級規則。

The rule is: when evaluating a request, Kong will first try to match the Routes with the most rules.

For example, if two Routes are configured like so:

{ "hosts": ["example.com"], "service": { "id": "..." } }, { "hosts": ["example.com"], "methods": ["POST"], "service": { "id": "..." } }

The second Route has a hosts field and a methods field, 因此第二條規則優先被Kong進行評估。通過這樣做，我們避免了第一個路由對第二個路由的“陰影”調用。

Thus, this request will match the first Route

GET / HTTP/1.1 Host: example.com 

And this request will match the second one:

POST / HTTP/1.1 Host: example.com

按照這種邏輯，如果要為第三條路由配置host字段、methods字段和uri字段，那么首先由Kong對其進行評估。

Proxying behavior

上面的代理規則詳細說明了Kong如何將傳入的請求轉發給上游服務。下面，我們將詳細說明從Kong匹配具有注冊路由的HTTP請求到實際轉發請求之間的內部過程。

1. Load balancing

Kong實現了負載平衡功能，可以跨上游服務的實例池分發代理請求。

You can find more information about configuring load balancing by consulting the Load Balancing Reference.

2. Plugins execution

Kong可以通過“插件”進行擴展，這些插件將自己掛接到代理請求的請求/響應生命周期中。插件可以在您的環境中對代理請求執行各種操作和/或轉換。

插件可以配置為全局運行(針對所有代理的流量)或在特定的路由和服務上運行。在這兩種情況下，您必須通過管理API創建plugin configuration。

一旦匹配了路由(及其關聯的服務實體)，Kong將運行與這兩個實體關聯的插件。在路由上配置的插件在服務上配置的插件之前運行，但是在其他情況下，應用插件關聯plugins association的通常規則。

這些配置好的插件將運行它們的訪問階段，您可以在插件開發指南Plugin development guide中找到更多關於這個階段的信息。

3. Proxying & upstream timeouts

一旦Kong執行了所有必要的邏輯(包括插件)，它就可以將請求轉發給上游服務了。這是通過Nginx的ngx_http_proxy_module完成的。您可以通過服務的以下屬性為Kong和給定上游之間的連接配置所需的超時:

upstream_connect_timeout:以毫秒為單位定義建立到上游服務的連接的超時。默認為60000。

upstream_send_timeout:以毫秒為單位定義用於將請求發送到上游服務的兩個連續寫操作之間的超時。默認為60000。

upstream_read_timeout:以毫秒為單位定義用於接收上游服務請求的兩個連續讀操作之間的超時。默認為60000。

Kong will send the request over HTTP/1.1, and set the following headers:

• Host: <your_upstream_host>, as previously described in this document.
• Connection: keep-alive, to allow for reusing the upstream connections.
• X-Real-IP: <remote_addr>, where $remote_addr is the variable bearing the same name provided by ngx_http_core_module. Please note that the $remote_addr is likely overridden by ngx_http_realip_module.
• X-Forwarded-For: <address>, where <address> is the content of $realip_remote_addr provided by ngx_http_realip_module appended to the request header with the same name.
• X-Forwarded-Proto: <protocol>, where <protocol> is the protocol used by the client. In the case where $realip_remote_addr is one of the trusted addresses, the request header with the same name gets forwarded if provided. Otherwise, the value of the $scheme variable provided by ngx_http_core_module will be used.
• X-Forwarded-Host: <host>, where <host> is the host name sent by the client. In the case where $realip_remote_addr is one of the trusted addresses, the request header with the same name gets forwarded if provided. Otherwise, the value of the $host variable provided by ngx_http_core_module will be used.
• X-Forwarded-Port: <port>, where <port> is the port of the server which accepted a request. In the case where $realip_remote_addr is one of the trusted addresses, the request header with the same name gets forwarded if provided. Otherwise, the value of the $server_port variable provided by ngx_http_core_module will be used.

All the other request headers are forwarded as-is by Kong.

One exception to this is made when using the WebSocket protocol. If so, Kong will set the following headers to allow for upgrading the protocol between the client and your upstream services:

• Connection: Upgrade
• Upgrade: websocket

More information on this topic is covered in the [Proxy WebSocket traffic][proxy-websocket] section.

4. Errors & retries

當代理過程中發生錯誤時，Kong將使用底層的Nginx重試機制將請求傳遞到下一個上游。

這里有兩個可配置的元素:

重試次數:可以使用重試屬性為每個服務配置重試次數。有關這方面的詳細信息，請參見管理API。

錯誤的確切構成:這里Kong使用Nginx默認值，這意味着在與服務器建立連接、向其傳遞請求或讀取響應頭時發生錯誤或超時。

第二個選項基於Nginx的[proxy_next_upstream][proxy_next_upstream]指令。此選項不能通過Kong直接配置，但可以使用自定義Nginx配置添加。 See the configuration reference for more details.

5. Response

Kong接收來自上游服務的響應，並以流方式將其發送回下游客戶端。此時，Kong將執行添加到路由和/或服務的后續插件，這些插件在header_filter階段實現一個鈎子。

所有已注冊插件的header_filter階段執行完成后，Kong將添加以下header，並將完整的header發送給客戶端:

• Via: kong/x.x.x, where x.x.x is the Kong version in use
• X-Kong-Proxy-Latency: <latency>, where latency is the time in milliseconds between Kong receiving the request from the client and sending the request to your upstream service.
• X-Kong-Upstream-Latency: <latency>, where latency is the time in milliseconds that Kong was waiting for the first byte of the upstream service response.

Once the headers are sent to the client, Kong will start executing registered plugins for the Route and/or Service that implement the body_filter hook. This hook may be called multiple times, due to the streaming nature of Nginx. Each chunk of the upstream response that is successfully processed by such body_filter hooks is sent back to the client. You can find more information about the body_filter hook in the Plugin development guide.

Configuring a fallback Route

用一個實際用例說明Kong在提供靈活的代理服務中提供“fallback Route”，所以為了避免Kong返回HTTP 404響應、“no route found”,我們能趕上這樣的請求和代理他們上游一個特殊的服務,或者應用插件(例如,這樣一個插件可以終止請求用不同的狀態代碼沒有代理請求或響應)。

Here is an example of such a fallback Route:

{ "paths": ["/"], "service": { "id": "..." } }

可以猜到，對Kong發出的任何HTTP請求實際上都與此路由匹配，因為所有uri都以根字符/作為前綴。正如我們在[請求路徑][proxy-request-path]一節中所知道的，最長的URL路徑首先由Kong計算，因此/ path最終將由Kong計算，並有效地提供了一個“fallback”路由，僅在最后才匹配。然后你可以發送流量到一個特殊的服務或應用任何插件，你希望在這條路線。

Configuring SSL for a Route

Kong提供了一種根據每個連接動態提供SSL證書的方法。SSL證書由核心直接處理，並通過管理API進行配置。連接到TLS上的Kong的客戶機必須支持 Server Name Indication擴展才能使用此功能。

SSL證書由Kong管理API中的兩個資源處理:

• /certificates, 它存儲您的密鑰和證書。
• /snis, 將注冊證書與服務器名稱指示關聯。

You can find the documentation for those two resources in the Admin API Reference.

Here is how to configure an SSL certificate on a given Route: first, upload your SSL certificate and key via the Admin API:

curl -i -X POST http://localhost:8001/certificates \ -F "cert=@/path/to/cert.pem" \ -F "key=@/path/to/cert.key" \ -F "snis=ssl-example.com,other-ssl-example.com" HTTP/1.1 201 Created ... 

snis表單參數是sugar參數，直接插入SNI並將上傳的證書關聯到它。

你現在必須在Kong注冊下列路線。為了方便，我們將僅使用host header將請求匹配到此路由: 

curl -i -X POST http://localhost:8001/routes \ -d 'hosts=ssl-example.com,other-ssl-example.com' \ -d 'service.id=d54da06c-d69f-4910-8896-915c63c270cd' HTTP/1.1 201 Created ... 

You can now expect the Route to be served over HTTPS by Kong:

curl -i https://localhost:8443/ \ -H "Host: ssl-example.com" HTTP/1.1 200 OK ...

在建立連接並協商SSL握手時，如果客戶端發送SSL -example.com作為SNI擴展的一部分，Kong將提供之前配置的cert.pem證書。

Restricting the client protocol (HTTP/HTTPS/TCP/TLS)

路由有一個protocols屬性來限制它們應該偵聽的客戶機協議。該屬性接受一組值， which can be "http", "https", "tcp" or "tls".

A Route with http and https will accept traffic in both protocols.

{ "hosts": ["..."], "paths": ["..."], "methods": ["..."], "protocols": ["http", "https"], "service": { "id": "..." } }

Not specifying any protocol has the same effect, since routes default to ["http", "https"].

然而，如果某個路由只配置了https那么就只接受https上的流量。如果SSL終止以前發生在受信任的IP上，它還將接受未加密的通信流。如果請求來自trusted_ips中配置的ip之一，並且設置了x -Forwarded-Proto: https header，則認為SSL終止有效:

{ "hosts": ["..."], "paths": ["..."], "methods": ["..."], "protocols": ["https"], "service": { "id": "..." } }

If a Route such as the above matches a request, but that request is in plain-text without valid prior SSL termination, Kong responds with:

HTTP/1.1 426 Upgrade Required Content-Type: application/json; charset=utf-8 Transfer-Encoding: chunked Connection: Upgrade Upgrade: TLS/1.2, HTTP/1.1 Server: kong/x.y.z {"message":"Please use HTTPS protocol"}

Since Kong 1.0 it’s possible to create routes for raw TCP (not necessarily HTTP) connections by using "tcp" in the protocols attribute:

{ "hosts": ["..."], "paths": ["..."], "methods": ["..."], "protocols": ["tcp"], "service": { "id": "..." } }

Similarly, we can create routes which accept raw TLS traffic (not necessarily HTTPS) with the "tls" value:

{ "hosts": ["..."], "paths": ["..."], "methods": ["..."], "protocols": ["tls"], "service": { "id": "..." } }

A Route with only TLS would only accept traffic over TLS.

It is also possible to accept both TCP and TLS simultaneously:

{ "hosts": ["..."], "paths": ["..."], "methods": ["..."], "protocols": ["tcp", "tls"], "service": { "id": "..." } }

Proxy WebSocket traffic

Kong supports WebSocket traffic thanks to the underlying Nginx implementation. When you wish to establish a WebSocket connection between a client and your upstream services through Kong, you must establish a WebSocket handshake. This is done via the HTTP Upgrade mechanism. This is what your client request made to Kong would look like:

GET / HTTP/1.1 Connection: Upgrade Host: my-websocket-api.com Upgrade: WebSocket 

This will make Kong forward the Connection and Upgrade headers to your upstream service, instead of dismissing them due to the hop-by-hop nature of a standard HTTP proxy.

WebSocket and TLS

Kong will accept ws and wss connections on its respective http and https ports. To enforce TLS connections from clients, set the protocols property of the Route to https only.

When setting up the Service to point to your upstream WebSocket service, you should carefully pick the protocol you want to use between Kong and the upstream. If you want to use TLS (wss), then the upstream WebSocket service must be defined using the https protocol in the Service protocol property, and the proper port (usually 443). To connect without TLS (ws), then the http protocol and port (usually 80) should be used in protocol instead.

If you want Kong to terminate SSL/TLS, you can accept wss only from the client, but proxy to the upstream service over plain text, or ws.

Back to TOC

Conclusion

Through this guide, we hope you gained knowledge of the underlying proxying mechanism of Kong, from how does a request match a Route to be routed to its associated Service, on to how to allow for using the WebSocket protocol or setup dynamic SSL certificates.

This website is Open-Source and can be found at github.com/Kong/docs.konghq.com. Feel free to provide feedback to this document there, or propose improvements!

If you haven’t already, we suggest that you also read the Load balancing Reference, as it closely relates to the topic we just covered.