diagnosing the Upstash daemon state

Questions / Help
1

Upstash Redis instance accepts TCP on 6379 but the protocol layer doesn’t respond. Tested from 4 paths:

  1. ioredis from inside the running app container (private IPv6 hostname) — close-after-accept

2. Raw net.Socket + tls.connect inside the container — server ends connection before any data exchanged
3. nc -zv reports the port “open” but the TCP handshake is the only thing that succeeds
4. flyctl redis proxy to my local laptop, then ioredis through the proxy — same MaxRetriesPerRequestError
Destroyed and recreated the instance once; new instance same symptom.

Need help diagnosing the Upstash daemon state. Two candidate causes I can’t verify from outside: (a) instance binding broken on the Upstash side, (b) some org-level config preventing AUTH from succeeding.

4

Hi, this basically sounds like “Upstash Redis doesn’t work at all” which didn’t seem to be the case when I tested it.
Can you install nc in your Fly machine and connect directly to Redis?

printf "AUTH default YOUR_PASWORD\r\nPING\r\nQUIT\r\n" | nc your_redis.upstash.io 6379
+OK
+PONG
+OK

The REDIS_URL is usually redis://default:YOUR_PASSWORD@your_redis.upstash.io:6379 , you can extract the password and hostname from that.

5

Are those still Flycast addresses, these days?

I think a lot of people’s problems with Upstash might stem from their clients defaulting to TLS. OP kind of hints at that with attempt #2 (“net.Socket + tls.connect”).

I’m leery of recommending to anyone that they turn off encryption, though, :sweat_smile:…