UPDATE: Reproduced against Railway's own diagnostic service

The issue can now be reproduced without our application, domain, DNS, certificate, or deployment being involved.

We tested Railway's public diagnostic endpoint:

rlwy-edge-info-production.up.railway.app

From DigitalOcean AS14061 Singapore, the request succeeds with HTTP 200 and Railway reports:

x-railway-edge: sin1

x-railway-upstream-zone: railway/asia-southeast1-eqsg3a

From DigitalOcean AS14061 Sydney, the exact same HTTPS request to the exact same Railway endpoint fails with:

Request timed out during the TLS handshake.

This provides a minimal independent reproduction: same ASN/provider, same Railway endpoint, same HTTPS request, with the source region changed from Singapore to Sydney. The Singapore request succeeds while the Sydney request stalls during TLS

We have independently reproduced what appears to be a regional TLS connectivity issue between DigitalOcean AS14061 in Sydney and Railway's edge.

Impact

Our SMS provider has been unable to reliably deliver HTTPS webhooks to our Railway-hosted application. Its last known source network was DigitalOcean AS14061 in Sydney., which RIPEstat identifies as DigitalOcean AS14061. DigitalOcean's published geofeed places the containing 209.38.16.0/20 prefix in Sydney, NSW.

We reproduced the failure independently using Globalping, without involving the SMS provider or our webhook handler.

Testing performed 2026-09-21 08:08–08:12 UTC

Five separate Globalping probes on DigitalOcean AS14061 in Sydney were tested.

Results:

• ai-jane.com.au:443 — 5/5 TCP connections established, then TLS handshake timed out after ~15 seconds.

• supa-production-060b.up.railway.app:443 — 5/5 TCP connections established, then TLS handshake timed out after ~15 seconds.

• railway.com:443 — 5/5 TLS handshake timeouts from the same probes.

• www.cloudflare.com:443 — 5/5 HTTP 200 from the same probes, with TLS completing in 6–12 ms.

• DigitalOcean Singapore → both application hostnames — 4/4 HTTP 200, TLS 5–10 ms.

• DigitalOcean Sydney plain HTTP → both application hostnames — 4/4 successful connections returning Railway's expected HTTP 301 HTTPS redirects.

• Broader geographically distributed HTTPS testing — 17/18 HTTP 200. The DigitalOcean Sydney path was the failure.

DNS resolution succeeds and TCP port 443 connections from DigitalOcean Sydney reach Railway in ~107 ms. TLS is where progress stops.

TCP traceroutes from DigitalOcean Sydney reach the destination, with visible transit through NTT Sydney/Tokyo before Railway's anycast IP.

We also tested both application hostnames locally while pinning them individually to Railway's two IPs. All four TLS 1.2 requests returned HTTP 200 with hostname verification retained.

supa-production-060b.up.railway.app → 69.46.46.67

Both Railway domains are ACTIVE and target port 8080. Railway WAF Under Attack Mode is disabled.

Interpretation

The evidence strongly supports a network/TLS path issue specifically affecting DigitalOcean Sydney → Railway rather than an application, DNS, certificate, or general DigitalOcean problem.

Importantly, railway.com itself exhibits the same TLS failure from these probes, while Cloudflare works normally.

We cannot determine from external testing whether the fault lies with Railway, DigitalOcean, transit, edge filtering, TLS termination, packet loss/MTU, or another transport mechanism.

Request

Could Railway please investigate ingress/TCP/TLS telemetry for connections from DigitalOcean AS14061 Sydney, particularly 209.38.16.0/20, to Railway's edge?

Because these connections establish TCP but stall during TLS, there is no corresponding application-level request for us to diagnose.

Example Globalping measurement IDs:

Sydney → ai-jane HTTPS: 2k4KuCpJEjeitYDQx00021Auw

Sydney → Railway app HTTPS: 2uD2n1MHSLEXzOSwY00021Auw

Sydney → railway.com: 2c6mg8GLxnUTKV4KL00021Auw

Sydney → Cloudflare control: 2RJEHBUvCkLoNb8Iy00021Auw

Singapore → ai-jane: 2EmO2iKgNmJxS28pb00021Auy

Singapore → Railway app: 2btJMaOzmIpvpcfyX00021Auy