Magento 2 "Could Not Validate a Connection to Elasticsearch/OpenSearch": The Complete Fix

Where the error appears

The exact string Magento prints depends on your version and engine, but it reads as one of these:

Could not validate a connection to Elasticsearch. No alive nodes found in your cluster.
Could not validate a connection to OpenSearch. No alive nodes found in your cluster.

It surfaces in three places, and they all point at the same root problem:

• Admin, Test Connection button. Stores > Configuration > Catalog > Catalog Search. You pick the engine, fill in host and port, click Test Connection, and it fails instead of showing a green tick.
• CLI reindex. Running bin/magento indexer:reindex catalogsearch_fulltext (or a full indexer:reindex) stops with the same connection error, because the fulltext indexer writes into the search node.
• Storefront 500. A search query, a category page with layered navigation, or the search autocomplete returns HTTP 500. Check var/log/exception.log and you will find the same "No alive nodes" trace.

All three mean the same thing: PHP cannot open a working connection to the search node at the host, port, and protocol Magento has configured. Now work through the causes.

Diagnose first: curl the search node from inside the PHP container

Do not touch config until you know whether the node is reachable and healthy. The single most useful test is a curl from the exact place Magento runs, which in a Docker setup is inside the PHP-FPM container, not your host shell.

# jump into the PHP container (name from your compose file)
docker compose exec phpfpm bash

# 1) is the node answering at all?
curl -s http://opensearch:9200

# 2) cluster health: green or yellow is fine, red or no answer is the problem
curl -s http://opensearch:9200/_cluster/health?pretty

# 3) list indices so you can see Magento's prefix
curl -s "http://opensearch:9200/_cat/indices?v"

A healthy node returns a JSON banner with its version and a health block:

{
  "name" : "opensearch",
  "cluster_name" : "docker-cluster",
  "version" : { "number" : "2.13.0", "distribution" : "opensearch" },
  "tagline" : "The OpenSearch Project: https://opensearch.org/"
}

Fix 1: confirm the search engine is set to OpenSearch

From Magento 2.4.6 onward OpenSearch is the default engine, and Adobe dropped native Elasticsearch support. If your catalog/search/engine value still says elasticsearch7 or elasticsearch8 after an upgrade, the admin can no longer validate it and Test Connection fails. Check the current value:

bin/magento config:show catalog/search/engine

On 2.4.6 to 2.4.9 this should print opensearch. If it prints an Elasticsearch value, or nothing, set it:

bin/magento config:set catalog/search/engine opensearch

If the value is stored in app/etc/env.php as a hardcoded system entry, config:set will not override it. Grep for it and remove the stale lock if you find one:

grep -R "catalog/search" app/etc/env.php

Fix 2: wrong host and port (in Docker, use the service name)

This is the number one cause on containerized stacks. Inside a Docker network, localhost and 127.0.0.1 point at the PHP container itself, not at the search node. The hostname Magento needs is the compose service name (or container name) of the OpenSearch node, resolved over the shared Docker network.

So if your docker-compose.yml defines the service as opensearch, the Magento hostname is opensearch, and the port is the container's internal 9200, not whatever you mapped to the host:

services:
  phpfpm:
    # ...
  opensearch:
    image: opensearchproject/opensearch:2.13.0
    ports:
      - "9200:9200"   # host mapping, irrelevant to container-to-container traffic

Set the host and port to the internal values:

bin/magento config:set catalog/search/opensearch_server_hostname opensearch
bin/magento config:set catalog/search/opensearch_server_port 9200

On a bare-metal server where OpenSearch runs on the same host as PHP, localhost and port 9200 are correct. The service-name rule is specific to Docker, Kubernetes, and any setup where PHP and search run in separate network namespaces. If in doubt, the curl test from Fix's diagnose step settles it: run the exact hostname you plan to configure and confirm it answers from inside the PHP container.

Fix 3: the search node is down or still booting (OOM, heap, vm.max_map_count)

If curl gives connection refused or times out, the node is not up. On small VPS boxes the usual reason is that OpenSearch started, tried to allocate memory, hit the kernel's memory-map limit, and exited. Check the container:

docker compose ps
docker compose logs --tail=80 opensearch

Two log lines tell the whole story. The first:

max virtual memory areas vm.max_map_count [65530] is too low,
increase to at least [262144]

Fix it on the Docker host (this is a host kernel setting, not a container one):

# temporary, until reboot
sudo sysctl -w vm.max_map_count=262144

# permanent
echo 'vm.max_map_count=262144' | sudo tee /etc/sysctl.d/99-opensearch.conf
sudo sysctl -p /etc/sysctl.d/99-opensearch.conf

The second is the OOM killer taking the JVM. Give OpenSearch a defined heap that fits the box. Set it to no more than half the RAM you can spare, and keep min and max equal:

  opensearch:
    image: opensearchproject/opensearch:2.13.0
    environment:
      - discovery.type=single-node
      - "OPENSEARCH_JAVA_OPTS=-Xms512m -Xmx512m"
      - bootstrap.memory_lock=true
    ulimits:
      memlock:
        soft: -1
        hard: -1

Fix 4: HTTPS, authentication, and the security plugin

The official OpenSearch image ships with the security plugin enabled, which means it answers on https with a self-signed certificate and demands credentials. If Magento is set to plain http with no auth, the handshake fails and you get the connection error. Your curl test exposes this immediately:

# plugin on: this fails with an SSL/handshake error over http
curl -s http://opensearch:9200
# and needs credentials over https
curl -sk -u admin:admin https://opensearch:9200

You have two clean options. For a local development stack, turn the security plugin off so OpenSearch speaks plain HTTP:

  opensearch:
    environment:
      - "DISABLE_SECURITY_PLUGIN=true"
      - discovery.type=single-node

For staging or production where you keep the plugin on, tell Magento to authenticate. These are the same keys the admin form writes, so setting them by CLI is equivalent to filling in the fields:

bin/magento config:set catalog/search/opensearch_enable_auth 1
bin/magento config:set catalog/search/opensearch_username admin
bin/magento config:set catalog/search/opensearch_password 'your-strong-password'

If the node uses HTTPS, set the port to the TLS port it listens on and make sure the certificate is trusted by the PHP container, or the TLS handshake still fails even with correct credentials. Do not disable certificate validation in production to paper over a bad cert.

Fix 5: index prefix collisions on shared hosts, and version mismatch

Index prefix collisions

Every Magento install writes indices into the search node under a prefix, held in catalog/search/opensearch_index_prefix and defaulting to magento2. On a multi-tenant box where several stores share one OpenSearch node, two installs using the same default prefix fight over the same indices, and reindex or validation breaks in confusing ways. List the indices and give each install its own prefix:

curl -s "http://opensearch:9200/_cat/indices?v"
bin/magento config:set catalog/search/opensearch_index_prefix clientstore_a

Version mismatch

Magento 2.4.6 and later ship the opensearch-project/opensearch-php client, which is built to talk to OpenSearch 1.x and 2.x. Point it at an OpenSearch 3.x node, or at a raw Elasticsearch 8 node without a compatibility shim, and the client cannot negotiate the API, so connection validation fails even when the node is healthy and reachable. Check the running version straight from the banner:

curl -s http://opensearch:9200 | grep -i number

Match the node to what your Magento version supports: OpenSearch 2.x is the safe target across 2.4.6 to 2.4.9. If your reindex is slow once search is healthy, that is a separate performance problem, and reducing time to first byte on catalog and search pages is covered in this walkthrough of cutting Magento TTFB from 1.8s to 180ms.

Apply the config from the CLI and reindex

Here is the whole fix as one runnable block. Adjust the hostname and port to your stack, then rebuild the search index and flush the cache so the storefront picks up the change:

# 1) engine (2.4.6+)
bin/magento config:set catalog/search/engine opensearch

# 2) connection
bin/magento config:set catalog/search/opensearch_server_hostname opensearch
bin/magento config:set catalog/search/opensearch_server_port 9200
bin/magento config:set catalog/search/opensearch_index_prefix magento2
bin/magento config:set catalog/search/opensearch_server_timeout 15

# 3) auth, only if the security plugin is on
# bin/magento config:set catalog/search/opensearch_enable_auth 1
# bin/magento config:set catalog/search/opensearch_username admin
# bin/magento config:set catalog/search/opensearch_password 'your-strong-password'

# 4) rebuild the search index and flush
bin/magento indexer:reindex catalogsearch_fulltext
bin/magento cache:flush

Then go back to Stores > Configuration > Catalog > Catalog Search and click Test Connection. A green result plus a clean reindex means you are done. If the reindex still complains about a stuck or locked indexer, reset and rebuild it, which is one of the recovery steps in this guide to Magento 2 reindexing and index management.

What changed in 2.4.6: Elasticsearch removed

Through 2.4.4 and 2.4.5 you could choose Elasticsearch 7, Elasticsearch 8, or OpenSearch in the engine dropdown. From 2.4.6 Adobe made OpenSearch the default and the only engine it tests and supports, and the bundled Elasticsearch adapter is gone. That is why an in-place upgrade to 2.4.6 or newer, carrying an old elasticsearch7 value in the database, throws the connection error on the first reindex: the engine it names no longer exists in core.

You can still point Magento at an Elasticsearch 7 or 8 node through the OpenSearch-compatible client in some setups, because the wire protocols overlap, but it is not the supported path and Adobe does not test it. For anything you have to keep running to 2.4.9 and beyond, run OpenSearch 2.x. It is the engine the platform is built and tested against, and it takes the guesswork out of every future patch.