# 494 Request header too large

**URL:** https://discuss.konghq.com/t/494-request-header-too-large/8010
**Category:** Questions
**Tags:** kubernetes
**Created:** [March 9, 2021, 2:18pm UTC](https://discuss.konghq.com/t/494-request-header-too-large/8010 "2021-03-09T14:18:15Z")
**Posts on this page:** 4
**Page:** 1

<div class="post-metadata">

### Author: ![merou](https://yyz2.discourse-cdn.com/flex036/user_avatar/discuss.konghq.com/merou/32/2620_2.png) [@merou](https://discuss.konghq.com/u/merou)
#### Post date: [March 9, 2021, 2:18pm UTC](https://discuss.konghq.com/t/494-request-header-too-large/8010/1 "2021-03-09T14:18:15Z")

</div>

Hello,

I installed kong in AKS private mode:  
Modified the service in all-in-one-dbless.yaml to match:  
[service.beta.kubernetes.io/azure-load-balancer-internal:](http://service.beta.kubernetes.io/azure-load-balancer-internal:) “true”  
and with loadBalancerIP:xxxx in the spec.

1/ `kubectl apply -f all-in-one-dbless.yaml`  
2/ Try to expose kong-proxy via SSL:

```yaml
apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
  annotations:
    cert-manager.io/cluster-issuer: letsencrypt-prod
    kubernetes.io/ingress.class: kong
  name: kong-ingress
  namespace: kong
spec:
  rules:
  - host: api.domain.com
    http:
      paths:
      - backend:
          serviceName: kong-proxy
          servicePort: 80
        path: /
  tls:
  - hosts:
    - api.domain.com
    secretName: kong-ingress-tls-secret

```

I am getting the following error in my browser:  
`Request header or cookie too large`

Locally it works as expected:  
`curl http://localhost:8000 {"message":"no Route matched with those values"}`

Thank you,  
merou

---

<div class="post-metadata">

### Author: ![merou](https://yyz2.discourse-cdn.com/flex036/user_avatar/discuss.konghq.com/merou/32/2620_2.png) [@merou](https://discuss.konghq.com/u/merou)
#### Post date: [March 9, 2021, 9:12pm UTC](https://discuss.konghq.com/t/494-request-header-too-large/8010/2 "2021-03-09T21:12:42Z")

</div>

I also tried all suggested recommendations but it did not work:  
e.g increase KONG\_NGINX\_HTTP\_CLIENT\_BODY\_BUFFER\_SIZE, change port…

The weird thing is that if I just use the self signed certificate from Kong it works (so basically i do not apply the ingress above).

So my question is how can i apply let’s encrypt certificate on `kong-proxy` service?

---

<div class="post-metadata">

### Author: ![traines](https://yyz2.discourse-cdn.com/flex036/user_avatar/discuss.konghq.com/traines/32/158_2.png) [@traines](https://discuss.konghq.com/u/traines)
#### Post date: [March 15, 2021, 10:39pm UTC](https://discuss.konghq.com/t/494-request-header-too-large/8010/3 "2021-03-15T22:39:48Z")

</div>

Your second message mentions the body size setting, not the header size setting. Header size is controlled by  
[client\_header\_buffer\_size](http://nginx.org/en/docs/http/ngx_http_core_module.html#client_header_buffer_size) and [large\_client\_header\_buffers](http://nginx.org/en/docs/http/ngx_http_core_module.html#large_client_header_buffers), which you’d set via the `KONG_NGINX_HTTP_CLIENT_HEADER_BUFFER_SIZE` and `KONG_NGINX_HTTP_LARGE_CLIENT_HEADER_BUFFERS` environment variables.

That example curl request isn’t passing any cookies (the most likely reason the headers are large), whereas your browser normally will send any cookies it has set, which is why you’re seeing different results there. The certificate configuration looks fine (you’d see a different error in your browser request otherwise).

---

<div class="post-metadata">

### Author: ![merou](https://yyz2.discourse-cdn.com/flex036/user_avatar/discuss.konghq.com/merou/32/2620_2.png) [@merou](https://discuss.konghq.com/u/merou)
#### Post date: [March 16, 2021, 10:00am UTC](https://discuss.konghq.com/t/494-request-header-too-large/8010/4 "2021-03-16T10:00:29Z")

</div>

Hello @traines thank you for your answer.

I ended up using the nginx ingress controller from Kubernetes and use Kong as an API gateway only.

For user adoption I think the Kong ingress controller should just work out the box, as it is the case for the nginx one.
