The URL Mingtiandi returns a 403 error message with Cloudflare branding when accessed by the user agent for Mailchimp. This 403 error does appear in the Cloudflare logs and does not appear in the logs for the host. This URL delivers an RSS feed which is accessible via HTTPS, but is not accessible by the Mailchimp user agent. Information on any potential sources of the 403 error would be helpful
What steps have you taken to resolve the issue?
Have worked with Mailchimp support and with support at the host (WP Engine)
What are the steps to reproduce the issue?
Insert the url Mingtiandi into a Mailchimp RSS campaign
More information on this problem with the 403 error.
When we paused Cloudflare for our site, the 403 error persisted.
We have since migrated our DNS from Cloudflare (to AWS) and paused Clloudflare and the 403 error has disappeared.
We would like to identify the source of the 403 error so that we can continue to use Cloudflare.
The 403 error was being received by Mailchimp’s user agent when it tried to access Mingtiandi, however, this user agent did not appear in the error logs.
The IP addresses for Mailchimp’s servers also do not seem to appear in the error logs on Cloudflare, nor did they appear in the error logs for our host.
WPEngine uses Cloudflare, which could explain this, although make sure after pausing you waited a little time for the DNS TTL to expire to be sure.
I would suggest to try this…
Set the DNS records in your Cloudflare DNS to “DNS only”, then switch back to Cloudlfare nameservers. This should be no different from using AWS nameservers as requests will go direct to WPEngine (through their Cloudflare account).
If it is ok, then you can proxy the records, but you must use only the CNAME and not A/AAAA IP addresses, as described here…
That way requests will pass through your Cloudflare account first before going to WPEngine. If you get problems then, check your security event log which will show why the request was blocked… https://dash.cloudflare.com/?to=/:account/:zone/security/events
You can then craft a WAF rule to work round the issue.
If you proxy A/AAAA records pointing to WPEngine, the requests will not pass through your Cloudflare account.
Thanks for the response and this is very helpful information.
We will try transferring the DNS back to Cloudflare on the weekend to avoid too much disruption, however, there’s a question about tracking problems in the security event log.
Now that we have removed Cloudflare from network for our site, we no longer receive the 403 error when accessing our target URL. So the 403 error should have been coming from Cloudflare.
However, in checking Cloudflare’s security event logs, from earlier in the week when the 403 error was being generated, there is no record of an event in the event logs.
Is this possible? What should we be looking at if the problem recurs?
