How to check Elasticsearch remote cluster connections

Checking Elasticsearch remote cluster connections confirms whether a local cluster currently has an open path to a configured remote alias before cross-cluster search or cross-cluster replication depends on it. It catches endpoint, security, and optional-remote problems that can otherwise make remote data disappear from a search result or leave follower indices unable to advance.

The remote cluster info API, _remote/info, reports connection state from the local cluster's view. Each alias shows its connection mode, endpoint fields, connected node or proxy socket counts, skip_unavailable behavior, and, for API-key remotes, the cluster_credentials marker.

The connected field means Elasticsearch has an open remote connection now; it does not prove that a target index exists or that the requesting user has remote_indices privileges. Use the same local endpoint, credentials, and HTTPS trust path that operators use for CCS or CCR requests, and remember that certificate-based remote-cluster security was deprecated in Elasticsearch 9.0 while API-key remotes use the dedicated remote-cluster interface on 9443 by default.

1. Query remote cluster information from a local Elasticsearch node.

   $ curl --silent --show-error --user elastic:strong-password "https://local-es.example.net:9200/_remote/info?pretty"
   {
     "dr-site" : {
       "connected" : true,
       "mode" : "sniff",
       "seeds" : [
         "remote-es.example.net:9443"
       ],
       "num_nodes_connected" : 1,
       "max_connections_per_cluster" : 3,
       "initial_connect_timeout" : "30s",
       "skip_unavailable" : false,
       "cluster_credentials" : "::es_redacted::"
     }
   }

   The request needs the cluster monitor privilege on secured clusters. The cluster_credentials marker means the remote alias is using API-key authentication; a missing marker usually means certificate-based authentication.

2. Reduce the response to the connection fields when several aliases are configured.

   $ curl --silent --show-error --user elastic:strong-password "https://local-es.example.net:9200/_remote/info?pretty&filter_path=*.connected,*.mode,*.skip_unavailable,*.num_nodes_connected,*.num_proxy_sockets_connected,*.seeds,*.proxy_address,*.cluster_credentials"
   {
     "dr-site" : {
       "connected" : true,
       "mode" : "sniff",
       "skip_unavailable" : false,
       "num_nodes_connected" : 1,
       "seeds" : [
         "remote-es.example.net:9443"
       ],
       "cluster_credentials" : "::es_redacted::"
     }
   }

   Since Elasticsearch 8.15, a remote alias without an explicit skip_unavailable setting is treated as optional for cross-cluster search. Required remotes should show skip_unavailable: false.

   Proxy mode reports proxy_address and num_proxy_sockets_connected instead of the sniff-mode seed and node count fields.

3. Test TCP reachability to the exact remote endpoint shown for the alias.

   $ nc -vz -w 3 remote-es.example.net 9443
   Ncat: Version 7.92 ( https://nmap.org/ncat )
   Ncat: Connected to 203.0.113.50:9443.
   Ncat: 0 bytes sent, 0 bytes received in 0.02 seconds.

   Use proxy_address for proxy mode or a seed host for sniff mode. API-key remotes use the remote-cluster server port 9443 by default; legacy certificate-based remotes usually use the transport port 9300.

4. Trigger a fresh resolve check for the remote index pattern that should be reachable.

   $ curl --silent --show-error --user elastic:strong-password "https://local-es.example.net:9200/_resolve/cluster/dr-site:logs-*?pretty&timeout=5s&filter_path=dr-site.connected,dr-site.skip_unavailable,dr-site.matching_indices,dr-site.version.number"
   {
     "dr-site" : {
       "connected" : true,
       "skip_unavailable" : false,
       "matching_indices" : true,
       "version" : {
         "number" : "9.4.2"
       }
     }
   }

   The _resolve/cluster request can trigger a reconnect attempt when _remote/info is stale. matching_indices: false with connected: true points to an index-pattern or privilege issue rather than a remote-cluster connection failure.

5. Inspect local Elasticsearch logs when an alias is disconnected or the resolve check fails.

   $ sudo grep --ignore-case --extended-regexp 'remote cluster|connect_exception|failed to establish trust|closed by remote|RemoteClusterService|SniffConnectionStrategy|ProxyConnectionStrategy' /var/log/elasticsearch/elasticsearch.log
   [2026-06-18T04:46:04,154][WARN ][o.e.d.t.RemoteConnectionManager] [local-es-01] The remote cluster connection to [dr-site] is using the certificate-based security model. The certificate-based security model is deprecated.
   [2026-06-18T04:46:04,201][INFO ][o.e.t.RemoteClusterService] [local-es-01] remote cluster connection [dr-site] updated: CONNECTED

   connect_exception usually points to host, port, routing, or firewall trouble. failed to establish trust points to a TLS CA or certificate mismatch. API-key problems commonly mention the wrong key type or an authentication failure.

   Official packages write application logs under /var/log/elasticsearch by default. Use journalctl with --unit elasticsearch.service and --grep only when the service is configured to send application logs to the systemd journal.
   Related: How to manage the Elasticsearch service with systemctl in Linux