Preface

Actually, I originally planned to end the CF series tutorials with the ninth part, "Zero Trust." After all, in the I Ching, nine is known as the “great number,” representing the largest and most complete number between heaven and earth—the so-called nine heavens, nine-nine returning to one, the eighty-one tribulations, and so on. Therefore, ending at the ninth part would secretly align with the will of heaven, and also make me look highly cultured~.

However, the various redirection methods provided by CF are indeed very valuable, especially the "dynamic redirection" later introduced in "Redirect Rules", which can use function expressions to flexibly construct the target URL of the jump. Combined with the redirection feature of "Page Rules" (which supports wildcards and wildcard-based capture groups), it can create many interesting possibilities. Therefore, after some thought, I resisted the urge to end at the ninth part and wrote this tenth part as the final chapter of the CF series tutorial.

However, ending at "ten" is not bad either. In Buddhism, there is a saying of "Nine Heavens and Ten Lands" (the Ten Lands represent the realms of practitioners in Buddhism). A Bodhisattva of the tenth land, “Dharmamegha-bhūmi” (Cloud of Dharma), already possesses perfect wisdom, compassion, and all skillful means, and is only one step away from Buddhahood.

It just so happens that I have studied the "Heart Sutra" and the "Diamond Sutra", so ending at "ten" is a karmic connection with Buddha~.

P.S. I wonder how many people still remember "Nine Heavens and Ten Lands, Nineteen Human Demons"?

What is redirection (HTTP redirection)?

Redirection(Redirect refers to the process of automatically guiding a user to another specified webpage or resource when they access a webpage or resource. Redirection usually occurs in the following scenarios:

1. URL changes: When the page address of a website changes, redirection ensures that the old URL is still accessible and guides users to the new URL, avoiding broken links and poor user experience.
2. Domain transfer: If a site changes its domain name, redirection can seamlessly transfer traffic from the old domain to the new domain, maintaining the continuity of website access.
3. Mobile Optimization: Redirect based on user device type (such as mobile and desktop devices) to provide optimized page versions.
4. SEO optimization: When page content is merged or deleted, using redirection can consolidate authority, avoid duplicate content, and optimize search engine rankings.

Common redirection types:
• 301 redirect(Permanent redirect): Indicates that the page has permanently moved to a new address. Search engines will pass the authority of the old address to the new address.
• 302 redirect(Temporary redirect): Indicates that the page has temporarily moved and may return to the old address in the future; search engines do not pass authority.

Note: In addition to the commonly used 301 and 302, there are also 303, 307, 308, and special redirects, but these are rarely encountered by average users, so they will not be discussed much in this article.

CF's redirection implementation methods

CF's redirection feature has several different implementation methods, the most important of which are: redirection implemented by Page Rules and Redirect Rules.

Redirection implemented by Page Rules

When I talked about Cache Rules (see:Home Data Center Series Cloudflare Tutorial (6) CF Cache Rules Feature Introduction and Detailed Configuration Tutorial), I also mentioned Page Rules, because Page Rules can also implement caching (only matching based on URL). By the same token, Page Rules can also implement redirection, except that they can also only match based on URL, and can only implement 301 or 302 redirects (of course, generally only 301 or 302 are needed).

The configuration of Page Rules is very simple, taking redirecting access fromtangwudi.comtowww.tangwudi.comas an example:

Although it can only match based on URL, redirection implemented through Page Rules has a unique advantage: it supports wildcards when matching incoming URLs, and*can pass content directly to the redirect URL through capture groups like "$number", as shown in the figure below:

However, using the precious Page Rules, which only have 3 free slots, to do redirection is a rather luxurious behavior~, even if you want to use them, you must use them in the most efficient way.

Using Page Rules for redirection has a major advantage: its priority in the traffic sequence (for the detailed concept of traffic sequence, see the article:Home Data Center Series: Cloudflare Tutorial (Part 2) - Brief Introduction to the Functions of Technical Nodes in CF's Overall Solution Traffic Sequence) is very high, higher than the "Redirect Rules" (and "Cache Rules") to be discussed later:

This is very important, and it is also the key to achieving complex redirection requirements in a certain scenario to be discussed later.

Redirect Rules

Introduction to Redirect Rules

Since Page Rules only have 3 free quotas and can only match incoming URL requests in a coarse way like URLs, they are not suitable as a routine method for daily redirection needs.

As an alternative, CF provides Redirect Rules as a routine method for daily redirection (similar to the relationship between the caching function implemented by Page Rules and Cache Rules).

Note: Redirect Rules can create simple 301 (permanent redirect) or 302 (temporary redirect) rules (actually there are also 303, 307, and 308 redirects, supporting more types than Page Rules):

Types of Redirect Rules

Redirect Rules are divided into "static" and "dynamic" types. Static redirection and dynamic redirection each have different uses and are suitable for different scenarios.

Static Redirection:

• Purpose: Static redirection is suitable for redirecting a fixed URL to another fixed URL (for example, in the previous example, redirecting all access tohttps://tangwudi.comtohttps://www.tangwudi.com), this redirection rule is static because it does not change dynamically based on the request content, parameters, etc. However, if parameters are required, for example, requiringhttps://tangwudi.com/*tohttps://www.tangwudi.com/*then static redirection cannot be used.
• Typical Scenarios: Migrating old pages to new pages, redirecting non-preferred domains to preferred domains (the case above), resolving dead links, and avoiding 404 errors.

Dynamic Redirection:

• Purpose: Dynamic redirection changes dynamically based on request content, query parameters, user geographic location, etc. For example, it can redirect to different domains based on the user's country, or redirect based on certain parameters in the URL.
• Typical Scenarios: Personalized redirection based on user geographic location and device type or browser type, defining redirection rules based on specific request conditions (such as user device, country of origin, etc.), and redirecting based on a certain "pattern" of the original domain name.

Redirect Rules configuration scenarios

Static redirection

Common use cases

Taking the previous example again: redirectingtangwudi.comtowww.tangwudi.com, configure this requirement as follows.
Under "Rules" - "Redirect Rules" - "Create Rule":

Of course, the condition setting for "When incoming requests match" can be very flexible, with many other options besides hostname:

Of course, you can't have your cake and eat it too. The matching conditions of Redirect Rules also have disadvantages: they do not support the*wildcards supported by Page Rules' incoming matching conditions, which prevents static redirection from passing parameters through wildcards like Page Rules' redirection does: no matter how many parameters the incoming URLtangwudi.com/has after it, it can only jump to the fixedwww.tangwudi.com/, which is the homepage.

Advanced use cases: Bulk redirection

Because static redirection can only jump to one target URL at a time, if there are a large number of URLs to jump to (such as migrating the entire site to another domain), the default quota of 10 rules is not enough. Therefore, static redirection also has a separate enhanced feature called "Bulk Redirects":

Note 2: The official CSV format is as follows:

example.com/contacts,https://example.net/contact-us,301,,,,
example.com/about,https://example.net/about-us,,FALSE,TRUE,,
example.com/docs,https://example.com/draft-docs,302,,TRUE

example.com/about,https://example.net/about-us,,FALSE,TRUE,,

Dynamic redirection

Common use cases: Jumps with URI content

example.com/docs,https://example.com/draft-docs,302,,TRUE"/*"Note 3: Bulk redirection is not the focus of this article, because since dynamic redirection became available, no matter how many "pattern-based" redirections there are, a single dynamic redirection target URL expression is enough~.

Dynamic redirection is relatively much more flexible. Although it still does not support wildcards, it can pass URI parameters through specified "fields". For example, the "http.request.uri.path" field can achieve the transfer effect of the URI part "" wildcard.For example, taking the above example again, this time I want to redirect access requests fortangwudi.com/*intact to

concat("https://www.tangwudi.com",http.request.uri.path)

Additional knowledge: Using specified fields and functions to construct expressions

Specified fields

The target URL expression for the redirection is as follows:https://blog.tangwudi.com/123concat("https://www.tangwudi.com",http.request.uri.path)

In the expression of dynamic redirection, specified fields can be used to automatically match the corresponding content in the incoming URL. For example: assume the complete incoming URL is:, at this time, if there is an "http.host" field in the expression, the field content is "blog.tangwudi.com"; if there is an "http.request.uri.path" field in the expression, the field content is "/123".。

Using functions to construct expressions

Note: For more fields, see:https://blog.tangwudi.com/123As an example, suppose the expression for the redirect target URL constructed using the "concat" function is as follows:

concat("https://www.tangwudi.com/",http.request.uri.path)

Then, the actual effect of the expression is:https://www.tangwudi.com//123, because the content represented by the "http.request.uri.path" field itself contains a "/", plus the field in the double quotes abovehttps://www.tangwudi.com/ending with "/", which naturally results in this. This is definitely incorrect, so the correct expression requires removing the "/" from the double quotes above, as follows:

concat("https://www.tangwudi.com",http.request.uri.path)

In addition to concat, other commonly used functions include substring, lower, and upper.

Taking the substring function as an example, its meaning is "extracting the string starting from the specified position from left to right". The specified position here starts counting from 0. For example: substring(http.request.uri.path,3) means indexing the string starting from position 3. Assuming the content of "http.request.uri.path" is "/tangwudi/abc", then the output of the function expression here is "ngwudi/abc".

Note: 0-/, 1-t, 2-a, 3-n.

Advanced use cases: Image hosting domain migration

Taking the images in my image hosting service as an example, suppose I want tohttps://image.tangwudi.com/2023/*.pngredirect tohttps://abc.tangwudi.com/image/*.png(*content must be the same), create a new dynamic redirect rule as follows:

concat("https://abc.tangwudi.com/image/",substring(http.request.uri.path,6))

Note: In this case, using page rules for redirection is also simple.

Advanced use cases: Multi-site domain jumps based on geographic location

This is an example of my previous deployment method. At that time, I happened to be in the period of migrating from my registered domain to "tangwudi.com", so during that period, both of my domains were active at the same time, and all applications had two domain entry points: one was CF's, with the domain "*.tangwudi.com"; the other was the registered domain, assuming the domain was "*.tangwudi.xyz".

My requirement at the time was for all applications to use a unified external entry point "*.tangwudi.com", but to make a judgment based on the source of the access request: if the visitor is from a domestic IP, redirect to "*.tangwudi.xyz/*"; if the visitor is not from a domestic IP, then access normally.

There are two*variables in this requirement: the hostname of the third-level domain and the URI content. When domestic users accessblog.tangwudi.com/123, they are redirected toblog.tangwudi.xyz/123; accessingwlk.tangwudi.com/12345, they are redirected towlk.tangwudi.xyz/12345。

However, this kind of requirement is a bit troublesome. As I mentioned earlier, even with dynamic redirection, the wildcard transfer effect corresponding to the URI part can only be achieved through the field "http.request.uri.path" "/*" wildcard transfer effect. Meanwhile, the hostname part "http.host" can only pass the full domain name (in this example, blog.tangwudi.com and wlk.tangwudi.com), and cannot pass only the hostname part of the third-level domain (in this example, blog and wlk).

Originally, if it was just unconditionally redirecting from "*.tangwudi.com/*" redirecting "*.tangwudi.xyz/*", a similar requirement could be handled with just one page rule redirect:

What should I do? After some thought: since the redirection implemented by page rules just doesn't support judgment based on geographical location, but the redirection part can be achieved; and dynamic redirection can achieve judgment based on geographical location, but cannot meet the requirements of the redirection part, can I combine the two parts to achieve this requirement?

With this idea, it becomes easy:

• Step 1: Create a dynamic redirect rule to redirect domestic users to a fictional URL

Construct a brand new URL with the fictional domain "abc.tangwudi.com" as the host through the target expression to redirect domestic users (the fictional domain also needs to have an arbitrary address resolution added in CF's DNS and the orange cloud enabled), while combining the complete third-level domain and the URI part together as the URI part of the new URL, so that page rules can use wildcards to extract them:

concat("https://abc.tangwudi.com/",http.host,http.request.uri.path)

In the above expression, "http.host" is used to pass the original third-level domain, and "http.request.uri.path" is used to represent the original URI part. So if the original access link is "https://blog.tangwudi.com/123", then the brand new URL constructed by this expression is "https://abc.tangwudi.com/blog.tangwudi.com/123".

• Step 2: Create a page rule to receive domestic users' access to the fictional URL, capture relevant information from the fictional URL to construct the correct access URL, and then send it to domestic users again via redirection

  Taking advantage of the fact that page rules have a higher priority in the traffic sequence than Cache Rules (this redirect cannot be cached), receive the access initiated by domestic clients using the new URL, and then use the wildcard capture groups mentioned earlier to separate the hostname contained in the URI part of the URL from the original URI content, forming the second redirect URL: "https://blog.tangwudi.xyz/123", and send it to domestic users.
  

  

• Step 3: Domestic users use the real URL received the second time "https://blog.tangwudi.xyz/123" to access.

In this way, after 2 redirections, my requirement for redirection based on geographic location and 2 variables was achieved. However, I don't actually recommend using this method under normal circumstances, because it has a major drawback: jumping back and forth, which gives a bad impression and makes the website look very unprofessional (personal opinion).

Note: I have only simply demonstrated 2 not-too-complex examples here. In actual situations, there are many more complex requirements, depending on everyone's understanding and imagination regarding dynamic redirection expressions and Page Rule wildcards.

Other redirection methods

Actually, in addition to using Page Rules and Redirect Rules to implement the redirection feature, using Workers can also achieve this. However, given the jack-of-all-trades status of Workers (many features can be implemented with Workers), I won't count it as a proper redirection method. Moreover, using Workers to implement redirection has a major hassle: the priority of Workers is the lowest in the traffic sequence, so to ensure that access requests can reach the Worker to achieve redirection, you might need to configure other functional modules in the traffic sequence to cooperate (such as Cache Rules). This is far less worry-free than using Redirect Rules and Page Rules together to complete the redirection feature.

Also: In "Transform Rules", there is another "URL Rewrite" feature:

If "redirection" is "openly" telling users that the access address has changed, then "URL Rewrite" is "secretly" modifying the URI part of the accessed URL (the domain name cannot be changed) without telling the user (the browser address will not change). However, this does not fit the theme of "redirection" in this article, so I won't say more.

Note: Domestic CDNs only provide the "URL Rewrite" feature (probably for fear of people doing bad things), so when domain redirection features are needed, many friends have to use their own VPS to achieve the jump (previously, I used Nginx on a Tencent Cloud Lighthouse server to achieve the www jump for my registered domain). From this perspective, the various powerful edge-network-based redirection features provided by CF for free are truly generous, saving us from having to configure things on a VPS at every turn (crucially, many people who host their own static websites don't even have their own VPS~). Once again, high praise to the great philanthropist.

Concluding thoughts

The CF tutorial series is finally finished (from the release of the first part on July 10 to the tenth part on September 2, spanning nearly 2 months). I wrote each part with great effort (including this last part, "Redirection", which I originally thought would be very easy to write). The key lies in the extensibility of CF-related knowledge: while writing, a concept I hadn't paid much attention to might pop up at any time (if I were just configuring features without writing articles, I wouldn't pay attention to these concepts either), forcing me to frequently use "Note" or "Additional Knowledge" for temporary explanations, otherwise the readability of the article would be ruined. Coupled with the fact that many CF features are inherently interrelated, writing each tutorial was extremely exhausting.

However, despite this, I think it was very much worth it. Looking back at myself before writing this tutorial series, my understanding of the features described in each tutorial was relatively superficial, only staying at the level of being able to handle basic usage, which also left a shallow impression. For example, regarding the redirection feature in this tutorial, I had even forgotten how exactly I configured it when migrating from the registered domain to "tangwudi.com" (after all, I hadn't used complex redirection features much since the migration more than half a year ago). It took me quite a while to find the key point (this is the consequence of not keeping written records). But now, with this tutorial written down, even if I forget again in the future, I can just look at this tutorial and remember everything. As the saying goes: a good pen is better than a good memory.

However, the content covered in the CF tutorial series is only based on my daily usage habits, summarizing and concluding the features I consider commonly used. Outside the blind spots formed by my "daily usage habits", there are still too many features left unmentioned, such as the "point" type "Hotlink Protection" feature, which, when turned on by default, can prevent image hotlinking (based on referer judgment):

It's just that because my current knowledge is limited, I don't even know how to take advantage of some features, leaving only regrets in my heart. If I find out how in the future, I will write about them in articles, but not under the name of the tutorial series. After all, we cannot break the "perfect ten".

Also: As the saying goes, "Keep your word and resolve your actions." I have finally finished writing the tutorial series, and this OCD patient can finally get a good night's sleep: