Both TXT ownership records match, but the domains are not routing HTTP traffic to Railway. The apex resolves to 104.18.x.x A records and www resolves to the same addresses, so neither name reaches our servers. A root/apex domain requires a DNS provider that supports CNAME flattening or a dynamic ALIAS record, as covered in our root domain guide, which also lists supported and unsupported providers. If your provider does not support it, the options are moving nameservers to one that does, or serving from www with a standard CNAME after removing any redirect or parking record on that subdomain.

Update after the rollback and a controlled test:

• The prior host uses Cloudflare-fronted A records (104.18.26.246 / 104.18.27.246). After deleting and recreating both Railway custom-domain objects, Railway shows “Cloudflare proxy detected” for both apex and www while those Manus A records remain live.
• The fresh Railway targets are www → b2z008i5.up.railway.app and apex → ydws3gex.up.railway.app. Both ownership TXT values resolve exactly at both Hostinger authoritative nameservers plus 1.1.1.1 and 8.8.8.8.
• A clean control subdomain on the same Hostinger zone, railwaytest.keystonebridgeglobal.com, using a direct Railway CNAME and TXT, verified and received a valid Railway TLS certificate. It was then removed.

This suggests the earlier issue may be the existing Cloudflare-fronted Manus A answers being detected before the switch, rather than a general Hostinger/Railway failure.

Can you confirm:

1. Does “Cloudflare proxy detected” update live when DNS changes, or is it cached per custom-domain object?
2. For a www-only direct CNAME cutover, should the message clear and Railway issue its own certificate, or does Railway require a different configuration?

We will test www only first, leaving apex on the prior host. Please route this to a human because the previous attempt’s literal www CNAME still did not verify.

The bounded preflight is scheduled to complete before the 13:55 UTC go/no-go check. No DNS change is authorized until then.

Update after the rollback and a controlled test:

• The prior host uses Cloudflare-fronted A records (104.18.26.246 / 104.18.27.246). After deleting and recreating both Railway custom-domain objects, Railway shows “Cloudflare proxy detected” for both apex and www while those Manus A records remain live.
• The fresh Railway targets are www → b2z008i5.up.railway.app and apex → ydws3gex.up.railway.app. Both ownership TXT values resolve exactly at both Hostinger authoritative nameservers plus 1.1.1.1 and 8.8.8.8.
• A clean control subdomain on the same Hostinger zone, railwaytest.keystonebridgeglobal.com, using a direct Railway CNAME and TXT, verified and received a valid Railway TLS certificate. It was then removed.

This suggests the earlier issue may be the existing Cloudflare-fronted Manus A answers being detected before the switch, rather than a general Hostinger/Railway failure.

Can you confirm:

1. Does “Cloudflare proxy detected” update live when DNS changes, or is it cached per custom-domain object?
2. For a www-only direct CNAME cutover, should the message clear and Railway issue its own certificate, or does Railway require a different configuration?

We will test www only first, leaving apex on the prior host. Please route this to a human because the previous attempt’s literal www CNAME still did not verify.

Controlled www-only result: success. After changing only www to CNAME b2z008i5.up.railway.app (apex remained on the previous Cloudflare-fronted A records), both Hostinger authorities and 1.1.1.1/8.8.8.8 converged on the CNAME. Railway issued a SAN-valid www.keystonebridgeglobal.com certificate in 11 minutes. Strict HTTPS now returns the expected 301 to the still-Manus apex. The Railway panel shows www online while apex alone still shows Cloudflare proxy detected. This is direct evidence that the proxy detection is live and per-hostname; the earlier failed window kept both names on the Cloudflare-fronted prior-host answers until the switch. We will retain the observation window, then separately test the apex ALIAS path.

The www domain is verified with a valid certificate. The proxy detection does re-evaluate per hostname as DNS changes propagate. For the apex, our root domain guide lists your current DNS provider among those that do not support CNAME flattening or dynamic ALIAS records, so the apex cannot point at Railway while the zone lives there. The two options are to move the zone's nameservers to a provider that supports flattening (the guide covers the Cloudflare approach), or to serve traffic from www and redirect the apex to it at the registrar level.