I suggest you move your DNS nameservers to Cloudflare. It will most likely fix your issue.

Thanks for the suggestion, but I'd like to understand the underlying issue before adding Cloudflare to the stack.

I have two other production domains on the same Railway setup that work perfectly with Beget DNS directly — no Cloudflare in front.

Both use identical DNS setup:

• Beget DNS provider
• A @ → Fastly anycast 151.101.2.15
• TXT _railway-verify for ownership
• MX records co-existing at apex
• No CAA records

The Railway/Fastly Let's Encrypt pipeline clearly works for my account on these domains — so it's not a setup issue on my side. Something on Railway's end is preventing the ACME challenge from being triggered for current specifically.

Could you escalate this to your infra team to look at why provisioning isn't happening for this hostname? I'd much rather have a proper diagnosis than work around it with a different DNS provider — especially since the rest of my account works correctly without one.

If there's a specific log entry or attempt history on your side for current cert provisioning, that would help understand whether ACME challenge is being attempted and failing, or not being attempted at all.

I only suggested Cloudflare, because it's generally more reliable than other DNS providers. So, you would encouter less issues while setting up your custom domain. It also has an automatic DNS records configuration when you add a custom domain through Railway's dashboard (less error prone). And your custom domain setup has no flaws, so I suspected it could be an issue related to Let's encrypt/Beget.

With that said, The Railway team usually doesn't get involved when the issue is an Application/configuration problem (not caused by the Railway platform), but they might still help you with your issue.

You can try moving your DNS nameservers to Cloudflare to confirm it's not an issue related to Railway atleast.

My theory is that the issue may not actually be DNS ownership verification, since _railway-verify works correctly and the domain resolves through Fastly.

The reasoning was:

neuro-cadr.ru resolves and reaches Fastly

Fastly serves only the default *.up.railway.app certificate

crt.sh shows no certificate ever issued for neuro-cadr.ru

identical domains on the same account and same Beget DNS setup work correctly

Based on that, the theory is that certificate provisioning may never actually be starting rather than Let's Encrypt failing validation.

Possible causes suggested were:

Hostname attachment may be stuck internally on Railway/Fastly

ACME challenge generation may never be triggered

Certificate provisioning could be queued but stalled

An unnoticed AAAA record or DNS edge case could interfere

Fastly routing for this hostname may not fully attach despite DNS resolving

Another observation was that seeing only the *.up.railway.app wildcard certificate can indicate the hostname reaches Fastly but is not considered fully attached for custom TLS provisioning.

I cannot verify whether this diagnosis is correct, but it seems consistent with the symptoms because no certificate issuance attempt appears in CT logs at all.

Does this theory make sense to someone with knowledge of Railway's certificate provisioning pipeline?

Thanks, that maps to what I see too. I just checked — no AAAA records anywhere on the domain or on the _railway-verify subdomain. Apex has only A 151.101.2.15, MX records, NS, and an SPF TXT — nothing else, no surprises. The IPv6 / DNS edge-case angle is ruled out.

That leaves only the internal-attachment / queued-provisioning theories you mentioned — hostname stuck partially attached on Fastly, ACME challenge never triggered, provisioning queued but stalled. Those would all explain the zero entries in crt.sh perfectly.

None of those are something I can fix from the DNS side. Waiting on Railway staff to look at the Fastly cert-binding state for this specific hostname. Will report back once they reply.

Railway doesn't support A records. Just because it works on other domains doesn't mean you should be using it. You should only be using CNAME records when adding custom domains to Railway.

Thanks — that confirms the issue. I'll move DNS to Cloudflare and set up a proper CNAME at the apex.

Why Cloudflare specifically: my current DNS provider (Beget) doesn't allow CNAME at the root when MX records are present, which is my case (I need MX for the operator email on this domain). Cloudflare supports CNAME flattening, so the apex CNAME pointing to Railway and the MX records can coexist on the same hostname.

One question before I start the migration: once the new CNAME at apex is live in DNS, will Railway pick it up automatically and trigger cert provisioning on the next check, or should I remove and re-add the custom domain in the Railway dashboard to force a fresh attachment? Want to avoid ending up in the same stuck state.

I'll post back here once the migration is complete with the result.

Update: Issue resolved. Migration complete.

Final setup:

• www.neuro-cadr.ru registered as the Railway custom domain (CNAME on subdomain pointing to the Railway-provided target). Railway issued Let's Encrypt cert within minutes — confirmed subject=CN=www.neuro-cadr.ru, issuer=Let's Encrypt E7.
• Apex neuro-cadr.ru handled outside Railway: Beget hosting site with .htaccess 301-redirect to https://www.neuro-cadr.ru. Beget auto-issued its own Let's Encrypt cert for the apex via their hosting integration.
• Both endpoints work cleanly with valid certs, no warnings.

A few notes for future users hitting the same pattern:

1. The "use CNAME" policy isn't well-surfaced in docs for users coming from older A-record setups that still work. It would help to call out the "delete + re-add custom domain" gotcha — existing A-record domains keep their certs via legacy renewal, but new domains (or re-added ones) silently fail to get certs at all when configured with A records, with zero ACME attempts in CT logs. The failure mode is invisible from the dashboard (DNS shows verified green).
2. I'd suggested a Cloudflare workaround in this thread (CNAME flattening for apex when MX coexists) — confirming that this works technically but is not viable for projects with a Russian audience: Cloudflare's proxy IPs are throttled/blocked by RU ISPs (Discord, Fiverr also unreachable from the same network during testing). The www-canonical route ended up being the cleaner solution.

Thanks for the clarification on the CNAME-only policy — without that hint the silent-failure mode would have eaten a lot more time. Closing this thread.