Skip to main content
search
Error Logs

Error log: NodeNotConnectedException / NoNodeAvailableException – The Unreachable Cluster

By November 21, 2025No Comments

Error log: You’ll typically see these errors in the logs of your client applications (e.g., Logstash, your custom application using a client library, or even cURL if it can’t connect) trying to talk to OpenSearch:

 [ERROR] [org.opensearch.client.transport.TransportClientNodesService] [your-app] NoNodeAvailableException[None of the configured nodes are available: [{#transport#-1}{your-ip-or-hostname}{your-ip-or-hostname:9300}]]

Or:

 [ERROR] [org.opensearch.client.RestClient] [your-app] Request failed: Connection refused

Why… is this happening? NodeNotConnectedException or NoNodeAvailableException (often seen with older clients or specific libraries) means that the client application itself cannot establish a connection to any of the OpenSearch nodes it’s configured to talk to. This is distinct from a node within the cluster not finding the cluster manager; this is an external client failing to reach any part of the cluster.

Common reasons include:

  1. OpenSearch cluster is down: The most straightforward reason – all the OpenSearch nodes that the client is trying to connect to are actually offline.
  2. Incorrect client configuration: The client application’s configuration (e.g., opensearch.hosts, opensearch.port) specifies incorrect IP addresses, hostnames, or ports for the OpenSearch cluster.
  3. Network connectivity (client to cluster): Firewalls, security groups, or network ACLs are blocking the client’s access to the OpenSearch cluster on the correct port (typically 9200 for HTTP/REST API or 9300 for Transport API).
  4. DNS resolution failure: If the client is configured with hostnames, its inability to resolve those hostnames to IP addresses will lead to connection failures.
  5. Network saturation/overload: While less common for a “connection refused” error, extreme network congestion or an overloaded OpenSearch node could prevent the initial connection from being established.
  6. TLS/SSL issues: If OpenSearch is configured for HTTPS/TLS, but the client is trying to connect over plain HTTP, or the client doesn’t trust the cluster’s SSL certificate, a connection might be refused or fail.

Best Practice:

  1. Verify cluster status: First, confirm your OpenSearch cluster is running and healthy. Use curl -XGET https://:9200/_cluster/health (adjusting for HTTPS and port) directly from one of your OpenSearch nodes, or check your cloud provider’s monitoring.
  2. Check client configuration: Double-check the IP addresses, hostnames, and ports configured in your client application. Ensure they match your OpenSearch cluster’s network.host and http.port/transport.port settings.
  3. Network connectivity check (Client Side):
    • From the machine running your client application, try ping [opensearch_node_ip] to check basic reachability.
    • Use telnet 9200 (or 9300 for transport clients) to see if you can establish a connection to the OpenSearch port. If it immediately says “Connection refused,” a firewall or the OpenSearch process itself isn’t listening.
    • Review firewall rules and security groups on both the client and OpenSearch server.
  4. Review OpenSearch logs: Check the OpenSearch node logs for any messages indicating it’s not starting up correctly or is refusing connections from your client’s IP.
  5. SSL/TLS configuration: If using HTTPS, ensure your client is configured to use SSL/TLS and trusts the certificates presented by your OpenSearch cluster.

What else can I do? Is your application unable to connect to your OpenSearch cluster? Don’t let network woes block your data flow! Connect with the OpenSearch community for guidance, reach out to the vibrant OpenSearch community for help and support on the OpenSearch Slack Channel.

Author