How to fix NoNodeAvailableException: None of the configured nodes are available in Elasticsearch

ElasticsearchINTERMEDIATECRITICALUpdated Dec 29, 2025· 140 views

The NoNodeAvailableException occurs when an Elasticsearch client cannot establish a connection to any of the configured nodes in the cluster. This typically results from network connectivity issues, incorrect node configuration, nodes being down, or port/firewall mismatches between client and server.

Quick fix

Fixes NoNodeAvailableException: None of the configured nodes are available

# Check if Elasticsearch service is running
sudo systemctl status elasticsearch

# Or for Docker
docker ps | grep elasticsearch

# Attempt to connect to the configured nodes directly
curl -X GET "http://node1.example.com:9200/"
curl -X GET "http://192.168.1.100:9200/"

# Test from the client machine itself
curl -X GET "http://ELASTICSEARCH_HOST:9200/"

Verify Elasticsearch cluster is running and accessible
Verify client configuration has correct node addresses
Check DNS resolution from client to nodes
Confirm Elasticsearch is listening on correct port

elasticsearch — error

$# Check if Elasticsearch service is running
sudo systemctl status elasticsearch
# Or for Docker
docker ps | grep elasticsearch
# Attempt to connect to the configured nodes directly
curl -X GET "http://node1.example.com:9200/"
curl -X GET "http://192.168.1.100:9200/"
# Test from the client machine itself
curl -X GET "http://ELASTICSEARCH_HOST:9200/"
NoNodeAvailableException: None of the configured nodes are available

What this error means

The NoNodeAvailableException is a client-side error that indicates the Elasticsearch client library (such as the Java Transport Client, Python client, or Node.js client) was unable to connect to any of the nodes specified in its configuration. This differs from other connection errors because it occurs after the client has attempted to reach one or more nodes and failed on all of them. The exception is thrown when the client exhausts all configured node addresses without establishing a successful connection. Common scenarios include: - The Elasticsearch cluster is completely unreachable from the client's network location - All nodes in the cluster are down or unresponsive - The client is configured with incorrect node addresses or ports - Firewall rules block communication between client and nodes - The Transport Client (port 9300) is being used but only HTTP (port 9200) is accessible - Network latency or timeouts cause all connection attempts to fail - DNS resolution fails for configured hostnames

Typical symptoms

Application crashes or hangs when trying to initialize Elasticsearch client
NoNodeAvailableException appears in logs with empty node list
All Elasticsearch operations fail immediately with no retry attempts
Data cannot be indexed or searched from the application
CI/CD pipelines fail at the Elasticsearch connection step
Metrics show zero successful connections to any configured nodes
The error message includes attempted node addresses but none successful

Common causes

Elasticsearch cluster is completely down or not running on any configured node
Client is configured with wrong hostnames or IP addresses
Client is connecting to wrong port (using 9200 for Transport Client instead of 9300)
Firewall rules blocking all connection attempts from client to nodes
Network connectivity issues between client and cluster (routing, VPN, cloud network)
DNS resolution failing for configured Elasticsearch hostnames
All nodes have crashed or are in an unrecoverable state
Client version incompatible with Elasticsearch server version
Network interface or IP binding issues on Elasticsearch nodes

How to fix "NoNodeAvailableException: None of the configured nodes are available"

1Verify Elasticsearch cluster is running and accessible

First, confirm that at least one Elasticsearch node is actually running and responding:

bash

# Check if Elasticsearch service is running
sudo systemctl status elasticsearch

# Or for Docker
docker ps | grep elasticsearch

# Attempt to connect to the configured nodes directly
curl -X GET "http://node1.example.com:9200/"
curl -X GET "http://192.168.1.100:9200/"

# Test from the client machine itself
curl -X GET "http://ELASTICSEARCH_HOST:9200/"

If curl returns connection refused or timeout errors, the Elasticsearch node is not listening. Start the service:

bash

# For systemd
sudo systemctl start elasticsearch

# For Docker
docker start elasticsearch

# Check logs for startup errors
sudo journalctl -u elasticsearch -f
# or
docker logs -f elasticsearch

2Verify client configuration has correct node addresses

Review your Elasticsearch client configuration to ensure it points to valid nodes:

java

// Java Transport Client example
TransportClient client = new PreBuiltTransportClient(settings)
    .addTransportAddress(new TransportAddress(InetAddress.getByName("node1.example.com"), 9300))
    .addTransportAddress(new TransportAddress(InetAddress.getByName("node2.example.com"), 9300));

javascript

// Node.js Elasticsearch client
const { Client } = require('@elastic/elasticsearch');
const client = new Client({
  nodes: [
    'http://node1.example.com:9200',
    'http://node2.example.com:9200',
    'http://node3.example.com:9200'
  ]
});

python

# Python Elasticsearch client
from elasticsearch import Elasticsearch

es = Elasticsearch([
    {'host': 'node1.example.com', 'port': 9200},
    {'host': 'node2.example.com', 'port': 9200},
    {'host': 'node3.example.com', 'port': 9200}
])

Verify:
1. Hostnames or IPs are resolvable from the client machine
2. Ports are correct (9200 for HTTP, 9300 for Transport protocol)
3. Protocol matches (http:// vs https://)
4. No typos in hostnames or IP addresses

3Check DNS resolution from client to nodes

Network connectivity often fails due to DNS resolution issues:

bash

# Test DNS resolution
nslookup elasticsearch.example.com
dig elasticsearch.example.com

# Or with getent
getent hosts elasticsearch.example.com

# Test connectivity with telnet or nc
telnet node1.example.com 9200
nc -zv node1.example.com 9200

# Test from inside Docker if applicable
docker exec app-container nslookup elasticsearch
docker exec app-container curl http://elasticsearch:9200/

If DNS resolution fails:
- Verify the hostname is correctly spelled
- Check if /etc/hosts has the correct entries
- Ensure DNS servers are reachable from the client
- For Docker, ensure containers are on the same network

If connectivity times out:
- Check firewall rules
- Verify the node is actually listening on that port
- Check for network routing issues

4Confirm Elasticsearch is listening on correct port

Verify that Elasticsearch is actually listening on the port your client is trying to connect to:

bash

# Check what ports Elasticsearch is listening on
sudo netstat -tulpn | grep java
# or
sudo ss -tulpn | grep 9200
sudo ss -tulpn | grep 9300

# Expected output for port 9200 (HTTP):
# tcp    0    0 0.0.0.0:9200    0.0.0.0:*    LISTEN    12345/java

# Expected output for port 9300 (Transport):
# tcp    0    0 0.0.0.0:9300    0.0.0.0:*    LISTEN    12345/java

Check Elasticsearch configuration if ports are not listening:

yaml

# /etc/elasticsearch/elasticsearch.yml
http.port: 9200
transport.port: 9300

# Verify network.host setting (should not bind only to localhost for multi-node)
network.host: 0.0.0.0
# or specify the actual IP
network.host: 192.168.1.100

After making configuration changes:

bash

sudo systemctl restart elasticsearch
sudo systemctl status elasticsearch

# Wait a few seconds for it to start
sleep 5

# Verify ports are now listening
sudo netstat -tulpn | grep java

5Verify firewall rules allow connections

Check that firewall rules aren't blocking client connections to Elasticsearch:

bash

# Check UFW (Ubuntu/Debian)
sudo ufw status numbered
# Allow ports if needed
sudo ufw allow 9200/tcp
sudo ufw allow 9300/tcp

# Check firewalld (CentOS/RHEL)
sudo firewall-cmd --list-all
sudo firewall-cmd --permanent --add-port=9200/tcp
sudo firewall-cmd --permanent --add-port=9300/tcp
sudo firewall-cmd --reload

# Check iptables directly
sudo iptables -L -n | grep -E "9200|9300"

# Test specific connectivity
telnet elasticsearch-host 9200
# Or using nc
nc -zv elasticsearch-host 9200

For cloud providers:
- AWS EC2: Check security group inbound rules
- Azure: Check Network Security Group (NSG) rules
- GCP: Verify VPC firewall rules
- Docker: Ensure containers are on same network or ports are mapped

Test from client to server:

bash

# From the client machine, test if you can reach the port
nc -zv elasticsearch-server.com 9200
# Output should be: "succeeded"

6Verify Transport Client vs HTTP Client port mismatch

A common cause is using the wrong protocol/port combination:

java

// WRONG: Using Transport Client to connect to HTTP port
TransportClient client = new PreBuiltTransportClient(settings)
    .addTransportAddress(new TransportAddress(InetAddress.getByName("localhost"), 9200));
    // ERROR: port 9200 is HTTP, not Transport protocol!

// CORRECT: Transport Client uses port 9300
TransportClient client = new PreBuiltTransportClient(settings)
    .addTransportAddress(new TransportAddress(InetAddress.getByName("localhost"), 9300));

Client library compatibility:
- Transport Client (deprecated in ES 7.0+): Uses port 9300
- REST Client (Java): Uses port 9200 with HTTP
- JavaScript Client: Uses port 9200 with HTTP
- Python Client: Uses port 9200 with HTTP

Modern approach for all languages:

javascript

// Use REST client for all modern versions
const { Client } = require('@elastic/elasticsearch');
const client = new Client({
  node: 'http://elasticsearch:9200'  // HTTP port 9200
});

java

// Use RestHighLevelClient (ES 7.x) or newer Java API client
RestHighLevelClient client = new RestHighLevelClient(
    RestClient.builder(
        new HttpHost("localhost", 9200, "http")
    ).build()
);

7Check and increase client connection timeout settings

If nodes are slow to respond, client timeouts may prevent successful connections:

java

// Java Transport Client - increase timeout
Settings settings = Settings.builder()
    .put("client.transport.ping_timeout", "60s")     // Default 5s
    .put("client.transport.nodes_sampler_interval", "60s")  // Default 5s
    .put("cluster.name", "my-cluster")
    .build();

TransportClient client = new PreBuiltTransportClient(settings)
    .addTransportAddress(new TransportAddress(InetAddress.getByName("localhost"), 9300));

javascript

// Node.js - increase timeout
const { Client } = require('@elastic/elasticsearch');
const client = new Client({
  node: 'http://elasticsearch:9200',
  requestTimeout: 30000,  // milliseconds
  sniffOnStart: false,    // Don't sniff on startup if nodes unreachable
  sniffOnConnectionFault: false
});

python

# Python - increase timeout
from elasticsearch import Elasticsearch

es = Elasticsearch(
    ['http://elasticsearch:9200'],
    timeout=30
)

Disable sniffing if causing issues with cloud deployments:

javascript

const client = new Client({
  node: 'http://elasticsearch:9200',
  sniffOnStart: false,         // Prevents auto-discovery of nodes
  sniffOnConnectionFault: false
});

Advanced notes

## Advanced Troubleshooting

### Docker Network Issues
For Docker deployments, verify container networking:

bash

# List all networks
docker network ls

# Inspect the network your containers use
docker network inspect bridge

# Verify both containers are on same network
docker inspect elasticsearch | grep NetworkMode
docker inspect app | grep NetworkMode

# Test connectivity between containers
docker exec app-container curl http://elasticsearch:9200/

# Check DNS resolution inside container
docker exec app-container ping elasticsearch

If using docker-compose, ensure proper setup:

yaml

services:
  elasticsearch:
    image: docker.elastic.co/elasticsearch/elasticsearch:8.11.0
    environment:
      - discovery.type=single-node
      - network.host=0.0.0.0
    ports:
      - "9200:9200"
    networks:
      - elastic

  app:
    image: my-app:latest
    environment:
      - ELASTICSEARCH_URL=http://elasticsearch:9200  # Use service name
    depends_on:
      - elasticsearch
    networks:
      - elastic

networks:
  elastic:
    driver: bridge

### Kubernetes Deployments
For Kubernetes, configure the client with the Elasticsearch service DNS name:

yaml

# Client configuration
ELASTICSEARCH_URL: http://elasticsearch-service.default.svc.cluster.local:9200

Verify service discovery:

bash

# Check if service exists
kubectl get svc elasticsearch-service

# Verify DNS resolution from a pod
kubectl run -it --image=busybox dns-test -- nslookup elasticsearch-service

### Cluster Discovery and Sniffing Issues
The Java Transport Client's sniffing feature can cause NoNodeAvailableException in cloud environments:

java

// PROBLEMATIC: Sniffing enabled
Settings settings = Settings.builder()
    .put("client.transport.sniff", true)  // Tries to auto-discover nodes
    .build();

// This fails in cloud if discovered IPs are not reachable from client

// SOLUTION: Disable sniffing
Settings settings = Settings.builder()
    .put("client.transport.sniff", false)
    .build();

### Cloud Provider Specifics

AWS Elasticsearch/OpenSearch:
- Use the endpoint provided by AWS (e.g., domain.region.es.amazonaws.com)
- Enable VPC access if in private subnet
- Check security groups for port 9200
- Authentication may be required

javascript

const { Client } = require('@elastic/elasticsearch');
const client = new Client({
  node: 'https://domain.region.es.amazonaws.com',
  auth: { username: 'user', password: 'password' }
});

Elastic Cloud:
- Use the Elasticsearch endpoint provided (includes port)
- Always use HTTPS
- Disable node sniffing for cloud deployments

javascript

const client = new Client({
  node: 'https://my-deployment.es.us-east-1.aws.cloud.es.io',
  auth: { apiKey: 'your-api-key' },
  sniffOnStart: false,
  sniffOnConnectionFault: false
});

### Network Monitoring and Diagnostics
Use tcpdump or Wireshark to diagnose connection issues:

bash

# Capture traffic on port 9200
sudo tcpdump -i any port 9200 -A

# Check connection states
sudo netstat -an | grep 9200
sudo ss -an | grep 9200

# Monitor ongoing connections
watch -n 1 'netstat -an | grep 9200'

### Version Compatibility
Always match client and server versions:

bash

# Check Elasticsearch version
curl http://elasticsearch:9200/

# Expected output includes version number
# {
#   "version": {
#     "number": "8.11.0",
#     ...
#   }
# }

Use compatible client libraries:
- Elasticsearch 8.x → elasticsearch-js 8.x, elasticsearch-py 8.x
- Elasticsearch 7.x → elasticsearch-js 7.x, elasticsearch-py 7.x
- Transport Client is removed in ES 7.0+

### Memory and Resource Issues
If Elasticsearch crashes due to resource constraints, increase available resources:

yaml

# docker-compose
elasticsearch:
  image: docker.elastic.co/elasticsearch/elasticsearch:8.11.0
  environment:
    - "ES_JAVA_OPTS=-Xms2g -Xmx2g"
  deploy:
    resources:
      limits:
        memory: 4G

### Logging and Debugging
Enable debug logging to see connection attempts:

yaml

# elasticsearch.yml
logger.org.elasticsearch.transport: DEBUG
logger.org.elasticsearch.client: DEBUG

For Java clients:

java

// Enable debug logging
Logger.getLogger("org.elasticsearch").setLevel(Level.DEBUG);

Frequently asked questions

What does "NoNodeAvailableException: None of the configured nodes are available" mean?: js client) was unable to connect to any of the nodes specified in its configuration. This differs from other connection errors because it occurs after the client has attempted to reach one or more nodes and failed on all of them. The exception is thrown when the client exhausts all configured node addresses without establishing a successful connection.
How do I fix "NoNodeAvailableException: None of the configured nodes are available"?: The NoNodeAvailableException occurs when an Elasticsearch client cannot establish a connection to any of the configured nodes in the cluster. This typically results from network connectivity issues, incorrect node configuration, nodes being down, or port/firewall mismatches between client and server.
What causes "NoNodeAvailableException: None of the configured nodes are available"?: Elasticsearch cluster is completely down or not running on any configured node Client is configured with wrong hostnames or IP addresses Client is connecting to wrong port (using 9200 for Transport Client instead of 9300)
Is the "NoNodeAvailableException: None of the configured nodes are available" error serious?: Yes. This is a critical-severity error that usually blocks work until it is fixed, but the steps above resolve it.

Official resources & further reading

📚Elasticsearch Official Documentation
📖
discuss.elastic.co - 92000(Official Docs)
🐙
github.com - 23010(GitHub)
🔗
opster.com - none of the configured nodes were available
📖
elastic.co - modules network(Official Docs)
📖
elastic.co - docker(Official Docs)
🔗
learn.liferay.com - troubleshooting the elasticsearch connection

How to fix NoNodeAvailableException: None of the configured nodes are available in Elasticsearch

Quick fix

What this error means

Typical symptoms

Common causes

How to fix "NoNodeAvailableException: None of the configured nodes are available"

Advanced notes

Frequently asked questions

Related errors

Official resources & further reading