Elasticsearch Error: Connection refused - Common Causes & Fixes

Connection refused (Linux ECONNREFUSED) is the OS-level error returned when a client attempts a TCP connection to a host:port where nothing is listening. With Elasticsearch, it means one of: the Elasticsearch process is not running, it bound to a different interface (typically 127.0.0.1 instead of 0.0.0.0), the port is wrong, or a firewall is dropping the SYN with a TCP reset. The client gets an immediate failure - no timeout, no retry helps.

What This Error Means

Connection refused is distinct from Connection timed out (no response, often a packet filter) and No route to host (network unreachable). The remote host received the connection attempt and explicitly rejected it because no process is bound to the requested port. The client connection attempt fails in milliseconds.

For Elasticsearch, the default ports are 9200 (REST/HTTP) and 9300 (transport/node-to-node).

Common Causes

1. Elasticsearch process not running. How to confirm: on the node, sudo systemctl status elasticsearch reports inactive; ps -ef | grep elasticsearch returns nothing.
2. Bound to localhost only. How to confirm: ss -ltnp | grep 9200 shows 127.0.0.1:9200, not 0.0.0.0:9200; network.host in elasticsearch.yml is unset or _local_.
3. Wrong port (custom http.port). How to confirm: GET / against 9200 fails; check elasticsearch.yml for http.port.
4. Firewall or security group dropping packets. How to confirm: nc -vz <host> 9200 from another host shows refused/dropped; iptables/ufw/aws SG rules block the port.
5. Bootstrap check failure preventing startup (production mode, vm.max_map_count too low, etc.). How to confirm: journalctl -u elasticsearch shows bootstrap checks failed near startup.
6. TLS enabled but client connecting via HTTP. How to confirm: on the node, 9200 listens but accepts only TLS; client gets handshake/protocol error that some libraries report as connection refused.

How to Fix Connection Refused

1. Verify the process is running on the target node:

   sudo systemctl status elasticsearch
   sudo journalctl -u elasticsearch -n 200
   

2. Confirm the listening socket:

   sudo ss -ltnp | grep -E '9200|9300'
   

   Expected output binds 0.0.0.0 (or the node's reachable IP) on both ports.

3. Set network.host to a reachable interface in /etc/elasticsearch/elasticsearch.yml:

   network.host: 0.0.0.0     # all interfaces
   # or
   network.host: 10.0.1.5    # specific IP
   http.port: 9200
   transport.port: 9300
   

   Restart:

   sudo systemctl restart elasticsearch
   

4. If bootstrap checks fail at startup, fix the underlying setting (e.g., raise vm.max_map_count):

   sudo sysctl -w vm.max_map_count=262144
   # persist in /etc/sysctl.conf
   

5. Open the firewall:

   # UFW
   sudo ufw allow from <client_subnet> to any port 9200 proto tcp
   # firewalld
   sudo firewall-cmd --permanent --add-port=9200/tcp && sudo firewall-cmd --reload
   

6. Match scheme. If the cluster has TLS enabled, clients must use https://. Test:

   curl -k https://<host>:9200/
   

7. Test end-to-end:

   curl -v http://<host>:9200/   # or https://
   

Resolve Connection Refused Automatically with Pulse

Pulse is an AI DBA for Elasticsearch and OpenSearch. When Connection refused (ECONNREFUSED) blocks clients from reaching 9200 or 9300, Pulse:

• Probes both ports from outside the cluster, snapshots ss -ltnp | grep -E '9200|9300' on each node, reads network.host/http.port/transport.port from elasticsearch.yml, parses journalctl -u elasticsearch for bootstrap-check failures, and correlates with recent restarts and configuration changes
• Identifies which of the six causes applies: Elasticsearch process not running, bound to 127.0.0.1 only because network.host is unset or _local_, custom http.port clients do not know about, firewall/security group dropping packets, bootstrap check (e.g., vm.max_map_count < 262144) preventing startup, or TLS-required cluster receiving plain HTTP from a client
• Generates the exact remediation: the elasticsearch.yml change setting network.host: 0.0.0.0 (or a specific IP), the sysctl -w vm.max_map_count=262144 plus /etc/sysctl.conf persistence, the ufw allow from <client_subnet> to any port 9200 proto tcp rule, or the https:// scheme update plus CA trust
• Applies dynamic firewall and sysctl changes with operator approval; leaves elasticsearch.yml edits and restarts as one-click PRs because they need coordinated rolling restarts

Pulse correlates "Connection refused" with the most recent configuration change in the cluster timeline, so the offending diff (the network.host removal, the bootstrap-check setting drift) surfaces immediately instead of through a git blame archaeology session.

Start a free trial to connect your cluster.

Frequently Asked Questions

Q: What ports does Elasticsearch use?
A: 9200 for HTTP/REST and 9300 for transport (node-to-node and Java transport client traffic). Both are TCP. The defaults can be changed via http.port and transport.port in elasticsearch.yml.

Q: How is "Connection refused" different from "Connection timed out"?
A: Connection refused (ECONNREFUSED) means the host received the SYN and replied with RST - no listener on that port. Connection timed out (ETIMEDOUT) means no reply at all - packets are dropped by a firewall or the host is unreachable.

Q: Why does Elasticsearch fail to start with bootstrap-check errors?
A: Production-mode bootstrap checks enforce minimum kernel and process settings (vm.max_map_count >= 262144, nofile >= 65535, seccomp available, etc.). Until they pass, Elasticsearch exits and the port is not opened. Check journalctl -u elasticsearch for the specific check.

Q: Will Connection refused affect data integrity?
A: No. Write requests fail before reaching the cluster - they return an error to the client immediately. The client should retry or queue the work after the cluster is reachable again. No partial writes occur.

Q: How do I know if it is a firewall or a binding issue?
A: On the cluster node, ss -ltnp | grep 9200 shows the listening socket. If it binds 0.0.0.0, the cluster is listening on all interfaces and a remote refusal points at a firewall. If it binds 127.0.0.1, only localhost can connect and the binding is the cause.

Q: Can changing network.host cause cluster splits?
A: It can if you change it on some nodes but not others, or to a value that breaks node-to-node transport (9300) reachability. Change network.host carefully and restart nodes one at a time, verifying cluster health after each.

Q: What's the fastest way to diagnose "Connection refused" in production?
A: Pulse, the AI DBA for Elasticsearch and OpenSearch, probes 9200 and 9300 from outside the cluster, reads the listening socket and network.host/http.port on each node, parses bootstrap-check failures from journalctl, and correlates with the most recent configuration change. It names whether the cause is process state, binding, firewall, bootstrap, or TLS scheme and routes the fix to the right place.

Related Reading

• Elasticsearch No alive nodes found in cluster: the client-library wrapper for this and related errors.
• Elasticsearch SocketTimeoutException: for the other half of the timeout-vs-refused split.
• Elasticsearch cluster health check: post-recovery diagnostics.
• Elasticsearch UnknownServiceException: scheme/protocol-related connection errors.
• Elasticsearch monitoring: external reachability monitoring.