{"message":"no Route matched with those values"}

I have an issues where I deployed kong ingress controller and kong ingress resource in kubernetes and certificates using cert manager but why website fails to load and shows no routes matches though the ingress shows all routes.

kubectl get ingress -n staging
Warning: extensions/v1beta1 Ingress is deprecated in v1.14+, unavailable in v1.22+; use networking.k8s.io/v1 Ingress
https-webapp stg .us-east-1.elb.amazonaws.com 80, 443 22h

Shows up rules too. Please assist

Could you provide the complete Ingress YAML and an example request?

Do your ingress controller logs indicate that it encountered any errors pushing configuration?

If you send a GET /routes request to the admin API (you’ll probably need to use kubectl port-forward to reach it), do you see your routes configured as expected?

kubectl describe ingress https-webapp

                      /                                                        webapp:80 (
                      /api/echo/?(.*)                                          echo-service:8080 (
                      /(account|accounts|register-pilot|role|roles|pilots).*   accounts:10001 (
                      /(mission|missions).*                                    operations:10002 (
                      /(drones|drone-models|device-certificate).*              devices:10003 (
                      /path                                                    pathfinder:10007 (
                      /(network|networks).*                                    networks:10008 (
                      /laanc/approvals                                         laanc-approvals:5000 (
                      /laanc/faa/                                              laanc-faa:5000 (

Get request is
curl https://networks?lang=en

I see the routes and services running but I see blank page on the browser and many of these routes doesn’t work except echo test and laanch-approvals

Let me know if you need more info


The complete Ingress YAML manifest is what we’re looking for–that’s what we’d need to actually replicate the same configuration locally.

Is your request indeed curl https://networks?lang=en? If so, networks is a hostname, not a path, so it won’t match. You’d need to send a request for something like https://example.com/networks to match that Ingress.

That said, a blank page probably indicates that the service isn’t returning visible content in its response. If actually you’re failing to match a route, you’ll see the browser render the {“message”:”no Route matched with those values”} JSON string you originally mentioned.

YAML file as below . Please do not the our application uses auth0 for authentication services. Request will be as below

curl https://stg.intra.com/networks?lang=en

Where hostname is actual route53 url pointing to ELB of ingress controller hostname. It shows 404 page not found or no routes matched with those values even after providing below ingress resource.
so far only laanc-approvals and echo-service ( added for testing) has worked

apiVersion: networking.k8s.io/v1beta1
kind: Ingress
name: https-webapp
namespace: staging
konghq.com/strip-path: “true”
kubernetes.io/ingress.class: kong
konghq.com/plugins: cors-plugin,jwt-plugin
certmanager.k8s.io/cluster-issuer: letsencrypt-prod
ingressClassName: “kong”

  • host: stg.intra.com
    • path: /
      pathType: Prefix
      serviceName: webapp
      servicePort: 80
    • path: /api/echo/?(.*)
      serviceName: echo-service
      servicePort: 8080
    • path: /(account|accounts|register-pilot|role|roles|pilots).*
      pathType: Prefix
      serviceName: accounts
      servicePort: 10001
    • path: /(mission|missions).*
      pathType: Prefix
      serviceName: operations
      servicePort: 10002
    • path: /(drones|drone-models|device-certificate).*
      pathType: Prefix
      serviceName: devices
      servicePort: 10003
    • path: /path
      pathType: Prefix
      serviceName: pathfinder
      servicePort: 10007
    • path: /(network|networks).*
      pathType: Prefix
      serviceName: networks
      servicePort: 10008
    • path: /laanc/approvals
      pathType: Prefix
      serviceName: laanc-approvals
      servicePort: 5000
    • path: /laanc/faa/
      pathType: Prefix
      serviceName: laanc-faa
      servicePort: 443


  • hosts:
    • stg.intra-.com
      secretName: stg.intra.com-tls

That appears to work fine. Using a simplified version (I also had to convert to v1 since I don’t have easy access to test clusters that still use v1beta1) I did get a request from a test upstream httpbin service:

$ curl -sv http://stg.intra.com/networks?lang=en --resolve stg.intra.com:80:
* Added stg.intra.com:80: to DNS cache
* Hostname stg.intra.com was found in DNS cache
*   Trying
* Connected to stg.intra.com ( port 80 (#0)
> GET /networks?lang=en HTTP/1.1
> Host: stg.intra.com
> User-Agent: curl/7.84.0
> Accept: */*
* Mark bundle as not supporting multiuse
< HTTP/1.1 404 NOT FOUND
< Content-Type: text/html; charset=UTF-8
< Content-Length: 233
< Connection: keep-alive
< Server: gunicorn/19.9.0
< Date: Tue, 23 Aug 2022 21:46:12 GMT
< Access-Control-Allow-Origin: *
< Access-Control-Allow-Credentials: true
< X-Kong-Upstream-Latency: 10
< X-Kong-Proxy-Latency: 1
< Via: kong/2.8.1
<title>404 Not Found</title>
<h1>Not Found</h1>

Although that’s a 404, it’s from httpbin, which doesn’t recognize the /networks path, so Kong did successfully route the request. Again, you probably want to review what your service is actually returning and/or check if you’re seeing an X-Kong-Upstream-Latency response header–if you are, the request matched a route and was proxied upstream.

You probably do want to use ImplementationSpecific for any regex paths. We handle Prefix by wrapping provided paths in another regex, to account for slight differences between Kong’s native behavior and what the Ingress spec says. We do use prefix matching normally (including in ImplementationSpecific, unless you provide a $-terminated regex). That additional regex doesn’t appear to cause issues here, but can result in unexpected behavior.

I see this for my upstream

  • Mark bundle as not supporting multiuse
    < HTTP/1.1 404 Not Found
    < Content-Type: text/plain; charset=utf-8
    < Content-Length: 19
    < Connection: keep-alive
    < X-Content-Type-Options: nosniff
    < Date: Tue, 23 Aug 2022 22:40:10 GMT
    < X-Kong-Upstream-Latency: 0
    < X-Kong-Proxy-Latency: 1
    < Via: kong/2.8.1
    404 page not found

Also why would the webpage come up blank. with docker-compose it works just fine on kubernetes it throws blank page.

It could be any number of reasons. Only the application actually generating the response can say for sure why it’s generating something different depending on the environment, so you’d want to review its logs for discrepancies. Common examples could be that your proxy configuration sends a different hostname than what you’re sending in the compose environment, or that it’s sending a different path because your strip_path and/or service path isn’t what you need, but ultimately you need to determine why the application is behaving differently so you know what needs to change in that configuration.

What does this means . Is Kong redirecting to backend?

< X-Kong-Upstream-Latency: 0
< X-Kong-Proxy-Latency: 1

curl -v https://stg.com/

  • Trying…
  • Connected to stg.com (x.x.x.x) port 443 (#0)
  • ALPN, offering h2
  • ALPN, offering http/1.1
  • successfully set certificate verify locations:
  • CAfile: /etc/ssl/certs/ca-certificates.crt
    CApath: /etc/ssl/certs
  • TLSv1.3 (OUT), TLS handshake, Client hello (1):
  • TLSv1.3 (IN), TLS handshake, Server hello (2):
  • TLSv1.3 (IN), TLS handshake, Encrypted Extensions (8):
  • TLSv1.3 (IN), TLS handshake, Certificate (11):
  • TLSv1.3 (IN), TLS handshake, CERT verify (15):
  • TLSv1.3 (IN), TLS handshake, Finished (20):
  • TLSv1.3 (OUT), TLS change cipher, Change cipher spec (1):
  • TLSv1.3 (OUT), TLS handshake, Finished (20):
  • SSL connection using TLSv1.3 / TLS_AES_256_GCM_SHA384
  • ALPN, server accepted to use http/1.1
  • Server certificate:
  • subject: CN=stg.com
  • start date: Aug 22 19:27:23 2022 GMT
  • expire date: Nov 20 19:27:22 2022 GMT
  • subjectAltName: host “stg.com” matched cert’s “stg.com
  • issuer: C=US; O=Let’s Encrypt; CN=R3
  • SSL certificate verify ok.

GET / HTTP/1.1
Host: stg.com
User-Agent: curl/7.68.0
Accept: /

  • TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
  • TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
  • old SSL session ID is stale, removing
  • Mark bundle as not supporting multiuse
    < HTTP/1.1 200 OK
    < Content-Type: text/html; charset=UTF-8
    < Content-Length: 2022
    < Connection: keep-alive
    < Server: nginx/1.19.2
    < Date: Wed, 31 Aug 2022 18:52:51 GMT
    < Last-Modified: Thu, 18 Aug 2022 14:29:34 GMT
    < ETag: “62fe4cce-7e6”
    < Content-Security-Policy: upgrade-insecure-requests
    < Accept-Ranges: bytes
    < X-Kong-Upstream-Latency: 0
    < X-Kong-Proxy-Latency: 1
    < Via: kong/2.8.1

Yes, if you’re seeing an X-Kong-Upstream-Latency header, it’s a response that Kong proxied from upstream.