Introduction

Kubernetes Ingress is primarily designed around HTTP host and path routing, so hostnames are the normal fit. If you want to access an ingress by raw IP instead of a DNS host, the usual solution is not to put the IP into the host field, but to omit the host and let the rule match requests regardless of hostname.

Understand what Ingress actually matches

An Ingress controller usually routes based on:

• the HTTP Host header
• the request path
• sometimes TLS settings

When a client accesses an ingress by IP, the Host header is often that IP address or may be absent depending on the client. That means a hostname-specific ingress rule may not match.

So the practical question is not "how do I make an IP host rule," but "how do I make the rule work when no stable DNS hostname is used."

Omit the host to match all hosts

The usual answer is to define the rule without a host field:

1apiVersion: networking.k8s.io/v1
2kind: Ingress
3metadata:
4  name: demo
5spec:
6  ingressClassName: nginx
7  rules:
8    - http:
9        paths:
10          - path: /
11            pathType: Prefix
12            backend:
13              service:
14                name: web
15                port:
16                  number: 80

With no host specified, the ingress controller can route based only on the path, which makes IP-based access possible.

Why putting the IP in host is usually not the best idea

Even if some controllers appear to tolerate an IP-looking host string, that is generally not the clean design target for Ingress. Ingress is meant for virtual-host style HTTP routing, where DNS names are the normal identifier.

If the only external address you have is an IP:

• omit host for broad matching
• or use a LoadBalancer or NodePort directly if host routing is unnecessary

If you later add DNS, you can tighten the ingress rule by adding a proper hostname.

TLS is where raw IP access gets awkward

Plain HTTP access by IP can work with a hostless ingress rule. TLS is harder, because certificates are usually issued for DNS names rather than bare IPs.

That means:

• HTTP by IP is often straightforward
• HTTPS by IP is often operationally awkward

If browser-trusted HTTPS matters, DNS is usually the better long-term solution.

Example test flow

After applying the ingress, find the external IP of the controller:

kubectl get ingress demo
kubectl get svc -n ingress-nginx

Then test it:

curl http://203.0.113.10/

If you still get the wrong response, check which controller owns the ingress and what its default routing behavior is.

When Ingress is not the right tool

If you do not need host-based routing at all, a plain LoadBalancer service is often simpler:

1apiVersion: v1
2kind: Service
3metadata:
4  name: web
5spec:
6  type: LoadBalancer
7  selector:
8    app: web
9  ports:
10    - port: 80
11      targetPort: 8080

Ingress adds value when multiple services share one entry point or when controller features such as rewrites, auth, or rate limiting matter. If all you want is "expose one service on one IP," a service may be the cleaner answer.

Common Pitfalls

The most common mistake is putting a DNS-oriented host rule in the ingress and then expecting a raw IP request to match it. Another is treating Ingress as the only way to expose HTTP traffic when a LoadBalancer service might be simpler. Teams also often forget that TLS by IP is a separate problem from plain ingress routing and then assume the ingress controller is broken when the certificate warning appears. Controller-specific defaults can also cause confusion if a hostless ingress falls through to a different backend than expected. Finally, testing only with a browser can hide details about the actual Host header being sent.

Summary

• Ingress is primarily designed for host and path routing, usually with DNS names.
• If you want IP-based access, the usual pattern is to omit the host field.
• Putting a literal IP into the host rule is generally not the preferred design.
• HTTPS on a raw IP is often awkward because certificate handling is DNS-oriented.
• If host routing is unnecessary, a LoadBalancer service may be simpler than Ingress.
• Test the actual external IP and controller behavior rather than assuming all ingress controllers behave identically.