Our production shipment preparation is blocked by selective outbound connectivity failures to Allegro. One Railway service cannot establish TCP/443 connections to api.allegro.pl or allegro.pl, while another service running the same application version can connect to the same destinations. We reproduced this with standalone, unauthenticated HTTPS GET / probes outside the application code, using IPv4, fresh connections and normal certificate validation: - On the affected service, DNS succeeds, but TCP does not connect within a 7-second timeout. TLS and HTTP are not reached. - On the working service, TCP completes in about 30 ms, TLS in about 60 ms, and the API root returns HTTP 308 in about 90 ms. - Explicitly selecting each of two resolved Allegro API destination addresses, while preserving hostname/SNI, gives the same difference between services. - Control HTTPS requests to unrelated providers succeed from both services. - Restarting the affected service did not resolve the issue. We have not redeployed it or changed network configuration. The application error is UND_ERR_CONNECT_TIMEOUT. We have recorded exact UTC timestamps, public egress addresses and service identifiers, but are withholding those infrastructure details from this public thread. Could Railway provide a private channel to share the full diagnostics and investigate egress/NAT/routing or source-dependent filtering? We do not yet know whether the issue is on Railway, an upstream network or the destination side. Please advise the least disruptive recovery option and do not restart, redeploy or change production configuration without our approval.

Production outage: outbound TCP/443 to Allegro times out on web, works on worker

erpajans

HOBBYOP

4 days ago

Our production shipment preparation is blocked by selective outbound connectivity failures to Allegro. One Railway service cannot establish TCP/443 connections to api.allegro.pl or allegro.pl, while another service running the same application version can connect to the same destinations.

We reproduced this with standalone, unauthenticated HTTPS GET / probes outside the application code, using IPv4, fresh connections and normal certificate validation:

On the affected service, DNS succeeds, but TCP does not connect within a 7-second timeout. TLS and HTTP are not reached.
On the working service, TCP completes in about 30 ms, TLS in about 60 ms, and the API root returns HTTP 308 in about 90 ms.
Explicitly selecting each of two resolved Allegro API destination addresses, while preserving hostname/SNI, gives the same difference between services.
Control HTTPS requests to unrelated providers succeed from both services.
Restarting the affected service did not resolve the issue. We have not redeployed it or changed network configuration.

The application error is UND_ERR_CONNECT_TIMEOUT. We have recorded exact UTC timestamps, public egress addresses and service identifiers, but are withholding those infrastructure details from this public thread.

Could Railway provide a private channel to share the full diagnostics and investigate egress/NAT/routing or source-dependent filtering? We do not yet know whether the issue is on Railway, an upstream network or the destination side. Please advise the least disruptive recovery option and do not restart, redeploy or change production configuration without our approval.

$10 Bounty

2 Replies

Railway

BOT

4 days ago

This thread has been opened as a bounty so the community can help solve it.

Status changed to Open Railway • 4 days ago

chemistpath

HOBBY

3 days ago

The symptoms point directly to an IP block by Allegro's edge firewall targeting the specific egress IP of the affected service. Because Railway assigns egress IPs dynamically, the fastest and least disruptive recovery option is to trigger a clean redeploy of the affected service without making any code or configuration changes.

sundayabasi684-byte

FREE

4 hours ago

Railway handles outbound traffic through dynamic egress IPs assigned to host nodes. When a third-party API provider like Allegro blocks or throttles a specific source IP due to rate-limiting or firewall rules, services pinned to that host node encounter a 7-second TCP connection timeout, while other services on different nodes succeed.

Because standard container restarts can preserve the underlying host slot allocation, trigger a clean redeploy of the affected web service from your dashboard or toggle Static Outbound IPs on the Pro plan to force a new egress IP assignment and bypass the destination-side block.

Welcome!