TL;DR: Managed Redis (Upstash, Redis Cloud) requires TLS. If your URL starts with `redis://`, the connection fails. Change it to `rediss://` (note the double s) or set `REDIS_SSL=true`, and it connects.

```text
Error: connect ETIMEDOUT / connection reset
```

(Plain `redis://` against a TLS-only endpoint. The exact error varies; timeouts and resets are typical.)

## Fix it

1. Change the scheme in your connection URL:

```
rediss://your-endpoint:6379
```

   Or if you configure via env vars, set `REDIS_SSL=true` alongside `REDIS_HOST`, `REDIS_PORT`, `REDIS_PWD`.

2. Restart the MCP server.

   Expected: the server connects and tools respond.

## When to use this

- Connecting redis/mcp-redis to Upstash, Redis Cloud, or any managed Redis.
- Local `redis://YOUR_HOST:6379` works but the managed endpoint does not.

## When NOT to use this

- Local dev Redis without TLS. Forcing TLS there breaks the connection the other way.
- The error is NOAUTH or WRONGPASS. TLS is fine; the credentials are the problem.

## Compatibility

- redis/mcp-redis (REDIS_SSL env var, rediss:// URL scheme).
- Upstash, Redis Cloud, AWS ElastiCache with in-transit encryption.

## Why it happens

Managed Redis providers terminate TLS at the endpoint and refuse plaintext. A `redis://` client starts a plaintext handshake the server immediately drops, which surfaces as a timeout or reset rather than a helpful error. The `rediss://` scheme tells the client to negotiate TLS first.

## Edge cases

- Self-signed or private-CA certs on private endpoints may need `REDIS_SSL_CA_CERTS` pointed at the CA bundle.
- Upstash also offers a REST API with a token. That is a different protocol, not a substitute for the Redis password over `rediss://`.
- Some clients need the port from the provider panel. Upstash uses 6379; Redis Cloud uses a per-database high port.