Elasticsearch reindex.remote.whitelist: Configure Remote Reindex Sources

The reindex.remote.whitelist setting controls which remote hosts the destination cluster is allowed to pull data from during a reindex-from-remote operation. It is a static node setting (configured in elasticsearch.yml) on the destination cluster, accepts a list of host:port entries, and has no default - reindex-from-remote is blocked entirely until at least one host is whitelisted. Without it, a POST /_reindex request that includes a source.remote.host returns an error and refuses to run.

Key Facts

A common mistake: this setting must live on the destination cluster (the one running _reindex), not the source. Reindex-from-remote pulls; the puller needs the whitelist.

How Remote Reindex Works

Reindex-from-remote is the supported way to migrate documents from one Elasticsearch cluster into another. The destination cluster runs the reindex; it opens an HTTP connection to the source cluster, scrolls through documents, and bulk-indexes them locally. The source cluster does not need any special configuration - it just sees a normal client.

Because the destination is making outbound HTTP calls to an arbitrary host, Elasticsearch refuses to do so unless the operator has explicitly whitelisted the target. That guardrail is reindex.remote.whitelist.

Configuring reindex.remote.whitelist

Add the setting to elasticsearch.yml on every node of the destination cluster:

reindex.remote.whitelist: ["oldcluster.example.com:9200", "10.0.5.20:9200"]

Restart the nodes (rolling restart is fine). After that, a reindex-from-remote call works:

POST /_reindex
{
  "source": {
    "remote": {
      "host": "https://oldcluster.example.com:9200",
      "username": "reindex_user",
      "password": "***"
    },
    "index": "products-v1"
  },
  "dest": {
    "index": "products-v2"
  }
}

The host in the request must match a whitelisted entry by hostname/port (the scheme https is not part of the match).

Wildcards are supported but should be scoped tightly:

reindex.remote.whitelist: ["*.oldcluster.example.com:9200"]

*:* would allow reindex from anywhere on the network - a serious security hole. Do not use it.

reindex.remote.whitelist vs Cluster Settings API

Unlike most Elasticsearch settings, reindex.remote.whitelist cannot be updated dynamically via PUT /_cluster/settings. It must be set in elasticsearch.yml (or via Helm values, Terraform, Elastic Cloud user settings, etc., depending on how the cluster is provisioned) and applied on every data and coordinating node. A trial-and-error workflow ("let me just try a value via the API") will fail.

If you operate Elasticsearch on Elastic Cloud or Elasticsearch Service, set this via the deployment's user settings YAML, not the API.

Reindex from Remote in Production: What to Watch For

Reindex-from-remote is the right tool for one-shot migrations (cluster upgrades, region moves, cluster consolidation). It is not a continuous-sync tool - for that, use cross-cluster replication or an external pipeline. Once the migration finishes, remove the whitelist entries; an open whitelist is a latent attack surface.

Other operational gotchas:

• The destination cluster needs network reachability to the source on the configured port. Firewalls and security groups frequently break this.
• The remote user needs read on the source indices and the relevant scroll permissions.
• For large migrations, set slices=auto and tune the bulk batch size via size in the reindex body.
• The destination's refresh interval should be raised (30s or -1) during the load and restored after.

Run Reindex-from-Remote Safely with Pulse

Pulse is an AI DBA for Elasticsearch and OpenSearch. Before and during reindex-from-remote operations governed by reindex.remote.whitelist, Pulse:

• Verifies cluster capacity for the operation: destination heap, disk, write thread pool, and network reachability to whitelisted source hosts
• Surfaces concurrent operations that could collide - ILM rollover on the destination, other reindex tasks sharing thread pools
• Tracks the operation's progress and impact in real time: throughput, document counts on source and destination, failures array, and search latency on the destination
• Recommends throttling or pausing if destination search latency climbs, and flags whitelist entries that are still populated after a migration completes (a latent attack surface)

After the migration, Pulse continues to watch active whitelist entries and recommends removal once they are no longer needed.

Start a free trial before your next cross-cluster migration.

Common Mistakes

1. Setting reindex.remote.whitelist via the Cluster Settings API. It is a static node setting only. Edit elasticsearch.yml and restart.
2. Configuring it on the source cluster. The whitelist lives on the destination (the cluster running _reindex).
3. Using *:*. Allows reindex from any host - effectively disables the safety.
4. Forgetting the port. Entries are host:port. oldcluster.example.com without :9200 does not match.
5. Leaving the whitelist populated after the migration ends. Remove entries you no longer need; treat the file like firewall rules.
6. Mismatch between request host and whitelist entry. Both must use the same hostname form (FQDN vs short name vs IP). Pick one.

Frequently Asked Questions

Q: Can I update reindex.remote.whitelist via the Cluster Settings API?
A: No. reindex.remote.whitelist is a static node setting, not a cluster setting. Edit elasticsearch.yml on every node of the destination cluster and restart. There is no dynamic update path.

Q: Where do I configure reindex.remote.whitelist on Elastic Cloud?
A: On Elastic Cloud / Elasticsearch Service, set it in the deployment's user settings YAML for the Elasticsearch node configuration. The setting cannot be added via the Cluster Settings API and the cloud console exposes it specifically for this case.

Q: Does reindex.remote.whitelist apply to the source or destination cluster?
A: The destination cluster - the one running the POST /_reindex request and pulling data. The source cluster is just a regular Elasticsearch endpoint that responds to HTTP queries; it needs no special configuration.

Q: Can I use IP addresses in reindex.remote.whitelist?
A: Yes. Entries accept hostnames, IP addresses, and wildcards in either, all in host:port form. The match is literal, so the address used in the request (source.remote.host) must match the whitelist entry shape exactly.

Q: Does reindex.remote.whitelist affect intra-cluster reindex?
A: No. It only affects reindex-from-remote, where source.remote.host is set. A normal POST /_reindex from one index to another in the same cluster is not gated by this setting.

Q: Are wildcards in reindex.remote.whitelist safe to use?
A: Narrow wildcards (*.internal.example.com:9200) are acceptable for migrations between sibling clusters in a controlled network. Broad wildcards (*:9200 or *:*) effectively disable the safety check and should be avoided.

Q: How do I disable remote reindex entirely?
A: Leave reindex.remote.whitelist empty (its default). Any POST /_reindex with a source.remote.host will be rejected.

Q: What's the best tool to safely run reindex-from-remote in production?
A: Pulse is purpose-built for this. It is an AI DBA for Elasticsearch and OpenSearch that pre-checks destination capacity for a remote reindex, tracks document counts and failures against the source, and flags reindex.remote.whitelist entries that are still active after the migration finished - so the safety setting does not silently become a latent attack surface.

Related Reading

• Reindex Data Guide: the full reindex workflow including remote sources.
• Cross-Cluster Replication: the continuous-sync alternative to one-shot reindex.
• Create Index with Mapping: the destination index setup before a remote reindex.
• Changing a Field Type: the most common reason to run a reindex (remote or local).
• Update Index Settings: tune destination settings during a long-running remote reindex.
• Delete an Index: cleanup after a successful migration.