Preface

As I mentioned in my previous article, if you build a website based on Cloudflare, when it comes to choosing the origin connection method, I have always only recommended using Cloudflare Tunnel, because using Cloudflare Tunnel (also known as Cloudflare Argo Tunnel) has many unique advantages compared to the traditional Cloudflare public IP origin connection (direct proxy).

However, in the past few days, I discovered a ”big” problem with Cloudflare Tunnel origin pull. Although this ”big” problem does not involve fundamental issues like security, it is highly hidden (enabled by default), affects the SEO authority of the website URL, and crucially, impacts the website's image (making it look cheap/low-end).

Advantages of Cloudflare Tunnel

Although this article mainly discusses the ”big” problem of Cloudflare Tunnel, to be honest, this problem is completely negligible compared to its advantages (and there are ways to solve it). To avoid putting the cart before the horse, and in the spirit of praising first and criticizing later, let's first comprehensively compare Cloudflare Tunnel origin pull and traditional public IP origin pull from five aspects: security, configuration and deployment, network performance and stability, scalability and redundancy, and security and defense capabilities, to prove the superiority of Cloudflare Tunnel origin pull:

Security

Cloudflare Tunnel:

• Tunnel Encryption: Tunnel transmits 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 internet, it can still communicate securely with Cloudflare.

• No Public Exposure: When using Tunnel, the origin server's IP address is not exposed to the outside, and all access is relayed through Cloudflare. This effectively reduces the risk of potential DDoS attacks, port scans, and other network attacks.

• Block Unauthorized Access: Since the origin server does not directly provide services to the outside, hackers or attackers cannot directly access the origin server.

Traditional Origin Pull (Cloudflare Direct Proxy):

• Public IP Exposure of Origin Server: In the traditional Cloudflare proxy mode, the origin server's IP address is public. Although Cloudflare proxies the requests, the origin server's own IP address remains exposed to the outside, making it vulnerable to DDoS attacks or other network attacks.

• No Encrypted Tunnel Provided: Unless additional encryption configurations are used, Cloudflare does not provide extra encryption protection for the connection to the origin server in this mode.

Configuration and Deployment

Cloudflare Tunnel:

• No Need to Expose Ports: When using Tunnel, the origin server does not need to open ports to the public network; all traffic is transmitted through Cloudflare's edge nodes. You only need to install Cloudflare's cloudflared client on the origin server and configure the Tunnel to forward traffic directly to Cloudflare.

• Simplified Firewall Configuration: Since the origin server does not expose ports, there is no need for complex port configurations on the firewall. Simply allowing Cloudflare's IP address ranges to access your origin server reduces the complexity of configuration and maintenance.

Traditional Origin Pull (Cloudflare Direct Proxy):

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

• More Network and Port Management: More manual configuration is required to ensure the origin server can correctly respond to Cloudflare's requests, especially when using multiple ports or services.

Network Performance and Stability

Cloudflare Tunnel:

• Smart Routing: Cloudflare Tunnel can leverage Cloudflare's Argo Smart Routing feature to optimize the transmission path of traffic, choosing the best path to reduce latency and improve website response speed and stability.

• Firewall Traversal: If the origin server is located in an internal network or behind strict firewalls, Cloudflare Tunnel can bypass firewalls or NAT network devices by creating a secure tunnel between the origin server and Cloudflare, ensuring uninterrupted traffic transmission.

Traditional Origin Pull (Cloudflare Direct Proxy):

• Network Load and Transmission: Traditional origin pull relies on the network connection between the origin server and Cloudflare. If the origin server's network bandwidth or stability is insufficient, it may lead to performance issues, especially during high traffic.

• Potentially Limited Smart Routing: Traditional proxy modes cannot directly use the Argo Smart Routing feature, so the network connection quality of the origin server may directly affect website performance.

Scalability and Redundancy

Cloudflare Tunnel:

• Automatic load balancing and fault tolerance: Cloudflare Tunnel can integrate with Cloudflare's load balancing features, allowing traffic to be intelligently distributed across multiple origin servers. If an origin server fails, Cloudflare can automatically switch to a backup origin server, ensuring high availability for the website.

• Multi-region support: If you have multiple origin servers distributed across different geographical locations, Cloudflare Tunnel can automatically manage traffic routing between these origin servers, ensuring that user requests reach the closest origin server optimally.

Traditional Origin Pull (Cloudflare Direct Proxy):

• Complex load balancing and redundancy configuration: In traditional proxy mode, load balancing and redundancy configurations usually need to be manually set up on the origin server or in the Cloudflare dashboard. 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-region data centers or multi-node deployments, traffic distribution under the traditional origin pull mode may not be as efficient as with Tunnel.

Security and Defense Capabilities

Cloudflare Tunnel:

• Protecting intranet applications: Cloudflare Tunnel allows you to securely expose intranet applications (such as applications restricted to company employees) to the internet without exposing them directly to the public network. For example, if you have an internal service that you only want specific external users to access, it can be securely served via Cloudflare Tunnel.

• Reducing the exposed attack surface: When using Tunnel, the internal applications of the origin server are not directly exposed to the public network, preventing attackers from directly launching attacks against these internal applications.

Traditional Origin Pull (Cloudflare Direct Proxy):

• Exposed attack surface: In traditional origin pull mode, although the Cloudflare proxy layer provides you with DDoS protection and basic firewall features, the attack surface of the origin server exposed to the public network is relatively large, especially if additional firewalls and protective measures are not properly configured.

Summary: Cloudflare Tunnel vs. Traditional Origin Pull

Feature	Cloudflare Tunnel	Traditional Origin Pull (Cloudflare Direct Proxy)
Security	No need to expose the origin server, uses encrypted tunnels, reduces the exposed attack surface	Origin IP is exposed, posing a risk of attack, requires additional security configurations
Configuration Simplicity	Install cloudflared, simplifying origin configuration and firewall settings	Requires manual configuration of origin ports, making configuration more complex
Performance and Stability	Uses Cloudflare's Argo Smart Routing to optimize network paths	Network performance is limited by the origin server's network connection
Scalability and Redundancy	Automatic load balancing, supports traffic distribution for multi-region applications	Requires manual configuration of load balancing, complex redundancy configuration
Intranet Support	Can securely expose intranet applications, suitable for external access to internal systems	Mainly used for public network exposure, cannot easily handle intranet applications

Therefore, as can be seen from the above comparison, compared to the traditional public IP origin pull method, Cloudflare Tunnel wins in all aspects, with 360-degree coverage and absolutely no weaknesses, except for being somewhat unstable in certain harsh network environments (such as behind corporate egress devices with strict restriction policies or when using broadband operators with extremely restrictive policies).

Discovery, Analysis, and Resolution of the Issue

Accidental Discovery

It all started with my habitual action: searching for my own blog on Google (most personal bloggers probably have this slightly self-indulgent habit~). Normally, if you start from the first page and go page by page to the end, there should be at most 16 pages:

But at the very bottom of the 16th page, the following will be displayed:

What are those 155 highly similar results in the image above? It wasn't until yesterday, when I accidentally hovered my mouse over a search record, that I noticed a display similar to the one below (I don't remember how I originally found that record, as it should normally be hidden in regular searches):

How could there be an 8443 port? Then I searched directly in Google for ”blog.tangwudi.com:8443", and the results shocked me:

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

The port 8443, which is open by default on Cloudflare, gave me a bad feeling. I had previously mentioned 8443 in Chapter 3 of my Cloudflare tutorial series (see details:Home Data Center Series Cloudflare Tutorial (Part 3): How to Enter CF's Edge Network and How to Choose a Suitable Origin Pull Method):

However, I had always thought that this 8443 (including others like 2053, 2083, 2087, 2096) was just an origin service port supported by Cloudflare by default (meaning if the origin server used these ports, there was no need to use Origin Rules on Cloudflare to customize the origin pull port). But finding this record today left me a bit bewildered. So, I searched for the other ports one by one, and they all existed, just not as many (unlike 8443 which had 10 pages), and they could all be accessed using a browser with the port added:

Why is this happening?

Ports Opened by Cloudflare by Default

After searching online, I found that the ports (8443, 2053, 2083, 2087, 2096) opened by default on Cloudflare's Anycast IPs are meant to support various services and protocols. These ports are not opened specifically for each user's individual needs, but are configured for Cloudflare's own infrastructure and common use cases:

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 alternative HTTPS port, typically used as a non-standard port for the HTTPS protocol. In many cases, enterprise-grade applications and certain website services use this port for secure HTTPS connections. Cloudflare supports this port by default for certain communications with Cloudflare services or proxied traffic.

• 2053: This port is typically used for Cloudflare's HTTP traffic proxying. Cloudflare routes traffic through this port, usually to support special services for various protocols.

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

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

• 2096: This port is used for cPanel WebmailWebmail ports are typically used to access the Webmail interface provided by cPanel, and Cloudflare also supports this port to provide compatibility for users.

Why does Cloudflare open these ports?

• Compatibility: These ports correspond to many common Web applications and services, especially in Web Hosting 和 enterprise hosting environments. To ensure the widest range of compatibility, Cloudflare opens these ports, especially for hosting service providers using panels like cPanel and WHM.

• Traffic Proxy Support: One of Cloudflare's core functions is to proxy traffic and provide performance optimization and security protection. To support multiple services and protocols, Cloudflare needs to allow traffic on these ports to route through its network, thereby providing comprehensive DDoS protection, content delivery, and performance optimization.

• HTTPS Proxy: For various services that require secure communication via HTTP(S), Cloudflare opens 8443 and other ports by default as alternative ports for HTTPS proxying. This allows users and service providers to use ports other than the standard ones for transmitting encrypted traffic.

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 at its edge nodes and provides DDoS Protection、Web Application Firewall (WAF) and other security features to ensure the security of the traffic.

In plain English, the above means: on all of Cloudflare's Anycast IPs (the IP addresses resolved when accessing domains hosted on Cloudflare), these ports are open at Layer 4 (a TCP 3-way handshake can be established, you can use telnet to access the port for simple testing, or use other tools to test Layer 4 port availability), and they provide the same protection as port 443. However, these ports are not directly exposed to all users (meaning users cannot access them using domain+port by default), which means they should normally be closed at Layer 7.

---

Conducting a Layer 4 reachability test on port 8443 of ”www.visa.com“, it is indeed open:

Conducting a Layer 4 reachability test on port 8443 of ”www.visa.com“ for a Layer 7 reachability test (you can use curl in the command line), it indeed cannot be accessed using a browser:

The above tests indeed prove Cloudflare's official statement.

---

The Culprit: Cloudflare Tunnel?

To be honest, this really confused me. The key is that there is no similar option to configure in the Cloudflare dashboard. In the end, the only thing I could think of was the difference in the origin pull method. Could it be due to the difference between public IP origin pull and Cloudflare Tunnel origin pull? To confirm this, I had to find actual examples to compare. To be safe, I needed examples of both traditional public IP origin pull and Cloudflare Tunnel origin pull.

Traditional Public IP Origin Pull

Taking the blog of a blogger I quite admire (Benben) (https://blognas.hwb0307.com) as an example for traditional public IP origin pull testing.
Layer 4 reachability of port 8443:

Layer 4 reachability of port 2053:

Layer 4 reachability of port 2083:

Layer 7 reachability of port 8443 (for Layer 7, testing port 8443 is enough, they are all the same):

As you can see, it is the same as the previouswww.visa.comresults, which also indirectly proves that accessing via port 8443 by default with traditional public IP origin pull should result in a timeout.

Cloudflare Tunnel Origin Pull

This is a bit more troublesome because I don't know anyone who built a site using the tunnel method, so I had to search directly online. I planned to specifically look for personal blogs that introduce building sites with Cloudflare Tunnel. If their domain-resolved IP belongs to Cloudflare's IP address range, there is a high probability that they used the Tunnel method. Isn't this idea just genius? Using the keyword ”Cloudflare Tunnel site building”, I immediately found a target:

First, verify the identity to confirm whether Cloudflare is indeed being used:

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

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

Then test Layer 7 reachability: access the default 443, followed by 8443, 2053, 2083, 2087, and 2096 (fully testing all ports for the first test subject), and use the curl command for access to make it easier to observe; since the homepage has too much content and is not suitable for observation, I chose/about.html(which is the about page) for testing.
Default port 443:

Port 8443:

Port 2053:

Port 2083:

Port 2087:

Port 2096:

The above is basically enough to prove my ”Goldbach'sUltimate Conjecture”: For websites using Cloudflare Tunnel for origin pull, in addition to the standard port 443, ports 8443, 2053, 2083, 2087, and 2096 can all be accessed via HTTPS by default.

For further verification, I also found some blogs (their domain resolutions are all Cloudflare IP addresses, and verifying only port 8443 is enough; I was too lazy to take screenshots of the other ports one by one, as they all have the same effect. If you are interested, you can verify the other ports yourself):
1、https://liuhouliang.com:8443

2、https://mszx.me:8443

3、https://dmesg.app:8443

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

…….

Searching on Google with the keyword ”Cloudflare Tunnel website building” using this line of thought, you will find websites built with Tunnel on basically every page, and then you will find that these ports are all open by default.

Principle Analysis (Friends who dislike technical details can skip this)

Under the two different origin pull methods, ”Traditional Public IP Origin Pull” and ”Cloudflare Tunnel Origin Pull”, the difference in port behavior is caused by the fundamental differences in their ”traffic forwarding methods” and ”proxy handling mechanisms”.

Reasons for Port Timeout during Traditional Public Network Origin Pull

1. Port Restrictions of Cloudflare Proxy

• In the traditional public IP origin pull method, Cloudflare acts as a reverse proxy server, mainly responsible for forwarding user requests to your origin server. The standard ports exposed by Cloudflare to the outside are 80 (HTTP) 和 443 (HTTPS), meaning that only through these two ports will traffic be normally proxied to the specified port range of the origin server (namely ports 80, 8080, 8880, 2052, 2082, 2086, 2095 for the HTTP protocol, and ports 8443, 2053, 2083, 2087, 2096 for the HTTPS protocol). Here, "specified port range" means that choosing any of these ports is fine. As long as Cloudflare finds that one or more of these ports on the origin server are accessible, it will forward traffic from HTTP port 80 or HTTPS port 443 to one or more corresponding protocol ports on the origin server.

• For access requests on other non-standard ports (such as HTTP 2052 or HTTPS 2053), Cloudflare will also forward them, but it will only forward them to ”the same port on the origin server“.

2. Origin Server 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 has not opened the corresponding ports to receive traffic, even if Cloudflare forwards the traffic, timeouts or connection failures will occur. This is the reason for the default timeout,because under normal circumstances, the origin server will not open these non-standard ports at all(Friends who build websites using the traditional public IP origin pull method can verify this themselves).

Reasons Why All Ports Can Be Accessed Normally during Cloudflare Tunnel Origin Pull

1. Port Flexibility of Encrypted Tunnels

• Cloudflare Tunnel(cloudflared) is different from traditional origin pull methods. It establishes an encrypted tunnelto forward traffic from Cloudflare's edge nodes to your origin server, while the actual IP address and ports of the origin server are not directly exposed to the outside world.

• In this mode, Cloudflare is no longer limited to ports 80 and 443 (perhaps because Cloudflare thinks the tunnel is secure enough, so they let themselves go?), and it forwards all access requests received on all default open ports of its Anycast IP to the specified port of the origin server.

2. Tunnel Forwarding Mechanism is Not Limited by Ports

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

• After the traffic inside 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 through the tunnel to the local cloudflared client, then the client hands the requests over to the origin server for processing.

• This approach exposes the origin server's ports Cloudflare Tunnel internally, eliminating the need to expose them publicly or configure firewall rules to allow specific ports to directly pull origin through the traditional public network.

3. Separation of Origin Server Ports and Cloudflare Tunnel

• Unlike traditional origin pull, Cloudflare Tunnel establishes a “virtual proxy layer” within the tunnel, so that the origin server's ports are not directly exposed to the internet. The origin traffic is processed by the encrypted tunnel before reaching the origin server, so it is not restricted by public network firewalls and port blocking rules.

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

4. No port mapping and port forwarding requirements

• In traditional origin pull mode, if the origin server is configured with non-standard ports, Cloudflare must allow traffic through these ports and perform corresponding port forwarding. However, in Cloudflare Tunnel , 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.

Brief Summary

The above analysis is actually quite meaningless; essentially, it just depends on Cloudflare's preference. Currently, it seems that in the public network origin pull mode, non-standard traffic other than port 443 is only forwarded to the same port on the origin server (the HTTP protocol ports will be forced to redirect to HTTPS, so they are not considered); while in Tunnel mode, requests from all HTTPS protocol ports (443, 8443, 2053, 2083, 2087, 2096) are forwarded to a specific port on the origin server—it's just that crazy.

P.S. Who knows, maybe they'll change it whenever they feel like it?

Impact Brought About

Actually, if all these ports are subject to all of Cloudflare's security checks in the same way, then there won't be any security issues, which might be why Cloudflare doesn't care. The key to the problem is: because these are completely default behaviors, you might be totally unaware that, in addition to port 443 of the HTTPS protocol, traffic from so many other ports is being forwarded to your origin server!

Regardless of the reason why Cloudflare defaults to forwarding traffic from these extra ports other than 443 to the origin server, in practice, it may bring some negative impacts to the website.

SEO Issues

• Duplicate Content Issues: Although multiple ports point to the same application, if these ports can be publicly accessed (such as 8443, 2053, etc.) and no URL canonicalization is performed, thensearch engines may treat them as different pages, thereby considering it as the occurrence ofduplicate content, which in turn may consider these different URLs as independent pages (even though their content is actually the same), potentially affecting your site's ”SEO Ranking“.

Port Management Complexity

• Maintenance and Management Pressure: 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 at the origin server. For example, access logs from different ports may become cluttered, or if certain ports expose unnecessary services, these ports could become unexpected entry points for traffic.

• Unnecessary Traffic Allocation: Although these ports do not pose actual security risks, without proper access control, the origin server may bear more traffic, and such traffic usually does not bring additional business value.

Brand/User Experience Impact

• Trust and Professionalism: If users or potential customers find that your website can be accessed through multiple ports, especially some that look like “technical details” (such as 8443 or 2053), they might question the website's ”technical level” or ”professionalism” (which is the ”low-end” feel I mentioned earlier). Although most users will not delve into backend settings, exposing multiple ports may lead some users to believe the website lacks ”fine-grained configuration” or is ”poorly managed.”

• User Perception: Some users may not care about these ports, but users with high standards for ”brand image” may doubt the website's professionalism because of this. Especially in highly competitive industries, details often influence users' impressions.

Solutions

Solving the issue of ports other than 80 and 443 being accessible is actually very simple. You only need to add the following rule at the highest priority position of the WAF custom rules (using my domain as an example, you will need to change it to your own domain):

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

Note that the above command can only be written by editing the expression, as this option is not available in the standard GUI:

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

Note: Why do I recommend adding a block rule at the highest priority position? Because normally, if we want to optimize the website's SEO, Cloudflare WAF's custom rules usually include a high-priority skip rule to allow access from various verified automated programs (including search engine spiders), as follows:

If the rule blocking access to non-80/443 ports is placed after this skip rule, then due to the priority of custom rules, search engines can still access the website through all ports, while only regular users' browser access is blocked. Consequently, the issue of a single URL having multiple search records (for different ports) in search results will persist, and the SEO problem remains unresolved. However, if this block rule is placed at the highest priority, all access to non-standard ports (including search engine spiders) will be blocked, naturally solving 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 (Part 4): CF WAF Feature Introduction and Detailed Configuration Tutorial。

Additional Knowledge: Some Other ”Hidden Parameters”

During the use of Cloudflare, there are some “hidden parameters” that are not directly accessible to ordinary users and are not easily noticed, but can to some extent affect site behavior, traffic management, or security. These parameters usually belong to Cloudflare's more advanced Worker 或 Firewall Rules configurations, which involve some underlying traffic control and security rules. These parameters may be very important for developers or site administrators, but ordinary users generally do not need to understand or use them directly (similar to the ”cf.edge.server_port” parameter used in the previous section).

Below are some parameters similar to cf.edge.server_port that are generally unknown to ordinary users and typically require deeper Cloudflare configuration permissions:

cf.edge.server_port

• Features: This parameter is the port used when the Cloudflare edge node receives a request, while Cloudflare Tunnel will forward these requests to the specified port on the origin server based on the configured tunnel settings.

• Use Cases: Used in WAF custom rules to control traffic passing through specific ports.

cf.client.ip

• Features: Returns the requesting client's 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.

• Use Cases: Can be used to set access whitelists or blacklists based on IP, or even perform Rate limiting 或 geographic restrictions。

cf.ray

• Features: This is the Cloudflare request tracking identifier. Each request generates a unique Ray ID, which is used to find and track specific requests in Cloudflare's backend.

• Use Cases: Typically used for debugging or viewing detailed request information to help support teams analyze request paths and issues.

cf.visitor.ip

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

• Use Cases: Same as cf.client.ip, it can be used to set IP restrictions, request analysis, etc.

cf.pragma

• Features: This parameter displays headers related to Cloudflare caching; specifically, it shows whether Cache-Control or other cache settings are enabled. It is typically used to debug caching behavior.

• Use Cases: Used when you want to check or adjust cache settings, especially during Cache Rules debugging in.

cf.cf_access

• Features: Returns Cloudflare Access authentication-related information, such as the user's authentication status, whether authentication is required, etc.

• Use Cases: Cloudflare Access is an identity-based application access control tool. This parameter can be used to set application access permissions and authentication mechanisms.

cf.browser.bot

• Features: This is used by Cloudflare to determine whether the access request comes from the target of(Bot) parameter. If true, it indicates that the request comes from non-human users such as machines or crawlers, which may trigger some security policies or rules unrelated to user behavior.

• Use Cases: Typically used for WAF In firewall rules, filtering crawler traffic or executing Bot Management policies.

cf.warp

• Features: Indicates whether the request is through Cloudflare's Warp service for acceleration and encryption. Warp is a VPN service provided by Cloudflare, mainly used to accelerate users' internet connections.

• Use Cases: Can be used to set different routing rules or policies for users accelerated through Warp.

cf.edge.timing

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

• Use Cases: Used for performance monitoring and optimization.

cf.edge.request

• Features: This parameter can provide more detailed information about Cloudflare requests, such as the request's processing time, response time from Cloudflare to the origin server, etc.

• Use Cases: Typically used in diagnostic tools or request optimization to help detect response bottlenecks.

cf.worker

• Features: Parameters related to Cloudflare Workers, returning Worker execution information of the service. Worker is Cloudflare's serverless computing platform, which can be used to run JavaScript, handle requests, modify responses, etc.

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

cf.mirror

• Features: Indicates whether Cloudflare is using mirror data, meaning that in certain scenarios, Cloudflare will enable cache mirroring based on content type or other factors.

• Use Cases: Applicable to advanced caching and content delivery strategies.

cf.origin.latency

• Features: Shows the latency from Cloudflare to the origin server. It can help you understand origin performance, especially when request response times are long.

• Use Cases: Used for performance monitoring, detecting network bottlenecks.

cf.ratelimit

• Features: Returns information on whether the request is subject to Rate limiting rate limits. This parameter is typically used in conjunction with Cloudflare's rate limiting feature to help detect if traffic exceeds set thresholds.

• Use Cases: Controls to prevent malicious requests such as DDoS attacks and brute force.

Note: Except for ”cf.edge.server_port” among the parameters mentioned above, the information for other parameters is just collected. I haven't had the chance to use them yet, so I cannot guarantee that the functional descriptions are absolutely correct. I will verify them when I have the opportunity in the future.

Summary

Most of these control parameters are advanced features that ordinary users usually do not encounter, but they are very important fortraffic analysis、security protection、Performance Optimization和custom configurationmanagement, and monitoring needs. In most cases, only users withadministrator privilegesordeveloperswill come into contact with these parameters. Regular users can just treat this as additional knowledge.

Afterword

Actually, this article does not have much practical use for general personal bloggers: those who use the traditional public IP address origin pull method won't need it, and those who build websites using Cloudflare Tunnel generally might not care about this (except for some bloggers who pay close attention to site SEO). Therefore, at best, this article can only be regarded as a technical discussion about Cloudflare Tunnel.

However, this article also brings up a somewhat useless little trick to quickly distinguish whether a website using Cloudflare (a website whose domain resolves to Cloudflare's Anycast IP address) is based on ”traditional public IP address origin pull” or ”Cloudflare Tunnel origin pull”: simply use a browser or a command-line tool like curl to access port 8443 (or 2053, 2083, 2087, 2096) of the website. If it times out, it is based on ”public IP address origin pull”; if it is accessible or shows ”blocked”, it is based on ”Cloudflare Tunnel origin pull”.

Note 1: This article can also be considered a rather interesting case of how to quickly locate the layer (Layer 4 or Layer 7) where an issue occurs when discovering application access-related problems, as well as how to further troubleshoot the issue points and solve the problem (normal people would definitely not think that Cloudflare would treat different origin-pull methods differently). Back when I was still working, when I was falsely accused of having problems with our own equipment (friends who have worked on application delivery equipment should understand), I often needed to prove my innocence. In those situations, doing this kind of troubleshooting and locating was indispensable. In the end, over 90% of the problems had nothing to do with our own equipment~.

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