12 days ago
My TCP Proxy accepts TCP/TLS at the edge but never forwards any bytes to my container. It reproduces on a brand-new service and across multiple proxy clusters and regions, so it looks like an account/infra-level edge routing issue rather than my app.
IDs
- Project: c8e35a65-6d9a-4a4e-a0c3-7aa7e5563f8e (fulfilling-dedication)
- Environment: production (c0b32961-1363-4974-a210-53bffcce9ea9)
- Service: c5270b9a-6e67-4325-8725-c5c2221f460c (TGproxy)
- Latest deployment: bfaf3254-15a3-4cdf-8250-058b96423ac3 (SUCCESS)
- Current TCP Proxy: zephyr.proxy.rlwy.net:37439 (applicationPort 8080)
The container is provably healthy
- Listens on
[::]:8080(dual-stack; accepts IPv4 and IPv6). - Returns a valid TLS handshake when reached via the private domain
<service>.railway.internal:8080and via127.0.0.1:8080from inside the Console. - Outbound egress works.
RAILWAY_TCP_APPLICATION_PORT=8080, matching the app port and the TCP Proxy applicationPort.
External probe (from my machine)
nc -vz zephyr.proxy.rlwy.net 37439→ "succeeded" (TCP connect OK).openssl s_client -connect zephyr.proxy.rlwy.net:37439→SSL handshake has read 0 bytes and written 306 bytes,no peer certificate available. The edge terminates TCP/TLS but 0 bytes ever reach the container.
Already tried (no effect)
- Multiple full redeploys (including after ~2 weeks).
- Region change sfo → europe-west4.
- Recreating the TCP proxy several times — landed on clusters acela, sakura, zephyr, all with the same 0-byte behavior.
- Deleting and recreating the service entirely.
- Scaling replicas 1 → 2 → 1.
Ask: please reattach/refresh the edge→container routing for this service/account so the TCP Proxy forwards traffic to the container. Happy to run any diagnostics.
1 Replies
12 days ago
This thread has been opened as a bounty so the community can help solve it.
Status changed to Open Railway • 12 days ago
2 days ago
The container itself looks healthy: it’s listening on [::]:8080, the TLS handshake works through both the private Railway domain and 127.0.0.1:8080, outbound networking works, and RAILWAY_TCP_APPLICATION_PORT=8080 matches the TCP Proxy configuration.
The key part is that the external connection to zephyr.proxy.rlwy.net:37439 succeeds at the TCP level, but the proxy never sends anything to the container. openssl s_client connects successfully but gets 0 bytes back and no certificate, which is consistent with the edge accepting the connection but the edge→container path not actually forwarding the traffic.
It also doesn’t look like a bad deployment or a single bad host because this has survived multiple full redeploys, changing regions, recreating the TCP Proxy across acela, sakura, and zephyr, deleting/recreating the service, and changing the replica count.
At this point, I’d expect Railway to check the edge routing/attachment for the service or account and verify that the TCP Proxy backend is actually attached to the running container. If the backend attachment/state is stale, reattaching or refreshing the edge→container route would make sense.
The strongest reproduction is simply: nc -vz zephyr.proxy.rlwy.net 37439 - TCP connection succeeds
openssl s_client -connect zephyr.proxy.rlwy.net:37439 - handshake writes data but reads 0 bytes, with no peer certificate
while connecting directly from inside the Railway environment to 127.0.0.1:8080 or the private service domain successfully reaches the application.
So I’d ask the Railway team to specifically investigate the TCP Proxy edge - container backend attachment/routing* rather than the container, port configuration, or application itself