Error log: “Connection refused” – The locked door

Error log: This error, like its cousin “Connection timed out,” will not appear in your OpenSearch logs. It’s a low-level network error that your client application receives instantly.

None
# From curl

curl: (7) Failed to connect to 127.0.0.1 port 9200: Connection refused

Or in a Java application log:

None
java.net.ConnectException: Connection refused

Why… is this happening? This is a very clear network error. It’s an active rejection from the server’s operating system.

It is not a firewall issue. A firewall drops packets, leading to a “Connection timed out” (Blog #36). “Connection refused” means your client’s request successfully reached the server, but the OS found no process listening on that port (e.g., port 9200) and immediately sent back a “nobody’s home” rejection.

Common causes:

1. OpenSearch is not running: This is the #1 cause. The OpenSearch process on that node is stopped, crashed, or failed to start.
2. Wrong port: Your client is configured to connect to port 9200, but your OpenSearch node is configured (in opensearch.yml) to listen on a different port, like 9201.
3. Wrong host / IP: Your client is connecting to the wrong server. For example, you’re connecting to 10.1.2.3 (your web server) instead of 10.1.2.4 (your OpenSearch node).
4. Wrong network.host Setting: In opensearch.yml, network.host is set to localhost (or 127.0.0.1). This tells OpenSearch to only accept connections from the machine itself. When your client tries to connect from another server, the OS refuses the connection.

Best Practice:

1. Check if the process is running: Log in to the OpenSearch server and run:
Bash

None

ps -ef | grep java | grep opensearch

2. If you see no process, OpenSearch is down. Check the opensearch.log to see why it failed to start.

3. Check the listening port: On the server, run netstat to see what is actually listening on that port:
Bash

None

sudo netstat -tulpn | grep 9200

4. If you see a Java process, it’s running. If you see nothing, it’s not running or it’s on a different port.

5. Check opensearch.yml: Open your opensearch.yml and check these two settings:

• • http.port: Is this 9200 or something else?
  • network.host: For a production cluster, this must be set to an IP address (e.g., _site_, _local_, or 0.0.0.0) that is reachable by your clients. If it’s localhost, that’s your problem.

What else can I do? This is almost always a configuration mismatch or a crashed process. By checking ps, netstat, and opensearch.yml on the server, you can almost always find the root cause. For help, contact us in The OpenSearch Slack Channel in #General.