7 days ago
Worker service (ID 9d34d5d3-3a6f-4567-a17b-7139de11776c) times out connecting to our Redis service's TCP proxy (tokaido.proxy.rlwy.net:12791, Redis service ID fcf338c6-22c7-41c4-a927-ed2cc88826c8) with a plain connection timeout — no DNS error, no auth error. At the exact same moment, redis-cli -h tokaido.proxy.rlwy.net -p 12791 -a ping from an external network returns PONG successfully.
Both services are in the production environment (dcb709af-b145-43c2-94f2-43c0a2b6268a), same region (us-east4-eqdc4a).
This means your own proxy is reachable externally while a container inside your own infrastructure cannot reach it. Configuration (host/port/password) has been verified correct and unchanged between working (18:10–18:26) and failing (18:41 onward) periods.
1 Replies
7 days ago
This thread has been opened as a public bounty so the community can help solve it. The thread and any further activity are now visible to everyone.
Status changed to Open Railway • 7 days ago
2 hours ago
Both services are in the same project and environment, so the worker shouldn't be reaching Redis via tokaido.proxy.rlwy.net at all. That hostname is the public TCP proxy — traffic to it leaves Railway's network and comes back in from the internet. It exists for external clients, which is exactly why redis-cli from your laptop gets a PONG while the worker sitting right next to the database times out.
Service-to-service traffic should stay on the private network:
redis.railway.internal:6379
Note the port is Redis's own 6379, not the proxy port 12791 — 12791 only exists on the public edge.
Railway's Redis service already gives you both: REDIS_URL is the private URL, REDIS_PUBLIC_URL is the proxy one. Point the worker at REDIS_URL rather than a hardcoded proxy host.
One thing that will bite you immediately after switching, because it fails in the same silent timeout way: if this environment was created before October 16th 2025, Railway's private network is IPv6-only. redis.railway.internal has AAAA records and no A record, and ioredis does an IPv4-only lookup by default — as does anything built on it, BullMQ included. Fix is to allow IPv6:
- ioredis connection object: family: 0 for dual-stack (or family: 6)
-
- via the URL: append ?family=0
-
- BullMQ: set family: 0 in the connection object
Environments created after that date are dual-stack, so skip this if yours is newer.
I can't tell you why the proxy path worked 18:10-18:26 then stopped at 18:41 with no config change — that's public-edge behaviour only Railway can see. But it isn't the supported path for internal traffic regardless. Private traffic also doesn't count against egress.
If it still times out after switching to redis.railway.internal, post your client library and version — that narrows it to the IPv6 lookup issue fast.