Machine unreachable from WireGuard peer but healthy and reachable from other apps in the same org

Questions / Help
,
1

One machine in our DEV org became unreachable from our WireGuard peer, while staying
perfectly healthy inside the private network. Every other machine in the same org, over
the same peer, works fine at the same moment.

App: gdi-postgres-dev · Machine: d8946d0f674018 · Region: gru
Private IP: fdaa:4a:67f8:a7b:5c6:5de2:5d5b:2 · flyctl v0.4.99 (Windows 11, client in AR)
Started around 2026-09-18 22:10 UTC, still ongoing.

What happens:

  • fly proxy 5433:5432 -a gdi-postgres-dev opens, but psql through it hangs forever.
  • fly ssh console -a gdi-postgres-dev hangs at “Connecting to fdaa:…:5d5b:2”.
  • The Postgres logs show ZERO connection attempts for any of those — packets never reach
    the guest. It does log connections coming from other Fly apps normally.

Why I think the machine itself is fine:

  • Logs: “database system is ready to accept connections” after a clean restart.
  • From another app in the same org, the port opens immediately:
    fly ssh console -a gdi-backend-dev -C "python -c \"import socket;socket.create_connection(('gdi-postgres-dev.internal',5432),8)\"" → OK
  • Our backend queries it continuously without issues.
  • fly ips private and the internal DNS resolution agree on the same address, so it’s not
    a stale record.

Control test (same peer, same org, same minute):

  • fly ssh console -a gdi-backend-dev -C "echo OK" → OK
  • fly proxy 8099:8080 -a gdi-backend-dev + curl → healthy JSON response

So peer, proxy mechanism, token and local network all check out. Only this one machine is
unreachable from outside the 6PN.

Already tried, with no change: fly agent restart, fly machine restart, stop+start from
the dashboard (it stayed on the same host), fly wireguard reset (new peer created — the
control test above was run with the new peer), and reopening the proxy on different ports.

Is there anything else I can check from my side? My guess is that traffic from the WireGuard
gateway to that machine’s host is being dropped, but I can’t inspect the guest to confirm
because ssh uses the same broken path. If the fix is moving it to another host, what’s the
safe procedure with an attached volume (vol_vgnp2n1jp22q3qj4)? I’d rather not clone into an
empty volume.

Tanks!

2

Hm… There’ve been a string of these lately…

https://community.fly.io/t/fly-ssh-times-out-on-port-22-while-the-tunnel-and-fly-doctor-are-healthy/28661

https://community.fly.io/t/ssh-is-timing-out-all-day/28660

In the first thread, it was mentioned that it was a problem with the underlying physical host machine, and perhaps the same fault has now spread to gru. If you don’t need SSH access over the weekend, it’s probably easier to wait for the fix to that. (That’s my own guess, anyway.)

With PG Flex (if that’s what you’re using), the simplest one to describe is volume forking:

https://community.fly.io/t/urgency-problems-with-postgres-the-database-is-not-responding/19926/2

(Expanding to a multi-node cluster and then shrinking back down is more elegant, but it has nuances.)