> ## Documentation Index
> Fetch the complete documentation index at: https://docs.akua.dev/llms.txt
> Use this file to discover all available pages before exploring further.
# Direct IP
> Route traffic directly to your worker nodes using Gateway API and DNS
With direct IP routing, traffic reaches your applications through your worker nodes' public IP addresses. You point your domains at your workers via DNS, and a Gateway API controller on the cluster routes requests to the correct application based on the hostname.
This approach is ideal for **self-hosted clusters** where you manage the nodes and have direct access to their public IPs.
## How it works with Akua-managed clusters
Clusters created through Akua use Cilium as the CNI, which includes a built-in Gateway API controller. Cilium's envoy proxy runs on every worker via host network mode, listening on ports 80 and 443:
```
Client → worker-node-ip:80 → Cilium envoy (host network) → Route match → Service → Pod
```
The envoy proxy checks the `Host` header against all configured routes and forwards matching traffic to the correct application, regardless of which node the app's pod runs on.
## Imported and cloud-hosted clusters
If you import an existing cluster into Akua, the Gateway API controller depends on your Kubernetes setup:
* **Cloud providers** (GKE, EKS, AKS): these typically include their own Gateway API controller backed by cloud load balancers. Traffic goes through the cloud's load balancer rather than directly to worker node IPs, so you don't need to manage A records yourself.
* **Self-hosted with Cilium**: works the same as Akua-managed clusters. Deploy a Cilium Gateway from your cluster's detail page.
* **Other CNIs**: consult the documentation for your CNI or Kubernetes distribution to set up a Gateway API controller. The route configuration workflow stays the same; only the underlying controller and how traffic enters the cluster differs.
## Prerequisites
* A cluster with a Gateway API controller (Cilium Gateway for Akua-managed and self-hosted clusters, or a cloud-provided controller)
* One or more worker nodes with public IP addresses (for direct IP setups)
* A domain you control with access to its DNS settings
## Set up a custom domain
For Packages that expose web ports through Akua's generated install flow, go to the installation's **Settings > Ports** and toggle **Expose externally** on the port you want to make public. Enter your domain (for example, `app.yourdomain.com`) as the hostname.
For chart sources, configure the route hostname through the Package inputs when the Package exposes those values.
The gateway runs on every worker node, so any worker with a public IP can receive traffic. Choose a DNS strategy based on your setup:
Create one A record pointing your domain at the worker's public IP:
| Record type | Name | Value |
| ----------- | -------------------- | ------------------ |
| A | `app.yourdomain.com` | Worker's public IP |
Add an A record for each worker. DNS automatically distributes requests across them:
| Record type | Name | Value |
| ----------- | -------------------- | ------------------ |
| A | `app.yourdomain.com` | Worker 1 public IP |
| A | `app.yourdomain.com` | Worker 2 public IP |
| A | `app.yourdomain.com` | Worker 3 public IP |
Create A records for a base hostname (for example, `workers.eu.yourdomain.com`) pointing to all workers in a region, then CNAME your app domains to it. When you add or remove workers, you only update the base record:
| Record type | Name | Value |
| ----------- | --------------------------- | --------------------------- |
| A | `workers.eu.yourdomain.com` | Worker 1 public IP |
| A | `workers.eu.yourdomain.com` | Worker 2 public IP |
| CNAME | `app.yourdomain.com` | `workers.eu.yourdomain.com` |
DNS propagation can take a few minutes to a few hours depending on your provider and TTL settings.
Once DNS has propagated, open `http://app.yourdomain.com` in your browser. The gateway routes the request to your application based on the hostname.
## Test before DNS propagation
You can verify that gateway routing works correctly before creating DNS records. Use `curl` with an explicit `Host` header to simulate what a browser does after DNS resolves:
```bash theme={null}
curl -H 'Host: app.yourdomain.com' http:///
```
Replace `` with your worker node's public IP and `app.yourdomain.com` with the hostname you configured.
* **If you see your app's response**: the routing is correct. Create the DNS record and you're done.
* **If you get a 404 from envoy**: the hostname doesn't match any route. Double-check that the hostname in your app's port configuration matches exactly what you're passing in the `Host` header.
This works because HTTP routing is based entirely on the `Host` header. The `curl` command sends the same header a browser would send after resolving your domain through DNS. The only difference is you're connecting directly to the server IP instead of going through DNS.
## Troubleshooting
The gateway is running but no route matches the request's `Host` header. Check that:
* The hostname in your app's port configuration matches your domain exactly.
* The port has **Expose externally** toggled on.
* The route was created (check the app's status).
The gateway's envoy proxy isn't running on the worker node. Verify that:
* A Cilium Gateway is deployed to the cluster.
* The gateway pod is running and healthy.
* Host network mode is enabled in the Cilium configuration.
This is normal with Cilium's host network mode. The gateway creates a ClusterIP service (not a LoadBalancer), so the status never reports an external IP. Traffic still flows correctly through the host network envoy proxy.
DNS propagation can take time. While waiting, use the `curl` test above to confirm routing works. If `curl` returns your app, the issue is DNS propagation, not routing.
## Related topics
Compare all options for exposing applications.
Route custom domains without public IPs.
Instant URLs managed by Akua.
Connect compute with public IPs to your cluster.