Elasticsearch network.host Setting

network.host is the default bind address for both the HTTP layer (port 9200, client traffic) and the transport layer (port 9300, inter-node traffic). It is the single most consequential network setting in Elasticsearch: changing it from the default loopback to a non-loopback address moves the node from development mode to production mode, which activates the bootstrap checks. The setting accepts IPs, hostnames, interface names, and several special values.

• Default: Loopback addresses only - _local_ (127.0.0.1 and [::1])
• Scope: Per-node, static - configured in elasticsearch.yml, requires restart
• Possible values: IP address, hostname, interface name (_eth0_), or special values

Special Values

These shortcuts let one config file work across hosts with different IPs - useful for golden images and automation.

How network.host Interacts with Other Settings

network.host is a default that more specific settings override:

Common production patterns:

# Single NIC, everything together
network.host: 10.0.5.12

# Separate networks for client and cluster
http.host: 0.0.0.0
transport.host: 10.0.5.12

# Cloud with auto-discovery
network.host: _site_

The Production-Mode Trigger

Binding to any non-loopback address activates Elasticsearch's production-mode bootstrap checks. The cluster will refuse to start if any check fails:

• Heap size sane (-Xms == -Xmx)
• File descriptors limit raised
• vm.max_map_count raised (Linux)
• Memory locking succeeded if requested
• Cluster bootstrapping config present (8.x+)

This is intentional. The bootstrap checks exist precisely because a node bound to a non-loopback address is exposed to other workloads on the network. Setting network.host: 0.0.0.0 and accepting the checks is the canonical way to deploy a production node.

Common Pitfalls

1. Setting network.host: 0.0.0.0 on a public-facing host without TLS and authentication. The cluster ends up indexed by Shodan within hours.
2. Setting network.host: localhost in a multi-node cluster. Each node binds to its own loopback and cannot reach peers.
3. Mixing network.host, http.host, and transport.host inconsistently across cluster nodes. Some peers can connect, others can't.
4. Forgetting that hostnames in network.host are resolved at startup, not on each connection. DNS changes don't propagate until restart.

Production Recommendations

1. Bind transport to the private cluster network only: transport.host: 10.0.5.12.
2. Bind HTTP to the client-facing network with TLS enabled.
3. Always enable security (xpack.security.enabled: true).
4. Use a firewall to limit who can reach port 9200 and 9300 even when bound to public interfaces.
5. Confirm publish addresses match what peers can reach.

Pulse flags network configuration mismatches - cluster nodes with inconsistent bind addresses, public-facing HTTP without auth, transport bound to public interfaces - before they cause an incident or end up as a security advisory.

Frequently Asked Questions

Q: What is the default value of network.host in Elasticsearch?
A: The default is _local_, which binds to loopback addresses (127.0.0.1 and [::1]). The node is only reachable from the same host. Changing it to a non-loopback value moves the node into production mode.

Q: How do I make Elasticsearch listen on all network interfaces?
A: Set network.host: 0.0.0.0 (or [::] for IPv4+IPv6) in elasticsearch.yml and restart. The node will then pass through production-mode bootstrap checks - heap, file descriptors, vm.max_map_count, and others - which must all pass for startup to succeed.

Q: What's the difference between network.host, http.host, and transport.host?
A: network.host is the default for both HTTP (port 9200) and transport (port 9300). http.host and transport.host override the default for each layer independently. Use the layer-specific settings when you need different bind addresses.

Q: Can I use a hostname for network.host?
A: Yes. Elasticsearch resolves the hostname at startup. Be aware that DNS changes don't take effect until restart - static IPs are more predictable in production.

Q: Is network.host: 0.0.0.0 safe?
A: Only with TLS, authentication, and firewall rules. Binding to all interfaces exposes the node to every network it can reach. Production-mode bootstrap checks raise the bar but don't replace network controls.

Q: Why does Elasticsearch fail to start after changing network.host?
A: Switching from loopback to a routable address triggers production-mode bootstrap checks. Common failure causes: -Xms and -Xmx not equal, file descriptor limit below 65535, vm.max_map_count below 262144 (Linux), or bootstrap.memory_lock: true without the memlock ulimit raised.

Related Reading

• Elasticsearch transport.host Setting: Transport-layer bind
• Elasticsearch transport.publish_host Setting: Advertised transport address
• Elasticsearch bootstrap.memory_lock Setting: Lock heap in RAM
• Elasticsearch Disable Security: Security implications
• Elasticsearch Master Not Discovered Diagnosis: Discovery troubleshooting