Skip to main content

Resolving 'Connection Refused' Elasticsearch Errors for Magento 2 on Cloudways

 There are few things more anxiety-inducing in the Magento ecosystem than a deployment failing at 90% execution. You run bin/magento setup:upgrade, the console hangs, and finally outputs the dreaded No alive nodes found in your cluster exception.

For architects and developers working with Magento 2.4+ on Cloudways, this is a distinct bottleneck. Since Adobe deprecated MySQL search in favor of Elasticsearch (and subsequently OpenSearch), the search engine is no longer just a feature—it is a critical dependency. If Elasticsearch goes down, the checkout breaks, the catalog vanishes, and the admin panel becomes inaccessible.

This guide details the root causes of Elasticsearch connection refusals on Cloudways managed hosting and provides a rigorous, step-by-step resolution path.

The Root Cause: Connection Pools and JVM Pressure

Before applying fixes, you must understand why the error occurs to prevent recurrence.

When Magento attempts to connect to Elasticsearch, it utilizes the elasticsearch-php client. This client maintains a Connection Pool. When you see "No alive nodes," it means the client attempted to ping the configured host (usually localhost:9200), failed to receive a handshake, and marked the node as "dead."

On Cloudways, this typically happens for three specific reasons:

  1. The OOM Killer: Elasticsearch runs on the Java Virtual Machine (JVM). On Cloudways servers with 2GB or 4GB of RAM, the combined memory pressure of Magento (PHP-FPM), MySQL, Varnish, and Elasticsearch often exceeds available physical memory. The Linux kernel's Out-Of-Memory (OOM) killer sacrifices the heaviest process—usually Java—to save the OS.
  2. Service Dormancy: Cloudways may not automatically restart the Elasticsearch service if it crashes silently, leaving port 9200 closed.
  3. Configuration Drift: Magento 2.4.4+ enforces strict version requirements. If your env.php requests Elasticsearch 7 but the server is running OpenSearch (or vice versa), the handshake fails.

Diagnosis: Verifying the Failure

Do not assume the service is running. Verify the socket connection via SSH.

Log into your Cloudways server via SSH and execute a direct cURL request to the local loopback interface.

curl -XGET 'http://127.0.0.1:9200/_cluster/health?pretty'

Scenario A: Connection Refused

If the output is:

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

The Elasticsearch service is completely down. Proceed to Solution 1.

Scenario B: Valid JSON Response

If you receive a JSON payload with status green or yellow, the service is up. The issue lies within your Magento configuration files. Proceed to Solution 2.

Solution 1: Reviving the Service & Managing Heap Size

If the service is down, a simple restart via the Cloudways UI often fixes it temporarily, but it will crash again under load. You must ensure the JVM heap size is appropriate for your instance.

1. Check Service Status via Cloudways UI

  1. Navigate to Server Management > Manage Services.
  2. Locate Elasticsearch.
  3. If the status is "Stopped," click Start.

2. Validate Memory Allocation

Elasticsearch performance relies on Heap Memory. A general rule of thumb is allocating 50% of available RAM to the JVM, but never crossing 32GB. However, on a shared Cloudways instance (e.g., 4GB RAM), allocating 2GB to ES will starve MySQL and PHP.

On Cloudways, you cannot edit jvm.options directly as root access is restricted. You must ensure you are on a server size that supports the stack.

  • Minimum Viable: 4GB Server (Risk of OOM).
  • Recommended: 8GB+ Server for production Magento 2.4 stacks.

If you are on a 4GB server and experiencing crashes during reindexing, you must scale the server up. No amount of configuration tweaking will solve a physical lack of memory for the required stack.

Solution 2: Correcting Magento Configuration

If Elasticsearch is running (Scenario B) but Magento still throws errors, the issue is often a mismatch in app/etc/env.php.

1. Force Configuration via CLI

Do not rely on the Admin Panel if the site is unstable. Use the CLI to inject the correct connection parameters. Note that we explicitly use 127.0.0.1 rather than localhost to bypass DNS resolution latency or IPv6 conflicts.

Execute the following in your Magento root:

bin/magento config:set catalog/search/engine 'elasticsearch7'
bin/magento config:set catalog/search/elasticsearch7_server_hostname '127.0.0.1'
bin/magento config:set catalog/search/elasticsearch7_server_port '9200'
bin/magento config:set catalog/search/elasticsearch7_index_prefix 'magento2'
bin/magento config:set catalog/search/elasticsearch7_enable_auth '0'
bin/magento config:set catalog/search/elasticsearch7_server_timeout '15'

2. Verify env.php Integrity

Sometimes CLI commands do not persist if env.php is read-only or malformed. Open app/etc/env.php and manually inspect the system array. It should look exactly like this structure:

<?php
return [
    // ... other configs
    'system' => [
        'default' => [
            'catalog' => [
                'search' => [
                    'engine' => 'elasticsearch7',
                    'elasticsearch7_server_hostname' => '127.0.0.1',
                    'elasticsearch7_server_port' => '9200',
                    'elasticsearch7_index_prefix' => 'magento2',
                    'elasticsearch7_enable_auth' => '0',
                    'elasticsearch7_server_timeout' => '15'
                ]
            ]
        ]
    ],
    // ...
];

Note: If you are using OpenSearch (required for very recent Magento versions), change elasticsearch7 to opensearch in the engine key.

Solution 3: The Reindexing Trap

After restoring the connection, your index is likely corrupted or stale. You will see products in the backend but empty categories on the frontend.

1. Clean the Slate

Flush the cache to remove stale configuration data.

bin/magento cache:clean config full_page

2. Reset Index Status

If a previous reindex failed, the indexers might be "Locked."

bin/magento indexer:reset

3. Execute Full Reindex

Run the catalog search indexer specifically to test the connection immediately.

bin/magento indexer:reindex catalogsearch_fulltext

If this command completes successfully, your cluster is healthy.

Deep Dive: OpenSearch Migration

Cloudways has begun rolling out OpenSearch support as the default for newer Magento installations. This creates a common "No alive nodes" scenario where Magento expects Elasticsearch 7 but the server is running OpenSearch on port 9200.

Identifying the Engine

Run the curl command again:

curl -XGET 'http://127.0.0.1:9200'

If the JSON response contains "number" : "1.x.x" (OpenSearch versioning) or specifically mentions OpenSearch, you must update Magento to use the correct adapter.

Updating the Adapter

Magento 2.4.4+ supports OpenSearch natively.

# Switch engine to OpenSearch
bin/magento config:set catalog/search/engine 'opensearch'

# Set hostname (Port remains 9200 usually)
bin/magento config:set catalog/search/opensearch_server_hostname '127.0.0.1'
bin/magento config:set catalog/search/opensearch_server_port '9200'

Failure to switch the engine type while pointing to an OpenSearch instance will result in subtle query syntax errors or connection timeouts, as the strict type validation in Magento's vendor code will reject the OpenSearch handshake response.

Summary

The "No alive nodes" error on Cloudways is rarely a code bug; it is almost exclusively an infrastructure or configuration alignment issue.

  1. Check Memory: If the service is dead, you are likely OOMing. Scale the server.
  2. Verify Port: Use curl to confirm port 9200 is listening on 127.0.0.1.
  3. Hardcode Config: Set the hostname and port explicitly in env.php or via CLI, avoiding localhost ambiguity.
  4. Match Engines: Ensure Magento is configured for opensearch if the server payload returns OpenSearch headers.

By treating the search engine as a primary infrastructure component rather than a background service, you ensure higher uptime and faster recovery during deployments.

Labels: