[[modules-network]] === Networking Each {es} node has two different network interfaces. Clients send requests to {es}'s REST APIs using its <>, but nodes communicate with other nodes using the <>. The transport interface is also used for communication with <>. The transport interface uses a custom binary protocol sent over <> TCP channels. Both interfaces can be configured to use <>. You can configure both of these interfaces at the same time using the `network.*` settings. If you have a more complicated network, you might need to configure the interfaces independently using the `http.*` and `transport.*` settings. Where possible, use the `network.*` settings that apply to both interfaces to simplify your configuration and reduce duplication. By default {es} binds only to `localhost` which means it cannot be accessed remotely. This configuration is sufficient for a local development cluster made of one or more nodes all running on the same host. To form a cluster across multiple hosts, or which is accessible to remote clients, you must adjust some <> such as `network.host`. [WARNING] .Be careful with the network configuration! ============================= Never expose an unprotected node to the public internet. If you do, you are permitting anyone in the world to download, modify, or delete any of the data in your cluster. ============================= Configuring {es} to bind to a non-local address will <>. If a node refuses to start after configuring its network settings then you must address the logged exceptions before proceeding. [[common-network-settings]] ==== Commonly used network settings Most users will need to configure only the following network settings. `network.host`:: (<>, string) Sets the address of this node for both HTTP and transport traffic. The node will bind to this address and will also use it as its publish address. Accepts an IP address, a hostname, or a <>. + Defaults to `_local_`. However, note that <> will add `http.host: 0.0.0.0` to your `elasticsearch.yml` configuration file, which overrides this default for HTTP traffic. `http.port`:: (<>, integer) The port to bind for HTTP client communication. Accepts a single value or a range. If a range is specified, the node will bind to the first available port in the range. + Defaults to `9200-9300`. `transport.port`:: (<>, integer) The port to bind for communication between nodes. Accepts a single value or a range. If a range is specified, the node will bind to the first available port in the range. Set this setting to a single port, not a range, on every master-eligible node. + Defaults to `9300-9400`. [[remote_cluster.port]] `remote_cluster.port`:: (<>, integer) The port to bind for remote cluster client communication. Accepts a single value. + Defaults to `9443`. [[network-interface-values]] ==== Special values for network addresses You can configure {es} to automatically determine its addresses by using the following special values. Use these values when configuring `network.host`, `network.bind_host`, `network.publish_host`, and the corresponding settings for the HTTP and transport interfaces. `_local_`:: Any loopback addresses on the system, for example `127.0.0.1`. `_site_`:: Any site-local addresses on the system, for example `192.168.0.1`. `_global_`:: Any globally-scoped addresses on the system, for example `8.8.8.8`. `_[networkInterface]_`:: Use the addresses of the network interface called `[networkInterface]`. For example if you wish to use the addresses of an interface called `en0` then set `network.host: _en0_`. `0.0.0.0`:: The addresses of all available network interfaces. NOTE: In some systems these special values resolve to multiple addresses. If so, {es} will select one of them as its publish address and may change its selection on each node restart. Ensure your node is accessible at every possible address. NOTE: Any values containing a `:` (e.g. an IPv6 address or some of the <>) must be quoted because `:` is a special character in YAML. [[network-interface-values-ipv4-vs-ipv6]] ===== IPv4 vs IPv6 These special values yield both IPv4 and IPv6 addresses by default, but you can also add an `:ipv4` or `:ipv6` suffix to limit them to just IPv4 or IPv6 addresses respectively. For example, `network.host: "_en0:ipv4_"` would set this node's addresses to the IPv4 addresses of interface `en0`. [TIP] .Discovery in the Cloud ================================ More special settings are available when running in the Cloud with either the {plugins}/discovery-ec2.html[EC2 discovery plugin] or the {plugins}/discovery-gce-network-host.html#discovery-gce-network-host[Google Compute Engine discovery plugin] installed. ================================ [[modules-network-binding-publishing]] ==== Binding and publishing {es} uses network addresses for two distinct purposes known as binding and publishing. Most nodes will use the same address for everything, but more complicated setups may need to configure different addresses for different purposes. When an application such as {es} wishes to receive network communications, it must indicate to the operating system the address or addresses whose traffic it should receive. This is known as _binding_ to those addresses. {es} can bind to more than one address if needed, but most nodes only bind to a single address. {es} can only bind to an address if it is running on a host that has a network interface with that address. If necessary, you can configure the transport and HTTP interfaces to bind to different addresses. Each {es} node has an address at which clients and other nodes can contact it, known as its _publish address_. Each node has one publish address for its HTTP interface and one for its transport interface. These two addresses can be anything, and don't need to be addresses of the network interfaces on the host. The only requirements are that each node must be: * Accessible at its HTTP publish address by all clients that will discover it using sniffing. * Accessible at its transport publish address by all other nodes in its cluster, and by any remote clusters that will discover it using <>. Each node must have its own distinct publish address. If you specify the transport publish address using a hostname then {es} will resolve this hostname to an IP address once during startup, and other nodes will use the resulting IP address instead of resolving the name again themselves. You must use a hostname such that all of the addresses to which it resolves are addresses at which the node is accessible from all other nodes. To avoid confusion, it is simplest to use a hostname which resolves to a single address. If you specify the transport publish address using a <> then {es} will resolve this value to a single IP address during startup, and other nodes will use the resulting IP address instead of resolving the value again themselves. You must use a value such that all of the addresses to which it resolves are addresses at which the node is accessible from all other nodes. To avoid confusion, it is simplest to use a value which resolves to a single address. It is usually a mistake to use `0.0.0.0` as a publish address on hosts with more than one network interface. ===== Using a single address The most common configuration is for {es} to bind to a single address at which it is accessible to clients and other nodes. To use this configuration, set only `network.host` to the desired address. Do not separately set any bind or publish addresses. Do not separately specify the addresses for the HTTP or transport interfaces. ===== Using multiple addresses Use the <> if you wish to bind {es} to multiple addresses, or to publish a different address from the addresses to which you are binding. Set `network.bind_host` to the bind addresses, and `network.publish_host` to the address at which this node is exposed. In complex configurations, you can configure these addresses differently for the HTTP and transport interfaces. [[advanced-network-settings]] ==== Advanced network settings These advanced settings let you bind to multiple addresses, or to use different addresses for binding and publishing. They are not required in most cases and you should not use them if you can use the <> instead. `network.bind_host`:: (<>, string) The network address(es) to which the node should bind in order to listen for incoming connections. Accepts a list of IP addresses, hostnames, and <>. Defaults to the address given by `network.host`. Use this setting only if binding to multiple addresses or using different addresses for publishing and binding. `network.publish_host`:: (<>, string) The network address that clients and other nodes can use to contact this node. Accepts an IP address, a hostname, or a <>. Defaults to the address given by `network.host`. Use this setting only if binding to multiple addresses or using different addresses for publishing and binding. NOTE: You can specify a list of addresses for `network.host` and `network.publish_host`. You can also specify one or more hostnames or <> that resolve to multiple addresses. If you do this then {es} chooses one of the addresses for its publish address. This choice uses heuristics based on IPv4/IPv6 stack preference and reachability and may change when the node restarts. Ensure each node is accessible at all possible publish addresses. [[tcp-settings]] ===== Advanced TCP settings Use the following settings to control the low-level parameters of the TCP connections used by the HTTP and transport interfaces. `network.tcp.keep_alive`:: (<>, boolean) Configures the `SO_KEEPALIVE` option for network sockets, which determines whether each connection sends TCP keepalive probes. Defaults to `true`. `network.tcp.keep_idle`:: (<>, integer) Configures the `TCP_KEEPIDLE` option for network sockets, which determines the time in seconds that a connection must be idle before starting to send TCP keepalive probes. Defaults to `-1`, which means to use the system default. This value cannot exceed `300` seconds. Only applicable on Linux and macOS. `network.tcp.keep_interval`:: (<>, integer) Configures the `TCP_KEEPINTVL` option for network sockets, which determines the time in seconds between sending TCP keepalive probes. Defaults to `-1`, which means to use the system default. This value cannot exceed `300` seconds. Only applicable on Linux and macOS. `network.tcp.keep_count`:: (<>, integer) Configures the `TCP_KEEPCNT` option for network sockets, which determines the number of unacknowledged TCP keepalive probes that may be sent on a connection before it is dropped. Defaults to `-1`, which means to use the system default. Only applicable on Linux and macOS. `network.tcp.no_delay`:: (<>, boolean) Configures the `TCP_NODELAY` option on network sockets, which determines whether {wikipedia}/Nagle%27s_algorithm[TCP no delay] is enabled. Defaults to `true`. `network.tcp.reuse_address`:: (<>, boolean) Configures the `SO_REUSEADDR` option for network sockets, which determines whether the address can be reused or not. Defaults to `false` on Windows and `true` otherwise. `network.tcp.send_buffer_size`:: (<>, <>) Configures the size of the TCP send buffer for network sockets. Defaults to `-1` which means to use the system default. `network.tcp.receive_buffer_size`:: (<>, <>) Configures the size of the TCP receive buffer. Defaults to `-1` which means to use the system default. include::http.asciidoc[] include::transport.asciidoc[] include::remote-cluster-network.asciidoc[] include::network/tracers.asciidoc[] include::network/threading.asciidoc[] [[readiness-tcp-port]] ==== TCP readiness port preview::[] If configured, a node can open a TCP port when the node is in a ready state. A node is deemed ready when it has successfully joined a cluster. In a single node configuration, the node is said to be ready, when it's able to accept requests. To enable the readiness TCP port, use the `readiness.port` setting. The readiness service will bind to all host addresses. If the node leaves the cluster, or the <> is used to mark the node for shutdown, the readiness port is immediately closed. A successful connection to the readiness TCP port signals that the {es} node is ready. When a client connects to the readiness port, the server simply terminates the socket connection. No data is sent back to the client. If a client cannot connect to the readiness port, the node is not ready.