Preface

In the previous tutorial (see article:Home Data Center Series CF Tutorial (Part 1): Introduction to CF and Its Benefits to Individual Webmasters), I introduced Cloudflare (hereinafter referred to as CF) and the main functions provided by its solutions (Free plan). However, based solely on the introduction in the previous article, you might still feel a bit confused: for example, with so many functions, where in the CF console are they configured? And is there a specific order in which these functions take effect?

Therefore, in this article, I plan to introduce the priority of each specific technical node in the overall CF solution within the entire CF traffic sequence, as well as their main functions and corresponding configuration locations in the CF console.

CF's Traffic Sequence

What is a Traffic Sequence?

CF's overall solution is composed of a series of technical nodes. Before an access request is sent to the origin server, these technical nodes of CF will process the access request according to a pre-defined hit determination priority order. This hit determination priority order is the traffic sequence, as shown in the figure below:

Note 1: It should be noted that this priority is the hit determination priority. Once a node function in the traffic sequence is hit and processed normally (so-called normal processing does not include terminating actions, such as block, drop, redirect, etc.), it will continue to be passed to the next functional module for determination in the order of the traffic sequence.
Note 2: After being processed by all the technical node modules in the aforementioned traffic sequence, if the request is still legitimate and needs to access the origin server, CF will then forward the request to the origin server (origin pull).
Note 3: After the origin server responds, the response data will pass through relevant node processing modules (such as caching, content optimization) before being returned to the client.

Prerequisite: Domain hosted on CF

Before officially starting, please meet the prerequisite: host your domain on CF. If your domain is hosted with another domain provider, you need to migrate the domain to CF first, which usually takes about 5 days.

Note: For the specific steps to migrate a domain to CF, you can refer to my other article:Home Data Center Series: Leveraging CF for Free via Domestic ICP-Licensed Cloud Hosts to Achieve Fast Access to Domestic Sites from Abroad。

DDoS Protection

CF's DDoS protection feature is a critical security service designed to protect websites and networks from Distributed Denial of Service (DDoS) attacks. DDoS attacks overwhelm target servers with massive amounts of fake traffic, causing service disruptions. CF provides comprehensive DDoS protection to ensure website availability and performance.

A brief introduction to CF's DDoS protection features is as follows:

1. Automatic Detection and Mitigation：
   • Description: CF uses advanced algorithms and machine learning models to monitor traffic in real time and automatically detect abnormal traffic patterns.
   • Purpose: Once a DDoS attack is detected, CF immediately takes mitigation measures to filter out malicious traffic, ensuring that normal traffic is unaffected.
2. Global Anycast Network：
   • Description: CF relies on its massive Anycast network to distribute traffic across more than 200 data centers worldwide.
   • Purpose: By absorbing and dispersing attack traffic through the distributed network, it prevents single points of failure and network congestion.
3. Multi-layered Protection：
   • Description: Provides comprehensive protection at the application layer (L7), transport layer (L4), and network layer (L3).
   • Purpose: Protects websites, applications, and the entire network infrastructure from DDoS attacks of all scales and complexities.
4. Custom Rules：
   • Description: Administrators can configure custom protection rules based on specific needs.
   • Purpose: Set fine-grained protection policies for specific traffic patterns or attack types to further enhance security.
5. Real-time Monitoring and Reporting：
   • Description: CF provides detailed traffic monitoring and attack reports to help administrators understand attack details and mitigation effectiveness.
   • Purpose: Timely adjust and optimize security policies through visual monitoring tools and reports.

Personally, I think this is the most valuable free feature provided by CF. With simple configuration, it can achieve unlimited protection against conventional DDoS attacks, and I personally feel the interception rate can reach 99%. However, even if only 1% gets through, without other protection, it is still very easy to crash the origin site. After all, the performance of the cloud hosts used by most people is not that great (except for wealthy people who buy expensive, high-performance cloud hosts). This is also one of the reasons why I recommend home data centers.

For a detailed introduction to CF DDoS attacks and a tutorial on configuring CF DDoS attack protection, please refer to:Home Data Center Series Cloudflare Tutorial (Part 5): Introduction to DDoS Attacks and CF DDoS Protection Configuration Tutorial。

URL Rewrite

Note: URL rewriting refers to the process of converting the original URL requested by a user into another URL. It is typically used on the server side and handled by a web server or application framework (to be precise, it is completed by a software module on the server, such as Apache's mod_rewrite module, Nginx's rewrite directive, or the built-in URL rewriting function of an application framework).

Here, URL rewriting is completed by CF, and by the time it reaches the origin server, it is already the rewritten URL.

The main purposes of URL rewriting include:

1. Improving user experience: By using concise, easy-to-read URLs, users can more easily remember and understand the structure of the website. For example, rewriting example.com/product.php?id=123 to example.com/product/123.
2. SEO optimization: Search engines prefer clear, concise URLs that contain keywords. Through URL rewriting, URLs can be made more descriptive, thereby improving search engine rankings.
3. Security: By hiding internal architecture and parameters, the security of the website can be improved. For example, hiding the actual request path and parameters to avoid leaking sensitive information.
4. URL normalization: Resolving duplicate content issues caused by different URLs pointing to the same content. For example, rewritingexample.com和www.example.comuniformly into one format.
5. Simplifying routing: In web applications, complex routing and parameter passing can be handled more easily through URL rewriting. For example, in an MVC framework, requests can be rewritten to specific controllers and actions.
6. If the browser does not support cookies or the user blocks allcookies, thesessionIdcan be added to theurland sent to the server (or load balancer), which is a very reliable method to supportsessions.

Page Rules

CF's Page Rules is a feature used to manage and optimize specific URLs or paths. Through Page Rules, users can set different behaviors and optimization strategies for specific pages or paths on their website, thereby improving performance, security, and user experience (Note: The Free plan only supports 3 Page Rules).

Here are some common use cases for Page Rules:

1. Redirecting URLs: Specific URLs can be redirected to another URL. For example, redirecting an old page to a new page, or redirecting a URL without “www” to a URL with “www”.
2. Cache settings: Cache policies can be set for specific pages or paths to improve loading speed. For example, the cache time for static resources (such as images, CSS, JavaScript) can be set.
3. SSL/TLS settings: SSL/TLS can be forced enabled or disabled for specific pages or paths. For example, HTTP requests can be forced to redirect to HTTPS, ensuring the page is transmitted over a secure connection.
4. Firewall rules: Access control can be set for specific pages or paths. For example, access from specific countries or IP addresses can be restricted, or specific security protections (such as DDoS protection) can be enabled.
5. Page optimization: Specific optimization features can be enabled or disabled for specific pages or paths. For example, auto-minify can be enabled, image loading optimized, or certain performance optimizations disabled to ensure the page renders correctly.
6. Custom HTTP headers: Custom HTTP headers can be set for specific pages or paths. For example, a Content Security Policy header can be set to enhance page security.
7. Bandwidth saving: Bandwidth limits can be set for specific pages or paths. For example, the download speed of large files can be limited to avoid consuming too much bandwidth.

Note 1: Some time ago, CF announced the deprecation of Page Rules because many functional options in Page Rules could be completed in other subsequent technical nodes, such as redirection, caching, etc. However, it has now been restored~~ Personally, I feel it is because Page Rules has its own unique characteristics and many users opposed its deprecation. We will discuss this separately when we talk about Page Rules.

Note 2: Page Rules have high priority, but the number of rules is small (only 3 in the Free plan). Therefore, if it can be implemented using subsequent lower-priority specialized features, such as redirection functions and Cache Rules, try not to use Page Rules to accomplish it.

Origin Rules

CF's Origin Rules is a feature used to adjust and optimize access requests before they reach the origin server. Specific actions are executed based on specific attributes of the request (such as URL path, HTTP headers, etc.) to enhance the website's performance, security, and flexibility.

However, in the Free plan, the only feature that Origin Rules can implement is modifying the access port when returning to the origin server:

And it is only useful when the origin server uses a public IP to build the website. When I previously used a home broadband public IP to build a website, because there were no ports 80 and 443, I used this feature to change the origin port to a non-standard port. However, after using the tunnel feature later, I no longer needed this feature (the tunnel feature can freely specify the service port and host on the origin server, etc.).

Cache Rules

CF's Cache Rules allow users to customize how website content is cached to improve performance and reduce origin server load. By setting cache rules, users can more precisely control what content is cached, the cache duration, and when to refresh the cache.

By properly configuring cache rules, the following effects can be achieved:
• Improving performance: Through cache rules, the load on the origin server can be significantly reduced, and the loading speed of content can be improved.
• Flexible control: What content is cached, how long it is cached, and when the cache is refreshed can be precisely controlled based on actual needs.
• Reducing costs: Reduces the bandwidth consumption of the origin server and the number of processed requests, thereby lowering operating costs.

Common uses of Cache Rules are as follows:

1. Set Cache Level: Define cache policies, such as “Standard Cache”, “No Cache”, “Cache Only Static Content”, etc.
2. Customize Cache TTL (Time to Live): Set the expiration time of the cache for specific content. For example, you can set a longer cache time for static resources (such as images, CSS, JavaScript) and a shorter cache time for dynamic content (such as HTML pages).
3. Bypass cache: Set specific URLs or paths to not be cached to ensure real-time content updates. For example, login pages or shopping cart pages are usually not suitable for caching.
4. Cache Keys: Use query parameters, cookies, or other headers to determine cache policies. For example, different versions of a page can be cached based on the user's language preference.
5. Cache Rule Trigger Conditions: Set conditions based on URL paths, file extensions, query parameters, etc., to trigger specific cache rules.

For detailed function introductions and configuration tutorials of Cache Rules, please refer to:Home Data Center Series Cloudflare Tutorial (6) CF Cache Rules Feature Introduction and Detailed Configuration Tutorial

Note: The previous Page Rules can also configure cache rules for a specific URL. In fact, there is indeed some redundancy. Since there are only 3 Page Rules, whenever I have a need to set cache rules later, I switch to Cache Rules to implement them.

Configuration Rules

CF's Configuration Rules allow users to dynamically apply different configuration settings based on specific conditions of access requests. Through configuration rules, users can apply customized settings to specific paths, URLs, HTTP methods, etc., without affecting the entire website, thereby improving performance, security, and flexibility.

Common uses of Configuration Rules are as follows:

1. Security Settings: Apply different security policies based on specific conditions of the request (such as source IP, country, HTTP method, etc.). For example, enable or disable WAF (Web Application Firewall), DDoS protection, etc., for specific paths.
2. Performance Optimization: Apply different performance optimization settings for specific pages or resources. For example, enable or disable auto-minify, image optimization, etc.
3. traffic management: Adjust traffic management policies based on specific conditions of the request. For example, enable load balancing, smart routing, etc., for users in specific regions.
4. User Experience Optimization: Apply different user experience optimization settings based on conditions such as user device type, browser, etc. For example, provide a simplified version of the page for mobile device users.

Compared to Origin Rules, which are stingily limited to acting only on the access ports of origin requests, Configuration Rules can achieve far more functions for access requests, such as:

For example, when I configure that the accessed hostname contains "tangwudi.com" and does not equal "blog.tangwudi.com", to set the SSL encryption mode separately to "Strict" (the default is Full), you only need to set it as follows:

Redirect Rules

CF's Redirect Rules allow users to redirect requests to different URLs based on custom conditions. Through redirect rules, users can flexibly manage website traffic, optimize user experience, and ensure SEO effectiveness.

Some common uses of Redirect Rules are as follows:

1. HTTP to HTTPS Redirect: Ensure all traffic is transmitted over a secure HTTPS connection.
2. Domain Redirect: Redirect non-www domains to www domains, or vice versa, to ensure URL consistency.
3. Page Migration: When redesigning a website or migrating content, redirect old URLs to new URLs to maintain SEO rankings and user access continuity.
4. Path Redirect: Redirect specific paths or directories to new paths or directories.
5. Custom Redirect: Perform more complex redirect operations based on conditions such as query parameters, user agents, etc.

Note: The previous Page Rules can also configure redirects for a specific URL, so if it can be implemented solely with Redirect Rules, try not to use Page Rules.

Although URL Rewriting and URL Redirecting are somewhat similar in concept, they have distinct differences in functionality and implementation:

• URL Rewriting:
The URL seen by the user in the browser will not change.
Usually used to create user-friendly and SEO-optimized URLs, hiding the internal structure.
Processed on the server side, the rewriting process is invisible to the user.

• URL Redirecting:
The URL seen by the user in the browser will change.
Usually used for page migration, forcing HTTPS, domain consistency, etc.
Notifies the browser to jump via HTTP status codes, and the redirect process is visible to the user.

IP Access Rules

Here, you can directly set corresponding actions (block, allow, challenge, etc.) for access requests at the IP address level (which can be an individual IP address, IP address range, country/region, ASN number), and you can also block access from specific types of requests based on the User Agent.

Note: Actually, the functions here can also be implemented in WAF, but WAF rules are limited after all (only 5 for the Free plan). Therefore, if the desired effect can be achieved here, you don't need to consume WAF rules to achieve the same effect.

Bots

CF's Bot features are an intelligent security measure designed to detect and manage automated traffic, such as crawlers, bots, and other automated programs. Through these features, CF can help website administrators distinguish between human users and automated traffic, thereby protecting the website from malicious activities while ensuring that legitimate automated programs can access it normally.

Several key aspects of CF's Bot features are as follows:

1. Automatic Detection: CF uses advanced machine learning and behavioral analysis technologies to automatically detect and classify automated traffic. These detection technologies can identify common bot behavior patterns and make judgments based on factors such as user activity and request frequency.
2. Challenges and Verification: For suspicious automated traffic, CF can issue challenges, such as CAPTCHA verification, to ensure that the traffic originates from real users rather than malicious bots.
3. Rate limiting: CF can set rate limiting rules to limit the number of requests per user within a specific time frame based on IP addresses or other identifiers, thereby preventing scrapers or DDoS attacks.
   
   
4. Custom Rules: Website administrators can customize rules to target specific types of automated traffic. For example, allowing trusted search engine crawlers to access while blocking unknown or malicious bots, which needs to be implemented in combination with WAF features.
5. Analysis and Reporting: CF provides detailed traffic analysis and reports to help website administrators understand the sources and behavioral patterns of automated traffic, thereby adjusting security policies.

This automated program feature itself is actually just a detection mechanism: it can detect access by automated programs (including scrapers, attacks, etc.) and classify and identify these automated programs, while the specific policy control over these automated programs still needs to be implemented in combination with other features, such as WAF rule settings.

WAF

CF's Web Application Firewall (WAF) is a powerful security feature designed to protect websites from common web attacks, such as SQL injection, cross-site scripting (XSS) attacks, cross-site request forgery (CSRF), etc. By analyzing and filtering HTTP/HTTPS traffic, WAF can identify and block malicious requests, ensuring the security of websites and applications.

The main features and advantages of CF WAF are as follows:

1. Rule Sets: CF WAF contains a large number of predefined security rule sets, covering the OWASP Top 10 vulnerabilities and other common threats. These rule sets are updated regularly to address the latest security threats:
   
   
2. Custom Rules: Website administrators can create custom rules (the Free plan has a quota of 5 rules) to meet specific security needs. For example, rules can be created based on specific URL paths, query parameters, or HTTP headers:
   
   
3. Virtual Patching: After a vulnerability is discovered, website administrators can immediately apply virtual patches without waiting for the development team to fix the code, thereby quickly blocking potential attacks. This is implemented by using WAF custom rules for protection based on the principle of the vulnerability.
4. Defending Against Advanced Attacks: Through integrated machine learning and behavioral analysis technologies, CF WAF can detect and block complex and advanced attacks, such as zero-day attacks, which is also implemented through custom rules.
5. Bot Management: In addition to protecting websites from the threat of human attackers, CF WAF can also identify and manage automated traffic to prevent attacks from malicious scrapers and botnets, which needs to be implemented by combining custom rules with automated program features.
6. Logging and Monitoring: WAF provides detailed attack logs and real-time monitoring to help website administrators understand the sources and types of attacks and adjust security policies in a timely manner:
   
   

For specific CF WAF feature introductions and detailed configuration tutorials, please refer to: Home Data Center Series Cloudflare Tutorial (Part 4): CF WAF Feature Introduction and Detailed Configuration Tutorial

Header Modification

CF's header modification feature allows website administrators to add, delete, or modify HTTP request and response headers by configuring rules.

A brief introduction to the header modification feature is as follows:

1. Add Headers：
   • Description: Add new headers to HTTP requests or responses.
   • Purpose: Can be used to pass custom information, implement security policies (such as Content-Security-Policy), optimize browser caching (such as Cache-Control), set Cross-Origin Resource Sharing (CORS), etc.
2. Modify Headers：
   • Description: Modify existing HTTP request or response headers.
   • Purpose: Can be used to update security policies, adjust cache settings, change user agent information, etc.
3. Delete Headers：
   • Description: Delete specific headers from HTTP requests or responses.
   • Purpose: Can be used to remove sensitive information, disable unnecessary headers, improve security, etc.

Common Uses

1. Security：
   • Add Security Headers: Such as X-Frame-Options, X-XSS-Protection, Strict-Transport-Security (HSTS), etc., to prevent clickjacking, cross-site scripting attacks, and other common security threats.
   • Content Security Policy (CSP): Control resource loading through the Content-Security-Policy header to prevent XSS attacks.
2. Performance Optimization：
   • Cache Control: Optimize browser caching through Cache-Control and Expires headers to improve page load speed.
   • Compression Settings: Set the Content-Encoding header to enable Gzip or Brotli compression, reducing the amount of transmitted data.
3. Cross-Origin Resource Sharing (CORS)：
   • Set CORS Headers: Such as Access-Control-Allow-Origin, Access-Control-Allow-Methods, etc., to allow or restrict cross-origin requests.
4. traffic management：
   • Custom Headers: Add custom headers to track or classify traffic, supporting specific needs of the application.

Access (Zero Trust)

Note: As of May 25, 2022, Access configuration has moved to Zero Trust.

The Zero Trust feature is a comprehensive security solution designed to protect enterprise networks and applications through a Zero Trust architecture. The Zero Trust model assumes that all network traffic is untrusted, regardless of its source, and must be secured through strict verification and authorization mechanisms. A brief introduction to the Zero Trust feature is as follows:

1. Authentication and Access Control：
   • Description: Ensure only verified and authorized users can access corporate resources by integrating Single Sign-On (SSO), Multi-Factor Authentication (MFA), and fine-grained access control policies.
   • Purpose: Protect internal applications, SaaS applications, and remote work environments from unauthorized access.
2. Secure Web Gateway (SWG)：
   • Description: Monitor and filter all outbound internet traffic to prevent malware, phishing attacks, and other threats.
   • Purpose: Protect the security of employees' internet access and ensure compliance with corporate internet use policies.
3. Application and API Security：
   • Description: Protect applications and APIs from various cyberattacks through Web Application Firewall (WAF), Bot Management, and DDoS protection.
   • Purpose: Ensure the availability and security of corporate online services and applications.
4. Zero Trust Network Access (ZTNA)：
   • Description: Provide secure access for distributed work environments without the need for traditional VPNs. Ensure users can only access resources they are authorized to through policy-driven access control.
   • Purpose: Protect remote and hybrid work environments, providing more secure and efficient access.
5. Data Protection：
   • Description: Protect sensitive corporate data from leakage through Data Loss Prevention (DLP) and Cloud Access Security Broker (CASB) features.
   • Purpose: Ensure the security of corporate data during transmission and storage, preventing data leaks and unauthorized access.

Zero Trust has the following advantages:

1. Enhanced Security: Protect corporate networks and applications from various attacks through strict authentication, access control, and real-time threat detection.
2. Simplified Management: Centrally manage all security policies and configurations, simplifying management tasks for IT teams.
3. Flexibility and Scalability: Support distributed work environments, providing security solutions suitable for various scales and industries.
4. Compliance: Help enterprises meet the security requirements of various laws and industry regulations.

Note: There are too many Zero Trust features and configurations to cover in a few sentences. I will introduce them in detail in multiple upcoming articles. Here, I will only mention the two most commonly used features: Tunnel and WARP+, both of which are configured in the Zero Trust section.

Workers Routes

CF's Workers routing is a serverless computing platform that allows developers to run JavaScript and TypeScript code (both of which run based on the V8 JavaScript engine, the core of Google Chrome and Node.js) on CF's global edge network, and allows developers to route network requests to different Workers scripts based on specific rules and conditions. Through these routing rules, developers can achieve fine-grained management and processing of requests, thereby improving application flexibility and performance.

A brief introduction to the CF Workers routing feature is as follows:

1. Path-based routing：
   • Description: Route requests to specific Workers scripts based on the requested URL path.
   • Purpose: Suitable for assigning specific processing logic to different URL paths. For example, routing requests for the /api/* path to the Workers script that handles API requests.
2. Subdomain-based routing：
   • Description: Route requests to different Workers scripts based on the requested subdomain.
   • Purpose: Suitable for multi-tenant architectures or subdomain segmentation scenarios. For example, routing requests for blog.example.com to the Workers script handling blog content, and routing requests for shop.example.com to the Workers script handling e-commerce features.
3. Query parameter-based routing：
   • Description: Route requests to specific Workers scripts based on the query parameters of the request.
   • Purpose: Suitable for scenarios requiring special processing based on query parameters. For example, routing requests to the Workers script handling English content based on the query parameter ?lang=en.
4. Custom rules and conditions：
   • Description: Create complex custom rules and conditions to route based on various attributes of the request (such as user agent, request headers, geographic location, etc.).
   • Purpose: Suitable for scenarios requiring complex decision-making based on multiple conditions. For example, routing requests to different processing scripts based on the user agent to adapt to different client devices.

For a detailed introduction to Worker features and a configuration tutorial on using Workers to optimize website access, please refer to the article:Home Data Center Series Cloudflare Tutorial (7): Introduction to CF Worker Features and Practical Operation, Verification, and Technical Principles of Accelerating Website Access Based on Workers to Implement "Budget APO for WordPress"。

Note: CF Workers features are extremely powerful, and I will cover them in dedicated articles later. Here is a brief mention: for example, when Docker Hub is blocked and inaccessible in China, you can deploy a JS script on Workers to implement a reverse proxy for pulling images; or if accessing your own website deployed on CF from China still feels slow even with CDN, you can deploy a JS script on Workers to implement a budget APO feature to accelerate website access (Free plan). Additionally, there are many Workers-based projects on GitHub that can achieve numerous features. The only thing to note is that the Free plan only supports a quota of 100,000 requests per day, and it will stop working once exceeded (for example, if hit by an attack~).

Summary

I believe that after reading this article, you will have a general understanding of the features of each technical node involved in the traffic sequence and the priority order of hit determination for processing access requests. As for the specific configuration details of each part, I will introduce them in detail in subsequent articles. Of course, they will be written in articles of different lengths depending on the number of features involved and the importance of each technical node.

Summary in one sentence: This article introduces what CF does from the moment a user's access request "enters CF's edge network" until it is "ready to be sent to the origin server."

As for how to make "the user's access request reach CF's edge network" and "how CF sends the request to the origin server," that will be covered in the next article.

P.S.: I have always wanted to write this article, but I was always too lazy to do so, thinking it was too troublesome. However, this step is unavoidable if I want to introduce CF's overall solution. So this time, taking advantage of writing the CF tutorial series, I pushed myself and finally wrote it. Surprisingly, I did discover some details I hadn't noticed before, such as the IP access rules in the WAF interface actually having a higher processing priority than the WAF itself.