Domain proxying not working after updating A record
We're moving from a site on Azure to a WordPress site on WPEngine. We also have a number of existing worker routes we want to keep running for the new location. We tested this setup on a test instance with a
test. subdomain and everything worked fine.
I updated the A record to point to the new hosting and waited for things to propagate (according to DNSChecker.org and other tools) and the DNS seems to work fine and the WPEngine site loads. However, none of the worker routes for the root domain work and requests for the root domain don't show up in the Instant Logs or in the HTTP Traffic. It's like the domain isn't going through CF, although I'm pretty sure it is. I cleared the CF cache and my browser cache multiple times. I also tried running the domain through a CNAME record with no noticeable change.
You can see in the attached screenshot that requests to the root domain dropped off entirely soon after I updated the A record at around 9:30.
I verified there are no Page Rules or Firewall rules applied, the cf- headers are being returned in the HTTP reponses, the DNS points to CF's IP addresses, and Proxy is turned on for the domain's A record.
Strangely, I also ran the beta Trace tool and it returned "hostname does not belong to your account."
All of the above still work fine for any of our subdomains, including the worker routes and Trace. It's just the root domain that's the problem. And when I switched the A record back to the previous site location on Azure, everything started working again. Requests show up in the logs, worker routes are processed, and the Trace tool even works again.
Any ideas what could cause this? Is it some kind of DNS caching thing?
I could simply give things more time to make sure they've propagated fully, but my client can't have their site not functioning for that amount of time. I've already rolled back the migration for tonight after spending a few hours on this.
Any suggestions would be great. Thanks!
4 Replies
Any ideas what could cause this? Is it some kind of DNS caching thing?CF For Saas/SSL4SaaS partner using the old setup where it skips your zone's configuration entirely. WP Engine is a listed partner. If you're Enterprise can ask your CSM to enable special O2O Setting, if non-ent have to still email the PM last I heard a few weeks ago: https://community.cloudflare.com/t/status-of-shopify-o2o-for-non-enterprise-cloudflare-users/382415/10?u=chaika
@Chaika Super helpful. Been digging into this more - you've definitely pointed me in the right direction. So my understanding is that I DO want the O2O (Orange-to-Orange) enabled for our plan?
According to this it appears to be enabled automatically when using CNAME to
wp.wpenginepowered.com for the Advanced Network we're on, even for non-Enterprise customers.
https://developers.cloudflare.com/cloudflare-for-platforms/cloudflare-for-saas/saas-customers/provider-guides/wpengine/
I think I'll experiment again with using the CNAME to hook things up and see if I can get it working, then I might try reaching out to the PM.
Thanks!Cloudflare Docs
WP Engine | Cloudflare for Platforms docs
Learn how to configure your zone with WP Engine.
It gets kind of confusing because there's two versions of CF For SaaS/SSL4SaaS, new which automagically works with your zone's settings and old which requires custom enablement, both of which are "O2O".
I think I'll experiment again with using the CNAME to hook things up and see if I can get it working,Were you not using a CNAME before? Worth noting even the new version 100% will not work/apply your config with A/AAAA records, only with CNAME. If that was the case then yea -- try with CNAME, if still no work they're using the old setup that needs custom enablement. Trace saying
hostname does not belong to your account is a good way of telling, you can also use a simple Transform Rule Modify Response Header Rule something simple like thispassedthroughmyzone yes to easily tell, or if you're fancy zone Dynamic: cf.zone.nameYep, the CNAME seemed to solve it.
I recall I'd tested it with CNAME at one point, but WPEngine wouldn't validate the domain and I never saw it propagate. But I also remembered I'd seen that before and tried both with the CF proxy disabled, and it all worked fine. So once it was validated in WPE I went back and turned the proxy back on, and all the traffic started showing up in my CF logs, and was loading the site from WPE. Success!
I also tested a couple of workers routes, and those appear to be working now too.
So it was the CNAME all this time, but with some really complicated underlying circumstances. But a simple solution in the end.
Thanks a lot. This was a big help! I'll also keep note of your other tips at the end, if anything related to this comes up again.