Custom domain stuck - Let's Encrypt rate limited after repeated "internal error" cert failures
danitechdev
HOBBYOP

a month ago

Hi team/community,

My custom domain api.tradivr.com is unable to issue a TLS certificate. The

first

several attempts failed with "An internal error occurred. Please retry or

contact support." After those repeated internal failures, I'm now hitting

Let's Encrypt's per-hostname rate limit: "Failed to issue TLS certificate.

Let's Encrypt rate limit reached. Please wait before retrying."

Setup

  • Service: @tradivr/api (Node/Express monorepo, building cleanly,

    /health responds correctly on the auto-generated *.up.railway.app URL)

  • Custom domain: api.tradivr.com

  • Target port: 8080 (matches PORT env var Railway injects)

  • Registrar / DNS: Hostinger

DNS records added in Hostinger (both verified propagating via Google DNS):

  • CNAME api kwfi0ldw.up.railway.app
  • TXT _railway-verify.api railway-verify=6dcba811af69580ff3fc989d

fdc8018b06a664d1b0e530584f6a08d8b03f6938

Verified with nslookup against 8.8.8.8:

api.tradivr.com  ->  kwfi0ldw.up.railway.app  ->  66.33.22.147

_railway-verify.api.tradivr.com TXT returns the exact value above. I deleted and ended with with new CNAME value this:  qz7mhzzz.up.railway.app

What I tried

  1. Removed and re-added the custom domain entry multiple times. Each

re-add

 gave a new CNAME target (xtmtivco -> t149aigt -> kwfi0ldw) but the TXT 

 verification token stayed identical.

2. Updated Hostinger DNS each time to match the new CNAME target Railway

 showed.

3. Used "Try Again" between attempts — each failed with the internal error

 before eventually returning the Let's Encrypt rate-limit message.

I suspect Railway's internal cert-issuance pipeline failed for reasons

unrelated to my DNS (DNS has been correct the entire time), and those

failures consumed my Let's Encrypt validation attempts.

Could you:

  1. Look at the cert-issuance attempts for api.tradivr.com on my service

    and see why the initial requests errored internally.

  2. Once the rate limit window clears, trigger a manual cert issuance, OR

    confirm a workaround.

Project ID: 7e5dd7fa-5dd7-479f-8992-5ff52e1efcbf/service/f983c1d6-c3b5-4d9e-8cbd-72b9af0b2de0?environmentId=c0c8eed8-0fdb-4093-986f-d903dd73b64f

Thanks.

$10 Bounty

1 Replies

Status changed to Open Railway • about 1 month ago

sheeki03
FREE

a month ago

Stop deleting and re-adding the custom domain for now. Each re-add can rotate the Railway target and create another certificate attempt. Since Let's Encrypt is already rate limiting the hostname, the priority is to make DNS match the current Railway dashboard value once, then wait for the CA limit to clear.

Right now the important mismatch is the app hostname:

api.tradivr.com CNAME -> lgjfegal.up.railway.app
_railway-verify.api.tradivr.com TXT -> railway-verify=6dcba811af69580ff3fc989dfdc8018b06a664d1b0e530584f6a08d8b03f6938

Your post says the latest Railway CNAME target is qz7mhzzz.up.railway.app, but DNS is still returning lgjfegal.up.railway.app. The TXT verification can be correct while the actual app hostname is still pointed at the previous Railway target.

Suggested fix:

  1. Open the service's Public Networking settings and copy the current CNAME target shown for api.tradivr.com.
  2. In Hostinger, leave the TXT record as-is if it still matches Railway's dashboard.
  3. Replace the api CNAME with exactly the current Railway target. Do not leave any old api CNAME record in place.
  4. Avoid deleting/re-adding the Railway custom domain again while waiting. That can rotate the target and make DNS chase a moving value.
  5. Wait for DNS propagation and the Let's Encrypt per-hostname rate limit window to clear. While waiting, also verify CAA, DNSSEC, and any Cloudflare/proxy behavior if applicable.
  6. Once the rate limit clears and DNS matches the dashboard target, let Railway issue the certificate. If it still fails after DNS matches and the limit clears, open a private support thread because the earlier "internal error occurred" failures may need staff-side certificate job cleanup.

Two extra checks:

  • Check CAA records for tradivr.com; if present, make sure Let's Encrypt is allowed.
  • If Hostinger has any separate A/AAAA records for api.tradivr.com, remove them. For this subdomain, use the CNAME plus the verification TXT. DNS tools may still show an A result after following the CNAME, but there should not be a separate Hostinger A record competing with the CNAME

Welcome!

Sign in to your Railway account to join the conversation.

Login
Loading...