# Configure Client Connections

> For the complete documentation index, see [llms.txt](https://docs.redpanda.com/llms.txt). Component-specific: [cloud-data-platform-full.txt](https://docs.redpanda.com/cloud-data-platform-full.txt)

---
title: Configure Client Connections
latest-operator-version: v26.1.4
latest-console-tag: v3.7.3
latest-connect-version: 4.93.0
latest-redpanda-tag: v26.1.9
docname: cluster-maintenance/configure-client-connections
page-component-name: cloud-data-platform
page-version: master
page-component-version: master
page-component-title: Cloud
page-relative-src-path: cluster-maintenance/configure-client-connections.adoc
page-edit-url: https://github.com/redpanda-data/cloud-docs/edit/main/modules/manage/pages/cluster-maintenance/configure-client-connections.adoc
description: Learn about guidelines for configuring client connections in Redpanda clusters for optimal availability.
page-git-created-date: "2025-11-19"
page-git-modified-date: "2026-05-26"
---

<!-- Source: https://docs.redpanda.com/cloud-data-platform/manage/cluster-maintenance/configure-client-connections.md -->

Optimize the availability of your clusters by configuring and tuning properties.

> 💡 **TIP**
>
> Before you configure connection limits or reconnection settings, start by gathering detailed data about your client connections.
>
> -   Use the [`redpanda_rpc_active_connections` metric](https://docs.redpanda.com/cloud-data-platform/reference/public-metrics-reference/#redpanda_rpc_active_connections) to view current Kafka client connections.
>
> -   For clusters on v25.3 and later, use [`rpk cluster connections list`](https://docs.redpanda.com/cloud-data-platform/reference/rpk/rpk-cluster/rpk-cluster-connections-list/) or the `GET /v1/monitoring/kafka/connections` endpoint in the Data Plane API to identify:
>
>     -   Which clients and applications are connected
>
>     -   Long-lived connections and long-running requests
>
>     -   Connections with no activity
>
>     -   Whether any clients are causing excessive load
>
>
>     By reviewing connection details, you can make informed decisions about tuning connection limits and troubleshooting issues.
>
>
> See also: [Data Plane API reference](https://docs.redpanda.com/api/doc/cloud-dataplane/operation/operation-monitoringservice_listkafkaconnections), [Monitor Redpanda Cloud](https://docs.redpanda.com/cloud-data-platform/manage/monitor-cloud/#throughput)

## [](#limit-client-connections)Limit client connections

To mitigate the risk of a client creating too many connections and using too many system resources, you can configure a Redpanda cluster to impose limits on the number of client connections that can be created.

The following Redpanda cluster properties limit the number of connections:

-   [`kafka_connections_max_per_ip`](https://docs.redpanda.com/cloud-data-platform/reference/properties/cluster-properties/#kafka_connections_max_per_ip): Similar to Kafka’s `max.connections.per.ip`, this sets the maximum number of connections accepted per IP address by a broker.

-   [`kafka_connections_max_overrides`](https://docs.redpanda.com/cloud-data-platform/reference/properties/cluster-properties/#kafka_connections_max_overrides): A list of IP addresses for which `kafka_connections_max_per_ip` is overridden and doesn’t apply.


> 📝 **NOTE**
>
> -   These connection limit properties are disabled by default. You must manually enable them.
>
> -   The total number of connections is not equal to the number of clients, because a client can open multiple connections. As a conservative estimate, for a cluster with N brokers, plan for N + 2 connections per client.

### [](#configure-connection-count-limit-by-client-ip)Configure connection count limit by client IP

Configure the `kafka_connections_max_per_ip` property to limit the number of connections from each client IP address.

> ❗ **IMPORTANT**
>
> Per-IP connection controls require Redpanda to see individual client IPs. If clients connect through private link endpoints, NAT gateways, or other shared-IP egress, the per-IP limit applies to the shared IP, affecting all clients behind it and preventing isolation of a single offending client. Similarly, multiple clients running on the same host will share the same IP address, and the limit applies collectively to all those clients.

See also: [Configure Cluster Properties](https://docs.redpanda.com/cloud-data-platform/manage/cluster-maintenance/config-cluster/)

#### [](#configure-the-limit)Configure the limit

To configure `kafka_connections_max_per_ip` safely without disrupting legitimate clients, follow these steps:

1.  Set up your monitoring stack for your cluster. See [Monitor Redpanda Cloud](https://docs.redpanda.com/cloud-data-platform/manage/monitor-cloud/).

2.  Monitor current connection patterns using the `redpanda_rpc_active_connections` metric with the `redpanda_server="kafka"` filter:

    ```none
    redpanda_rpc_active_connections{redpanda_id="CLOUD_CLUSTER_ID", redpanda_server="kafka"}
    ```

3.  Analyze the connection data to identify the normal range of connections for each broker during typical traffic cycles. For example, in the following Grafana screenshot, the normal range is around 200-300 connections:

    ![Range of active connections over time](https://docs.redpanda.com/cloud-data-platform/shared/_images/monitor_connections.png)

4.  Set the `kafka_connections_max_per_ip` value based on your analysis. Use the upper bound of normal connections observed, or use a lower value if you know how many connections per client IP are being opened.

5.  Continue monitoring the connection metrics after applying the limit to ensure that legitimate clients are not affected and that the problematic client is properly controlled.


> 📝 **NOTE**
>
> If you find a high load of unexpected connections from multiple IP addresses, `kafka_connections_max_per_ip` alone may be insufficient. If offending IPs outnumber legitimate client IPs, you may need to set `kafka_connections_max_per_ip` so low that it affects legitimate clients. If this is the case, use `kafka_connections_max_overrides` to exempt known legitimate client IPs from the connection limit.

#### [](#limitations)Limitations

-   Decreasing the limit does not terminate any currently open Kafka API connections.

-   This limit does not apply to Kafka HTTP Proxy connections.

-   Clients behind NAT gateways or private links share the same IP address as seen by Redpanda brokers.

-   The limit may negatively affect tail latencies across all client connections.

-   All clients behind the shared IP are collectively subject to the single `kafka_connections_max_per_ip` limit.

-   Connection rejections occur randomly among clients when the limit is reached. For example, suppose `kafka_connections_max_per_ip` is set to 100, but clients behind a NAT gateway collectively need 150 connections. When the limit is reached, clients can make only some of the connections while others get rejected, leaving the client in a not-working state.

-   Redpanda may modify this property during internal operations.

-   Availability incidents caused by misconfiguring this feature are excluded from the Redpanda Cloud SLA.


## [](#configure-client-reconnections)Configure client reconnections

You can configure the Kafka client backoff and retry properties to change the default behavior of the clients to suit your failure requirements.

Set the following Kafka client properties on your application’s producer or consumer to manage client reconnections:

-   `reconnect.backoff.ms`: Amount of time to wait before attempting to reconnect to the broker. The default is 50 milliseconds.

-   `reconnect.backoff.max.ms`: Maximum amount of time in milliseconds to wait when reconnecting to a broker. The backoff increases exponentially for each consecutive connection failure, up to this maximum. The default is 1000 milliseconds (1 second).


Additionally, you can use Kafka properties to control message retry behavior. Delivery fails when either the delivery timeout or the number of retries is met.

-   `delivery.timeout.ms`: Amount of time for message delivery, so messages are not retried forever. The default is 120000 milliseconds (2 minutes).

-   `retries`: Number of times a producer can retry sending a message before marking it as failed. The default value is 2147483647 for Kafka >= 2.1, or 0 for Kafka <= 2.0.

-   `retry.backoff.ms`: Amount of time to wait before attempting to retry a failed request to a given topic partition. The default is 100 milliseconds.


## [](#see-also)See also

-   [Configure Producers](https://docs.redpanda.com/cloud-data-platform/develop/produce-data/configure-producers/)

-   [Manage Throughput](https://docs.redpanda.com/cloud-data-platform/manage/cluster-maintenance/manage-throughput/)