{
  "id": "proxy-policy",
  "title": "Configure proxy policy",
  "url": "https://redis.io/docs/latest/operate/rs/7.8/databases/configure/proxy-policy/",
  "summary": "",
  "content": "Redis Software provides high-performance data access\nthrough a proxy process that manages and optimizes access to shards\nwithin the Redis Software cluster. Each node contains a single proxy process.\nEach proxy can be active and take incoming traffic or it can be passive\nand wait for failovers.\n\n## Proxy policies\n\nA database can have one of the following proxy policies:\n\n| Proxy policy | Description | Recommended use cases | Advantages | Disadvantages |\n|--------------|-------------|-----------------------|-----------|-----------------|\n| Single | Only a single proxy is bound to the database. This is the default database configuration. | Most use cases without high traffic or load | Lower resource usage, fewer application-to-cluster connections | Higher latency, more network hops |\n| All primary shards | Multiple proxies are bound to the database, one on each node that hosts a database primary shard. | Most use cases that require multiple endpoints, such as when using the [OSS Cluster API]() | Lower latency, fewer network hops, higher throughput | Higher resource usage, more application-to-proxy connections |\n| All nodes | Multiple proxies are bound to the database, one on each node in the cluster, regardless of whether or not there is a shard from this database on the node. | When using [load balancers]() for environments without DNS | Higher throughput | Highest resource usage |\n\n## View proxy policy\n\nYou can use the Cluster Manager UI, [`rladmin`](), or the [REST API]() to view proxy configuration settings.\n\nThe [`rladmin info cluster`]() command returns the current proxy policy for sharded and non-sharded (single shard) databases.\n\n```sh\n$ rladmin info cluster\ncluster configuration:\n   ...\n   default_non_sharded_proxy_policy: single\n   default_sharded_proxy_policy: single\n   ...\n```\n\n## Configure database proxy policy\n\nYou can use the [Cluster Manager UI](#cluster-manager-ui-method), the [REST API](#rest-api-method), or [`rladmin`](#command-line-method) to configure a database's proxy policy.\n\n\nAny configuration update that unbinds existing proxies can disconnect existing client connections.\n\n\n### Cluster Manager UI method\n\nYou can change a database's proxy policy when you [create]() or [edit]() a database using the Cluster Manager UI:\n\n1. While in edit mode on the database's configuration screen, expand the **Clustering** section.\n\n1. Select a policy from the **Database proxy** list.\n\n1. Click **Create** or **Save**.\n\n### REST API method\n\nYou can specify a proxy policy when you [create a database]() using the REST API:\n\n```sh\nPOST /v1/bdbs\n{ \n  \"proxy_policy\": \"single | all-master-shards | all-nodes\",\n  // Other database configuration parameters\n}\n```\n\nTo change the proxy policy of an existing database and endpoint, you can use an [update database configuration]() REST API request:\n\n```sh\nPUT /v1/bdbs/\u003cdatabase-id\u003e\n{ \n  \"proxy_policy\": \"single | all-master-shards | all-nodes\",\n  \"endpoint\": \u003cendpoint_uid\u003e\n}\n```\n\n### Command-line method\n\nYou can configure a database's proxy policy using [`rladmin bind`]().\n\nThe following example changes the bind policy for a database named \"db1\" with an endpoint ID \"1:1\" to \"All primary shards\" proxy policy:\n\n```sh\nrladmin bind db db1 endpoint 1:1 policy all-master-shards\n```\n\nThe next command performs the same task using the database ID instead of the name. The ID of this database is \"1\".\n\n```sh\nrladmin bind db db:1 endpoint 1:1 policy all-master-shards\n```\n\n\nYou can find the endpoint ID for the endpoint argument by running `rladmin status`. Look for the endpoint ID information under\nthe `ENDPOINT` section of the output.\n\n\n### Reapply policies after topology changes\n\nIf you want to reapply the policy after topology changes, such as node restarts,\nfailovers and migrations, run this command to reset the policy:\n\n```sh\nrladmin bind db db:\u003cID\u003e endpoint \u003cendpoint id\u003e policy \u003call-master-shards|all-nodes\u003e\n```\n\nThis is not required with single policies.\n\n#### Other implications\n\nDuring the regular operation of the cluster different actions might take\nplace, such as automatic migration or automatic failover, which change\nwhat proxy needs to be bound to what database. When such actions take\nplace the cluster attempts, as much as possible, to automatically change\nproxy bindings to adhere to the defined policies. That said, the cluster\nattempts to prevent any existing client connections from being\ndisconnected, and hence might not entirely enforce the policies. In such\ncases, you can enforce the policy using the appropriate rladmin\ncommands.\n\n## Multiple active proxies\n\nEach database you create in a Redis Software cluster has an endpoint, which consists of a unique URL and port on the FQDN. This endpoint receives all the traffic for all operations for that database. By default, Redis Software binds this database endpoint to one of the proxies on a single node in the cluster. This proxy becomes an active proxy and receives all the operations for the given database. If the node with the active proxy fails, a new proxy on another node takes over as part of the failover process automatically.\n\nIn most cases, a single proxy can handle a large number of operations\nwithout consuming additional resources. However, under high load,\nnetwork bandwidth, or a high rate of packets per second (PPS) on the\nsingle active proxy can become a bottleneck to how fast database\noperations can be performed. In such cases, having multiple active proxies across multiple nodes, mapped to the same external database\nendpoint, can significantly improve throughput.\n\nYou can configure a database to have multiple internal proxies, which can improve performance in some cases.\nEven though multiple active proxies can help improve the throughput of database\noperations, configuring multiple active proxies may cause additional\nlatency in operations as the shards and proxies are spread across\nmultiple nodes in the cluster.\n\n\nWhen the network on a single active proxy becomes the bottleneck, consider enabling multiple NIC support in Redis Software. With nodes that have multiple physical NICs (Network Interface Cards), you can configure Redis Software to separate internal and external traffic onto independent physical NICs. For more details, refer to [Multi-IP \u0026 IPv6]().\n\n\nHaving multiple proxies for a database can improve Redis Software's ability for fast failover in case of proxy or node failure. With multiple proxies for a database, a client doesn't need to wait for the cluster to spin up another proxy and a DNS change in most cases. Instead, the client uses the next IP address in the list to connect to another proxy.\n",
  "tags": ["docs","operate","rs"],
  "last_updated": "2026-04-01T08:10:08-05:00"
}