P0 production incident affecting Railway custom domains from Moscow/RU routes. Affected project: Apikley (project 84b2c35b-d892-4a91-aa89-a8ab539554f4, environment production). Affected domains and assigned endpoints: - apikley.ru -> 69.46.46.106: TLS ClientHello is reset / connection times out before HTTP. - app.apikley.ru -> v52ohovf.up.railway.app -> 69.46.46.31: same failure. - Control: api.apikley.ru -> d1msyp98.up.railway.app -> 69.46.46.28 works normally. Railway trace from the affected Moscow host: - pop=ams1 - node=9qww - route=production-hikari-dpams-4 Proof this is edge routing/binding, not the applications: - Both services are healthy and their Railway-provided *.up.railway.app domains return HTTP 200. - Custom-domain status is ACTIVE, DNS propagated, certificates VALID, target port 8080. - Production deploy SHA 9cc33c3b0212 succeeded; fresh redeploys of both frontend services at 2026-07-10 19:46 UTC also succeeded and did not change the symptom. - `curl --resolve apikley.ru:443:69.46.46.28 https://apikley.ru/` returns 200 with valid TLS and correct content. - `curl --resolve app.apikley.ru:443:69.46.46.28 https://app.apikley.ru/` returns 200 with valid TLS and correct content. - The same tests through 69.46.46.47 also return 200. - Normal DNS-selected .106/.31 paths reset before application code. Self-service attempts already tried: - Re-applied app.apikley.ru target port 8080: control-plane updated, no recovery. - Certificate retry is unavailable because certificates are VALID. - We did NOT delete/re-add production domains: a disposable custom-domain test proved each re-add rotates to a new required CNAME, which would require synchronized DNS changes and risks global downtime. Request: please manually repair/rebind the custom-domain routes/certificates on the affected ams1 ingress endpoints, or reissue reachable edge targets WITHOUT deleting the production domain objects. This matches recent regional custom-domain TLS cases that were fixed by an internal edge rebind.

P0: regional TLS resets for Apikley custom domains on Railway edge .31/.106 (ams1)

salve2023

FREEOP

a month ago

P0 production incident affecting Railway custom domains from Moscow/RU routes.

Affected project: Apikley (project 84b2c35b-d892-4a91-aa89-a8ab539554f4, environment production).

Affected domains and assigned endpoints:

apikley.ru -> 69.46.46.106: TLS ClientHello is reset / connection times out before HTTP.
app.apikley.ru -> v52ohovf.up.railway.app -> 69.46.46.31: same failure.
Control: api.apikley.ru -> d1msyp98.up.railway.app -> 69.46.46.28 works normally.

Railway trace from the affected Moscow host:

pop=ams1
node=9qww
route=production-hikari-dpams-4

Proof this is edge routing/binding, not the applications:

Both services are healthy and their Railway-provided *.up.railway.app domains return HTTP 200.
Custom-domain status is ACTIVE, DNS propagated, certificates VALID, target port 8080.
Production deploy SHA 9cc33c3b0212 succeeded; fresh redeploys of both frontend services at 2026-07-10 19:46 UTC also succeeded and did not change the symptom.
curl --resolve apikley.ru:443:69.46.46.28 https://apikley.ru/ returns 200 with valid TLS and correct content.
curl --resolve app.apikley.ru:443:69.46.46.28 https://app.apikley.ru/ returns 200 with valid TLS and correct content.
The same tests through 69.46.46.47 also return 200.
Normal DNS-selected .106/.31 paths reset before application code.

Self-service attempts already tried:

Re-applied app.apikley.ru target port 8080: control-plane updated, no recovery.
Certificate retry is unavailable because certificates are VALID.
We did NOT delete/re-add production domains: a disposable custom-domain test proved each re-add rotates to a new required CNAME, which would require synchronized DNS changes and risks global downtime.

Request: please manually repair/rebind the custom-domain routes/certificates on the affected ams1 ingress endpoints, or reissue reachable edge targets WITHOUT deleting the production domain objects. This matches recent regional custom-domain TLS cases that were fixed by an internal edge rebind.

Solved$10 Bounty

8 Replies

Railway

BOT

a month ago

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

Status changed to Open Railway • about 1 month ago

javierdmgz2023

HOBBY

a month ago

Looks like your site and app are fine — the problem is on Railway’s side.

Some users, especially from Moscow/Russia, are getting routed through a broken Railway endpoint, so the connection fails before it even reaches your app. Your deployments, SSL certificates, DNS, and services all seem healthy.

Don’t delete or re-add the domains, because that could change the DNS targets and cause more downtime.

The best move is to contact Railway support and ask them to fix or rebind the custom-domain routes for apikley.ru and app.apikley.ru on the ams1 edge.

You can send them this:

“Please repair or rebind the custom-domain TLS/routing for apikley.ru and app.apikley.ru on the affected ams1 ingress. Please don’t delete or recreate the existing domain records, since that could require DNS changes and cause extra downtime.”

The broken IPs are 69.46.46.106 and 69.46.46.31. The same domains work normally through 69.46.46.28 and 69.46.46.47, so this looks like a Railway edge-routing issue.

Best of luck!

0x5b62656e5d

MODERATOR

a month ago

Seems like this is related to your region/ISP, as I'm able to access your site just fine. If that's the case, your only option would be to use a VPN to connect to your sites.