How to fix No route to host: connection refused to load balancer in Kubernetes

KubernetesINTERMEDIATEHIGHUpdated Dec 6, 2025· 138 views

GCP load balancer health checks fail when there is no network route between load balancer and backend services. Pods become unreachable due to firewall rules, misconfigured routes, or Service endpoint configuration issues.

Quick fix

Fixes No route to host: connection refused to load balancer

gcloud compute firewall-rules create allow-gcp-health-checks \
  --allow tcp,udp \
  --source-ranges 35.191.0.0/16,130.211.0.0/22
  1. Verify firewall rules allow health checks
  2. Verify Service port configuration
  3. Check health check configuration
  4. Test pod connectivity
kubernetes — error
gcloud compute firewall-rules create allow-gcp-health-checks \
  --allow tcp,udp \
  --source-ranges 35.191.0.0/16,130.211.0.0/22
No route to host: connection refused to load balancer

What this error means

This error occurs when GCP's health check probes cannot reach your Kubernetes Service endpoints. The load balancer is unable to establish a network path to the backend pods, typically due to Google Cloud firewall rules, route table misconfigurations, or incorrect Service endpoint exposure. Without valid routes, health checks fail and the load balancer removes all backends, causing complete service unavailability.

Typical symptoms

  • Load balancer shows all backends as unhealthy (0% healthy)
  • Traffic to LoadBalancer IP times out or is refused
  • Health check logs show "connection refused" or "network unreachable"
  • Service works with ClusterIP but fails with LoadBalancer type
  • GCP health check probe IPs (35.191.0.0/16, 130.211.0.0/22) blocked
  • Intermittent health check failures depending on node
  • Pods are running but cannot be reached through load balancer

Common causes

  1. GCP firewall rule blocking health check probes (35.191.0.0/16, 130.211.0.0/22)
  2. Service target ports do not match container listening ports
  3. Health check path/port misconfigured in Service annotations
  4. Node firewall (iptables/nftables) blocking load balancer traffic
  5. Network policy denying ingress from GCP load balancer
  6. Service selector not matching any pods
  7. Load balancer backend group not properly synced with Service

How to fix "No route to host: connection refused to load balancer"

1Verify firewall rules allow health checks

GCP load balancers use specific IP ranges for health probes. Create a firewall rule allowing these:

bash
gcloud compute firewall-rules create allow-gcp-health-checks \
  --allow tcp,udp \
  --source-ranges 35.191.0.0/16,130.211.0.0/22

Check existing rules:

bash
gcloud compute firewall-rules list --filter="name~'gcp-health' OR name~'load-balancer'"
2Verify Service port configuration

Check if the Service port matches pod container ports:

bash
kubectl get svc <service-name> -o yaml | grep -A5 ports:
kubectl get pods -o wide
kubectl logs <pod-name> | grep -i "listening on port"

If ports don't match, update the Service:

yaml
spec:
  ports:
  - port: 80           # external port
    targetPort: 8080   # container port
    protocol: TCP
3Check health check configuration

Configure proper health check probes in the Service:

yaml
apiVersion: v1
kind: Service
metadata:
  name: my-service
spec:
  type: LoadBalancer
  selector:
    app: my-app
  ports:
  - port: 80
    targetPort: 8080
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-app
spec:
  template:
    spec:
      containers:
      - name: app
        readinessProbe:
          httpGet:
            path: /health
            port: 8080
          initialDelaySeconds: 10
          periodSeconds: 10
4Test pod connectivity

Create a test pod to verify networking:

bash
kubectl run -it --rm debug --image=gcr.io/cloud-builders/kubectl --restart=Never -- bash

# Inside the pod:
curl -v http://<service-cluster-ip>:<port>/health
nc -zv <pod-ip> <port>

If these succeed, load balancer configuration is the issue.

5Check GCP Backend Service health

Verify GCP backend service configuration:

bash
gcloud compute backend-services list
gcloud compute backend-services get-health <backend-service-name> --global

# Check instance groups:
gcloud compute instance-groups list
gcloud compute instance-groups get-named-ports <ig-name> --zone=<zone>

Ensure instance groups match your nodes.

6Review node network policies

Check if Kubernetes Network Policies are blocking traffic:

bash
kubectl get networkpolicies -A
kubectl describe networkpolicy <policy-name>

If blocking ingress, modify to allow load balancer traffic:

yaml
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-lb
spec:
  podSelector:
    matchLabels:
      app: my-app
  ingress:
  - from:
    - namespaceSelector: {}
    ports:
    - protocol: TCP
      port: 8080
7Check GKE load balancer annotations

Verify Service annotations for GCP load balancer:

bash
kubectl get svc <service-name> -o yaml | grep -A10 annotations

For GCP-specific configuration:

yaml
apiVersion: v1
kind: Service
metadata:
  annotations:
    cloud.google.com/load-balancer-type: "Internal"  # if internal LB
spec:
  type: LoadBalancer
  sessionAffinity: ClientIP  # optional
8Force load balancer sync

If configuration is correct, force GCP to re-sync:

bash
# Delete and recreate the Service
kubectl delete svc <service-name>
kubectl apply -f service.yaml

# Or patch to force update
kubectl patch svc <service-name> -p '{"spec":{"clusterIP":"None"}}' --type merge
kubectl patch svc <service-name> -p '{"spec":{"clusterIP":"<original-ip>"}}' --type merge

This triggers GCP to rebuild backend groups.

Advanced notes

GCP Health Check IPs (35.191.0.0/16, 130.211.0.0/22) must be allowed in ALL firewall rules and Network Policies. Use GCP Console → Load Balancing → Backend Services → Health Checks to test connectivity directly. For internal load balancers, use different IP ranges (35.199.0.0/16). In Shared VPC environments, verify firewall rules exist in host project.

Frequently asked questions

What does "No route to host: connection refused to load balancer" mean?
This error occurs when GCP's health check probes cannot reach your Kubernetes Service endpoints. The load balancer is unable to establish a network path to the backend pods, typically due to Google Cloud firewall rules, route table misconfigurations, or incorrect Service endpoint exposure. Without valid routes, health checks fail and the load balancer removes all backends, causing complete service unavailability.
How do I fix "No route to host: connection refused to load balancer"?
GCP load balancer health checks fail when there is no network route between load balancer and backend services. Pods become unreachable due to firewall rules, misconfigured routes, or Service endpoint configuration issues.
What causes "No route to host: connection refused to load balancer"?
GCP firewall rule blocking health check probes (35.191.0.0/16, 130.211.0.0/22) Service target ports do not match container listening ports Health check path/port misconfigured in Service annotations
Is the "No route to host: connection refused to load balancer" error serious?
Yes. This is a high-severity error that usually blocks work until it is fixed, but the steps above resolve it.

Official resources & further reading