The fastest way to get the Minikube IP address is to run minikube ip, which prints the address of the primary control plane node and nothing else. That single value is what you combine with a NodePort to reach a service from your workstation. On some setups, though, the address it prints is real but unreachable, and that is where most of the confusion around this command comes from.
minikube ip to print the cluster IP. Add -p <profile> for a named cluster and -n <node> for a specific node in a multi node cluster. If you are on macOS or Windows with the Docker driver, that IP is not routable from your host, so use minikube service <name> --url or kubectl port-forward instead.This guide covers every way to retrieve the address, how the answer changes per profile and per node, why the Docker driver behaves differently on macOS and Windows than it does on Linux, and how to actually reach a NodePort service once you have the value. Everything below was checked against minikube 1.38.1, which ships Kubernetes v1.35.1 by default.
The direct method: minikube ip
The command exists for exactly this purpose and writes a bare address to standard output, which makes it easy to capture in a shell variable.
minikube ip
# 192.168.49.2
IP=$(minikube ip)
curl "http://$IP:30080"The address you see depends entirely on the driver. The Docker driver puts the cluster on a bridge network and typically hands out something in the 192.168.49.0/24 range. The KVM2 and VirtualBox drivers create their own host only networks and usually land in 192.168.39.0/24 or 192.168.59.0/24. The none driver runs Kubernetes directly on the host, so the value it reports is the host’s own address. Do not hard code any of these into a script. Always read the value back from the command.
Getting the IP with kubectl instead
If you would rather not depend on the minikube binary, kubectl can tell you the same thing from the cluster itself. This is the approach to use inside CI, where the cluster may have been created by something other than minikube.
# The API server endpoint, which includes the IP and the port
kubectl cluster-info
# Just the internal address of every node
kubectl get nodes -o wide
# Machine readable, one address per line
kubectl get nodes -o jsonpath='{.items[*].status.addresses[?(@.type=="InternalIP")].address}'
# The API server URL straight out of the active kubeconfig context
kubectl config view --minify -o jsonpath='{.clusters[0].cluster.server}'The InternalIP that kubectl reports matches what minikube ip prints for a single node cluster. The value in your kubeconfig is the same address with the API server port appended, normally 8443.
Profiles: more than one cluster on one machine
Minikube supports multiple independent clusters through profiles, and each one gets its own address. If you have a staging cluster and a scratch cluster running side by side, a bare minikube ip only answers for whichever profile is active.
# List every profile, its driver, status and IP in one table
minikube profile list
# Ask a specific profile
minikube ip -p staging
# Change which profile is the default for later commands
minikube profile stagingminikube profile list is the single most useful command here because it shows the driver, the Kubernetes version and the IP for every cluster at once. Reach for it before you start debugging a connection you think should work.Multi node clusters and the node flag
Once you start a cluster with minikube start --nodes 3, there are three addresses, not one. A bare minikube ip returns only the control plane. Use the node flag to ask about a worker.
minikube start --nodes 3 -p multi
minikube node list -p multi
minikube ip -n multi-m02 -p multiWorker nodes follow the naming pattern <profile>-m02, <profile>-m03 and so on. A NodePort is opened on every node, so any of these addresses will serve the request as long as the network between your host and that node is open.
How the driver changes the answer
This is the part that trips people up. The address printed by minikube ip is always correct from inside the cluster, but whether your host can route to it depends on the driver and the operating system.
| Driver and OS | Typical range | Reachable from host? | How to reach a NodePort |
|---|---|---|---|
| Docker on Linux | 192.168.49.0/24 | Yes | curl the IP and node port directly |
| Docker on macOS | 192.168.49.0/24 | No | minikube service --url or port forward |
| Docker on Windows or WSL | 192.168.49.0/24 | No | minikube service --url or port forward |
| KVM2 on Linux | 192.168.39.0/24 | Yes | curl the IP and node port directly |
| VirtualBox | 192.168.59.0/24 | Yes | curl the IP and node port directly |
| none (bare metal) | Host address | Yes | localhost and the node port |
The official minikube accessing apps handbook states the constraint plainly: the network is limited when using the Docker driver on Darwin, Windows or WSL, and the node IP is not reachable directly. That is not a bug in your setup. It is how Docker Desktop’s virtual machine boundary works.
Reaching a NodePort service once you have the IP
Assume you have a deployment exposed on a NodePort. Here is the full sequence, and the two fallbacks for when the raw IP will not work.
kubectl create deployment web --image=nginx
kubectl expose deployment web --type=NodePort --port=80
# Find the assigned node port (the 3xxxx number)
kubectl get svc web -o jsonpath='{.spec.ports[0].nodePort}'
# Option 1: raw IP, works on Linux and on VM drivers everywhere
curl "http://$(minikube ip):$(kubectl get svc web -o jsonpath='{.spec.ports[0].nodePort}')"
# Option 2: let minikube build the URL and open a tunnel if it needs one
minikube service web --url
# Option 3: skip node ports entirely
kubectl port-forward svc/web 8080:80minikube service --url prints a 127.0.0.1 address on a random high port and holds the tunnel open. Close that terminal and the URL stops working. Run it in a window you can leave open, or use kubectl port-forward, which behaves the same way but is not minikube specific.Scripting the value safely
If you are wiring the address into a test harness, guard against the cluster being stopped. A stopped cluster makes minikube ip exit non zero with an error on standard error, which is easy to miss if you capture only standard output.
#!/usr/bin/env bash
set -euo pipefail
if ! minikube status -p dev >/dev/null 2>&1; then
echo "cluster dev is not running" >&2
exit 1
fi
IP=$(minikube ip -p dev)
PORT=$(kubectl get svc web -n default -o jsonpath='{.spec.ports[0].nodePort}')
echo "service at http://${IP}:${PORT}"The same discipline applies when you are provisioning tooling on top of the cluster. If you are adding charts, our walkthrough on how to install Helm in Minikube pairs well with this, because most chart values files want a reachable host name and this is where you get it.
Troubleshooting
minikube ip says the profile does not exist. You are asking for a profile that was never created or has been deleted. Run minikube profile list to see the real names. Profile names are case sensitive and a typo produces exactly this error.
The IP prints fine but curl times out. First confirm the driver. Run minikube profile list and look at the driver column. If it says docker and you are on macOS or Windows, the timeout is expected and you need the tunnel. If you are on Linux, check that the service really has an endpoint with kubectl get endpoints web. An empty endpoint list means the service selector does not match any running pod.
The IP changed after a restart. This is normal with the Docker driver when other containers claim the bridge subnet first. Read the value fresh on every run rather than caching it. If you need stability, create the cluster with minikube start --static-ip 192.168.200.200, which pins the address for Docker driver clusters.
Connection refused rather than a timeout. Refused means something answered. Usually the node port number is wrong. Confirm it with kubectl get svc -o wide and remember that a ClusterIP service has no node port at all, so there is nothing on the node to connect to. Change the service type to NodePort or use a port forward.
Two clusters, wrong answers. The kubectl context and the minikube profile are separate settings and they can drift apart. Check both with kubectl config current-context and minikube profile list, then align them using kubectl config use-context <name>. If you set up your cluster following our guide to installing Minikube on Ubuntu, the default profile is simply called minikube.
Frequently asked questions
Why does minikube ip return 192.168.49.2 so often?
That address is the first usable host on the default Docker bridge network minikube creates for its clusters. The control plane container is the first thing attached to that network, so it receives the second address in the range. A second profile will typically land on a neighboring subnet instead.
Can I set a fixed Minikube IP address?
Yes, on the Docker driver. Pass --static-ip when you create the cluster, for example minikube start --static-ip 192.168.200.200. The address must be inside a private range and must not collide with a network Docker already uses. Existing clusters cannot be changed in place, so you have to delete and recreate.
What is the difference between minikube ip and kubectl cluster-info?
The minikube command prints a bare address suitable for scripting. The kubectl command prints a human readable summary that includes the full API server URL with its port, plus the CoreDNS endpoint. Both read the same underlying value, so they will never disagree about a healthy cluster.
How do I get the IP of a worker node?
Use the node flag: minikube ip -n minikube-m02. List the available node names first with minikube node list. Alternatively, ask Kubernetes directly using kubectl get nodes -o wide, which prints the internal address for every node in one table.
Does the IP survive a minikube stop and start?
Usually yes, because the container and its network are preserved rather than recreated. It can change if Docker reassigns the subnet after a daemon restart or if another project claims the range first. Treat the value as something you read at run time, never as a constant.
The bottom line
For a single node cluster on Linux, minikube ip is the whole answer and you can go straight to curling a NodePort. Add -p when you juggle profiles and -n when you run multiple nodes, and confirm both with minikube profile list before you start guessing.
On macOS and Windows with the Docker driver, stop expecting the printed address to be routable. Reach for minikube service --url or kubectl port-forward and keep that terminal open. Once you internalize that split, the command stops feeling unpredictable. If you are still setting up, our guide to installing Minikube on Windows covers the driver choice that determines all of this, and once the cluster is running you will want to know how to create a namespace in Minikube to keep your workloads separated.
