The packet-level instrumentation here is the most direct evidence in any of these related threads — you're not just inferring "the healthcheck isn't reaching it," you've actually observed zero inbound connections on the listening port during the failure window, with a live control (same service, previously healthy) showing connections arriving normally. That's about as close to proof as you can get from outside the platform that this is a proxy/routing issue, not an app-side one.

Two things worth adding to strengthen this before Railway looks at it:

Cross-link to the other open healthcheck threads — there's a cluster of very similar reports right now: "Runtime V2 EU West: new frontend deploys fail healthcheck..." (borrkoli2) and gmazzone79-ctrl's report (US West), both starting around Aug 28. borrkoli2 isolated their fix to the healthcheck path returning a 307 redirect instead of a direct 200 — you mention your app also returns 307 on / (per your loopback test). Worth explicitly testing: point the healthcheck at a route that returns 200 directly and see if it resolves, same as their fix. If it does, that ties your case to the same underlying bug even though your symptom (zero inbound connections) looks more severe than theirs (connections arrived but got rejected as unhealthy) — possibly a broader/harder failure mode of the same regression.

If the direct-200 test does not fix it, that's actually a useful negative result — it'd mean your case is a distinct routing failure (proxy never dispatching the healthcheck at all) rather than the redirect-handling bug, and worth explicitly separating from the other threads so Railway doesn't conflate two different bugs under one fix.

Given your last-known-good was Aug 26 (slightly earlier than the ~Aug 28 20:00 UTC onset in the other reports) and you have the strongest direct network evidence of the group, I'd suggest sharing the deployment IDs/timestamps/network capture with Railway support directly rather than waiting on community diagnosis — this looks like it needs someone with access to the proxy's actual routing decisions for your instance.

Answers to your three questions: the healthcheck connects directly to the new deployment's container on its PORT, it never goes through the proxy or your domain, and yes, there's a known change. On Aug 28 we shipped a security fix that stopped the healthcheck from following redirects. Your / returns a 307, which now counts as a failure on every attempt, where before the prober followed it to a 200 and passed. That also reframes your control test: the connections you saw on the healthy instance were live proxy traffic, which the healthcheck never uses, and the probe's connections are brief enough that polling-based observation can miss them. The "service unavailable" wording is our misleading hardcoded log message, and a fix is in review to show the real status code, which was 307 here. Point the healthcheck at a route that returns 200 directly, like a dedicated /healthz. If you saw this same failure on a deploy before Aug 28 afternoon UTC, tell us, that would be something different.