TLS handshake fails from source IP 88.212.249.244
usman-3103
HOBBYOP

5 hours ago

Hello Railway Support,

We are experiencing a TLS handshake failure when amoCRM sends webhook requests to our Railway service.

Service domain:

https://web-production-d1975.up.railway.app

Source IP used by amoCRM:

88.212.249.244

Current DNS resolution:

web-production-d1975.up.railway.app → 69.46.46.84

Confirmed diagnostics:

• The TCP connection to port 443 succeeds.

• The client sends a TLS ClientHello with the correct SNI hostname.

• The server does not return a ServerHello or certificate.

• curl reports “SSL connection timeout” or “unexpected EOF while reading”.

• OpenSSL connects at TCP level and sends ClientHello, but receives no TLS response.

• Traceroute/MTR reaches the destination successfully with no final packet loss.

• The failed webhook request does not appear in Railway Network Logs, indicating that it does not reach our application.

• Requests from other sources reach the application and receive HTTP 200.

• amoCRM reports: “net/http: TLS handshake timeout”.

Please check Railway’s edge/CDN routing, firewall, filtering, connection resets, or any blocking affecting source IP 88.212.249.244 when connecting to this hostname over HTTPS port 443.

Please also confirm whether this source IP is being blocked or rate-limited at Railway’s edge.

Thank you.

Awaiting User Response

1 Replies

Railway
BOT

5 hours ago

From our side, that hostname completes the TLS handshake normally and serves a valid certificate for its SNI, and we don't block or rate-limit individual source IPs at our edge on your behalf.

The pattern you describe, TCP connecting and then the handshake hanging after ClientHello with no reset from one network only while other clients succeed, matches filtering on the network path between the caller and our edge rather than at the edge itself. Some Russian ISPs drop traffic to specific edge IPs in the 69.46.46.0/24 range or by SNI hostname, and that would also explain why the request never shows up in your logs. We can't lift ISP-side filtering or assign a different edge IP to your service, and redeploys or region changes don't change the edge IP.

The lasting fix is to put a proxy or CDN in front of the endpoint whose IPs the caller's network can reach, and have amoCRM send webhooks to that hostname.


Status changed to Awaiting User Response Railway • about 5 hours ago


Welcome!

Sign in to your Railway account to join the conversation.

Loading...