How to check Elasticsearch remote cluster connections

Remote cluster connections keep Cross-Cluster Search and Cross-Cluster Replication from turning into partial results, delayed follower indices, or hard-to-trace timeouts. A fast connection check confirms the local cluster can still reach the remote before queries or replication depend on it.

Remote clusters are defined by a configured alias and a set of seed endpoints, then maintained as persistent transport connections (typically on 9300) from nodes allowed to act as remote-cluster clients. The _remote/info API reports the live state per alias, including whether the remote is currently connected and how many remote nodes are connected.

Firewall rules, DNS drift, TLS trust mismatches, and authentication failures are the most common causes of disconnected remotes showing zero connected nodes. Some environments also set skip_unavailable, which can make cross-cluster searches appear “fine” while silently skipping an unreachable remote, so reading _remote/info is a reliable first check.

1. Query the remote cluster connection state from a local Elasticsearch node.

   $ curl --silent --show-error "http://localhost:9200/_remote/info?pretty"
   {
     "dr-site" : {
       "connected" : true,
       "mode" : "sniff",
       "seeds" : [
         "192.0.2.51:9300",
         "192.0.2.52:9300"
       ],
       "num_nodes_connected" : 2,
       "max_connections_per_cluster" : 3,
       "initial_connect_timeout" : "30s",
       "skip_unavailable" : true
     }
   }

   Placing passwords directly in the command line can leak into shell history and process listings.

   Security-disabled clusters can drop --user and --cacert while using http://localhost:9200, and an empty {} response indicates no remote clusters are configured.

2. Reduce the output to connectivity fields when scanning multiple remotes.

   $ curl --silent --show-error "http://localhost:9200/_remote/info?pretty&filter_path=*.connected,*.num_nodes_connected,*.skip_unavailable,*.seeds"
   {
     "dr-site" : {
       "connected" : true,
       "num_nodes_connected" : 2,
       "skip_unavailable" : true,
       "seeds" : [
         "192.0.2.51:9300",
         "192.0.2.52:9300"
       ]
     }
   }

   When skip_unavailable is true, cross-cluster searches can return results without error while omitting data from an unavailable remote.

3. Test TCP reachability to each remote seed host on the transport port.

   $ nc -vz -w 3 192.0.2.51 9300
   Connection to 192.0.2.51 9300 port [tcp/*] succeeded!
   $ nc -vz -w 3 192.0.2.52 9300
   Connection to 192.0.2.52 9300 port [tcp/*] succeeded!

   Remote cluster links use the transport protocol on 9300, not the HTTP API port on 9200.

4. Inspect the local node logs for remote cluster connection and handshake errors.

   $ sudo grep -i "remote cluster" /var/log/elasticsearch/search-cluster.log | tail -n 4
   [2026-01-08T02:57:40,269][WARN ][o.e.t.RemoteClusterService] [node-01] failed to update remote cluster connection [dr-site]
   [2026-01-08T04:04:16,208][WARN ][o.e.t.RemoteClusterService] [node-01] failed to update remote cluster connection [dr-site] within 10s
   [2026-01-08T04:04:36,218][WARN ][o.e.t.RemoteClusterService] [node-01] failed to update remote cluster connection [dr-site]
   [2026-01-08T04:05:51,992][WARN ][o.e.a.a.c.s.TransportClusterStatsAction] [node-01] Failed to get remote cluster stats for [dr-site]: org.elasticsearch.transport.ConnectTransportException: [][203.0.113.50:9300] connect_timeout[30s]

   File-based logs are commonly written under /var/log/elasticsearch/elasticsearch.log when the service is not configured to forward logs to the systemd journal.

5. Confirm the remote cluster reports as connected after network or security changes.

   $ curl --silent --show-error "http://localhost:9200/_remote/info?pretty&filter_path=*.connected,*.num_nodes_connected"
   {
     "dr-site" : {
       "connected" : true,
       "num_nodes_connected" : 2
     }
   }