I have tried this on a fresh worker script without any routes associated with the script
This happens both using wrangler dev and in production
I have tried to disable caching with the cf object properties related to caching
I have Full (Strict) SSL enabled on the zone, and have tried the other options as well to no avail.
I can successfully get a response from every other website I’ve tried over SSL.
I can successfully curl the above domain
The host has SNI enabled, and cipher suites Cloudflare supports (according to SSL Labs)
For some reason, in the worker playground, it will successfully fetch this domain if I use the HTTP simulator (see screenshot). This apparently proxies worker requests through the https://dash.cloudflare.com/api/v4/accounts/.../workers/scripts/white-bread-97d2 endpoint…
If any other information is needed, I can provide it.
addEventListener('fetch', function(event) {
event.respondWith(handleRequest(event.request))
})
async function handleRequest(request) {
// Only GET requests work with this proxy.
if (request.method !== 'GET') return MethodNotAllowed(request)
return fetch(`https://deepl.com`)
}
function MethodNotAllowed(request) {
return new Response(`Method ${request.method} not allowed.`, {
status: 405,
headers: {
'Allow': 'GET'
}
})
}
To use it on your domain, you might need to have DNS records pointed (for example A www and A yourdomain.com to 192.0.2.1 and added the active Worker (in production) under the zone to the route like yourdomain.com/*) and setup a Page Rule for the SSL (Full maybe?).
Otherwise it’s the cause as stated from below cite:
I am also having this issue as well with a different endpoint/domain altogether, using the default worker.dev address. It works fine in development/quick edit/preview, but not in production. I get the status 525 returned. Is this a bug with Cloudflare workers?
UPDATE: The endpoint I’m attempting to make secure (HTTPS) fetches to is hosted by AWS
UPDATE 2: I was able to resolve this by setting up a route to the worker using my domain, and ensuring that the SSL settings for my domain on Cloudflare was set to “Full” - For whatever reason, this seems to be an issue when using the default workers.dev route/address and attempting to fetch from AWS and other sources. Just create a route with a subdomain of a domain you can set to “Full” SSL. Otherwise, I’d suggest buying a new domain to use specifically for this purpose. (Did you know Cloudflare offers registrar services, and recently started supporting domain purchases?)
Just so that you know, this will keep your entire site insecure. If you have to pick this insecure mode, it is better to do it via a page rule for that specific path.
Although, I am surprised that would fix it, as a 525 indicates a general SSL issue, which you should also experience on that insecure encryption mode.
I believe you’re mistaken. Setting SSL to “Full” requires a secure connection from the origin/web server to Cloudflare and offers a secure connection (proxy) to visitors connecting to the site. It is “Off” and “Flexible” that are insecure. The only difference between “Full” and “Full (strict)” is that “strict” requires the SSL certificate used for encryption to be issued/signed/cross-signed by a Cloudflare-trusted certificate authority or Cloudflare origin certificate.
In the case of using a domain route for the worker, Cloudflare essentially intercepts the request to your origin and instead directs it to access your worker, but only for the configured routes of that domain.
I can’t say why the workers.dev domain has this issue though, and of course we don’t have access to its SSL settings.
I am not and I am not going to address this yet again. Please use the search.
As long as you are on Full you have an insecure site. I understand in this context it might be tricky, hence the suggestion to only implement it via a page rule.
Plus, it’s not clear why Full should work for aforementioned reason.
