Someone spammed my original thread with the same response several times so it’s no longer possible to reply to it.
It was established that issues #1 and #3 are related. For some reason, my HSTS and Cache-control headers are being overridden.
The conclusion regarding #2 is that you don’t need to configure anything SSL-related in Cloudflare.
Issue #4 was answered: Workers, which is a paid service.
Issues #5 and #6 were not addressed at all.
Are you effing kidding?
I am taking my effing time to respond to your question, to analyse why your effing domain does not cache because you are unable to configure your server correctly and instead of reading and applying my responses you call me an effing spammer?!
I seriously think I have had it. Seriously, whats wrong with you people! Un-effing-believable!
And no, dont double post!
CF will respect the headers your server sends unless it is overridden in the dashboard.
For cache-control, the caching page under “browser cache expiration” controls whether or not CF changed that header. if it’s “respect existing headers”, cf won’t change the header.
You can check yourself within your browser by
cache-control and strict-transport-security.For HSTS, the ssl/tls->edge certificates page has an option to override the HSTS setting:
If it’s not enabled, it’ll look like this:
When not enabled, CF will return the origin’s HSTS headers to the browser.
It’d be simpler to link all of them 
https://www.cloudflare.com/products/cloudflare-workers/
Custom error pages will only take effect if CF is having issues connecting to your server, or if a user hits a “challenge page” (used to prevent bad bots from getting to your site)
Apps can either run a Cloudflare Worker, meaning they can modify/read the request/response of each request to do stuff like log requests, or they can inject javascript scripts into the page to do stuff like adding notifications or adding a support widget. Note that CSP might need to be changed to allow these apps to be injected if you want to use them.
You can add, manage, and remove apps by going to the “apps” page of the dashboard.
Thank you for your detailed and informative response.
For caching, this is my CF configuration, which is different from the headers being seen by any tool:
The security headers website I linked above and gf.dev both report these two headers that I have never added anywhere on my server:
Cache-control max-age=0, no-cache, no-store, must-revalidate
Pragma no-cache
For HSTS, it turns out that my max-age is set to 0 in CF. That must be the default option that I overlooked during the setup and assumed that a value of 0 wouldn’t modify my existing max-age directive. So that mystery is solved.
Thank you for the links. I’ll admit I haven’t read up on those other features because performance and security are more of a priority. But on the subject of custom error pages, does that include the AlwaysOnline feature? Because the description says it makes CF serve a cached version of my website when it’s offline, but that’s not what happened in my testing. I got the CF error page with the “retry for live version” button.
Regarding apps that run a worker, does that mean they aren’t usable without paying to use their workers?
Apps that use a worker are free (for now; Workers for Apps is fairly new and pricing could change, but they won’t just start randomly charging you if you have one and pricing changes) even when on the default Workers free tier.
It will only crawl your site every few days:
After it crawls your site, it should show the cached version.
Finally:
Browser Cache Control should control the cache header for all non-HTML files to what is set in that browser cache control field, otherwise I’m not sure what else could be setting them. If you’re running some web framework, it’s likely set by that since it doesn’t show up on the files served directly from your server (likely apache/nginx).
