Got the "misconfigured and will stop working on Friday, August 14" email for

our www subdomain. The email says the record points directly at Railway's

origin IPs. It doesn't. It's a CNAME to exactly the target Railway assigned

under Service > Settings > Networking, and it's proxied through Cloudflare.

The domain works fine. Railway's edge returns 200 for it, and the Let's

Encrypt cert Railway issued for the hostname a month ago is renewing normally.

What I think is happening: when a record is proxied, public DNS returns

Cloudflare's IPs, so Railway's checker never sees the CNAME behind it.

I tested this. Temporarily switching the record to DNS only made Railway read

back the exact target it requires and flip the domain to PROPAGATED within

seconds. Switching the proxy back on reverted it to REQUIRES_UPDATE on the

next check. Nothing about the record changed, only Cloudflare's visibility.

There's also an odd asymmetry. Our apex and our www subdomain are both

proxied and both invisible to Railway's checker (currentValue is empty for

each in the API). The apex sits at PROPAGATED. The subdomain reverts to

REQUIRES_UPDATE. So the subdomain check looks specifically for a CNAME, which

a proxied record can never present, while the apex is evaluated differently.

If that's right, the flag is unsatisfiable for any Cloudflare-proxied

subdomain, and leaving the record unproxied isn't an option for us since it

would drop our DDoS protection.

Two questions:

1. Does Friday's restriction on direct origin access key off this stored

   verification status, or off actual traffic routing? If it's the status,

   every Cloudflare-proxied subdomain gets cut off over a check it can't pass.

2. Is there a supported way to verify a proxied record, or should the checker

   treat "resolves to Cloudflare" as valid rather than misconfigured?

Anyone else on Cloudflare seeing this on a subdomain but not an apex?