Redis+MCP+ECONNREFUSED+127+0+0+1+6379+from+Docker

Not specified by the original author.

TL;DR: connection refused from a containerized Redis MCP server usually means it is trying to reach Redis at the loopback address, which inside the container is itself. Set REDIS_HOST to the real address: host.YOUR_HOST for Redis on your laptop, or the container/service name on a shared Docker network.

Error: connect ECONNREFUSED the loopback address:6379

Fix it

1. Figure out where Redis actually lives relative to the MCP server:

   • Redis on your laptop, MCP server in Docker: host is host.YOUR_HOST.
   • Both in Docker Compose: host is the service name, e.g. redis.
   • Both on the host: the loopback address is correct, check Redis is running.
2. Set it explicitly. Do not rely on the default:

REDIS_HOST=host.YOUR_HOST
REDIS_PORT=6379

In a client config env block, add "REDIS_HOST": "host.YOUR_HOST".

3. Verify from inside the same network namespace if you can:

docker run --rm redis:7 redis-cli -h host.YOUR_HOST ping

Expected: PONG.

4. Restart the MCP server.

   Expected: connection refused is gone.

When to use this

• redis-cli ping works on your host but the MCP server gets ECONNREFUSED.
• The MCP server runs in Docker and Redis runs elsewhere.

When NOT to use this

• Both run on the same host outside Docker and it still refuses. Then Redis is not running or not listening on 6379.
• The error is NOAUTH or WRONGPASS. The connection works; auth is the problem.

Compatibility

• redis/mcp-redis in Docker / Docker Compose.
• Docker Desktop (macOS/Windows) supports host.YOUR_HOST. On Linux, add --add-host=host.YOUR_HOST:host-gateway.

Why it happens

Every container has its own loopback interface. the loopback address inside the MCP container never leaves the container, so it can only reach a Redis running in that same container. The default REDIS_HOST=the loopback address is only correct when server and Redis share a network namespace.

Edge cases

• --network=host on Linux makes container YOURHOST equal host YOURHOST, but it does not work on Docker Desktop for Mac/Windows.
• If Redis is bound to the loopback address in its own config, other containers cannot reach it even by service name. Bind Redis to the all-interfaces address (with a password) for container networking.
• Port mappings (-p 6379:6379) matter for host-to-container, not container-to-container. On a shared network, use the container port directly.

The redis/mcp-redis server defaults REDISHOST to the loopback address and REDISPORT to 6379 (documented in zskbot/catalog image/redis-mcp/guides.md, upstream https://github.com/redis/mcp-redis). When the MCP server runs in Docker and Redis runs on the host (or in another container), the loopback address resolves to the MCP container itself and the connection is refused. The documented pattern in containerized MCP setups is using host.YOUR_HOST as the hostname to reach the host from inside a container, as shown in dockerized MCP server guides.

Not specified by the original author.

TL;DR: ECONNREFUSED means nothing is listening where the MCP server is looking. Start MySQL, then make sure MYSQL_HOST and MYSQL_PORT in the client config match where it actually listens. The defaults (YOUR_HOST:3306) are wrong for Docker and remote setups.

Error: connect ECONNREFUSED the loopback address:3306

Fix it

1. Check MySQL is running:

# Linux
sudo systemctl status mysql
# macOS (Homebrew)
brew services list
# Docker
docker ps | grep mysql

2. Check what it listens on:

sudo netstat -tlnp | grep 3306

Expected: a line showing mysqld on 3306 (or your configured port).

3. Set the real address in the client config env block. Docker on the host: host.YOUR_HOST. Docker Compose service: the service name. Remote: the hostname or IP.

{
  "env": {
    "MYSQL_HOST": "host.YOUR_HOST",
    "MYSQL_PORT": "3306"
  }
}

4. Restart the MCP client.

   Expected: the refused error is gone. Next failure, if any, will be auth, which is progress.

When to use this

• The error is ECONNREFUSED mentioning the MySQL host and port.
• mysql -h [host] from a terminal also fails to connect.

When NOT to use this

• The error is ER_ACCESS_DENIED_ERROR. The server is reachable; credentials are wrong.
• The error is a timeout (ETIMEDOUT). That is firewall or routing, not a refused connection.

Compatibility

• benborla/mcp-server-mysql.
• MySQL 5.7, 8.x, MariaDB, in Docker or on the host.

Why it happens

Connection refused is the OS telling you the SYN packet arrived but no process accepted it. Either MySQL is down, or it is up but bound to a different interface or port than the config says. MCP defaults assume a local MySQL on 3306, which breaks the moment MySQL lives in Docker or on another machine.

Edge cases

• MySQL in Docker without a published port is unreachable from the host. Add -p 3306:3306.
• bind-address = the loopback address in my.cnf blocks remote connections even when the port is open. Set it to the all-interfaces address for remote access (with proper grants).
• Skip-networking enabled means TCP is off entirely. The MCP server needs TCP; use a socket only if the server supports it.

ECONNREFUSED is the standard TCP connection-refused error when the MySQL server is not running or not listening at the configured host and port, documented in MySQL troubleshooting guides with the fix of starting the MySQL service and verifying the host and port. The benborla/mcp-server-mysql server reads MYSQLHOST and MYSQLPORT from the environment, defaulting to YOUR_HOST:3306, so a MySQL running elsewhere or on a different port produces this exact error. Source: https://github.com/benborla/mcp-server-mysql

Not specified by the original author.

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.

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.

The okengine Upstash provider docs (omqkhafi/okengine site/content/docs/providers/upstash.mdx) state TLS is mandatory and redis:// without TLS fails, with the documented REDISURL form rediss://endpoint:6379. The redis-cloud.mdx doc repeats that public endpoints expect TLS, use the rediss:// scheme. The redis/mcp-redis server exposes REDISSSL to enable TLS for the Redis connection. Connecting without TLS to a TLS-mandating endpoint fails at the transport level.