3 months ago
We are running multiple services on Railway behind Railway's provided Cloudflare tunnel. We are observing intermittent connection failures where requests routed through the Cloudflare tunnel fail to reach internal Railway services. Using Railway's network logs, we have identified that TCP SYN packets are being dropped with a drop cause of TCP_INVALID_SYN at a rate of 1-2 per min.Network flow example:
flowId: e7f5c1f3-b848-4340-b028-81424a176016
captureStart: 2026-04-09T20:51:17.236781073Z
captureEnd: 2026-04-09T20:51:17.236793074Z
flowState: partial
srcAddr: fd12:fa72:697b:0:8000:e8:3134:760
dstAddr: fd12:fa72:697b:0:e000:1b:578f:a52c
srcPort: 33392
dstPort: 7080
l4Protocol: tcp
byteCount: 86
packetCount: 1
direction: ingress
l4LatencyMs: 1
peerKind: service
dropCause: TCP_INVALID_SYN
serviceId: 01ee8249-e822-4850-a71e-645692292ede
deploymentId: faeb1f0b-26cb-43ae-86fa-39b16f78a968
deploymentInstanceId: dcc28072-ef7e-4b3c-a5cf-2b967402f052Key observations:
- The source address fd12:fa72:697b:0:8000:e8:3134:760 is our Railway-provided Cloudflare tunnel service
- The destination fd12:fa72:697b:0:e000:1b:578f:a52c is an internal Railway service being proxied by the tunnel
- Both are Railway internal IPv6 ULA addresses (fd12:fa72:697b::/48)
- A single SYN packet arrives (packetCount: 1, flowState: partial) with no response — the TCP handshake never completes
- The drops appear specific to traffic originating from fd12:fa72:697b:0:8000:e8:3134:760 (the Cloudflare tunnel) — we have not observed the same pattern on direct service-to-service traffic that does not pass through the tunnel
Please reference flow ID e7f5c1f3-b848-4340-b028-81424a176016 as a concrete example. We are happy to provide additional flow IDs if helpful.
1 Replies
Status changed to Awaiting Railway Response Railway • 3 months ago
3 months ago
This thread has been marked as public for community involvement, as it does not contain any sensitive or personal information. Any further activity in this thread will be visible to everyone.
Status changed to Open Railway • 3 months ago
a month ago
A single SYN with flowState: partial usually means Railway saw the first packet but did not see a valid continuation of the handshake. That points below HTTP/app code.
I'd split the test into two paths:
- Direct service-to-service over the private Railway domain, bypassing the tunnel.
- Tunnel to the same destination/port, with the tunnel service restarted and keepalive/reused connections reduced if you control that layer.
If only tunnel traffic drops, collect 5 to 10 flow IDs with src/dst/ports and hand those to Railway as a gateway/tunnel routing issue. On your side, make sure the tunnel target is a stable private domain + port, not a URL/hostname that can resolve differently per deploy.
Also check whether the tunnel keeps stale connections after destination redeploys. Restarting the tunnel service and seeing the drops disappear temporarily would be a useful signal.