Introduction

curl: (7) Failed to connect ... Connection refused means the target IP was reachable, but nothing accepted the TCP connection on that port. With an address like 192.168.99.100, the issue often shows up in local VM or Kubernetes setups, where the service, NodePort, or port exposure no longer matches what the client expects.

What "Connection Refused" Actually Means

This error is different from a timeout. A timeout suggests packets disappeared or were filtered. A refusal means the host answered quickly and said, in effect, "no listener is accepting connections on that port."

That narrows the problem to a few likely causes:

• the process is not running
• the service is listening on a different port
• the application is bound only to loopback
• the container or Kubernetes service is not exposing the port correctly

Check The Listener First

If you can reach the host that owns the IP, verify whether anything is actually listening:

ss -lnt | grep 31591

If nothing is listening on 31591, curl is doing exactly what it should. Fix the service before doing deeper network debugging.

Also test locally on that host:

curl -v http://127.0.0.1:31591/
curl -v http://192.168.99.100:31591/

If loopback works but the host IP does not, the service may be bound only to 127.0.0.1 instead of 0.0.0.0.

If This Is Docker, Check Port Publishing

For containers, it is common to forget the host-to-container port mapping:

docker ps
docker inspect my-container --format '{{json .NetworkSettings.Ports}}'

If the application listens on port 3000 inside the container but Docker never published it to 31591 on the host, the host-side curl will fail.

A correct run command might look like:

docker run -p 31591:3000 my-image

Without that mapping, the container may be healthy while the host port stays closed.

If This Is Kubernetes, Check The Service And Endpoints

The address 192.168.99.100 is commonly associated with local cluster tools such as older Minikube VM setups. In that case, inspect the service:

kubectl get svc
kubectl describe svc my-service
kubectl get endpoints my-service

If the service has no endpoints, the selector probably does not match the pods. If the NodePort is not actually 31591, the client is hitting the wrong port.

It is also worth verifying the current cluster IP:

minikube ip

If the VM IP changed after a restart, a previously working hard-coded address can become stale.

Prefer Narrow, Repeatable Tests

Use several simple probes instead of guessing:

nc -vz 192.168.99.100 31591
kubectl port-forward svc/my-service 8080:80
curl -v http://127.0.0.1:8080/

If port-forward works but the NodePort does not, the application is probably fine and the issue is with cluster exposure, NodePort mapping, or local VM networking.

That comparison saves time because it separates application failure from routing and exposure failure.

Common Pitfalls

One common mistake is assuming "connection refused" means DNS trouble. DNS was already bypassed or succeeded by the time the refusal happened.

Another issue is debugging firewalls first even though the port is simply not listening anywhere.

A third problem is hard-coding a local cluster IP such as 192.168.99.100 and forgetting that the VM or cluster network can change after restarts.

Finally, in Kubernetes setups, developers often inspect pods but forget the service selector and endpoint objects, which are usually where NodePort exposure problems become obvious.

Summary

• 'curl error 7 with "connection refused" usually means the host is reachable but no process is accepting that port.'
• Verify the listener before investigating broader network causes.
• In Docker, confirm the host-to-container port publishing.
• In Kubernetes, check the service, NodePort, endpoints, and current cluster IP.
• Compare direct access with kubectl port-forward or local tests to isolate where the connection path breaks.