Static vs Dynamic Redirects?

I searched and searched but I have no answer on what’s the difference between the two.

What things need to be present in the redirect to be considered a dynamic redirect?

Isn’t it easier for us to just write the rule and let the system take care of this selection for us?

You tagged this Rules so I assume you’re talking about Single/Dynamic Redirects, and the option here?


This just changes what the target will be. If you pick static, you can just type out the URL you want to redirect to, like https://www.google.com/search?q=free+cookies, and it will redirect to there. Simple.

Dynamic Redirects are more interesting. When you pick Dynamic, you’ll notice the URL input box changes to “Expression”, because these are ruleset engine expressions. You can use various fields now and functions to create the redirect target.
Example, to redirect and keep the path:

There’s other examples here:

Ruleset Engine docs here (not all fields are available)

3 Likes

Thank you that is exactly what I wanted to know!

Regarding matching, other than the wildcard “*”, which is zero or more characters, is there a wildcard to match zero or 1 character or just 1 character?

Redirect Rules/Ruleset Engine does not support wildcard characters like that.
There is regex/matches support, but only for Business Plans or higher.
You can however separate out your match on different fields and use contains/starts with/ends with operators to meet a lot of different matches where otherwise wildcards would be required, ex:


You have fields for Hostname, URI Path, Query String, ssl/tls, etc.
(ex. You could do something like URI Path starts with … and URI Path ends with …)

1 Like

I can see that now. Thanks for clarifying, your answers are always great!

What about page rules? I know they can have *, what about other operators?

I want to match a lot of subdomains that start with zz and have three more random characters a-z,0-9. I deliberately named them like this so it would be easy to match. I also want to match the version with www, so it would look like something like this:

Hostname starts with "zz" OR "www.zz"

I always try to be as specific as possible when creating matching patterns to avoid any unwanted matches in the future. So I was wondering what would be the best operator here to use: STARTS WITH seems more specific than CONTAINS, what will catch more instances?

This works nicely except for one problem:

www.zz falls out of the Universal and Origin SSL’s coverage so it is not redirecting and I get an error ERR_SSL_VERSION_OR_CIPHER_MISMATCH.

This is a problem with a cPanel default feature where in order to host a domain example.com on it, it creates this nonsense subdomain on the main cPanel domain zzzABC.example.net plus a www version of it. So I ended up with two subdomains not covered by the SSL.

Why is it not redirecting? I thought the redirect should work even if the SSL doesn’t cover it. Could it be that “Always Use HTTPS” is creating a conflict?

It likely is redirecting, but the page won’t load as the browser finds the certificate does not cover *.*.example.com. If you want to support second-level subdomains you will need to use the advanced certificate manager for the edge certificate, and also a supporting certificate on your origin.

1 Like

You are right, I just checked!

The annoying thing with cPanel is that with every subdomain you create, for example, dev.example.com it also creates a DNS A record for www.dev.example.com.

I’m thinking of deleting this record as this subdomain serves nothing and won’t be used at all. I also don’t think it’s smart to leave it like that, showing an error.

One interesting thing is that the HTTP version gets redirected but not the HTTPS. I think “Always Use HTTPS” is redirecting the HTTP version:

http://www.dev.example.com/ => https://dev.example.com :heavy_check_mark:
https://www.dev.example.com/ => error :no_entry_sign:

EDIT: Tested the last statement, “Always Use HTTPS” does solve the HTTP redirect. Well, most of my sites don’t need deeper subdomain levels than the first so there is no point in buying the SSL just for the sake of covering the useless 2nd level www. I think deleting those records would be a solution.

The HTTP version will work as that doesn’t use the certificate. As it redirects to an HTTPS site covered by the certificate, all is good.

The HTTPS version doesn’t work as the requests for www.dev.example.com hits the Cloudflare edge and as the certificate only covers example.com and *.example.com your browser stops there. (…and there’d be a Cloudflare error anyway as your origin certificate also doesn’t support www.dev.example.com).

1 Like

I thought redirect would trigger before the browser reads the page.

What do you think of my proposed solution?

I’m thinking of deleting this record as this subdomain serves nothing and won’t be used at all. I also don’t think it’s smart to leave it like that, showing an error.

I’m asking because Apache does two things when creating a www subdomain for the dev.example.com:

  1. Creates ServerAlias directive
  2. Creates DNS A record

Does deleting the A record for www.dev.example.com hide its existence from the world or do I need to take care of the ServerAlias entry as well?

This topic was automatically closed 3 days after the last reply. New replies are no longer allowed.