We have made some changes to our routing table, can you confirm if this is still ongoing?

Still problems. I will sent more debug info in a few minutes

Hi, this is still ongoing, but it is now ISP/ASN-specific.

Affected source:

• Nicosia, Cyprus
• Cyta / Cyprus Telecommunications Authority (AS6866)
• Tested at 2026-09-11 14:03–14:07 UTC

Target:

• ws.slaylands.top
• CNAME: 8okht2xd.up.railway.app
• IPv4: 69.46.46.21

Railway routing headers:

• X-Railway-Edge: gru1
• X-Railway-Upstream-Zone: railway/europe-west4-drams3a
• X-Hikari-Trace alternates between gru1.jrt2 and gru1.469d

Request IDs:

• FUUmNxhPQTCD_SvG55So4g
• taEpCY1uSWCa52PFs_GTAg
• zV-qgDkrSeWsY9BMs_GTAg
• 9pBGmkewTxSXtVEx0-QtfA

Timing:

• ICMP: min 243 ms, max 248 ms, average 244 ms
• Packet loss: 0% across 20 packets
• Time until TLS secure connection: 487–582 ms
• Complete /api/health request: 916–1021 ms
• The service returns HTTP 200 and ready=true

Relevant traceroute section:

195.22.193.240 24 ms AS6762 Telecom Italia Sparkle

195.22.219.153 248–249 ms AS6762 Telecom Italia Sparkle

195.22.219.205 244 ms AS6762 Telecom Italia Sparkle

69.46.46.21 243–244 ms AS400940 Railway

The latency jump therefore occurs inside AS6762, before reaching Railway at gru1.

For comparison, the same machine and Cyta connection reaches

fsn1-speed.hetzner.com in normally 67–69 ms.

The routing change appears to have fixed only some networks:

• Cyprus / Cablenet AS35432: 42–46 ms
• Armenia / G-Core AS202422: 63 ms
• Armenia / House Net AS212183: still 200 ms
• Georgia / Cloud 9 AS57814: 73 ms
• Georgia / TradeZone AS203647: 82 ms
• Germany / Hetzner AS24940: 10–12 ms

Globalping results:

https://globalping.io?measurement=2M4McJ8OupeLBhs44000217GO

https://globalping.io?measurement=2I9Lr26JpkPH0wj7F000217GP

It looks like withdrawing Lumen fixed some paths, but traffic from

AS6866 via AS6762 is still being carried to São Paulo. Could you please

check the route for AS6866 and AS212183 as well?

I can provide the affected public source IP privately if needed.

@Railway team: Something is wrong guys!

Similar issue is faced by us! If this is Cloudflare issue, please escalate to Cloudflare and with them to fix this!

cf-connecting-ip:  3.7.220.174          ← Plivo's IP (AWS Mumbai)

cf-ipcountry:      IN

cf-ray:            a396db24b95a3b2e-BOM ← Cloudflare Mumbai edge

x-forwarded-for:   172.69.178.250, ...  ← 172.69.x.x is a Cloudflare egress IP

x-plivo-signature-v3: Q2707c3JSk...     ← proves this IS the Plivo telephony connection

x-railway-edge:    gru1                 ← Railway São Paulo

Thank you for this data. I have raised this with our networking engineer. We will follow up when we have more information to share.

Still problems guys

We're still verifying the routing for the remaining affected networks (AS6866 via AS6762 and AS212183), and we'll update you here once we have more to share.

Thanks, Keep us posted. We have already shifted critical traffic to GCP! This issue has impacted the latency in our application.

Any idea what is the issue ? Is it with Railway.com or other network providers!

Im using cloudflare tunnel. Cloudflared inside a pod. It helps fully to avoid broken railway edge.

I think I'll keep this solution permanently, as such response delays are unacceptable for my application.

We made additional changes to routing. It would be much appreciated if you could confirm whether they made an improvement for you, even if you choose to keep Cloudflared.