Podcasting & Cloudflare Issues

[whistles]

I have been using Clouflare for all my websites for many years but in the past 6 months have run into problems podcasting.

I only put my actual feed through CF and the files are routed directly, has worked fine, for literally years.

But in the past 6 months 1 specific podcasting site TuneIn.com no longer reads my feed correctly.

The only factor seems to be CF (after MUCH digging and support messages!).

My question is now, do I ByPass Cache on the feed url?

Would that solve it do you think? It’s not really what I want to do but I’m kind of stumped!

As a bit of background it appears that it is well known in Podcasting circles that CF and Podcasting dont work well together, as explained in this thread from a forum relating to the Wordpress Plugin I use to generate my feed: My 3 latest episodes aren’t showing up on Spotify/Apple even with the feed… | WordPress.org

Here are technical answers to your questions…

Cloudflare have always had issues with podcasting, feeds and media specifically. Cloudflare will randomly block IP addresses where Apple podcasts’s servers pull podcast feeds.
They also will randomly block HEAD requests, a feature required for most podcasting apps. Cloudflare blocks the IP’s because Apple does not have reverse pointer records to their servers, while blocking HEAD requests is a security technique to block hackers who may be scanning pages for security issues. If you did not notice issues until now, either you were lucky or you may have had issues and were not aware of them. We have never seen a podcast work well with Cloudflare unfortunately.

Your media files do not appear to be an issue, its your feed and your services where you are hosting your podcast feed appear to be serving a previous version of your feed, what we are referring to as a cached copy. As Mike noted you can view this behavior in a browser to see for yourself adding a ?value=random to the URL you have the episode there, while the original URL without the ?value=random does not, indicating that the version of the feed for the URL you submitted to Apple, etc… is an older one cached by either your web server your caching provider, aka Cloudflare.

[sdayman]

@whistles

you can view this behavior in a browser to see for yourself adding a ?value=random to the URL you have the episode there, while the original URL without the ?value=random does not,

Have you seen the above behavior with one of your Feed URLs?

Apple has a feed validator that might help:

Validate your podcast RSS feed - Apple Podcasts for Creators

Certainly, you can use a Page Rule to match a URL with a wildcard (just to be safe):

Match: example.com/podcastfeedpath* and a Cache Level of Bypass.

[whistles]

The podcast is listing and playable absolutely fine everywhere except TuneIn
Validates fine, no issues at all.
I actually have a ? in my feed url anyway!
It’s really odd and really annoying that they dont have a proper support system.
It’s only 1 site so I’m not overly concerned atm, but if it occurs elsewhere then

[whistles]

@sdayman

Have you seen the above behavior with one of your Feed URLs?

My feed has a ? in it all the time anyway, if I load the feed it’s the up to date feed.

[whistles]

@sdayman

Certainly, you can use a Page Rule to match a URL with a wildcard (just to be safe):

Match: example.com/podcastfeedpath* and a Cache Level of Bypass

I’m hesitant to do this as the RSS get hammered by (legit) podcast scrappers and the hosting is just a simple shared hosting plan

[sdayman]

I plead ignorance in Feed URLs. Can you post one that mimics your format? I’m thinking that if you can push it to a Worker when you update it, the caching issue can be avoided and it wouldn’t be subject to your shared hosting limits.