Railway Redis is completely inaccessible from our backend service using all documented connection methods. We've exhausted all troubleshooting steps including the IPv6 dual-stack DNS resolution fix from your documentation, but connections continue to fail with either DNS resolution errors or connection timeouts.

Environment

- Project ID: 6a4f6bde-9ea1-414d-b71e-f330b4d5dc30

- Environment: Production (f5d16d67-330b-4b68-8293-afba4849fa8b)

- Backend Service ID: f8c5226e-d891-49b9-b90a-c14e28e66213

- Redis Service: Provisioned via Railway Dashboard

- Node Version: 18.20.5

- Redis Client: ioredis (latest)

- Private Networking: Enabled for both Redis and backend services (verified)

Comprehensive Troubleshooting Attempts

Attempt 1: Private Networking with Internal Hostname

REDIS__URL=redis://default:@redis.railway.internal:6379_

REDIS_TLS_ENABLED=false

Result: DNS resolution failure

Redis client error {

operation: 'redis__error',_

error: {

message: 'getaddrinfo ENOTFOUND redis.railway.internal',

name: 'Error',

code: 'ENOTFOUND'

}

}

Attempt 2: Service Reference Variable (RAILWAY_PRIVATE_DOMAIN)

REDIS__URL=redis://default:@${{Redis.RAILWAY_PRIVATE_DOMAIN}}:6379_

Result: Variable resolved to redis.railway.internal, same ENOTFOUND error

Attempt 3: Public Networking with Proxy Endpoint

REDIS__URL=redis://default:@_hopper.proxy.rlwy.net:29169

REDIS_TLS_ENABLED=true

Result: Connection timeout after 10 seconds

Redis client error {

operation: 'redis__error',_

error: { message: 'connect ETIMEDOUT', name: 'Error', code: 'ETIMEDOUT' }

}

Attempt 4: IPv6 Dual-Stack Configuration (Per Railway Documentation)

Following your documentation at https://docs.railway.com/dynamic/reference/errors/enotfound-redis-railway-internal, we added the family:

0 parameter to enable IPv4+IPv6 dual-stack DNS resolution:

RedisClient.instance = new Redis(redisUrl, {

maxRetriesPerRequest: 3,

connectTimeout: 10000,

family: 0, // Enable dual-stack (IPv4 + IPv6) DNS resolution

// ... other config

});

Configuration:

REDIS__URL=redis://default:@redis.railway.internal:6379_

REDIS_TLS_ENABLED=false

Result: Still connection timeout (ETIMEDOUT), not DNS resolution error

Redis client error {

operation: 'redis__error',_

error: { message: 'connect ETIMEDOUT', name: 'Error', code: 'ETIMEDOUT' }

}

Verification Steps Completed

Private Networking enabled for both Redis and backend services (confirmed in Dashboard)

Backend successfully connects to PostgreSQL

via postgres.railway.internal (private networking works for Postgres)

Redis instance shows as healthy in Railway Dashboard

Correct authentication credentials (password verified)

TLS configuration tested (both enabled and disabled)

Multiple redeployments attempted

Environment variables verified via Railway CLI

IPv6 dual-stack DNS resolution enabled per documentation

Actual Behavior

1. Private networking: DNS resolution fails completely (ENOTFOUND)

2. Public endpoint: Connection times out after 10 seconds (ETIMEDOUT)

3. IPv6 fix from documentation: Changed error from ENOTFOUND to ETIMEDOUT, but still fails

Expected Behavior

Backend service should be able to connect to Redis via private networking at redis.railway.internal:6379, similar to how PostgreSQLprivate networking functions successfully.

Impact

Critical: This blocks OAuth state storage functionality in production. Multi-instance deployments require distributed state management, which is impossible without Redis connectivity.

Comparison with PostgreSQL

Private networking works perfectly for PostgreSQL:

- postgres.railway.internal:5432 resolves and connects successfully

- Same private networking configuration

- Same backend service

Why does PostgreSQL private networking work but Redis does not?

Request

Please investigate why:

1. redis.railway.internal DNS resolution fails despite private networking being enabled

2. Public Redis endpoint connections time out despite correct credentials

3. The documented IPv6 dual-stack fix doesn't resolve the issue

4. Private networking works for PostgreSQL but not Redis in the same project

This appears to be a fundamental issue with Railway's Redis private networking implementation.