Railway threads that smelled exactly like a network/MTU/peering problem reached the endpoint, request logged fine, response stream cut mid-flight turned out repeatedly to be an HTTP-client bug, not the network at all. In those cases Node's built-in global fetch reached the endpoint fine while the request failed only when it went through node-fetch, and static IPs, IPv4-first DNS, and a region change didn't help because they were aimed at a network problem that wasn't there. A client-side stream/keepalive bug on HTTPS specifically (while SMTP goes through a totally different library) would look exactly like what you're describing. So would a TLS-inspection middlebox on the return path that only mangles 443

ip route get 152.55.180.240

iptables -t mangle -A OUTPUT -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --set-mss 1360

If the call that reliably timed out completes once you clamp MSS to ~1360, you have a bulletproof MTU-blackhole reproduction and Railway can't hand-wave it. (You may not have _CAP_NET_ADMIN in the container to run iptables — if it's denied, that itself is worth noting, and you fall back to the packet-size test above plus a tracepath.)

tracepath -n .salesforce.com

look for the hop where MTU drops / where it stalls

your Salesforce calls go through Node, hit the same endpoint via curl and via global fetch/undici side-by-side. If curl succeeds where your app hangs, it's not the network and MSS clamping won't help you — it's your HTTP client.