Elasticsearch transport.host Setting

Q: What is the difference between transport.host and network.host in Elasticsearch?

transport.host binds the inter-node transport layer (port 9300). network.host is a fallback default for both transport and HTTP. Set them independently to separate cluster traffic from client traffic on a multi-homed host.

Q: What is the difference between transport.host and http.host?

transport.host is for node-to-node communication on port 9300. http.host is for client REST traffic on port 9200. They can bind to different interfaces and are configured independently.

Q: Can I bind transport.host to multiple addresses?

Yes - pass an array: transport.host: ["10.0.5.12", "_local_"] . The node listens on all listed addresses for inter-node connections.

transport.host controls which network interface Elasticsearch uses for the transport layer - the internal binary protocol nodes use to communicate with each other on port 9300. The setting governs inter-node traffic only; it is independent from http.host, which controls the REST API. By default Elasticsearch falls back to network.host; setting transport.host explicitly is the right move on multi-homed hosts, in containers, and anywhere the cluster network should be separate from client traffic.

Default: Inherits from network.host; ultimately binds to local addresses if neither is set
Possible values: IP address, hostname, network interface name, or special values like _local_, _site_, _global_, _eth0_
Scope: Per-node, static - requires a restart to change

How transport.host Works

Elasticsearch maintains two network stacks: HTTP (REST API, port 9200) and transport (binary, port 9300). The transport layer carries cluster state, shard requests, replication, and search fan-out traffic. Latency on this layer directly affects search and indexing throughput.

If transport.host is set, the node listens for transport connections only on the specified interface(s). If only network.host is set, both HTTP and transport bind there. Setting both lets you serve client HTTP traffic on one network and cluster traffic on another - the recommended production layout.

Configuring transport.host

In elasticsearch.yml:

transport.host: 10.0.5.12

Or use a special value:

transport.host: _site_   # First site-local (RFC 1918) address

Or an interface name:

transport.host: _eth1_   # IP of eth1 interface

The setting accepts an array for binding to multiple addresses:

transport.host: ["10.0.5.12", "_local_"]

Setting	Purpose
`transport.host`	Transport-layer bind address (port 9300, inter-node)
`transport.publish_host`	Address advertised to peer nodes for connect-back
`http.host`	HTTP-layer bind address (port 9200, client traffic)
`network.host`	Fallback default for both `transport.host` and `http.host`
`transport.port`	Transport port, default 9300

In a multi-homed host with one private and one public NIC, the production pattern is:

http.host: 0.0.0.0          # Allow clients on any interface (with TLS+auth)
transport.host: 10.0.5.12   # Cluster traffic stays on private NIC

Common Pitfalls

Binding transport.host to a public IP. Inter-node transport is unauthenticated by default until TLS is configured; exposing it on the internet is a critical vulnerability.
Setting transport.host: 127.0.0.1 on a multi-node cluster. Nodes can't reach each other - the cluster won't form.
Hostname mismatches across nodes. If one node advertises 10.0.5.12 and another resolves the same name to a different address, discovery fails inconsistently.
Forgetting to update firewall rules. Changing the bind address without opening port 9300 on the new interface leaves the node unreachable.

Operating transport.host

Verify the active transport bind:

GET /_nodes/_local?filter_path=**.transport_address,**.host

Pulse monitors transport-layer latency and connectivity between every pair of nodes. When a configuration change leaves a node bound to the wrong interface or unable to reach a peer, Pulse flags the connectivity gap before the cluster splits or shards go unassigned.

Frequently Asked Questions

Q: What is the difference between transport.host and network.host in Elasticsearch?
A: transport.host binds the inter-node transport layer (port 9300). network.host is a fallback default for both transport and HTTP. Set them independently to separate cluster traffic from client traffic on a multi-homed host.

Q: What is the difference between transport.host and http.host?
A: transport.host is for node-to-node communication on port 9300. http.host is for client REST traffic on port 9200. They can bind to different interfaces and are configured independently.

Q: Can I bind transport.host to multiple addresses?
A: Yes - pass an array: transport.host: ["10.0.5.12", "_local_"]. The node listens on all listed addresses for inter-node connections.

Q: Do I need to restart Elasticsearch after changing transport.host?
A: Yes. transport.host is a static setting and applies only at node startup. Do a rolling restart to apply the change without losing cluster availability.

Q: Is it safe to bind transport.host to 0.0.0.0?
A: Only behind a firewall with TLS enabled. The transport layer is unauthenticated until you configure security, so binding it to all interfaces (including a public one) is a critical risk.

Q: What's a typical production transport.host configuration?
A: Bind transport.host to the private cluster network address and http.host to the client-facing network. Combine with transport.publish_host if NAT or container networking means the bind address differs from the address peers should use.

Elasticsearch transport.publish_host Setting: Advertised transport address
Elasticsearch network.host Setting: Default bind address
Elasticsearch Discovery Seed Hosts: Cluster formation
Elasticsearch Master Not Discovered Diagnosis: Discovery failures
Elasticsearch Transport Compress: Compression on transport