What you're describing is the classic signature of a path-MTU discovery blackhole, and the numbers line up exactly.

Maxis delivers over PPPoE, which costs 8 bytes of the 1500-byte Ethernet frame — that's where 1492 comes from. Your machine advertises an MSS of 1452 (1492 minus 20 IP + 20 TCP) on the SYN. If the far end honours that, everything is fine. If it doesn't, it sends full 1500-byte segments, your router can't forward them, and it's supposed to reply with ICMP Type 3 Code 4 (Fragmentation Needed) so the sender backs off. When that ICMP is dropped somewhere in the path — or the sender ignores it — the large packets just vanish. Nothing is refused, nothing errors. The connection hangs until it times out. That's your ERR_TIMEOUT.

It also explains the two things that look strange:

Why small requests seem fine and the page then dies — the TCP handshake and small packets are under the limit and go through, so the connection looks established. It only breaks when the first full-size segment arrives, which is usually the TLS certificate or the first real response body.

Why only Railway — most large sites sit behind CDNs that clamp MSS at the edge (rewriting the advertised MSS down to fit the path) rather than relying on PMTUD working end to end. Clamping is belt-and-braces and it makes PPPoE users invisible as a problem class. If Railway's edge isn't clamping, PPPoE subscribers are exactly who breaks first.

For what it's worth, I probed a Railway edge address from a clean 1500-MTU path and it accepts DF packets all the way up to a 1472-byte payload, so the edge itself isn't the constraint. I can't test the 1492 return path from here, so I can't prove the clamping behaviour directly — but the fact that lowering your client MTU to 1452 fixes it is itself strong evidence, because 1452 is precisely the value that makes clamping unnecessary.

What you can actually do, given you can't ask users to touch their routers:

Put a CDN in front of your Railway service. Cloudflare in proxied mode is the usual choice and it's free — it terminates TCP at its own edge, clamps MSS, and has PoPs in Kuala Lumpur and Singapore. Your users' connections then terminate on infrastructure that handles PPPoE paths correctly and the Railway leg becomes CDN-to-Railway, which is a clean 1500 path. This is the fix that requires nothing from your users and it's testable in about fifteen minutes.

Worth confirming the diagnosis first so you don't do that work on a hunch. From an affected connection at MTU 1492:

ping -M do -s 1464

1464 payload plus 28 bytes of headers is exactly 1492. If that succeeds and 1465 fails with "message too long" locally but produces silence rather than an ICMP reply from the network, you've confirmed the blackhole.

The underlying fix is on Railway's side — MSS clamping at the edge — and it's worth them treating this as a real bug rather than an exotic edge case. PPPoE is the default for a very large number of residential subscribers across Southeast Asia and Europe, so anyone serving those users hits this. But the CDN route unblocks you today without waiting.

Cloudflare's edge perfectly handles MTU negotiation and MSS clamping with strict ISPs like Maxis.