Preface

In the previous article (see:Home Data Center Series: Cloudflare Tutorial (Part 2) - Brief Introduction to the Functions of Technical Nodes in CF's Overall Solution Traffic Sequence), I introduced what CF does during the period from when a user's access request "enters CF's edge network" until the request is "ready to be sent to the origin server." However, before "entering CF's edge network," how does CF make the user's access request enter the edge network? And after being "ready to be sent to the origin server," which specific method does CF use to send the user's access request to the origin server?

This article is here to explore these two questions.

How to Enter CF's Edge Network?

What is an Edge Network?

CF's edge network is a distributed network architecture designed to optimize the transmission and processing of internet traffic by deploying data centers and servers globally.

A brief description of CF's edge network is as follows:

1. Global Distribution
   • Description: Cloudflare has deployed data centers in more than 200 cities worldwide, covering over 100 countries and regions (except for a few special countries).
   • Purpose: To ensure that users, no matter where they are, can enjoy fast and reliable network services.
2. Low Latency
   • Description: By placing content and computing power at edge locations closer to users, the distance and time of data transmission are reduced.
   • Purpose: To speed up webpage loading times and application response times, improving user experience.
3. High Availability
   • Description: To ensure continuous service availability through multi-point redundancy and automatic failover mechanisms.
   • Purpose: Even if some nodes fail, traffic can automatically switch to other nodes, ensuring uninterrupted service.
4. Security
   • Description: Integrating multi-layered security protection measures on the edge network, including DDoS protection, Web Application Firewall (WAF), and malware detection.
   • Purpose: To intercept and filter malicious traffic close to the source of the attack, protecting the security of websites and applications.
5. Edge Computing
   • Description: Through Cloudflare Workers, developers can run serverless code on edge nodes to process requests and perform computing tasks.
   • Purpose: To pre-process user requests before they reach the origin server, reducing server load and improving application performance.

In plain English: The edge network can be understood as the edge portion of CF's entire network. It can be very close to the actual accessing users, and also very close to the origin server. By deploying CF's various services to the edge network, it can allow users' access requests to quickly get the content they need (for example, caching the origin server's response content via CDN into the cache of the edge network closest to the accessing user), intercept malicious access requests (for example, intercepting attacks in the WAF of the edge network closest to the malicious visitor, preventing them from entering CF's network at all, let alone reaching the origin server), and quickly perform origin-pull (initiating requests to the origin server from the edge network closest to the origin server and caching its response content).

In short, CF's edge network and the various services deployed within it can greatly improve the user access experience for applications.

---

Note: The above description is theoretical. In reality, domestic Free plan users call CF "negative optimization." The reason is that CF has not truly extended its backbone network into China (for reasons everyone understands), but only provides services indirectly through domestic partners (previously Baidu Cloud, now seemingly JD Cloud), with the main service targets being paid users.

As for general domestic Free plan users (webmasters using it for free), CF clearly cannot look after them well: for example, as mentioned earlier, during origin-pull, CF should initiate requests from the edge server closest to the origin server. However, in reality, most origin-pull addresses are directly assigned to the San Jose data center in US West. This means the origin-pull has to go back and forth across the Pacific, and the response speed can be imagined. Coupled with similar situations encountered by domestic users during normal access (some regions cannot even access it), this ultimately leads to an access experience where not using CF actually feels faster.

Is there any way for domestic Free plan webmasters to improve the speed of accessing their sites from within China? Of course there is, and we will explain it in the next section.

---

Webmaster's Perspective: How to Make User Access Requests Enter CF's Edge Network?

Conventional Method: Orange Cloud

Once the domain is hosted on CF (for the configuration steps of hosting a domain on CF, please refer to:Home Data Center Series: Using Domestic ICP-Filed Cloud Hosts to Leverage Cloudflare for Free to Achieve Fast Access to Domestic Sites from Abroad), the default proxy status of a newly created hostname is "Proxied", which is commonly referred to as the "Orange Cloud" status:

In this state, when users use DNS to resolve the corresponding hostname (such as abc.tangwudi.com in the figure above), although the resolution address I set is 110.110.110.110, the actual resolution result for users is as follows:

In the figure above, 104.21.76.18 and 172.67.185.18 are the entry IP addresses of CF's edge network. The negative optimization I mentioned earlier also refers to the effect of directly accessing through this point.

So, is there any way for webmasters using the Free plan to improve their site's access speed? Of course there is.

Acceleration Method 1: Preferred IP

CF's Preferred IP feature is mainly used to optimize network performance.

Preferred IP refers to IP addresses selected and allocated through specific mechanisms (such as geographical location, latency, etc.). These addresses are usually optimized and filtered to provide better connection quality and lower latency. As I mentioned earlier, domestic visitors are assigned to the US West data center, but if the Preferred IP feature is used, they might be assigned to the addresses of domestic cloud partners, which would greatly improve the access experience. Unfortunately, Preferred IP is currently a service exclusive to paid users, and Free plan users cannot enjoy it (there was a time in the past when it could be leveraged for free through CF's domestic partners, but that is long gone, and I didn't get to enjoy it, which is a great pity).

However, there is also an indirect way to enjoy the preferred IP feature (a workaround), which is CF's "Custom Hostnames" feature + the resolution function of domestic domain name providers + the "custom IP" detected by specific software:

Then, use the software to select the node with the highest success rate and the lowest latency:

Just configure the appropriate node IP (the first IP in the image above) in the console of the domestic domain name provider into the record value corresponding to the hostname that needs the preferred IP:

Note 1: Strictly speaking, the "custom IP" selected in this way is only valid in the short term. Therefore, if you use this method, you need to perform frequent tests to maintain the availability of the "custom" IP, which is not very efficient.

Note 2: There are many tutorials online on how to use custom hostnames to achieve preferred IP. If you are interested, you can search for them yourself. If necessary in the future, I will also consider dedicating an entire article to introduce the detailed configuration steps. It's mainly because I no longer use this solution now (I used it last year when I was still using an ICP-filed domain), so I don't have much motivation to write this tutorial for now (and the key is that it cannot be explained in just a few words~).

Acceleration Method 2: Workers

By utilizing CF's Workers, you can flexibly control traffic routing and request processing through programming, optimize network performance, and indirectly achieve the effect of preferred IP. This is mainly based on the following features of Workers:

1. Edge Computing：

Workers run in CF's globally distributed edge data centers and can process requests close to users. By processing requests near users, transmission distance and time are reduced, thereby improving response speed and reducing latency.

2. Intelligent Traffic Routing：

Use Workers code to dynamically select the best backend server or API endpoint, judging based on real-time network conditions and performance metrics, to achieve intelligent traffic routing, select the optimal path and server, and achieve the effect of preferred IP.

3. Real-time Monitoring and Adjustment：

Real-time monitor network performance and server health status through Workers code, dynamically adjust traffic routing, and automatically adjust routing strategies based on real-time data to avoid congestion and failures, improving network stability and performance.

4. Cache Management：

Use Workers to control caching strategies, caching static content or preprocessing dynamic content at edge nodes, reducing the frequency of requests to the origin server, speeding up content delivery, and reducing server load.

For detailed configuration steps on configuring Workers to accelerate website access, please refer to the article:Home Data Center Series Cloudflare Tutorial (7): Introduction to CF Worker Features and Practical Operation, Verification, and Related Technical Principles of Implementing ”Budget Version of APO for WordPress” Based on Workers to Accelerate Website Access。

---

Note: This part of the content is very important and is a very practical feature for webmasters using the Free plan. If configured properly, it is equivalent to having a preferred IP acceleration feature with a free quota of 100,000 requests per day. Under normal circumstances, a typical personal blog cannot use up 100,000 requests at all (except for special circumstances, such as being hit by a DDoS attack, which once made me very depressed~). I will dedicate an entire article to describe the configuration process in detail in the future.

---

Visitor's Perspective: WARP

CF WARP is a service that provides a safer, more private, and faster internet connection. It was originally launched as an extension of the CF 1.1.1.1 DNS resolver and has now become a standalone application and service.

A brief introduction to WARP features is as follows:

1. Enhanced Privacy and Security
   • Description: WARP encrypts traffic between user devices and the internet, preventing data from being stolen or tampered with.
   • Purpose: Protects users' online privacy, preventing hackers, man-in-the-middle attacks, and surveillance.
2. Improved Connection Speed
   • Description: WARP uses Cloudflare's global edge network to optimize data transmission paths and reduce latency.
   • Purpose: Speeds up webpage loading times and application response times, providing a smoother online experience.
3. DNS Encryption
   • Description: WARP integrates Cloudflare 1.1.1.1 DNS resolution service, encrypting DNS queries via DoH (DNS over HTTPS) or DoT (DNS over TLS).
   • Purpose: Prevents DNS queries from being eavesdropped on and tampered with, improving online security and privacy.

Simply put, WARP can be understood as a "dialer". As long as it can "dial through" (connect successfully), you can directly access CF's edge network in an encrypted way. If other websites you need to visit are also hosted on CF, the access speed can be greatly improved. Of course, I guess the main purpose of friends who used WARP in the past was actually some other incidental features, but in fact, the original function of WARP is just to access CF's edge network~~.

In short, WARP can be regarded as a means for visitors to actively access CF's edge network (for detailed configuration steps, please refer to my other two articles:Home Data Center Series: Make Rational Use of Cloudflare WARP to Improve Your Website Access Speed (Desktop Version)andHome Data Center Series: Deploy Cloudflare WARP on Cloud Servers to Improve Network Access Speed (Linux CLI Version))。

Note 1: WARP+ (Premium Edition) will use Cloudflare's Argo Smart Routing technology (which is the official version of preferred IP) to further improve performance. Normally this is a paid feature, but it can be used for free through Zero Trust's team.

Note 2: After mid-June, the stability of WARP+ also seems hard to say (previously my WARP could never connect, but WARP+ could connect stably). Sometimes it works, sometimes it doesn't, probably depending on luck. This is because WARP(+) is based on WireGuard, and WireGuard is completely useless in terms of obfuscation (after all, it wasn't originally designed for this). Its characteristics are very obvious, so it is easily targeted (refer to the "regular intermittent" packet loss of IPsec VPNs currently used in China~). It is actually very simple to interfere with and block it.

How to Choose the Right Origin-Pull Method

What is Origin-Pull?

Origin pull is a concept in CDN: If an application deployment uses a CDN, when the content requested by a visitor is unavailable on the CDN's edge cache server (cache miss or expired), the CDN server will request the content from the origin server (Origin Server). This is called origin pull.

---

Note: You can think of a CDN as a reverse proxy server with caching enabled (which it essentially is), making it much easier to understand:
If the requested content is cached on the reverse proxy, the reverse proxy will directly return the cached content to the visitor.
If the requested content is not cached on the reverse proxy, the reverse proxy will request the corresponding content from the upstream server and return the upstream server's response to the visitor. This step is called origin pull on a CDN.

---

Optional Origin-Pull Methods

Public IP Address Origin-Pull

What is Public IP Address Origin-Pull?

The feature of Origin with Public IP Addresses refers to the edge servers in CF's Content Delivery Network (CDN) requesting content from the origin server via public IP addresses. This is a common configuration method in CF's origin pull mechanism, allowing users to configure their website or application's origin server as a public IP address (requiring the origin server to have a public IP address, either v4 or v6) to distribute content and process requests through CF's edge network.

For specific configuration steps, you can still refer to the article:Home Data Center Series: Using Domestic ICP-Filed Cloud Hosts to Leverage Cloudflare for Free to Achieve Fast Access to Domestic Sites from Abroad。

Note 1: This method is actually the origin pull method corresponding to the "Orange Cloud" mentioned earlier. The configuration is also very simple. In fact, you just need to configure the correct public IP address of the origin server in the A record of the DNS, and then turn on the "Orange Cloud". As mentioned earlier, using this method, you don't have to worry about the origin site address being exposed, because what is published externally and resolved by users is CF's CDN address. Of course, all CDNs are in this form, so it's nothing special~.

Note 2: When using the "Orange Cloud" method for public origin pull in the Free plan, you can only change the target port of the origin pull request through "Origin Rules" (suitable for cases where the origin server does not use standard ports 80 or 443), and cannot change other parameters (such as host and other header parameters). For specific configuration, please refer to the article:Home Data Center Series: Solving the Problem of Having a Public IP but No Legal 80 or 443 Ports for Website Building via Cloudflare's Origin Rules。

---

Note 1: Using this method is only recommended for friends who use dynamic blogs (since static blogs can just be thrown to any free hosting provider) and whose deployed cloud servers are non-domestic cloud servers.

Why is it not recommended to use domestic cloud servers as origin sites? Technically, it doesn't matter whether it is domestic or foreign, but don't forget the uniqueness of domestic policies. First, ports 80 and 443 are unavailable and require ICP filing (other non-standard ports are not safe now either). Second, domestic supervision and crackdowns on non-ICP-filed domains are increasing day by day, and the formal implementation of the SNI whitelist system is only a matter of time. In this context, why take the gamble?

Note 2: CF supports many HTTP and HTTPS ports by default, not just 80 and 443, but except for 8080 which supports caching, other ports are not supported for caching under the Free plan, only supporting origin pull

• HTTP
  8080 (cacheable), 8880, 2052, 2082, 2086, 2095
• HTTPS
  2053,2083,2087,2096,8443

---

Additional Benefit: Hassle-Free SSL Certificate Service

After fully migrating to CF, one of the things that makes me happiest is: I no longer have to spend energy on SSL certificates. Looking back since I started researching website building in September last year, the most annoying thing for me has been the renewal of SSL certificates (to do various tests, I had too many 3rd-level domains, dozens of them...). At first, I was messing around with SSL certificates for reverse proxies at home and on cloud servers (at the beginning, I didn't understand Let's Encrypt, and was just freeloading Tencent Cloud's 1-year free certificates at the time, which ended up maxing out the 20-certificate limit directly), then later the SSL certificates on Tencent Cloud CDN, and finally, because I wanted to centrally manage the renewal of all SSL certificates, I went to research ohttps... (see article:Home Data Center Series: One-Stop SSL Certificate Management Tool OHTTPS Tutorial)

After switching to CF, once the "orange cloud" is enabled for the relevant domain, according to the default SSL/TLS configuration, all access requests to the domain will be forced to redirect to HTTPS upon reaching the edge network. Furthermore, the subsequent SSL certificate verification, encryption, and decryption operations are completed right at the edge network. These are all done automatically, requiring absolutely no action from webmasters.

Of course, webmasters can also set the communication method between visitors, the CF edge network, CF edge servers, and the origin server according to their own needs:

• Off (not secure)
  HTTP is used both from visitors to the CF edge network and from CF edge servers to the origin server.
• Flexible
  HTTPS is used between visitors and the CF edge network, while HTTP is used from CF edge servers to the origin server.
• Full
  HTTPS is used between visitors and the CF edge network, and HTTPS is also used from CF edge servers to the origin server, but the SSL certificate on the origin server is not a valid certificate.
• Full (strict)
  HTTPS is used between visitors and the CF edge network, and HTTPS is also used from CF edge servers to the origin server, and the SSL certificate on the origin server is a valid certificate.

Note 1: The "Full" mode is very useful. You can directly use an ultra-long-term, non-valid certificate (such as the 15-year certificate provided by CF) on the origin server, saving the trouble of managing SSL certificates on the origin server.

Note 2: In fact, domestic CDNs default to the "Full" mode, meaning they do not verify the validity of the origin server's certificate.

Using Tunnel for Origin-Pull

CF Tunnel (also known as Argo Tunnel) is a service that allows servers, applications, and devices to securely connect to Cloudflare's edge network without publicly exposing public IP addresses.

A brief introduction to the CF Tunnel feature is as follows:

1. Secure Access：
   • Description: Securely connect internal networks, applications, and devices to Cloudflare's edge network through encrypted tunnels.
   • Purpose: Avoid directly exposing the server's public IP address, preventing external attacks and unauthorized access.
2. Simplified Network Configuration：
   • Description: With Cloudflare Tunnel, there is no need to configure complex firewall rules or VPNs.
   • Purpose: Simplify network management, reducing configuration and maintenance workloads.
3. Zero Trust Architecture Support：
   • Description: Integrates with Cloudflare Access to support a Zero Trust security model, strictly authenticating users and devices.
   • Purpose: Ensure only verified and authorized users can access internal resources.
4. Automated Traffic Management：
   • Description: Cloudflare Tunnel automatically handles traffic routing and load balancing.
   • Purpose: Improve application reliability and availability, optimizing traffic paths.

In a nutshell: Tunnel is an encrypted tunnel that directly connects CF edge servers with user devices and the networks where those devices reside. Described in detail from a technical perspective: it directly connects CF edge servers with user devices installed with the Tunnel client (cloudflared), and can directly access addresses across the entire intranet where the user device is located (provided that intranet routing or policies allow it) with the help of the user device installed with the Tunnel client.

For example: Suppose A and B are two devices on the same user network segment, with IP addresses 192.168.100.1 and 192.168.100.2 respectively. Website web1 is deployed on A, with the corresponding domain web1.tangwudi.com and port 80; website web2 is deployed on B, with the corresponding domain web2.tangwudi.com and port 81.

Deploy cloudflared on A. If we want to publish the web1.tangwudi.com website, we only need the following configuration:

The configuration for the web2.tangwudi.com website on B is as follows. Since CF actually accesses B through the network via cloudflared installed on A, B's address must be filled in as 192.168.100.2:81, as shown in the figure below:

---

Note 1: The source address seen initiatinghttp://192.168.100.2:81the request on B is A's address 192.168.100.1.
Note 2: Using the Tunnel method is more flexible than public IP origin-pull. For example, you can change the host and some connection parameters:

Note 3: No matter the occasion, I always recommend using the Tunnel method for building websites: you don't have to worry about whether you have a public IP, whether you have valid ports 80 and 443, or even whether it is domestic or overseas.
Note 4: The only drawback of using Tunnel is that stability is hard to guarantee during sensitive periods. Of course, at those times, access to all websites on CF is hard to guarantee. And if CF completely exits the domestic market at some point (even losing its partners), then the Tunnel method will completely lose its meaning.

---

For detailed configuration steps of Tunnel, please refer to the article:Home Data Center Series: Using Tunnel Technology to Enable Home Broadband Without Public IP to Leverage Cloudflare for Free to Achieve Rapid Website Setup (Recommended)。

Afterword

The hardest-to-write "Foundation Building" trilogy: 3 articles introducing the main features and key concepts in CF's overall solution are finally finished. To be honest, writing this is countless times more troublesome than directly writing about how to configure a certain feature. This is also why my attitude towards the CF tutorial series in the past was always to procrastinate as much as possible and not want to write: if I don't write them, there is no skeleton from the perspective of the overall solution, making it hard to extend and refine later; if I do write them, the scope is too broad, giving me a headache (and I estimate not many people are actually willing to read them~).

Fortunately, I pushed myself this time and finally finished writing. The rest will be simple: I only need to describe the configuration of the main features. Of course, CF's features go far beyond these: such as R2 (object storage), CF Pages (static page hosting), and other features I haven't used. However, these features are not node features in the traffic sequence, and their correlation is not that strong, so I can introduce them in separate articles later.

As for the subsequent introduction of functional module configurations, I will not write them in the order of the traffic sequence, because implementing certain features requires the cooperation of some functional modules (for example, complete protection against DDoS attacks requires the cooperation of the DDoS module and the WAF module), so I will write them in my own logical order.