Custom domain verification stuck during website migration
jasoneka
PROOP

2 months ago

  • Project: ae1a35af-5139-46a3-a206-f99b772968bd
  • The domain: sherpany.com
  • The TXT record is being verified: railway-verify=ad9cbdbc3fa393de049b70ede29daabb1ef1d2166abd57bdc9bd0182cdf80695
  • Error message: "Cannot delete custom domain: an operation is already in progress" when I tried to delete domain and re-add it again
Solved

9 Replies

chandrika
EMPLOYEE

2 months ago

Your TXT verification record at _railway-verify.sherpany.com has propagated correctly. However, the domain's DNS is not yet pointing to Railway - it currently resolves to Cloudflare IPs. The CNAME (or equivalent ALIAS/flattened record, since this is an apex domain) needs to point to rashe73n.up.railway.app for the certificate to issue and verification to complete.

Regarding the "cannot delete custom domain: an operation is already in progress" error, we're aware of this issue and are looking into getting the domain unstuck for you.


Status changed to Awaiting User Response Railway 2 months ago


jasoneka
PROOP

2 months ago

ok, so you are saying that we are good to try again and this time after changing CNAME to proper value both will be shown as verified? I want to double check as I still see TXT records as not verified


Status changed to Awaiting Railway Response Railway 2 months ago


2 months ago

The domains should be all good for you. The "Updating domain" you see is just in the UI and will be updated on a redeploy


Status changed to Awaiting User Response Railway 2 months ago


Status changed to Solved jr 2 months ago


jasoneka
PROOP

2 months ago

Ok, we are trying it again right now but it is still not working. for root even cname is not verified while for www I can see that only cname is verified even though all records are available

dig TXT _railway-verify.www.sherpany.com +short

"railway-verify=d0cefc3858d4c288c79a8b6204278170ef5f614dc48ac1f15ec902c40bd978b1"

dig TXT _railway-verify.sherpany.com +short

"railway-verify=ad9cbdbc3fa393de049b70ede29daabb1ef1d2166abd57bdc9bd0182cdf80695"

dig CNAME www.sherpany.com +short

qc1ap9t1.up.railway.app.

however we can't add CNAME to the root, we are adding it as an ALIAS / ANAME

dig ANAME sherpany.com +short

151.101.2.15

dig ALIAS sherpany.com +short

151.101.2.15

Is it even supported?


Status changed to Awaiting Railway Response Railway about 2 months ago


jasoneka
PROOP

2 months ago

Here is how it looks on our DNS provider side - we are using Constellix

Attachments


jasoneka
PROOP

2 months ago

We can't move our dns to cloudflare but what we also tried was:

Use a www subdomain as the canonical address

If you can't change DNS providers:

  • Point www.sherpany.com → CNAME → Railway hostname (works fine, CNAMEs are allowed on subdomains)
  • Redirect @ (root) → www at the DNS/registrar level (many registrars offer "URL redirect" or "forwarding" for the apex)

Sadly, it didn't help

Is there any other way to get it working with Railway?


parmstar
EMPLOYEE

2 months ago

Yes, ANAME/ALIAS records are supported for apex domains. Your Constellix ANAME configuration pointing to the Railway target looks correct in the screenshot.

However, the root domain sherpany.com is no longer present in our domain system, likely due to the stuck operation from earlier. You should be able to re-add it now as a custom domain. Once re-added, you'll receive a new CNAME target value - update your Constellix ANAME record to point to that new target.

Your www.sherpany.com is fully working with a valid certificate. The TXT record showing as unverified in the UI for www is a cosmetic display issue and does not affect functionality.


Status changed to Awaiting User Response Railway about 2 months ago


jasoneka
PROOP

2 months ago

Ok removing and re-adding domains did the trick and we could properly finish the process. Thank you.

Right now we are seeing some slowness with the app even when using https but pretty quick when we hit http

➜ claude curl -w "ttfb: %{time_starttransfer}s\n" -o /dev/null -s https://sherpany-website-prod.up.railway.app/en

ttfb: 2.380043s

➜ claude curl -w "ttfb: %{time_starttransfer}s\n" -o /dev/null -s http://sherpany-website-prod.up.railway.app/en

ttfb: 0.063517s

Attachments


Status changed to Awaiting Railway Response Railway about 2 months ago


parmstar
EMPLOYEE

2 months ago

The HTTP request is not actually serving your page - it returns a 301 redirect to HTTPS, which is nearly instant. The HTTPS request is the one that actually renders the page (including all your database queries). That's why the TTFB difference is so large. You can confirm this by adding -L (follow redirects) to your HTTP curl command, which will show similar timing once it follows the redirect to HTTPS.


Status changed to Awaiting User Response Railway about 2 months ago


Railway
BOT

2 months ago

This thread has been marked as solved automatically due to a lack of recent activity. Please re-open this thread or create a new one if you require further assistance. Thank you!

Status changed to Solved Railway about 2 months ago


Welcome!

Sign in to your Railway account to join the conversation.

Loading...