# Clustering Configuration The [`cluster` configuration map](https://docs.nats.io/running-a-nats-service/configuration/..#clustering) has the following configuration options: | Property | Description | Version | | ---------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | ------- | | `host` | Interface where the gateway will listen for incoming route connections. | | | `port` | Port where the gateway will listen for incoming route connections. | | | `name` | Name of the cluster (recommended for NATS +v2.2) | | | `listen` | Combines `host` and `port` as `:`. | | | `tls` | A [`tls` configuration map](https://docs.nats.io/running-a-nats-service/configuration/securing_nats/tls) for securing the clustering connection. `verify` is always enabled and `cert_file` is used for client and server. [See](https://docs.nats.io/running-a-nats-service/securing_nats/tls#wrong-key-usage) for certificate pitfalls. | | | `advertise` or `cluster_advertise` | Hostport `:` to advertise how this server can be contacted by other cluster members. This is useful in setups with NAT. When using TLS this is important to set to control the hostname that clients will use when discovering the route since by default this will be an IP, otherwise TLS hostname verification may fail with an IP SANs error. | | | `no_advertise` | When set to 'true', the server will not gossip its server URLs to clients. This also disables `client_advertise` in the [general configuration](https://docs.nats.io/running-a-nats-service/configuration) section. Disabling advertise completely can be useful if the server can be reached via different load balancers and interfaces from different networks. Automatically advertising an internal IP address could result in reconnect delays due to failed attempts. | | | `routes` | A list of other servers (URLs) to cluster with. Self-routes are ignored. Should authentication via `token` or `username`/`password` be required, specify them as part of the URL. | | | `connect_retries` | After how many failed connect attempts to give up establishing a connection to a discovered route. Default is `0`, do not retry. When enabled, attempts will be made once a second. This, does not apply to explicitly configured routes. | | | `connect_backoff` | Enable exponential backoff on reconnection attempts. If `true`, will start exponential backoff at 1 second up to 30 seconds. | 2.12.0 | | `authorization` | [Authorization](https://docs.nats.io/running-a-nats-service/securing_nats/auth_intro#authorization-map) map for configuring cluster routes. When a single `username`/`password` is used, it defines the authentication mechanism this server expects, and how this server will authenticate itself when establishing a connection to a *discovered* route. This will not be used for routes explicitly listed in `routes` and therefore have to be provided as part of the URL. With this authentication mode, either use the same credentials throughout the system or list every route explicitly on every server. If the `tls` configuration map specifies `verify_and_map` only provide the expected `username`. Here different certificates can be used, but they have to map to the same `username`. The authorization map also allows for `timeout` which is honored but `users` and `token` configuration are not supported and will prevent the server from starting. The `permissions` block is ignored. | | | `pool_size` | The size of the connection pool used to distribute load across non-pinned accounts. Default is `3`. Refer to [v2 Routes](https://docs.nats.io/running-a-nats-service/configuration/v2_routes#connection-pooling) for details. | | | `accounts` | An optional list of accounts that will have a pinned route connection. Refer to [v2 Routes](https://docs.nats.io/running-a-nats-service/configuration/v2_routes#account-pinning) for details. | | | `compression` | The compression mode the server will use when connecting with peer servers. Default is `accept`. Refer to [v2 Routes](https://docs.nats.io/running-a-nats-service/configuration/v2_routes#compression) for details. | | ``` cluster { name: example # host/port for inbound route connections from other server listen: localhost:4244 # Authorization for route connections # Other server can connect if they supply the credentials listed here # This server will connect to discovered routes using this user authorization { user: route_user password: pwd timeout: 0.5 } # This server establishes routes with these server. # This server solicits new routes and Routes are actively solicited and connected to from this server. # Other servers can connect to us if they supply the correct credentials # in their routes definitions from above. routes = [ nats://route_user:pwd@127.0.0.1:4245 nats://route_user:pwd@127.0.0.1:4246 ] } ``` --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://docs.nats.io/running-a-nats-service/configuration/clustering/cluster_config.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.