Deleted permanent redirect still in effect

I created a permanent redirect page rule and deleted it.

Several hours after the deletion, the rule is still in effect.

The only way to get the DNS working is to disable the Cloudflare proxying for the apex domain’s A record.

Enabling, the Cloudflare proxy results in a 301 response.

How do I revert this?

301 redirects are “permanent” so it may be cached by your browser. Try clearing your browser cache or use incognito/private mode to verify if the redirect has been deleted.

As you say it’s gone when not proxied, can you give the URL that’s being redirected.

I get the 301 response using curl -i domain.com seconds after enabling the proxy and a proper response seconds after disabling it.
It is not a browser cache issue.

What is the domain/URL?

Do you have any other Page Rules or Redirect Rules?

The domain is letsadopt.net. At the moment the proxying is disabled and you will see it working.

I added a bulk redirect for www per the docs here.

When you are able, you can re-enable the proxy and run a request through the trace tool which will show how the Cloudflare pipeline is handling it and where any redirect may be…
https://dash.cloudflare.com/?to=/:account/trace

Sure. Give me a minute.

Looks like the issue is not due to an existing redirect rule, rather it is a cached 301 redirect by Cloudflare.

{
  "trace": [
    {
      "step_name": "file_upload_scan",
      "type": "product",
      "matched": false,
      "public_name": "Uploaded Content Scanning",
      "zoneName": "letsadopt.net"
    },
    {
      "step_name": "api_shield",
      "type": "product",
      "matched": false,
      "public_name": "API Shield",
      "zoneName": "letsadopt.net"
    },
    {
      "step_name": "http_request_firewall_managed",
      "type": "phase",
      "matched": false,
      "public_name": "WAF Managed Rules",
      "trace": [
        {
          "step_name": "77454fe2d30c4220b5701f6fdfb893ba",
          "type": "ruleset",
          "matched": false,
          "description": "Created by the Cloudflare security team, this ruleset is designed to provide protection for free zones",
          "name": "Cloudflare Managed Free Ruleset",
          "kind": "managed"
        }
      ],
      "zoneName": "letsadopt.net"
    },
    {
      "step_name": "http_request_redirect",
      "type": "phase",
      "matched": false,
      "public_name": "Bulk Redirect Rules",
      "trace": [
        {
          "step_name": "459ab0a9885448dbaa1acb9521f2749b",
          "type": "ruleset",
          "matched": false,
          "name": "default",
          "kind": "root"
        }
      ],
      "zoneName": "letsadopt.net"
    },
    {
      "step_name": "request_managed_headers",
      "type": "product",
      "matched": false,
      "managed_headers": [
        {
          "id": "add_client_certificate_headers",
          "enabled": false
        },
        {
          "id": "add_visitor_location_headers",
          "enabled": false
        },
        {
          "id": "remove_visitor_ip_headers",
          "enabled": false
        }
      ],
      "zoneName": "letsadopt.net"
    },
    {
      "step_name": "response_managed_headers",
      "type": "product",
      "matched": false,
      "managed_headers": [
        {
          "id": "remove_x-powered-by_header",
          "enabled": false
        },
        {
          "id": "add_security_headers",
          "enabled": false
        }
      ],
      "zoneName": "letsadopt.net"
    }
  ],
  "status_code": 301
}

Yes, I forgot it’s longer than I thought. See…

Meaning if I disable the proxy and wait for a couple of hours, the redirect should be gone?

I’ve never seen cloudflare place a location with a :443 appended. Are you resting curl against your origin in http and https when unproxied?

HTTP/2 301 
< date: Thu, 11 Apr 2024 17:44:52 GMT
date: Thu, 11 Apr 2024 17:44:52 GMT
< content-type: text/html; charset=UTF-8
content-type: text/html; charset=UTF-8
< location: https://letsadopt.net:443/
location: https://letsadopt.net:443/
< cache-control: private
cache-control: private

I do an http > https redirect server-side. It is a legacy solution. When not proxied, it works.

Quicker to purge the cache if you can.

Is your SSL set to Full (Strict)?

1 Like

I did a purge, it did not seem to help.

Nope, it is on flexible atm. I was planning to switch to full (strict) after I make sure the redirects work.

I always forget the obvious, as spotted by @cscharff.

As you are on Flexible, requests are going to your origin by HTTP, even if HTTPS is requested. The redirect is on your origin…

curl -I http://34.117.21.142 -H "Host:letsadopt.net" --insecure
HTTP/1.1 301 Moved Permanently
Cache-Control: private
Location: https://letsadopt.net:443/
Content-Length: 0
Date: Thu, 11 Apr 2024 18:01:02 GMT
Content-Type: text/html; charset=UTF-8
1 Like

So you’re redirecting requests sent on https through Cloudflare to http which has a redirect on the origin to redirect to http.

1 Like

Oh, I see.

It is fair to share that this became an issue, only after I introduced the redirect page rule mentioned above.