QuotaGuard and Redis Cloud CIDR Allow List Integration Guide

QuotaGuard Static IPs let your cloud application connect to a Redis Cloud database that has a CIDR allow list enabled. You add the two static IPs assigned to your subscription, and every connection arrives from a known address no matter which platform your app runs on.

You do not need QuotaGuard for local development or for infrastructure with stable IPs. This guide is for applications on Heroku, Render, Railway, Fly.io, Vercel, AWS Lambda, Google Cloud Run, Kubernetes, and other platforms where outbound IPs are dynamic.

The Problem: A CIDR Allow List Needs an Address You Do Not Have

Redis Cloud’s CIDR allow list restricts traffic to your database. Redis’s documentation states that when an allow list is configured, only the IP addresses defined in it can connect, and traffic from every other address is blocked.

That is the control your security review asks for. It is also unusable on a platform whose egress IPs rotate, because there is no stable CIDR to enter.

The failure looks like a network problem rather than an authentication problem:

Error: connect ETIMEDOUT

redis.exceptions.ConnectionError: Error 110 connecting to
redis-12345.c1.us-east-1-2.ec2.redns.redis-cloud.com:12345. Connection timed out.

redis: dial tcp: i/o timeout

The tell is a timeout rather than WRONGPASS or NOAUTH. A credential error means you reached the database. A timeout at connect time usually means the allow list refused you first.

The Common Workaround

The usual response is to allow 0.0.0.0/0, or to leave the CIDR allow list turned off entirely.

Redis Cloud databases are reachable on a public endpoint. With no network restriction, your password is the only thing between the internet and your data, and the control your compliance reviewer asked about is not actually in place.

The QuotaGuard Solution

Route your Redis connections through QuotaGuard’s SOCKS5 proxy. Traffic exits from one of the two static IP addresses assigned to your subscription. Add those two addresses to the allow list.

• Network-level protection is real, not nominal
• The same two IPs work from every platform in your stack
• Adding a worker on Fly.io or moving off Heroku changes nothing on the Redis side
• The allow list stops being a maintenance burden

Native Redis Cloud Options (What They Cover)

Two details from Redis’s documentation are worth knowing before you start.

The CIDR allow list is not available on free Redis Cloud Essentials plans. You need a paid Essentials plan or Redis Cloud Pro.

The database allow list applies to both the public endpoint and the private endpoint. If you reach the database over VPC peering or Transit Gateway, those addresses must be on the list too. Turning on the allow list does not exempt private connectivity.

Use QuotaGuard when:

• Your application runs on a platform with dynamic egress IPs you cannot enumerate
• Your platform does not support VPC peering at all, which covers Heroku, Render, Railway, Vercel, and most serverless runtimes
• Your stack spans several platforms and you want one pair of allow list entries for all of them
• You want the allow list on today without an infrastructure project
• You need the same static identity for other destinations too, not just Redis

Getting Started

After creating a QuotaGuard account, you will be redirected to your dashboard, where you can find your proxy credentials and the two static IP addresses assigned to your subscription.

Choose the right proxy region. Redis is used for latency-sensitive work. Cache reads, session lookups, and queue polling happen constantly, so an extra hop across regions is felt more here than almost anywhere else. Match your QuotaGuard region to the cloud region hosting your Redis Cloud database.

QuotaGuard proxies run in 12 AWS regions:

Your Redis Cloud database’s region appears on its Configuration screen, and it is also encoded in the endpoint hostname. Pick the matching QuotaGuard region, or the nearest available one, from the region list in your dashboard.

Your QuotaGuard SOCKS5 credentials look like this:

Host: <region>-static-01.quotaguard.com
Port: 1080
Username: your-username
Password: your-password

For example, us-east-static-01.quotaguard.com. Use the exact host and credentials shown in your QuotaGuard dashboard rather than assembling a hostname by hand.

Finding your static IPs: both addresses are shown in the QuotaGuard dashboard. Allowlist both. The dashboard pair is the single source of truth. Do not resolve the proxy hostname to obtain an address, and do not allowlist only one of the two.

Note Your Redis Cloud Endpoint Port

Redis Cloud assigns each database its own endpoint and port. The port is generally not 6379. It looks like this:

redis-12345.c1.us-east-1-2.ec2.redns.redis-cloud.com:12345

Copy the exact host and port from your database’s Configuration screen. You will need both for the tunnel mapping below, and the local port you map should match the port your client expects.

Configuring the Redis Cloud CIDR Allow List

Step 1: Open the Database Security Settings

1. Select Databases from the Redis Cloud console menu
2. Select your database from the list
3. On the database’s Configuration screen, select Edit database
4. Find the Security section

Step 2: Turn On the CIDR Allow List

Turn on the CIDR allow list toggle, then enter each address in CIDR notation and confirm it with the check mark. Use Add CIDR to add the second one.

Add both static IPs from your QuotaGuard dashboard as /32 entries:

203.0.113.10/32
203.0.113.11/32

Substitute the actual addresses shown in your dashboard. A /32 mask means exactly that one address.

Step 3: Add Any Other Sources Before You Save

Anything not on the list is blocked. If your application also connects from an office network, a CI runner, or a bastion host, add those CIDRs in the same pass. If you reach the database over VPC peering or Transit Gateway, add those addresses too, because the database allow list applies to the private endpoint as well as the public one.

Step 4: Verify Before You Rely on It

Confirm a successful connection through the proxy before you decommission whatever access path you were using previously. Add the pair, deploy the proxy configuration, confirm the application connects, then tighten.

Configuring Your Application

Redis speaks its own protocol over a plain TCP port. This needs a SOCKS5 proxy, not an HTTP proxy. QuotaGuard’s SOCKS5 service runs on port 1080.

Redis is friendlier here than Postgres is. Several Redis clients are written in the host language rather than wrapping a C library, so a socket-level proxy actually reaches them.

Go with go-redis

go-redis accepts a custom dialer on its options struct, which makes this the cleanest integration of the set.

go get golang.org/x/net/proxy

package main

import (
	"context"
	"fmt"
	"log"
	"net"
	"os"

	"github.com/redis/go-redis/v9"
	"golang.org/x/net/proxy"
)

func main() {
	auth := &proxy.Auth{
		User:     os.Getenv("QUOTAGUARD_SOCKS_USER"),
		Password: os.Getenv("QUOTAGUARD_SOCKS_PASS"),
	}

	socksAddr := fmt.Sprintf("%s:%s",
		os.Getenv("QUOTAGUARD_SOCKS_HOST"),
		os.Getenv("QUOTAGUARD_SOCKS_PORT"),
	)

	socksDialer, err := proxy.SOCKS5("tcp", socksAddr, auth, proxy.Direct)
	if err != nil {
		log.Fatal("socks5 dialer:", err)
	}

	opt, err := redis.ParseURL(os.Getenv("REDIS_URL"))
	if err != nil {
		log.Fatal("parse redis url:", err)
	}

	opt.Dialer = func(ctx context.Context, network, addr string) (net.Conn, error) {
		return socksDialer.Dial(network, addr)
	}

	rdb := redis.NewClient(opt)
	defer rdb.Close()

	if err := rdb.Set(context.Background(), "quotaguard:test", "ok", 0).Err(); err != nil {
		log.Fatal("set:", err)
	}

	val, err := rdb.Get(context.Background(), "quotaguard:test").Result()
	if err != nil {
		log.Fatal("get:", err)
	}

	fmt.Println("Connected to Redis Cloud through QuotaGuard:", val)
}

If your database has TLS enabled, redis.ParseURL on a rediss:// URL sets the TLS config for you, and the dialer still applies underneath it. The hostname stays intact, so certificate verification behaves normally.

Python with redis-py

redis-py is pure Python and opens its sockets through the standard socket module, so PySocks reaches it. This is a real difference from Postgres, where psycopg2 wraps libpq and never passes through Python’s socket layer.

pip install redis PySocks

import os
import socket
import socks
import redis

socks.set_default_proxy(
    socks.SOCKS5,
    os.environ["QUOTAGUARD_SOCKS_HOST"],
    int(os.environ.get("QUOTAGUARD_SOCKS_PORT", 1080)),
    username=os.environ["QUOTAGUARD_SOCKS_USER"],
    password=os.environ["QUOTAGUARD_SOCKS_PASS"],
)
socket.socket = socks.socksocket

r = redis.from_url(os.environ["REDIS_URL"])

r.set("quotaguard:test", "ok")
print("Connected to Redis Cloud through QuotaGuard:", r.get("quotaguard:test"))

socks.set_default_proxy() affects every socket in the process. If your application also talks to services that must not go through the proxy, that global patch will catch them too. Where that matters, use QGTunnel instead so the routing is scoped to one port rather than the whole runtime.

Ruby with redis-rb

gem install redis socksify

require 'redis'
require 'socksify'

TCPSocket.socks_server   = ENV['QUOTAGUARD_SOCKS_HOST']
TCPSocket.socks_port     = ENV['QUOTAGUARD_SOCKS_PORT'].to_i
TCPSocket.socks_username = ENV['QUOTAGUARD_SOCKS_USER']
TCPSocket.socks_password = ENV['QUOTAGUARD_SOCKS_PASS']

redis = Redis.new(url: ENV['REDIS_URL'])

redis.set('quotaguard:test', 'ok')
puts "Connected to Redis Cloud through QuotaGuard: #{redis.get('quotaguard:test')}"

For Rails, put the socksify configuration in an initializer that runs before anything opens a Redis connection:

# config/initializers/socks_proxy.rb
require 'socksify'

if ENV['QUOTAGUARD_SOCKS_HOST'].present?
  TCPSocket.socks_server   = ENV['QUOTAGUARD_SOCKS_HOST']
  TCPSocket.socks_port     = ENV['QUOTAGUARD_SOCKS_PORT'].to_i
  TCPSocket.socks_username = ENV['QUOTAGUARD_SOCKS_USER']
  TCPSocket.socks_password = ENV['QUOTAGUARD_SOCKS_PASS']
end

As with PySocks, this patches TCPSocket process-wide. Sidekiq and ActionCable will route through the proxy too, which is usually what you want when they share the same Redis, but confirm it is what you want.

Java with Jedis or Lettuce

The JVM’s SOCKS system properties apply to plain socket connections, which covers both Jedis and Lettuce’s default transport.

System.setProperty("socksProxyHost", System.getenv("QUOTAGUARD_SOCKS_HOST"));
System.setProperty("socksProxyPort", System.getenv("QUOTAGUARD_SOCKS_PORT"));

Authenticator.setDefault(new Authenticator() {
    @Override
    protected PasswordAuthentication getPasswordAuthentication() {
        return new PasswordAuthentication(
            System.getenv("QUOTAGUARD_SOCKS_USER"),
            System.getenv("QUOTAGUARD_SOCKS_PASS").toCharArray()
        );
    }
});

JedisPool pool = new JedisPool(URI.create(System.getenv("REDIS_URL")));

try (Jedis jedis = pool.getResource()) {
    jedis.set("quotaguard:test", "ok");
    System.out.println("Connected to Redis Cloud through QuotaGuard: "
        + jedis.get("quotaguard:test"));
}

These properties are JVM-wide. If Lettuce is configured with a Netty native transport rather than the default NIO socket, the system properties may not apply. Confirm against your configuration, and fall back to QGTunnel if the source address does not change.

Using QGTunnel

QGTunnel maps a local port to a remote destination through the QuotaGuard proxy. Your application connects to localhost. No client proxy support is needed, and the routing is scoped to one port instead of the whole process.

This is the right choice for Node.js and PHP, where the clients have no usable proxy hook, and for any runtime where a process-wide socket patch would catch traffic you did not intend to route.

Step 1: Download QGTunnel

curl https://s3.amazonaws.com/quotaguard/qgtunnel-latest.tar.gz | tar xz

This creates bin/qgtunnel and supporting files under vendor/nss_wrapper/.

The binary targets Linux. If you develop on macOS or Windows, test tunnel configuration inside a Linux container or VM so your local environment matches production.

Step 2: Create the Tunnel in Your Dashboard

In your QuotaGuard dashboard, go to Setup (the gear icon, top-right) > QGTunnel Configuration > Create a Tunnel.

Take the endpoint and port from your Redis Cloud database’s Configuration screen, not from this page.

Set Encrypted to true only if your Redis Cloud database does not have TLS enabled and you want the tunnel to encrypt the hop itself. If TLS is already on, the connection is encrypted end to end and the tunnel’s own encryption is redundant.

Step 3: Download the Configuration File

Download the configuration file from the dashboard and save it as .qgtunnel in your project root, then commit it. With the file present, your application does not depend on reaching the QuotaGuard API at startup.

Step 4: Point Your Application at the Tunnel

Original:

redis://default:<password>@redis-12345.c1.us-east-1-2.ec2.redns.redis-cloud.com:12345

Through the tunnel:

redis://default:<password>@localhost:12345

If your database uses TLS, connecting to localhost breaks certificate hostname verification. Use QGTunnel’s transparent mode instead, which overrides DNS for the Redis Cloud hostname and keeps your original connection string untouched. Do not disable certificate verification to work around this.

Step 5: Run Your Application Under QGTunnel

Local or generic:

bin/qgtunnel node server.js

Heroku (Procfile):

web: bin/qgtunnel node server.js
worker: bin/qgtunnel node worker.js

Render (start command):

bin/qgtunnel npm start

Railway (start command):

bin/qgtunnel npm start

Fly.io (fly.toml):

[processes]
  app = "bin/qgtunnel npm start"

Docker:

ENTRYPOINT ["/app/bin/qgtunnel"]
CMD ["node", "server.js"]

Kubernetes (container spec):

command: ["/app/bin/qgtunnel"]
args: ["node", "server.js"]

QGTunnel must be the entrypoint so it is listening before your application opens its first connection. If you run background workers as separate processes, each one needs its own QGTunnel wrapper.

Testing Your Implementation

Confirm the Source Address Redis Sees

Redis reports the address of each connected client. Run CLIENT LIST from your application and read the addr field:

Python:

info = r.client_list()
for client in info:
    print(client["addr"])

Go:

out, err := rdb.ClientList(context.Background()).Result()
if err != nil {
    log.Fatal(err)
}
fmt.Println(out)

Your own connection’s address should match one of the two static IPs in your QuotaGuard dashboard. Run it several times and both should appear across repeated connections.

Note that CLIENT LIST is restricted on some Redis Cloud plans and roles. If it is unavailable, use the check below instead.

Confirm the Outbound IP Separately

An independent check that does not depend on the Redis connection at all:

import os
import requests

proxy_url = os.environ["QUOTAGUARDSTATIC_URL"]
proxies = {"http": proxy_url, "https": proxy_url}

response = requests.get("https://ip.quotaguard.com", proxies=proxies)
print("Outbound IP:", response.json()["ip"])

A connection that succeeds while reporting an address not in your dashboard means the proxy configuration was not applied to that connection. A successful PING is not by itself proof that traffic went through the proxy, so check the address rather than assuming.

Latency Considerations

Redis is the most latency-sensitive destination in a typical stack. A cache lookup that took a millisecond now takes a round trip through an extra hop, and applications often make many Redis calls per request.

To keep the impact small:

1. Match all three regions. Application, QuotaGuard proxy, and Redis Cloud database in the same cloud region wherever possible. This matters more for Redis than for anything else you will proxy.
2. Use connection pooling. Let the client hold persistent connections. Through a proxy you pay the setup cost on every new connection, so per-request connections are the worst case.
3. Use pipelining and MULTI where you already can. Batching commands reduces the number of round trips the extra hop applies to.
4. Reconsider what belongs in Redis. If a code path makes dozens of sequential Redis calls per request, the added hop multiplies across all of them.

Measure against your own workload and region pairing rather than assuming a fixed figure.

Troubleshooting

Connection times out, no authentication error

The allow list is refusing you before the password is checked. In order:

1. Confirm both QuotaGuard IPs are on the list, not just one
2. Confirm the addresses match your dashboard exactly, including the /32 mask
3. Confirm the CIDR allow list toggle is actually on and the change was saved
4. Confirm the connection is going through the proxy using the checks above
5. Confirm you are using SOCKS5 on port 1080, not the HTTP proxy on 9293

The CIDR allow list option is not available

Redis’s documentation states the CIDR allow list requires a paid Redis Cloud Essentials plan or Redis Cloud Pro. It is not supported on free Essentials plans.

It worked over VPC peering and broke after enabling the allow list

The database allow list applies to the private endpoint as well as the public one. Peered or Transit Gateway source addresses must be on the list too.

WRONGPASS or NOAUTH

A Redis credential error, not a proxy or allow list problem. You reached the database. Check the password and, if you use RBAC, the username and its role.

TLS certificate verification fails after adding the tunnel

You are connecting to localhost while the certificate is issued for the Redis Cloud hostname. Switch QGTunnel to transparent mode so the original hostname is preserved.

TLS is not available on a Heroku add-on database

Redis’s support documentation notes that Redis Cloud databases provisioned through the Heroku add-on do not expose the option to enable TLS, regardless of the add-on plan size. Moving to a direct Redis Cloud subscription is the path to TLS. This is separate from the proxy configuration.

SOCKS authentication failed

1. Check the SOCKS username and password against your dashboard
2. Check for characters in the password that need URL encoding when embedded in a URL
3. Confirm SOCKS5, not SOCKS4

Other outbound traffic started routing through the proxy unexpectedly

socks.set_default_proxy() in Python and TCPSocket.socks_server in Ruby patch sockets process-wide. Every outbound connection in that process now goes through the proxy, which consumes bandwidth against your plan and may break services that expect a different source address. Use QGTunnel instead to scope the routing to a single port.

ECONNREFUSED 127.0.0.1

QGTunnel is not listening. It either did not start, started after your application, or has no mapping for that local port. Make QGTunnel the process entrypoint so it initializes first.

Environment Variables Reference

# SOCKS5 proxy (port 1080) - used for Redis and other TCP connections
QUOTAGUARD_SOCKS_HOST=<region>-static-01.quotaguard.com
QUOTAGUARD_SOCKS_PORT=1080
QUOTAGUARD_SOCKS_USER=your-username
QUOTAGUARD_SOCKS_PASS=your-password

# HTTP proxy (port 9293) - used for HTTP and HTTPS requests
QUOTAGUARDSTATIC_URL=http://username:password@<region>-static-01.quotaguard.com:9293

# Your Redis Cloud connection string, copied from the console
REDIS_URL=redis://default:<password>@<your-redis-cloud-endpoint>:<your-port>

Use the exact values from your QuotaGuard dashboard and your Redis Cloud console.

Security Best Practices

1. Turn the CIDR allow list on and keep it narrow. A list containing 0.0.0.0/0 provides no protection.
2. Allowlist both static IPs. Allowlisting one produces intermittent failures that are hard to diagnose.
3. Enable TLS where your plan supports it. The allow list controls who can connect. TLS controls what an observer on the path can read. They solve different problems.
4. Use RBAC rather than one shared password. Give each application its own user and role.
5. Never commit credentials. Use your platform’s secret storage for both the Redis URL and the proxy credentials.
6. Rotate credentials periodically, on both the Redis Cloud and QuotaGuard sides.

QuotaGuard Static vs QuotaGuard Shield

Static is right for most applications connecting to Redis Cloud. Choose Shield if the workload handles regulated data under HIPAA, PCI-DSS, or SOC 2, or if your environment requires TLS between your app and the proxy itself.

Redis deserves a specific note here. A Redis Cloud database without TLS enabled carries commands and values in the clear, and session tokens, personal data, and cached API responses routinely live in Redis. If TLS is not available on your plan and the data is sensitive, either move to a plan that supports it or use QGTunnel’s encrypted mode so the hop is not plaintext.

Ready to Get Started?

Turn on your CIDR allow list without locking your own application out.

Try QuotaGuard Now

Contact Support