# Kong 1.3 and kong-ingress-controller 0.6.0 keycloak issue **URL:** \ **Category:** Questions\ **Tags:** kubernetes\ **Created:** [October 16, 2019, 12:58pm UTC](https://discuss.konghq.com/t/kong-1-3-and-kong-ingress-controller-0-6-0-keycloak-issue/4672 "2019-10-16T12:58:41Z")\ **Posts on this page:** 7\ **Page:** 1
**Author:** ![Rahul\_Salunke](https://yyz2.discourse-cdn.com/flex036/user_avatar/discuss.konghq.com/rahul_salunke/32/1404_2.png) [@Rahul\_Salunke](https://discuss.konghq.com/u/Rahul_Salunke)\ **Post date:** [October 16, 2019, 12:58pm UTC](https://discuss.konghq.com/t/kong-1-3-and-kong-ingress-controller-0-6-0-keycloak-issue/4672/1 "2019-10-16T12:58:41Z")
Hello Guys, Recently we did upgrade our kong-version from version 1.1 to version 1.3 and kong-ingress-controller-version from 0.3.0 to 0.6.0. We are running keycloak behind the kong, so when we do hit to keycloak server, its getting below error: # Kong Error An invalid response was received from the upstream server. When we went through logs of kong pods, under kong pod, below log occured: kong-556cbdb888-khxvg kong-proxy] 2019/10/16 12:52:22 [error] 32#0: _4667106 upstream prematurely closed connection while reading response header from upstream, client: 10.0.5.53, server: kong, request: “GET / HTTP/1.1”, upstream: "http://_._._._:__ **/", host: "** _._ **.** _" [kong-556cbdb888-khxvg kong-proxy] 2019/10/16 12:52:22 [error] 32#0: _4667106 upstream prematurely closed connection while reading response header from upstream, client: 10.0.5.53, server: kong, request: “GET / HTTP/1.1”, upstream: "http://_._._._:__ **/", host: "** _._ **.** _" [kong-556cbdb888-khxvg kong-proxy] 2019/10/16 12:52:22 [error] 32#0: _4667106 upstream prematurely closed connection while reading response header from upstream, client: 10.0.5.53, server: kong, request: “GET / HTTP/1.1”, upstream: "http://_._._._:__ **/", host: "** _._ **.** _" Earlier with kong-1.1 and kong-ingress-controller-0.3.0 , keycloak was working as expected. after upgrading it, it stopped working. ---
**Author:** ![hbagdi](https://yyz2.discourse-cdn.com/flex036/user_avatar/discuss.konghq.com/hbagdi/32/562_2.png) [@hbagdi](https://discuss.konghq.com/u/hbagdi)\ **Post date:** [October 17, 2019, 8:31pm UTC](https://discuss.konghq.com/t/kong-1-3-and-kong-ingress-controller-0-6-0-keycloak-issue/4672/2 "2019-10-17T20:31:09Z")
Do you mind sharing the output of Kong routes, services and upstreams for Kong 1.1 and Kong 1.3? Is there any difference for the values that you see? ---
**Author:** ![Rahul\_Salunke](https://yyz2.discourse-cdn.com/flex036/user_avatar/discuss.konghq.com/rahul_salunke/32/1404_2.png) [@Rahul\_Salunke](https://discuss.konghq.com/u/Rahul_Salunke)\ **Post date:** [October 18, 2019, 11:58am UTC](https://discuss.konghq.com/t/kong-1-3-and-kong-ingress-controller-0-6-0-keycloak-issue/4672/3 "2019-10-18T11:58:16Z")
HI hbagdi, Thanks for replying on query. Actually we are using same route , services and upstream for both kong versions: apiVersion: extensions/v1beta1 kind: Ingress metadata: annotations: [ingress.kubernetes.io/force-ssl-redirect:](http://ingress.kubernetes.io/force-ssl-redirect:) “true” name: keycloak-ing namespace: breeze spec: rules: - host: [loginv1.test.com](http://loginv1.test.com) http: paths: - backend: serviceName: keycloak servicePort: 8443 path: /auth - backend: serviceName: keycloak servicePort: 8443 path: / * * * apiVersion: [configuration.konghq.com/v1](http://configuration.konghq.com/v1) kind: KongIngress metadata: name: keycloak-ing namespace: breeze proxy: protocol: https connect\_timeout: 10000 retries: 10 read\_timeout: 10000 write\_timeout: 10000 route: methods: - POST - GET - PUT - DELETE regex\_priority: 0 strip\_path: false preserve\_host: true protocols: - http - https with kong-1.1 its working but kong-1.3 giving error Thanks ---
**Author:** ![hbagdi](https://yyz2.discourse-cdn.com/flex036/user_avatar/discuss.konghq.com/hbagdi/32/562_2.png) [@hbagdi](https://discuss.konghq.com/u/hbagdi)\ **Post date:** [October 21, 2019, 3:48pm UTC](https://discuss.konghq.com/t/kong-1-3-and-kong-ingress-controller-0-6-0-keycloak-issue/4672/4 "2019-10-21T15:48:19Z")
> [@Rahul\_Salunke](#): > > [kong-556cbdb888-khxvg kong-proxy] 2019/10/16 12:52:22 [error] 32#0: _4667106 upstream prematurely closed connection while reading response header from upstream, client: 10.0.5.53, server: kong, request: “GET / HTTP/1.1”, upstream: "http://_ . _._ . _:_ _ **/", host: "** _ . _ **.** _ " This suggests that the upstream (Keycloak in your case) closed the connection while the response was being read from Kong. Do you seen any logs in Keycloak which suggest why it is abruptly closing the connections? ---
**Author:** ![Rahul\_Salunke](https://yyz2.discourse-cdn.com/flex036/user_avatar/discuss.konghq.com/rahul_salunke/32/1404_2.png) [@Rahul\_Salunke](https://discuss.konghq.com/u/Rahul_Salunke)\ **Post date:** [October 22, 2019, 6:33am UTC](https://discuss.konghq.com/t/kong-1-3-and-kong-ingress-controller-0-6-0-keycloak-issue/4672/5 "2019-10-22T06:33:33Z")
HI Harry, In keycloak logs, there is no incoming request is coming. like kong is not able to access keycloak-ingress. Thanks, ---
**Author:** ![HugoSart](https://yyz2.discourse-cdn.com/flex036/user_avatar/discuss.konghq.com/hugosart/32/2866_2.png) [@HugoSart](https://discuss.konghq.com/u/HugoSart)\ **Post date:** [April 23, 2020, 1:18am UTC](https://discuss.konghq.com/t/kong-1-3-and-kong-ingress-controller-0-6-0-keycloak-issue/4672/6 "2020-04-23T01:18:51Z")
I’m having this exact error. Any updates on this? ---
**Author:** ![elmar](https://yyz2.discourse-cdn.com/flex036/user_avatar/discuss.konghq.com/elmar/32/2509_2.png) [@elmar](https://discuss.konghq.com/u/elmar)\ **Post date:** [January 22, 2021, 3:22pm UTC](https://discuss.konghq.com/t/kong-1-3-and-kong-ingress-controller-0-6-0-keycloak-issue/4672/7 "2021-01-22T15:22:35Z")
FYI I have this error with nginx + keycloak 11, so it’s not a kong issue (I just stumbled accross this thread). I’m pretty sure it’s Keycloak/Undertows/Wildflys doing something wrong here. Just wanted to throw in my two cents. I’m still trying to investigate this issue further. Has anybody been able to get any further solving this issue?