Preface

In fact, CF Zero Trust was originally a feature set that I valued very much and was prepared to spend a lot of space to introduce. After all, it can provide comprehensive security protection for enterprises. Coupled with its important component warp+ (originally, after using warp to link your Zero Trust My Team, you can use warp+ for free), I can think of many applicable scenarios just by thinking about it.

Unfortunately, after June, warp(+) for Free plan users has been basically disabled in China, and some enterprise-level functions are mostly useless to individual users, so I have no motivation to write about it, so in the end the only two parts that are of practical significance are Zero Trust's Network and Access.

Zero Trust

Additional knowledge: About Zero Trust

What is Zero Trust?

Zero Trust is a security concept based on the following assumptions:No person or device, inside or outside the network, should be trusted by default.Unlike the traditional "verify and trust" security model, the zero trust model advocates Never trust, always verifyEven if a user or device has been authenticated, they still need to re-verify their identity and permissions each time they access a resource.

Key principles of Zero Trust include:

1. Continuous Validation: All access requests must be authenticated, regardless of whether the requester is an internal or external user.
2. Principle of least privilege: Users or devices can only access the minimum permissions required for their work, avoiding unnecessary access permissions that increase risks.
3. Fine-grained control: Access control is performed based on multiple factors such as user identity, device health status, geographic location, etc., ensuring that only requests that have been verified in multiple dimensions can obtain access rights.

This approach reduces the risk of relying on traditional perimeter protection (such as firewalls) and is more suitable for dealing with modern complex security threats and distributed environments. The zero trust concept has been widely used in various industries, especially in remote office and cloud computing environments, ensuring that no matter where the user is, access to corporate resources is strictly verified and controlled.

Comparison between traditional VPN-based solutions and zero-trust solutions

1. Trust Model

• Traditional VPN: The internal network is trusted by default. After connecting to the VPN, users can usually access the entire internal network resources. This model assumes that the internal network is secure.
• Zero Trust: Never trust any user or device, regardless of location. Every access request needs to be authenticated and authorized.

2. Access Control

• Traditional VPN: Access control based on user identity and network location, usually providing broad network access permissions.
• Zero Trust: Adopt the principle of least privilege to ensure that users and devices can only access the specific resources they need, limiting the potential attack surface.

3. Authentication

• Traditional VPN: Typically uses static username and password for authentication and may lack multi-factor authentication (MFA).
• Zero Trust: Emphasize strong identity authentication and multi-factor authentication to ensure that each access request is strictly verified.

4. Monitoring and response

• Traditional VPN: There is less monitoring of network traffic, making it difficult to identify abnormal activities in real time.
• Zero Trust: Continuously monitor user and device behavior, enabling rapid detection and response to suspicious activity.

5. Network Architecture

• Traditional VPN: Usually relies on a centralized network architecture, with users accessing the core network through VPN.
• Zero Trust: Use a distributed architecture to segment the network and reduce the attacker's range of movement in the network.

6. Adaptability

• Traditional VPN: With the popularization of remote work and cloud computing, there may be security vulnerabilities.
• Zero Trust: Designed to adapt to the modern working environment, it can better protect cloud services and remote access.

From the previous comparison, we can see that the traditional VPN solution is suitable for a relatively simple network environment, but it has great limitations in terms of security and flexibility, especially in the current form of increasing mobile office scenarios. The Zero Trust solution provides more stringent security measures for modern complex IT environments and can effectively respond to today's ever-changing threats.

Network

The Network part of Zero Trust has two functions: Tunnles and Routes. The most important one is Tunnels. This is currently the most critical supporting technology for my "home data center solution" to be feasible in China, and it is naturally the top priority described in this article.

CF Tunnel

What is CF Tunnel?

CF Tunnel (formerly known as Argo Tunnel) is a secure, lightweight network tunnel technology that allows users to expose internal services or applications to the Internet through CF's global network without exposing the server's public IP address or open ports. Its basic functions are as follows:

1. Establishing a secure connection:

• CF Tunnel creates an encrypted tunnel based on the TCP protocol between your server and the CF edge network, which means that all traffic will be routed through the CF network, thus avoiding direct exposure of your server.
• When a client (such as a browser) accesses an application, the traffic first passes through CF’s network and then is tunneled to the internal server. This ensures that the network request is made through CF’s security protection.

2. No need to expose public IP addresses:

• Traditionally, exposing applications requires opening firewall ports and exposing the server's public IP address. However, CF Tunnel eliminates the need to open inbound ports on the firewall by securely proxying all traffic.

Note: The above two points are great news for those who do not have a registered domain name and public IP in China but want to build a website (not only for home data centers, but also for domestic cloud hosts).

3. Dynamically generated tunnels:

• CF Tunnel Use client tools (such as cloudflared) to initiate a bidirectional tunnel with CF. Users can easily expose any internal service to CF, whether it is HTTP, SSH or other protocols.
• The tunnel is dynamically generated and has flexible configuration capabilities. The tunnel connection can be started or terminated at any time as needed.

4. High availability and load balancing:

• CF Tunnel can automatically load balance traffic and provide high availability in the event of tunnel failure. CF’s global network ensures efficient and redundant traffic routing through multiple edge nodes, thereby improving application availability.

Note: Point 4 does not really mean much to general users, but it provides a lot of potential advanced features to explore.

Detailed introduction and practical operation of CF Tunnel related technical points

---

FBI Warning: Since CF Tunnel can realize many advanced functions, it requires a lot of professional knowledge and boring principle analysis to sort them out, which can easily cause discomfort (dizziness, blurred vision, drowsiness). However, general routine use does not require those so-called advanced functions, so friends who are not interested in technical details can skip some of the content.

---

tunnel

What is a tunnel?

We have already discussed the concept of CF Tunnel in the previous section. The actual configuration of CF Tunnel in Zero Trust is tunnel.

When actually creating a tunnel, I like to use the physical location as the standard to create the tunnel. For example, in the figure below, "wudihome" represents my home data center, "tencentcloud" represents my Tencent Cloud server, and "aliyuncloud" represents my Alibaba Cloud server (tunnels use tunnel ids to indicate identification):

Note: Using location as the standard to create a tunnel is easy to understand in general scenarios: a logical tunnel connects CF's network and a physical location. However, in non-general scenarios (a logical tunnel connects CF's network and multiple physical locations at the same time), it is actually not very suitable. Therefore, when the tunnel involves multiple locations, from the perspective of operation and maintenance, a more reasonable naming method should be considered for the tunnel (such as the project name). However, I am too lazy to bother with this here.

Tunnel general usage scenarios

• Scenario 1: A tunnel contains only one location

This is probably the usage scenario for most people, either their own broadband or a cloud server. The similarity is that for CF Tunnel, there is only one location (one source IP). This is the most basic tunnel usage scenario, and the configuration is also very simple. There is nothing much to say, and it is not the focus of this article.

• Scenario 2: A tunnel contains more than one location, and the service delivery performance of these locations is similar

Possible scenarios include: the home data center's export broadband can have multiple dial-ups (and each dial-up has an independent IPv4 public IP address), so each dial-up counts as a location (my home data center has 3 dial-ups, 2 of which are used as the entrance to the tunnel), and each location delivers the same performance (because they all correspond to the WordPress main site, just coming in from different locations); or there are multiple cloud servers at the same time, and the performance of these cloud servers is similar (for example, they all have 2 cores, 2G, and 4 megabytes).

• Scenario 3: A tunnel contains more than one location, and the service delivery performance of these locations varies greatly

Taking myself as an example, my home data center itself contains 2 locations, and also includes Tencent Cloud server nodes, which adds up to 3 locations. The service delivery performance of these 3 locations is very different: the performance of the 2 locations of the home data center is the same, but the performance of Tencent Cloud lightweight server (2 cores, 2G, 4 megabytes) is just barely enough, and can only be said to be generally sufficient.

However, when there is a large amount of traffic access (such as when attacked by DDOS), the difference is obvious: the machine where my home wordpress is located has stronger performance (beggar version M1 macmini), and there are WAF and load balancing devices on the front end for pre-processing. In this way, facing the attack traffic that has been cleaned once by CF (DDoS protection and WAF), the abnormal attack traffic that finally reaches my main wordpress site is estimated to be only 1%; plus even if my main wordpress site is down, the local load balancing device can automatically transfer the request to the backup wordpress site (deployed on the inter cpu mini host), so for me, the performance and security of the home data center wordpress site are far better than a Tencent cloud server with nothing.

Because scenario 3 is the scenario I actually encountered, I would consider the disaster recovery solution of "Tencent Cloud Server will automatically take over the blog only when the home data center fails" (see the later part of the article for details).

Note: Conversely, multiple different tunnels can also be run in one location, but I won’t go into details in this article to avoid confusing you. If necessary, you can think about this scenario.

connector

What is a connector?

Connector is actually a concept subordinate to tunnel, corresponding to the "location" in tunnel: when the same tunnel is composed of multiple different physical locations, tunnel needs to use connectors to distinguish different locations.

Similar to how tunnels are identified by tunnel ids, connectors are identified by connector ids.

So how do we distinguish between the same location and different locations? We rely on the "source IP addresses" of different locations that CF sees when they use their own connectors to connect to the CF network.

---

The reason why "source IP address" is put in quotation marks is because the location with a public IP and the location without a public IP have different appearances.

In a location with a public IP (such as my home data center), I can clearly define which exit link the device running the connector goes out from. Because each of my three links has an IPv4 public address (there is no way for the chosen one, how many people can now make multiple connections and each have a public IPv4? Not to mention IPv6), so in theory I can let up to three different devices run connectors at the same time to go out from different exit links, thus creating the effect of having three different locations (if my 5G CPE router is included, it can create four locations~). Of course, two are usually enough. After all, in this scenario where there is only one physical location, multiple connectors are mainly used for redundancy to prevent blog access interruption caused by a problem with one of the connectors:

If the location does not have a fixed, public IP of its own (for example, a home broadband tunnel without a public IP), then the "source IP" of the location seen on the CF edge network is uncontrollable, so you can only go with the flow. Under normal circumstances, it will only correspond to one public IP (it may be an IPv4 address or an IPv6 address, depending on the operator's NAT policy) for a period of time.

---

When there are multiple connectors in the same tunnel, the advanced function of "multi-site load balancing and automatic redundancy" will be automatically activated: the back-to-origin request will automatically select different connectors (if you are using the free plan, this function is uncontrollable) to send, and when a connector is disconnected, the back-to-origin request will automatically be sent through the remaining normal connectors. These functions actually provide many potential high-end gameplay, including: multiple WordPress sites provide services at the same time and achieve global load balancing and redundancy, and a disaster recovery site that can automatically take over the business when the main WordPress site fails, etc. (This is just an example of WordPress, any method of building a site will work).

Note: Regarding the concept of return to the source (see the third part of the CF series tutorial for the specific concept of return to the source:Home Data Center Series CloudFlare Tutorial (Part 3) How to enter CF's edge network and how to choose the appropriate back-to-source method) method of choice. If the source host is in China, no matter what kind of environment it is (cloud host, home broadband), I only recommend the tunnel method to return to the source: 1. The domain name does not need to be registered (the disadvantage is that you cannot use domestic CDN, but CF itself has a free CDN, and it can still be used after some optimization), 2. No public IP is required (it doesn’t matter whether the home data center has a public IP or not), 3. There is no need to configure a reverse proxy and SSL certificate (because it directly opens up the http port communication between the intranet and the application), 4. There is no risk of exposing the source station IP (if the source station has a public IP), it is safe and convenient, so why not do it?

Connector General Configuration

In fact, the deployment of the connector is very simple. In CF's "Zero Trust"-"Networks"-"Tunnel", you can see the created tunnel:

Enter the existing tunnel, taking wudihome as an example:

Choose the installation method that suits you:

In fact, the content of deploying connectors in different locations is essentially the same (if it is the same system, such as Debian, the commands run are the same). The different connector IDs are displayed in the tunnel only because the source IPs of these locations are different in CF's view (if there are multiple connectors with the same source IP, the result of my test is that the access speed will drop significantly. It seems that the tunnel cannot correctly select the source connector in this case).

Public Hostname

The two concepts of tunnel and connector mentioned above only provide a basic logical channel to connect the CF network and our own network (as the saying goes: "To get rich, build roads first", but roads alone are not enough, agricultural products must be transported and sold through transportation to get rich). The last step is to securely publish internal services or applications to the Internet through domain names. This is the role of the "public hostname" function (here comes the transportation), but in actual deployment, the setting method of public hostname (the IP address of the main URL part) varies depending on the environment.

Single Tunnle, Single Connector (Conventional Scenario)

This is the scenario encountered by most personal webmasters. To add a public hostname, follow the steps in the following picture:

For individual webmasters, they usually use a single tunnel and a single connector (only one location) for deployment, and the connector and application are deployed on the same device. In this case, the URL can be set to localhost:port.

Note 1: For detailed configuration steps in this scenario, please refer to my previous article:The home data center series uses tunnel technology to allow home broadband without public IP to use cloudflare for free to quickly build a website (recommended).

Note 2: Do not replace 127.0.0.1 with localhost.

Single Tunnel, Multiple Connectors (High-end Scenario)

For individual webmasters, this scenario is relatively rare (perhaps only a small number of high-end people will encounter it~). In addition to multiple connectors corresponding to multiple locations, it is very likely that the connector and the application are not deployed on the same device. In this case, you cannot just fill in localhost:port in the URL as in the previous scenario.

However, whether or not "multi-site load balancing and automatic redundancy" can be achieved for multiple sites, the last step of correctly setting the URL is the most critical, and may even require some skills:

In fact, the key is what address should be filled in the red box in the above picture. Strictly speaking, it should be filled in: "What is the IP address of the application from the perspective of the node where the connector is deployed?" The following is a discussion of 3 scenarios.

• 1. Multiple connectors, and the application and connector are located on the same device

If connectors are deployed on more than one device, such as an Alibaba Cloud server and a Tencent Cloud server, and two connectors corresponding to the same tunnel are deployed respectively (corresponding to two connector ids in the tunnel), and the applications (such as WordPress) deployed on the two servers use the same port (such as port 80), then "localhost:80" should be filled in the red box. In this way, no matter which connector CF assigns the access request to or which server it reaches, the WordPress installed on itself can be accessed through "localhost:80". This is the most basic "multi-site load balancing and automatic redundancy" deployment method.

Note: It seems that some people use this method, treating multiple home broadbands as multiple connectors connected under the same tunnel, and using multiple connectors to disperse the traffic and requests during DDoS attacks. However, in my opinion, this is actually a temporary solution and not a fundamental solution. For the "True Home Data Center" solution, a free WAF and an open source load balancing software can easily solve the problem of leakage after the two layers of filtering by CF DDoS protection and WAF. I will write about it after I clear the article tasks in the queue. After all, this can be regarded as an advanced version of the home data center security solution.

• 2. Multiple connectors, but the application and connector are not on the same device

This situation is actually the scenario of my home data center: I use two Debian LXCs in my home data center (assuming the IP addresses are 172.16.0.1 and 172.16.0.2) to deploy the connector, and only the connector is deployed on these two LXCs.

The real address of my wordpress is 172.16.0.3 (actually it is not, this is the address of WAF, but it is OK to think it is the address of wordpress from the outside), so at this time I should fill in 172.16.0.3 in the red box above, because from the perspective of deploying the connector (no matter which one), wordpress can only be accessed through 172.16.0.3:80.

Note: When the connector and the application are not on the same device, the address range that can be filled in the URL depends on the route of the device where the connector is deployed. As long as the route is reachable, it can be filled in.

• 3. Both scenarios 1 and 2 are available in the same tunnel

Let’s take my home data center as an example: I have also deployed a tunnel connector called “wudihome” on the Tencent Cloud server. In this case, the first scenario’s localhost:80 method is applicable. However, there is also a connector for the home data center. In this case, the second scenario’s 172.16.0.3 method must be used. How can I resolve this contradiction?

In this scenario, the loopback interface "loopback" must be used flexibly. You only need to create a new loopback interface on the Tencent Cloud server and configure its IP address to 172.16.0.3. At this time, the access to the target address 172.16.0.3 reaching the Tencent Cloud server will be regarded by the Tencent Cloud server as an access to itself and the request will be processed normally.

Of course, in a real environment, I will not open all connectors at the same time (as mentioned earlier in the article, the performance and security of the WordPress main site in the home data center are not comparable to Tencent Cloud Server), so the connector on the Tencent Cloud server is closed by default. Only when the home data center fails (power outage, network disconnection) will the connector be automatically opened and take over the service of the WordPress main site (friends who are interested in the specific implementation details and related operations of this solution can refer to the article:Home data center series uses cloudflare tunnel to realize automatic takeover of disaster recovery site when WordPress main site fails).

Note 1: The loopback interface is a special interface in the network, usually used for testing, debugging and local host communication. Its most common IP address is 127.0.0.1, which is called the "localhost" address. However, in addition to the localhost address, the loopback address has many other uses. The most common one is that it is used as the Router ID when the three-layer device configures the dynamic routing protocol (RIP, OSPF, IS-IS) in the local enterprise network. The loopback address can be reached throughout the network, which is very convenient for managing three-layer devices or troubleshooting routing problems. The usage in this article is only the most basic use of the loopback interface, but it is an important technical puzzle that enables the disaster recovery solution mentioned above to be finally realized.

Note 2: The loopback address is used as the Router ID and is accessible to the entire network. It has certain similarities with the effects achieved by Anycast IP in terms of "entire network accessibility" and "virtualization and stability", which can help everyone understand the implementation principle of Anycast IP technology.

Multi-protocol support

For public hostname, not only can applications based on the http(s) protocol be published, but also many applications based on other protocols can be published:

However, these non-http(s) protocol-based applications mainly achieve single-point docking through CF Tunnel, and do not support multi-point access or optimization across multiple locations like http(s) applications (because they cannot use the Anycast technology provided by CF by default), so the use of these applications is relatively limited.

However, CF Zero Trust can still provide security features such as authentication, access control, and logging for these non-http(s) applications, so it still has some value (better than nothing).

Routes

---

Note: You only need to have a brief understanding of this part. It was originally used in conjunction with the warp+ and My Team functions. Unfortunately, users of the Free plan can no longer use warp+ in China. However, the Network part has Tunnel written on it. If I don’t write this, the article structure will seem incomplete and it does not conform to my aesthetic taste.

---

"Routes" is the section for configuring network traffic routing rules, which allows you to define how to handle traffic from users accessing internal resources through the CF network. This is one of the key components of implementing a zero-trust architecture, ensuring that all traffic is monitored and controlled.

The core features of Routes are:

1. Flow Control: Through Routes, you can define which traffic should be processed through CF's Zero Trust network. This includes the connection path from the user device to the target resource, ensuring that network access complies with the Zero Trust security policy.
2. Strategy Application: Routes allow you to specify policy rules for traffic, such as forcing the use of a VPN, verifying identity, or applying access control policies. This helps to enhance security and ensure that only authenticated users and devices can access internal resources.
3. Fine-grained configuration: You can create sophisticated routing rules based on different subnets, IP address ranges or DNS names to adapt to network access requirements in different scenarios.

Let me briefly explain the actual usage scenario. In the past, when warp+ could be used with the My Team function, if I had multiple locations, such as a home data center (network segment 192.168.10.x/24), the corresponding tunnel was "wudihome"; Tencent Cloud server (network segment 10.0.0.3/32), the corresponding tunnel was "tencentcloud", then I could set Routes as follows:

After successfully connecting to warp+ (my Team must be correctly associated), you can directly access 192.168.10.x and 10.0.0.3 in the home data center, which is much more advanced than the previous IPsec VPN point-to-point access. However, now warp+ is not available and you can't enjoy it. Of course, although I have this need, I just don't use warp+ to achieve it. What else do I need when I have tailscale?

Note: For those who are interested in how to use warp and whose environment allows it, please refer to my previous article:Home Data Center Series Reasonable use of cloudflare WARP to improve the speed of accessing websites (desktop version)andDeploy cloudflare warp on the home data center series cloud host to improve network access speed (Linux cli version).

Access

What is Access?

Zero Trust Access The function is to provide enterprises with a secure access control solution based on a zero-trust architecture. It ensures that only authenticated and authorized users can access specific applications and resources, whether these resources are located in a local data center or in the cloud.

In simple terms, Access allows you to publish internal applications directly to the public Internet, and through various identity authentication methods and security measures, you can ensure the security of the application while allowing people who really need it to quickly access the application.

Key features:

1. Authentication Integration:

• Supports integration with multiple identity providers (such as google, github, facebook) to achieve single sign-on (SSO) and multi-factor authentication (MFA) to ensure that only verified users can access protected resources.

2. Policy-based access control:
   • Administrators can create granular access policies to control who can access specific applications and resources based on user identity, location, device attributes, etc. This policy-driven access control improves security and flexibility.

3. No VPN access:

• CF Access offers a VPN-free alternative that allows users to access internal company resources directly through CF’s global network, reducing VPN complexity and latency while improving security.

4. Auditing and logging:

• Access provides detailed logging and auditing capabilities, allowing administrators to track who accessed which resources and when, enhancing visibility and auditing capabilities of access activities.

Unfortunately, most of the authentication functions of the Access part either require cooperation from a third party (such as the aforementioned Google, GitHub, Facebook, etc.), or need to be combined with the development of corporate websites (such as various Tokens). For individual users, the truly simple and practical authentication method is basically only to receive OTP (one-time pin) through email.

Use Access to add authentication capabilities to your published web applications

1. Select the web application you want to publish

I need an application to demonstrate, so I created a new domain name "ac86u.tangwudi.com" and associated it with the login interface of ASUS ac86u in my intranet. Now the access can be opened normally:

2. Create an Access Group in advance

When adding an application, the application needs to belong to an "Access Group", so it needs to be created in advance:

---

The Selector also has an option for emails ending in:

This method is suitable for multiple email addresses with the same mailbox suffix (such as corporate mailboxes), but friends who have set up CF email routing (see article:) and have their own mailboxes with domain suffixes can also use this method. In this case, as long as each friend is assigned a mailbox account with a domain suffix (associated with their own real mailbox), you can only set this one authentication rule, and all friends can access the applications you published that need to be verified.

---

3. Add applications

To use Access to add authentication functionality to your web application, follow the steps below.

Add an application:

Choose Self-hosted:

Set parameters for the application:

For the sake of convenience, you can keep all other options on this page as default, but there are some options that you can spend some time on, such as the logo:

After setting, select Next to continue to the next page:

Set the policy name and behavior of the application:

Then just click "Next" in the lower right corner to continue to the next page settings:

Finally add the application:

The application creation is complete:

4. Test the identity verification effect

Reopen "ac86u.tangwudi.com", the interface becomes like this:

It immediately became much more impressive. Enter the email address you set earlier in the Email box and send the verification code:


Then you can see the real application interface, and the address is also the real address (it was my team's address during previous authentication):

Additional knowledge: OAuth

In fact, for individual users, in addition to obtaining OTP codes through email for verification (simple, practical but low-level), they can also use third-party identity authentication (google, github, facebook, etc.) through OAuth.

What is OAuth?

OAuth (Open Authorization) is an open standard that allows users to grant third-party applications access to their information on a service without sharing their username and password. It is commonly used for secure access between social media, online services, and applications.

Basic concepts:

1. Resource Owner : User, who owns resources (such as personal information, photos, etc.).
2. Client : An application or service (such as a social media app) that requests access to a resource.
3. Authorization Server : A server that authenticates the user and issues an access token (such as Google or Facebook's authentication service).
4. Resource Server : A server that stores user resources (such as a server that stores user photos).

Workflow:

1. The user clicks the "Log in with XXX" button on the client application.
2. The client redirects the user to the authorization server, where the user logs in and authorizes the client to access its resources.
3. After the authorization server verifies the user's identity, it returns an authorization code to the client.
4. The client uses the authorization code to request an access token from the authorization server.
5. The authorization server verifies the authorization code and returns an access token to the client.
6. The client uses the access token to request the user's resources from the resource server.

This is actually often used in our daily life in China, that is, using QQ or WeChat account to authorize when logging into the app.

How to add third-party OAuth?

Follow these steps to add a third-party OAuth:

Select an idp (identity provider), taking github as an example (the prerequisite is that you must have a github account):

Then follow the tutorial on the right to set it up:

After the success, there will be an additional GitHub verification option:

The result of using this method is that any user with a GitHub account can be verified. If you want to further control who has a GitHub account and can access your application, you need to set additional access control policies in Zero Trust, such as finer-grained control based on user groups, roles, etc. You can study these if you are interested. I won't bother with them because they are useless. The setting location is here:

Of course, a single GitHub authentication is not impressive enough, so you can add others as well, so that any idp account can directly initiate a login application (it looks very high-end and has many allies~), but whether you can pass the authentication in the end depends on the conditions you set.

Afterword

Although CF Tunnel is a powerful tool, it is only one of the two conventional retrieval options that coexist with public network address retrieval. From the perspective of retrieval from a single source station, compared with the public network address retrieval method, it can only be said that each has its own advantages and disadvantages:
1. Encrypted tunnel

For networks in other countries, it does not matter whether an encrypted tunnel is used or not. In the public network address return-to-source method, using https to return to the source station can also ensure the security of the return-to-source.
2. No public IP

For networks in other countries, if there is no IPv4, there is always IPv6. Even if there is no IPv4, it is not difficult to apply for it. At worst, you can just find a cloud host in your own country that has a public IP (at least IPv6), so the public IP problem is easy to solve for building a website.

However, for websites built in a domestic environment, it is necessary to register if the public IP address is used for back-to-source, regardless of whether the domain name or pure IP is used:

In addition, it is difficult to obtain a public IP address, and home broadband operators frequently clean up inbound http(s) access to unregistered domain names. This has basically made the way of returning to the source using a public address useless. So, at this time, the way of returning to the source provided by CF Tunnel, which uses a fully encrypted tunnel based on the TCP protocol and does not require a public IP address, is simply invincible, right?

Of course, using CF Tunnel to build a site also has disadvantages by default:
1. Slow return to source

If the source station is in China, there is no way to solve the problem of slow return to the source, because the return to the source is from a foreign data center, back and forth across the Pacific Ocean, it would be strange if it was fast.
2. Slow access

After enabling Xiaocheng Cloud, the applications released will resolve to overseas IP addresses (for webmasters of the Free plan), so it is considered an overseas website. At this time, the speed of direct access from China is impressive.

These two reasons combined resulted in domestic access being barely usable before optimization. Therefore, if you are serious about targeting domestic users and require a good domestic access experience, you should go through the registration process honestly, and then use the acceleration service provided by domestic CDN suppliers. This way, the access experience is good and there is no hassle. Of course, the malicious consumption of paid CDN traffic and the expensive DDoS protection fees that follow are also things that must be faced.

So, is it possible to use CF Tunnel to build a website and still ensure that the domestic access experience is not too bad?

It's not impossible. The answer is hidden in the previous cloudflare series of tutorials~.