Your app is not reachable

Your pods are running and the hostname still does not give you your application. Work down this list; it is ordered so that each step rules out everything above it.

Is the route attached at all?

kubectl get httproute
kubectl describe httproute <name>

The Parents section at the end of describe is the answer. Accepted: True and ResolvedRefs: True mean the gateway took your route. Anything else names the problem.

Two failures show up here rather than at apply time:

• ResolvedRefs: False with a backend error means the Service in backendRefs does not exist, or its port does not match. The route is attached and answering, with nothing behind it.
• No matching listener means sectionName names a listener that was never created.

sectionName does not match the hostname

The single most common routing mistake. The listener name is the hostname with every dot replaced by a dash, prefixed with https-:

Hostname	sectionName
myapp.tenant-7.itsh.dev	https-myapp-tenant-7-itsh-dev
shop.example.com	https-shop-example-com

Get it wrong and the route attaches to the wrong listener or to none.

The site loads over plain HTTP

You left sectionName out. Without it the route also binds the port 80 listener, so your application is served unencrypted.

Set sectionName to the HTTPS listener. If you want plain HTTP to redirect rather than serve, add the separate redirect route from Gateway API.

The browser warns about the certificate

Certificates are issued automatically, but only if the HTTPRoute carries the issuer annotation:

metadata:
  annotations:
    cert-manager.io/cluster-issuer: "auto"

Only the presence of the annotation matters; the value does not select anything. Without it there is no HTTPS listener and no certificate.

Issuance is not instant. A new hostname takes a short while, and during that window the browser sees a name mismatch rather than your certificate. If it persists, the usual cause is DNS: the certificate cannot be issued until the hostname resolves to the gateway.

The hostname does not resolve

For a name under your namespace subdomain there is nothing to set up: it already points at the gateway. If one of those does not resolve, the problem is somewhere else on this page, not DNS.

For your own domain, point it at:

Type	Value
A	91.98.6.3
AAAA	2a01:4f8:1c1f:7bfa::1

Check what the world sees rather than what your machine has cached:

dig +short myapp.example.com

Remember the domain has to be verified in the portal before a route may use it, and the free tier cannot use custom domains at all.

Your application sees the wrong client IP

The gateway sets X-Forwarded-For and X-Real-IP. Your application should trust them only when the connection comes from the gateway, never from arbitrary senders. If it trusts them from anyone, any client can claim any address and defeat your logging, rate limiting and IP-based rules.

What's next

• Gateway API for the routing conventions in full
• The API said no if the route was refused on apply