Updated October 2026 for .NET 10 (LTS) and StackExchange.Redis 2.x.

Your .NET app fails at startup when it tries to connect to Redis. StackExchange.Redis could not reach any Redis server during the first connection attempt, so it gave up. The fix has two parts: let the client keep retrying in the background (abortConnect=false), and make sure the server is actually reachable with the right host, port, password and TLS settings.

The error

StackExchange.Redis.RedisConnectionException: It was not possible to connect to the redis server(s). To create a disconnected multiplexer, disable AbortOnConnectFail.

Why it happens

AbortOnConnectFail (abortConnect in a connection string) defaults to true, except for Azure endpoints. With true, ConnectionMultiplexer.Connect() throws this exception if it cannot connect after its initial attempts (3 by default). Common reasons it cannot connect:

  • Redis is not running yet, for example a container that starts after your app
  • Wrong host or port, or a firewall blocking the port
  • TLS mismatch: the server requires TLS but the client is not using ssl=true, or the other way round
  • Wrong or missing password
  • A brief network problem during startup

Fix 1: Set abortConnect=false in the connection string

With abortConnect=false, Connect() returns a disconnected multiplexer and keeps trying in the background. Your app starts, and Redis calls work as soon as the server is reachable. In appsettings.json:

{
  "ConnectionStrings": {
    "Redis": "my-redis-host:6379,password=YOUR_PASSWORD,ssl=true,abortConnect=false,connectRetry=5"
  }
}

Keep the password in user secrets, environment variables or Azure Key Vault rather than in the file.

Fix 2: Configure it in code and register one shared connection

Create the ConnectionMultiplexer once and share it as a singleton. Creating a new connection for every request is slow and can exhaust connections. In Program.cs:

using StackExchange.Redis;

var builder = WebApplication.CreateBuilder(args);

var redisOptions = ConfigurationOptions.Parse(
    builder.Configuration.GetConnectionString("Redis")!);

redisOptions.AbortOnConnectFail = false;                        // keep retrying in the background
redisOptions.ConnectRetry = 5;                                  // initial connect attempts
redisOptions.ReconnectRetryPolicy = new ExponentialRetry(500, 5000); // ms between reconnects
redisOptions.ConnectTimeout = 10000;                            // 10 s, useful for cloud servers

builder.Services.AddSingleton<IConnectionMultiplexer>(
    _ => ConnectionMultiplexer.Connect(redisOptions));

var app = builder.Build();

Then inject IConnectionMultiplexer wherever you need Redis:

app.MapGet("/stock/{sku}", async (string sku, IConnectionMultiplexer redis) =>
{
    var db = redis.GetDatabase();
    var stock = await db.StringGetAsync($"stock:{sku}");
    return stock.HasValue ? Results.Ok((int)stock) : Results.NotFound();
});

More on this pattern: Redis dependency injection with ConnectionMultiplexer.

Important: commands are not retried automatically

abortConnect=false only keeps the connection alive. While Redis is unreachable, individual commands still fail with RedisConnectionException or RedisTimeoutException. Catch those, fall back to your database where it makes sense, or add a short retry with Polly. See Implement the retry pattern in C#.

Still cannot connect? Checklist

  • Test from the same machine: run redis-cli -h my-redis-host -p 6379 ping (add --tls and -a for password if needed). It should reply PONG.
  • Check the port and TLS together. Many hosted Redis services use a separate TLS port. Match ssl=true to the port you use. See Connect to Redis with SSL/TLS in C#.
  • Docker: inside a container, localhost means the container itself. Use the Redis service name, for example redis:6379.
  • Firewall or cloud network rules must allow your app’s IP to reach the Redis port.
  • Read the full exception message. It lists each endpoint and why it failed, such as UnableToConnect or AuthenticationFailure.

FAQ

Is it safe to set abortConnect=false in production?

Yes. It is the recommended setting for cloud apps, because services often start in an unpredictable order. Your app should still handle the case where Redis is temporarily unavailable.

Do I need this on Azure?

StackExchange.Redis already defaults abortConnect to false for Azure endpoints. Setting it explicitly does no harm and makes the behaviour clear in your configuration.

How do I run Redis locally for testing?

The quickest way is Docker: docker run -d -p 6379:6379 redis. On Windows without Docker, see How to run Redis on Windows.

Related

Sources: StackExchange.Redis configuration docs · Redis: Production usage for .NET

Leave a Reply

Your email address will not be published. Required fields are marked *