How to check Elasticsearch remote cluster connections

Remote cluster connectivity determines whether cross-cluster search and cross-cluster replication can still reach data outside the local deployment, so checking it early helps avoid silent gaps, stalled follower indices, and misleading partial results during incidents or change windows.

In Elasticsearch, each remote is configured under a local alias and contacted over either sniff or proxy mode. The remote cluster info API on the local cluster returns the current connection state for each alias along with the configured endpoint data, the connection mode, the connected node or socket counts, and whether the remote is treated as optional for search requests.

The _remote/info result reflects the current state on the local cluster rather than a fresh availability probe, so a disconnected alias can remain connected: false until a new cross-cluster request or _resolve/cluster attempt triggers a reconnect. Requests to this API need the cluster monitor privilege on secured clusters, nodes that originate CCS or CCR traffic must keep the remote_cluster_client role, and the endpoint or port must match the remote security model: certificate-based remotes commonly use the transport interface on 9300, while API-key remotes use the dedicated remote-cluster server interface on 9443 unless that port is overridden.

Steps to check Elasticsearch remote cluster connections:

Query the current remote-cluster state from a local Elasticsearch node.

$ curl --silent --show-error "http://localhost:9200/_remote/info?pretty"
{
  "dr-site" : {
    "seeds" : [
      "203.0.113.50:9443"
    ],
    "connected" : true,
    "mode" : "sniff",
    "num_nodes_connected" : 1,
    "max_connections_per_cluster" : 3,
    "initial_connect_timeout" : "30s",
    "skip_unavailable" : true,
    "cluster_credentials" : "::es_redacted::"
  }
}

On secured clusters, use HTTPS and authenticate as a user or API key with the cluster monitor privilege. When cluster_credentials is present, the remote cluster is using API key authentication.

Reduce the output to connection fields when checking several aliases at once.

$ curl --silent --show-error "http://localhost: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" : true,
    "num_nodes_connected" : 1,
    "seeds" : [
      "203.0.113.50:9443"
    ],
    "cluster_credentials" : "::es_redacted::"
  }
}

Since Elasticsearch 8.15, remote clusters default to skip_unavailable: true unless the setting is pinned explicitly on the local cluster, so a search can still return results while omitting an unavailable remote.

Proxy-mode remotes report proxy_address and num_proxy_sockets_connected instead of the sniff-mode seed and node counts.

Test TCP reachability to the exact seed or proxy endpoint reported for the remote alias.
```
$ nc -vz -w 3 203.0.113.50 9443
Connection to 203.0.113.50 9443 port [tcp/*] succeeded!
```
Use the same host and port shown in _remote/info. Certificate-based remotes usually listen on 9300, while API-key remotes use the remote-cluster server port 9443 unless the remote cluster overrides remote_cluster.port.

Inspect recent local node logs for remote handshake, trust, or connection-close failures.

$ sudo journalctl --unit=elasticsearch.service --since "15 minutes ago" --no-pager | grep --ignore-case --extended-regexp 'remote cluster|connect_exception|failed to establish trust|closed by remote'
[2026-04-02T10:14:42,318][WARN ][o.e.c.s.DiagnosticTrustManager] [node-01] failed to establish trust with server at [203.0.113.50:9443]
[2026-04-02T10:14:42,320][WARN ][o.e.t.SniffConnectionStrategy] [node-01] fetching nodes from external cluster [dr-site] failed
org.elasticsearch.transport.ConnectTransportException: [][203.0.113.50:9443] connect_exception

failed to establish trust with server usually points to a TLS CA or certificate mismatch, while connect_exception is more commonly a host, port, routing, or firewall problem. If the package writes file logs instead of journal entries, search the active log under /var/log/elasticsearch for the same messages.

Re-check the alias after correcting routing, TLS, or remote-cluster-server settings.
```
$ curl --silent --show-error "http://localhost:9200/_remote/info?pretty&filter_path=*.connected,*.mode,*.num_nodes_connected,*.num_proxy_sockets_connected,*.cluster_credentials"
{
  "dr-site" : {
    "connected" : true,
    "mode" : "sniff",
    "num_nodes_connected" : 1,
    "cluster_credentials" : "::es_redacted::"
  }
}
```
If the alias still shows connected: false, run a fresh cross-cluster request or GET /_resolve/cluster/*:* from an account allowed to resolve remote indices to trigger another connection attempt, then compare the new response with the local log messages.