Preface

I have said in previous articles that if you build a website based on Cloudflare, I always recommend using Cloudflare Tunnel to return to the source, because Cloudflare Tunnel (also called Cloudflare Argo Tunnel) has many unique advantages compared to the traditional Cloudflare public address return to the source (direct proxy).

However, these days I discovered a "big" problem with Cloudflare Tunnel back-to-origin. Although this "big" problem does not involve fundamental issues such as security, it is hidden enough (effective by default) and will affect the SEO weight of the website URL. Most importantly, it will affect the image of the website (appearing lower).

Advantages of Cloudflare Tunnel

Although this article mainly talks about the "big" problem of Cloudflare Tunnel, to be honest, this problem is completely insignificant compared with its advantages (and there are solutions). In order to avoid being overshadowed, in the spirit of first praising and then criticizing, we will first make a comprehensive comparison between Cloudflare Tunnel back-to-origin and traditional public network address back-to-origin in terms of security, configuration and deployment, network performance and stability, scalability and redundancy, and security and defense capabilities to prove the superiority of Cloudflare Tunnel back-to-origin:

1. Security

Cloudflare Tunnel:

• Tunnel encryption: Tunnel passes traffic from Cloudflare's edge nodes to your origin server through an encrypted tunnel (TLS). This means that even if the origin server is not publicly exposed to the public Internet, it can communicate with Cloudflare securely.

• No public network exposure: When using Tunnel, the IP address of the source server will not be exposed to the outside world, and all access will be relayed through Cloudflare. This effectively reduces the risk of potential DDoS attacks, port scans, and other network attacks.

• Prevent unauthorized access: Because the origin site does not directly provide services to the outside world, hackers or attackers cannot directly access the origin site.

Traditional back-to-origin (Cloudflare direct proxy):

• Source station public IP exposure: In the traditional Cloudflare proxy mode, the IP address of the origin server is public. Although Cloudflare will proxy the request, the IP address of the origin server itself is still exposed to the outside world, so it may be attacked by DDoS or other network attacks.

• No encrypted tunneling: Unless additional encryption is configured, Cloudflare does not provide additional encryption protection for connections to origin servers in this mode.

2. Configuration and deployment

Cloudflare Tunnel:

• No need to expose ports: When using Tunnel, the source station does not need to open the port to the public network, and all traffic will be transmitted through Cloudflare's edge nodes. You only need to install Cloudflare's cloudflared client on the source station and configure Tunnel to forward traffic directly to Cloudflare.

• Simplify firewall configuration: Since the origin server does not expose ports, there is no need to perform complex port configuration on the firewall. You only need to allow Cloudflare's IP address segment to access your origin server, reducing the complexity of configuration and maintenance.

Traditional back-to-origin (Cloudflare direct proxy):

• Ports that need to be exposed: In traditional mode, the origin server needs to expose ports (such as 80 and 443) to communicate with Cloudflare. At this time, you need to ensure that the firewall rules are correctly configured to allow Cloudflare access.

• More network and port management: More manual configuration is required to ensure that the origin server can properly respond to requests from Cloudflare, especially if multiple ports or services are used.

3. Network performance and stability

Cloudflare Tunnel:

• Intelligent routing: Cloudflare Tunnel can take advantage of Cloudflare's Argo Smart Routing Function to optimize the traffic transmission path, select the best path to reduce delays, and improve the response speed and stability of the website.

• Through the firewall: If the origin server is located in the intranet or behind some strict firewalls, Cloudflare Tunnel can bypass the firewall or NAT network device by creating a secure tunnel between the origin server and Cloudflare, ensuring uninterrupted traffic transmission.

Traditional back-to-origin (Cloudflare direct proxy):

• Network load and transmission: Traditional back-to-origin relies on the network connection between the origin server and Cloudflare. If the network bandwidth or stability of the origin server is insufficient, it may cause performance issues, especially when the traffic is large.

• Possibly limited smart routing: The traditional proxy mode cannot directly use the Argo Smart Routing function, so the network connection quality of the origin server may directly affect the performance of the website.

4. Scalability and redundancy

Cloudflare Tunnel:

• Automatic load balancing and fault tolerance: Cloudflare Tunnel can be integrated with Cloudflare's load balancing function, so that traffic can be intelligently distributed to multiple origin servers. If the origin server fails, Cloudflare can automatically switch to the backup origin server to ensure high availability of the website.

• Support for multiple regions: If you have multiple origins in different geographic locations, Cloudflare Tunnel can automatically manage traffic routing between these origins, ensuring that user requests optimally reach the origin closest to them.

Traditional back-to-origin (Cloudflare direct proxy):

• Load balancing and redundancy configurations are more complex: In traditional proxy mode, load balancing and redundancy configuration usually need to be manually set up in the origin server or Cloudflare control panel. If you have multiple origin servers, you may need to configure DNS or multiple proxy servers to handle traffic.

• No automatic cross-region support: For cross-regional data centers or multi-node deployments, traffic distribution in the traditional back-to-source mode may not be as efficient as Tunnel.

5. Security and defense capabilities

Cloudflare Tunnel:

• Protecting intranet applications: Cloudflare Tunnel allows you to securely expose intranet applications (such as applications that are only accessible to company employees) to the Internet without exposing them directly to the public Internet. For example, if you have an internal service that you only want to make accessible to specific external users, it can be securely provided through Cloudflare Tunnel.

• Reduce exposed attack surface: When using Tunnel, the internal applications of the source station will not be directly exposed to the public network, and attackers cannot directly launch attacks against these internal applications.

Traditional back-to-origin (Cloudflare direct proxy):

• Exposure to attack surface: In the traditional back-to-origin model, although the Cloudflare proxy layer can provide you with DDoS protection and basic firewall functions, the attack surface of the origin station exposed to the public network is relatively large, especially if additional firewalls and protective measures are not properly configured.

Summary: Cloudflare Tunnel vs. Traditional Back-to-Origin

characteristic	Cloudflare Tunnel	Traditional back-to-origin (Cloudflare direct proxy)
safety	No need to expose the source station, use encrypted tunnels to reduce the exposed attack surface	The source station exposes the IP address, which may lead to the risk of being attacked. Additional security measures need to be configured.
Ease of configuration	Install cloudflared, simplifying source station configuration and firewall settings	The source station port needs to be manually configured, which is more complicated
Performance and stability	Optimize network paths using Cloudflare's Argo Smart Routing	Network performance is limited by the origin network connection
Scalability and redundancy	Automatic load balancing, supporting traffic distribution for multi-region applications	Manual configuration of load balancing is required, and redundant configuration is complex
Intranet support	Can safely expose intranet applications, suitable for external network access of internal systems	Mainly used for public network exposure, can not easily handle intranet applications

Therefore, from the above comparison, it can be seen that compared with the traditional public network address return method, Cloudflare Tunnel is superior in all aspects, with no dead ends and no weaknesses, except that it may not run stably in some harsh network environments (such as behind some enterprise export devices with strict restriction policies or broadband operators with some abnormal restriction policies).

Problem discovery, analysis and resolution

An unexpected discovery

It all started with my habitual operation: searching for my blog on Google (most personal bloggers probably have this somewhat stuffy habit~). Normally, if I start from the first page and go back page by page, there should be only 16 pages at most:

But at the bottom of page 16, the following is displayed:

What are the 155 entries with very similar results in the picture above? It was not until I accidentally put the mouse on a search record yesterday that I found a display similar to the following (I don’t remember how I searched for that record originally, and it should be hidden in normal searches):

How can there be a port 8443? Then I searched for "blog.tangwudi.com:8443" directly in Google, and the result shocked me:

Although not as many as 16 pages, there are still 10 pages:

The default open port 8443 of Cloudflare gives me a bad feeling. I mentioned it in Chapter 3 of the previous Cloudflare series tutorial (see: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) mentioned 8443:

However, I have always believed that 8443 (including other 2053, 2083, 2087, and 2096) is only the default source service port supported by Cloudflare (that is, if the source uses these ports, there is no need to use Origin Rules on Cloudflare to customize the back-to-origin port). However, I was a little confused when I found this record today, so I used several other ports to search in turn. There are all of them, but not many (unlike 8443, which has 10 pages), and they can be accessed by adding the port in the browser:

Why is this happening?

Cloudflare's default open ports

After searching online, I found that the ports (8443, 2053, 2083, 2087, 2096) that Cloudflare opens by default in its Anycast IP are to support multiple services and protocols. These ports are not opened specifically for the specific needs of each user, but are configured for Cloudflare's own infrastructure and common uses:

1. Default ports for Cloudflare services

These ports are typically used to interact with specific Cloudflare services or for compatibility with common third-party applications. Specifically:

• 8443: This is a common alternate HTTPS port, often used for non-standard ports for the HTTPS protocol. In many cases, enterprise applications and some web services use this port for secure HTTPS connections. Cloudflare supports this port by default for some communications with Cloudflare services or proxy traffic.

• 2053: This port is commonly used by Cloudflare’s HTTP traffic proxy. Cloudflare routes traffic through this port, often for special services supporting various protocols.

• 2083: This port is usually used for cPanel Supported by control panels. cPanel is a widely used website management control panel that uses port 2083 for HTTPS connections by default. Cloudflare supports this port, usually to proxy traffic from cPanel.

• 2087: Similar to 2083, 2087 is for WHM (WebHost Manager) A provided port that is typically used to provide hosting services and manage server configuration. Cloudflare supports this port to facilitate integration with web hosting service providers.

• 2096: This port is used for cPanel WebmailThe webmail port is usually used to access the webmail interface provided by cPanel. Cloudflare also supports this port to provide compatibility for users.

2. Why does Cloudflare open these ports?

• compatibility: These ports correspond to many common web applications and services, especially in Web Hosting and Enterprise Hosting Cloudflare opens these ports to ensure the widest possible compatibility, especially for hosting providers using panels such as cPanel, WHM, etc.

• Traffic proxy support：One of Cloudflare's core functions is to proxy traffic and provide performance optimization and security protection. In order to support multiple services and protocols, Cloudflare needs to allow traffic on these ports to be routed through its network, thereby providing comprehensive DDoS protection, content distribution, and performance optimization.

• HTTPS Proxy：For various services that require secure communication over HTTP(S), Cloudflare opens 8443 and other ports by default as alternative ports for HTTPS proxy. This allows users and service providers to use other ports for encrypted traffic transmission in addition to standard ports.

3. Security considerations

Although these ports are open by default on Cloudflare, they are not automatically exposed to all users. Cloudflare actually proxies traffic on these ports on its edge nodes and provides DDoS Protection,Web Application Firewall (WAF) and other security features to ensure the security of traffic.

以上的内容说人话说就是：在所有Cloudflare的 Anycast IP(访问托管在Cloudflare上的域名时解析到的IP地址)上，这些端口在4层上都是通的(可以建立tcp 3次握手，可以用telnet访问端口进行简单的测试，也可以用其他工具测试4层端口的可用性)，并且提供和443端口一样的防护，但是这些端口并不会直接暴漏给所有用户(就是用户默认情况下不能用域名加端口的方式进行访问)，也就是7层上正常应该是不通的。

---

right"www.visa.comThe 8443 port is tested for layer 4 reachability, and it is indeed accessible:

right"www.visa.com"Perform a layer 7 accessibility test on port 8443 (curl can be used on the command line). It is indeed not accessible using a browser:

The above tests do prove what Cloudflare officially said.

---

The culprit: Cloudflare Tunnel?

To be honest, this really confused me. The key is that there is no similar option to set in the Cloudflare dashboard. Finally, the only thing I can think of is the difference in the return-to-origin method. Could it be caused by the difference between the two methods of returning to the source via the public network address and returning to the source via Cloudflare Tunnel? To confirm this issue, we must find actual examples for comparison. To be safe, examples of both traditional public network return-to-origin and Cloudflare Tunnel return-to-origin are needed.

Traditional public network address back to source

Take the blog of a blogger I admire (Benzene)https://blognas.hwb0307.com) as an example of traditional public network back-to-source testing.
Port 8443 Layer 4 reachability:

Port 2053 Layer 4 reachability:

Layer 4 reachability of port 2083:

Layer 7 reachability of port 8443 (only port 8443 is required for layer 7, they are all the same):

Can see and frontwww.visa.comThe results are the same, which indirectly proves that the traditional public network address back to the source using the default port 8443 should time out.

Cloudflare Tunnel back to the origin

This is a little more troublesome, because I don't know anyone who uses the tunnel method to build a website. I can only look for it directly on the Internet. I plan to look for personal blogs that introduce the Cloudflare Tunnel method to build a website. If the IP address of its domain name resolution belongs to the Cloudflare IP address segment, then it is likely that the website is built using the tunnel method. This idea is really genius, isn't it? Use the keyword "Cloudflare Tunnel website building" and immediately find the target:

First verify your identity and confirm whether you are using Cloudflare:

Use "ip138" to query the IP information and confirm that it is the target:

Routinely check the Layer 4 reachability of port 8443 (checks of ports 2053, 2083, 2087, and 2096 are omitted, they are all the same), and it is accessible:

Then test the 7-layer accessibility: access the default 443, then 8443, 2053, 2083, 2087, 2096 (the first test object fully tests all ports), and for the convenience of observation, use the curl command to access; because the homepage has a lot of content and is not suitable for observation, so choose/about.html(that is, about the page) for testing.
The default port is 443:

Port 8443:

Port 2053:

Port 2083:

Port 2087:

Port 2096:

The above has basically proved myGoldbach"Invincible conjecture": For websites that return to the source based on Cloudflard Tunnel, by default, in addition to the standard 443 port, there are also 8443, 2053, 2083, 2087, and 2096, which can all be accessed through https.

For further verification, I also found some blogs (the domain name resolution is Cloudflare's IP address, and only port 8443 needs to be verified. I am too lazy to take screenshots of other ports one by one. They all have the same effect. If you are interested, you can verify other ports by yourself):
1,https://liuhouliang.com:8443

2,https://mszx.me:8443

3.https://dmesg.app:8443

4.https://www.nodeseek.com:8443

…….

According to my idea, use "Cloudflare Tunnel website building" as the keyword to search on Google. Basically, you will find websites that use Tunnel to build websites on every page, and then you will find that these ports are open by default.

Principle analysis (friends who don't like technical details can skip it)

The difference in port behavior in the two different return-to-origin methods, "traditional public network address return-to-origin" and "Cloudflare Tunnel return-to-origin", is caused by the fundamental differences in their "traffic forwarding methods" and "proxy processing mechanisms".

Causes of port timeout during traditional public network backhaul

1. Port restrictions for Cloudflare proxy

• In the traditional public network back-to-origin method, Cloudflare acts as a reverse proxy server, mainly responsible for forwarding user requests to your origin server. The standard port exposed by Cloudflare is 80 (HTTP) and 443 (HTTPS)That is, through these two ports, the traffic will be normally proxied to the specified port range of the source station (that is, ports 80, 8080, 8880, 2052, 2082, 2086, and 2095 of the HTTP protocol, and ports 8443, 2053, 2083, 2087, and 2096 of the HTTPS protocol). The specified port range here means that any port can be selected. As long as Cloudflare finds that one or more ports of the source station are accessible, it will forward the access from HTTP port 80 or HTTPS port 443 to one or more ports of the corresponding protocol of the source station.

• Cloudflare will also forward access requests to other non-standard ports (such as HTTP 2052 or HTTPS 2053), but only to "Same port forwarding as the source station".

2. Origin site firewall and port configuration

• Although Cloudflare forwards access requests on non-standard ports, the firewall and port settings of the origin server determine the access results of these non-standard ports. If the origin server does not have the correct firewall rules for these ports, or does not open the corresponding ports to receive traffic, Cloudflare will forward the traffic and timeouts or connection failures will occur. This is the reason for the default timeout.Because under normal circumstances, the source station will not open these non-standard ports(Friends who use the traditional public network address back-to-source method to build a website can verify it themselves).

Why all ports can be accessed normally when Cloudflare Tunnel returns to the origin

1. Port flexibility for encrypted tunnels

• Cloudflare Tunnel(cloudflared) is different from the traditional back-to-origin method. It establishes a Encrypted tunnel, forwarding traffic from Cloudflare's edge nodes to your origin server, while the actual IP address and port of the origin server are not directly exposed to the outside world.

• In this mode, Cloudflare is no longer restricted to ports 80 and 443 (perhaps because Cloudflare believes the tunnel is secure enough so it lets go?), and it forwards all access requests received on all default open ports on its Anycast IP to the specified port of the source site.

2. Tunnel forwarding mechanism is not restricted by port

• Cloudflare Tunnel The core working mechanism of is to forward the request to the origin server through an encrypted tunnel. This tunnel is handled by the cloudflared client, which communicates with Cloudflare's edge nodes through HTTPS.

• After the traffic in the tunnel is encapsulated and encrypted, Cloudflare can forward it to any specified port. Whether it is 8443, 2053 or other non-standard ports, Cloudflare can forward these requests to the local cloudflared client through the tunnel, and then the client will hand over the request to the origin server for processing.

• This method exposes the source station’s port to Cloudflare Tunnel Internally, there is no need to disclose or configure firewall rules to allow specific ports to be directly returned to the source through the traditional public network.

3. Separation of origin ports from Cloudflare tunnels

• Unlike traditional back-to-origin, Cloudflare Tunnel establishes a "virtual proxy layer" in the tunnel so that the source station's port is not directly exposed to the Internet. The source station's traffic is processed by the encrypted tunnel before reaching the source station, so it is not restricted by public network firewalls and port shielding rules.

• The traffic in the tunnel is completely controlled by Cloudflare and the cloudflared client. The local port configuration of the origin site becomes more flexible. You only need to ensure that the cloudflared client can forward the traffic correctly. Cloudflare is responsible for sending the traffic to the correct port through the tunnel.

4. No port mapping or port forwarding required

• In traditional back-to-origin mode, if the origin server is configured with non-standard ports, Cloudflare must allow traffic from these ports to pass through and perform corresponding port forwarding. Cloudflare Tunnel In , all port traffic is transmitted through the tunnel, and the interaction between external users and Cloudflare does not rely on the open ports of the origin server. Therefore, any port can be accessed through the tunnel without manually setting up port mapping.

Summary

The above analysis is actually meaningless. In essence, it depends on Cloudflare's preferences. At present, it seems that in the public network back-to-source mode, non-standard traffic other than port 443 is only forwarded to the same port of the source station (the ports of the http protocol will be forcibly redirected to https, so they are not considered); and in Tunnel mode, all requests for https protocol ports (443, 8443, 2053, 2083, 2087, 2096) are forwarded to the specific port of the source station. It's so abnormal.

Another thing: Maybe it will change if it becomes unhappy someday?

Impact

Actually, if all the above ports have to pass all the security checks of Cloudflare, then there will be no security issues, which may be why Cloudflare doesn't care. The key point is: because these are completely default behaviors, you may not realize that in addition to port 443 of the https protocol, there are so many ports of access traffic that will be forwarded to your origin server!

Regardless of the reason why Cloudflare forwards traffic accessed on additional ports other than 443 to the origin server by default, the fact is that it may have some negative effects on the website.

1. SEO Issues

• Duplicate content issues: Although multiple ports may point to the same application, if these ports are publicly accessible (such as 8443, 2053, etc.) and no URL normalization is performed, thenSearch engines may see it as a different page, thus believing that there has beenDuplicate content, and may think that these different URLs are separate pages (even though they actually have the same content), which may affect your site'sSEO ranking".

2. Port management complexity

• Maintaining and managing stress：Although Cloudflare Tunnel can route traffic to the same backend application, if you do not explicitly configure management rules, forwarding multiple ports may increase the difficulty of traffic management and maintenance of the origin server. For example, access logs for different ports may become redundant, or if some ports expose unnecessary services, these ports may become unexpected traffic entrances.

• Traffic allocation is unnecessary: Although these ports do not pose actual security risks, without reasonable access control, the origin station may be subject to more traffic, which usually does not bring additional business value.

3. Brand/user experience impact

• Trust and professionalism: If users or potential customers find that your website can be accessed through multiple ports, especially some ports that seem to be "technical details" (such as 8443 or 2053), they may question the "technical level" or "professionalism" of the website (that is, the "low" I mentioned earlier). Although most users do not have a deep understanding of the background settings, the exposure of multiple ports may make some users think that the website lacks "sophisticated configuration" or "improper management."

• User experience：Some users may not care about these ports, but users who have high requirements for "brand image" may doubt the professionalism of the website. Especially in a highly competitive industry, details can often affect the user's impression.

Solution

It is very simple to solve the problem that ports other than 80 and 443 can be accessed. You only need to add the following rule to the top priority of WAF's custom rules (using my domain name as an example, you need to change it to your own domain name):

http.host contains "tangwudi.com" and cf.edge.server_port ne 80 and cf.edge.server_port ne 443

Please note that the above command can only be written by editing the expression, because there is no such option in the regular GUI:

After that, access to other ports will be blocked. Take port 8443 of my current blog domain name as an example:

Note: Why do I suggest adding a blocking rule at the top priority? Because normally, if we want to do SEO for a website, Cloudflare WAF's custom rules usually have a high-priority skip rule to allow access by various authenticated automated programs (including search engine spiders), as follows:

If the rule to block access to ports other than 80 and 443 is placed after this skip rule, then due to the priority of the custom rule, search engines can still access the website through all ports, but regular users' browser access is blocked. Therefore, the problem of multiple search records (different ports) for one URL in the search history still exists, and the SEO problem is still not solved. If this rule to block access is at the top priority, then all access to non-standard ports (including search engine spiders) will be blocked, which naturally solves this problem:

Note: If you are not familiar with Cloudflare WAF custom rules, you can refer to my other article:Home Data Center Series CloudFlare Tutorial (IV) CF WAF Function Introduction and Detailed Configuration Tutorial.

Additional knowledge: some other "hidden parameters"

In the process of using Cloudflare, there are some "hidden parameters" that are not directly accessible to ordinary users and are not easy to detect, but can affect the behavior, traffic management or security of the site to a certain extent. These parameters are usually part of Cloudflare's more advanced Worker or Firewall Rules Configuration, which involves some low-level traffic control and security rules. These parameters may be very important for developers or site administrators, but ordinary users generally do not need to directly understand or use them (similar to the "cf.edge.server_port" parameter used in the previous section).

Here are some parameters similar to cf.edge.server_port that are not usually known to the average user and usually require deeper Cloudflare configuration permissions:

1. cf.edge.server_port

• Function: This parameter is the port used by the Cloudflare edge node when receiving the request, and Cloudflare Tunnel These requests will be forwarded to the specified port on the source server according to the set tunnel configuration.

• Usage scenarios: Used in WAF custom rules to control traffic passing through specific ports.

2. cf.client.ip

• Function: Returns the client that initiated the request IP addressAlthough ordinary users can view their own IP through logs, in Cloudflare, this value is very common and is used to set firewall rules, access control, and rate limiting.

• Usage scenarios: You can set up access whitelists or blacklists based on IP addresses, and even Rate Limiting or Geographic restrictions.

3. cf.ray

• Function: This is the Cloudflare request tracking identifier. Each request generates a unique Ray ID, which is used to find and track specific requests behind the scenes at Cloudflare.

• Usage scenarios: Usually used for debug Or view the details of a request to help the support team analyze the request path and issues.

4. cf.visitor.ip

• Function: This is the real IP address of the visitor. When Cloudflare acts as a reverse proxy, the original client's IP address is preserved in the request header.

• Usage scenarios: Same as cf.client.ip, can be used to set IP restrictions, request analysis, etc.

5. cf.pragma

• Function: This parameter displays Cloudflare cache-related headers, specifically, it shows whether Cache-Control or other cache settings are enabled. Often used to debug cache behavior.

• Usage scenarios: Use when you want to check or adjust cache settings, especially in Cache Rules When debugging in .

6. cf.cf_access

• Function: Return to Cloudflare Access Authentication-related information, such as the user's identity verification status and whether identity verification is required.

• Usage scenarios: Cloudflare Access is an authentication-based application access control tool. Use this parameter to set the application's access permissions and authentication mechanism.

7. cf.browser.bot

• Function：This is what Cloudflare uses to determine whether the access request comes from reptile(Bot) parameter. If true, it means the request comes from a non-human user such as a machine or crawler, which may trigger some security policies or rules that are not related to user behavior.

• Usage scenarios: Usually used for WAF In the firewall rules, filter crawler traffic or execute Bot Management Strategy.

8. cf.warp

• Function: Indicates whether the request is passing through Cloudflare Warp Warp is a VPN service provided by Cloudflare, which is mainly used to accelerate users' Internet connections.

• Usage scenarios: Can be used to set different routing rules or policies for users accelerated by Warp.

9. cf.edge.timing

• Function: Provides performance information about the request processing process, showing information such as latency from Cloudflare edge nodes to the origin server. This parameter is very important for performance analysis and tuning.

• Usage scenarios: Used for Performance Monitoring and optimization.

10. cf.edge.request

• Function: This parameter can provide more detailed information about the Cloudflare request, such as the requested Processing time, response time from Cloudflare to the origin server, etc.

• Usage scenarios：Usually in Diagnostic Tools Or used in request optimization to help detect response bottlenecks.

11. cf.worker

• Function: Parameters related to Cloudflare Worker, returned Worker Execution information of the service. Worker is Cloudflare's serverless computing platform that can be used to run JavaScript, process requests, modify responses, etc.

• Usage scenarios: Used for Custom request handling, such as modifying HTTP requests/responses, enhancing cache control, access permission control, etc.

12. cf.mirror

• Function: Indicates whether Cloudflare is being used Mirror Data, that is, in some scenarios, Cloudflare will enable cache mirroring based on content type or other factors.

• Usage scenarios: For advanced caching and content distribution strategies.

13. cf.origin.latency

• Function: Shows the latency from Cloudflare to the origin server. This can help you understand the performance of the origin server, especially when the request response time is long.

• Usage scenarios: Used for Performance Monitoring, detect network bottlenecks.

14. cf.ratelimit

• Function: Returns whether the request is received Rate Limiting This parameter is often used in conjunction with Cloudflare's rate limiting feature to help detect if traffic exceeds a set threshold.

• Usage scenarios: Prevent control of malicious requests such as DDoS attacks and brute force cracking.

Note: Except for "cf.edge.server_port" among the parameters mentioned above, the information of other parameters is just collected. I haven't had the opportunity to use them yet, so I can't guarantee that the function description is correct. I will verify it again when I have the opportunity in the future.

Summarize

Most of these control parameters are advanced functions that are not usually involved by ordinary users.Traffic Analysis,Safety protection,Performance OptimizationandCustom ConfigurationThese management and monitoring requirements are very important. In most cases, onlyAdministrator privilegesUsers orDevelopersYou will come into contact with these parameters, and most friends can just treat them as additional knowledge.

Afterword

In fact, this article is not very useful for general personal bloggers: because friends who use the traditional public network address return method cannot use it, and friends who use Cloudflare Tunnel to build a website generally do not care about this matter (except for some bloggers who pay more attention to site SEO), so this article can only be regarded as an article about Cloudflare Tunnel technology at best.

However, this article also introduces a useless little trick, which can quickly distinguish whether a website with Cloudflare (a website whose domain name is resolved to Cloudflare's Anycast IP address) is based on "traditional public network address back-to-source" or "Cloudflare Tunnel back-to-source": just use a browser or command line tool such as curl to access the website's port 8443 (or 2053, 2083, 2087, 2096). If it times out, it is based on "public network address back-to-source"; if it can be accessed or is shown as "blocked", it is based on "Cloudflare Tunnel back-to-source".

Note 1: This article is also an interesting case study on how to quickly locate the layer (layer 4 or layer 7) of the problem when an application access-related problem is discovered, and how to further investigate and solve the problem (normal people would never expect Cloudflare to treat different return-to-origin methods differently). When I was still working, I often needed to prove my innocence when I was wrongly accused of having problems with my own equipment (friends who have worked on application delivery equipment should understand). In that case, I had to do this kind of location investigation. As a result, the problems above 90% had nothing to do with my own equipment.

Note 2: Since this article talked about SEO, the next article will be about SEO-related content.