1 Introduction

Since purchasing Racknerd's VPS and completing the major project of migrating the disaster recovery node from Tencent Cloud Lighthouse Server to Racknerd Chicago VPS (see article:Home Data Center Series: The Second Reconstruction of Blog Architecture: Service Migration and Active-Active Disaster Recovery Practice Triggered by VPS Migration, data center migration is indeed a major project), I am still thinking about how to fully utilize this high-priced ($39.88/year) Chicago node (Racknerd_High-Spec 1_882), after all, a large amount of resources on the Chicago node are still idle:

On second thought, in addition to hardware resources, the Chicago node has a monthly traffic of up to 8500G, and I currently mainly use it as the primary origin server for Cloudflare for my core application (blog). This usage barely consumes any traffic, which means so much monthly traffic is completely wasted.

Since I want to make full use of the traffic, building a scientific node is the obvious choice. However, because I didn't have an overseas VPS before and didn't know much about this area, I need to sort out the relevant knowledge points first.

2 Background Knowledge: Access Dilemmas in Real-World Network Environments

In today's network environment, connections are not always ”open”: some websites are clearly online, but their pages won't open; some software has correct default configurations, but cannot be used normally; some domain names cannot be correctly resolved through public DNS; the browser's built-in encrypted DNS (such as DoH or DoQ) cannot be enabled normally... Such problems occur from time to time, and the reason is often not a failure on the server side, but ratherthe existence of a transparent ”wall” in the communication path.

In some regional networks, for purposes such as content compliance, information regulation, and data auditing, operators willtarget communications directed overseasfor intelligent identification and strategic interception. Behind this type of behavior lies a whole set of mechanisms known asDeep Packet Inspection (DPI), which does not need to decrypt the content itself, but rather analyzes the handshake metadata of encrypted protocols(such as TLS's SNI, JA3 fingerprint, QUIC's initial packet structure, etc.) to characterize and identify traffic, and then dynamically decide whether to allow it through based on matching results. These intervention behaviors all come from the transparent ”wall”.

It is worth noting that this type of intervention is not aimed at any specific protocol, service, or application, but is ratherbuilt upon the identification and blocking of ”communication behavior patterns”. This strategy naturally carries uncertainty, often resulting in ”intermittent connectivity” or ”partial service abnormalities” due to different egress links, path node policy updates, and changes in service deployment methods. As a result, what we face is no longer a stable network transmission model, but a realistic environment full of variables and dynamic gaming.

To give a simple example: you enable the ”Secure DNS” feature in your browser (such as Cloudflare or Google's DoH), intending to improve resolution privacy and integrity, but the connection might be reset by intermediate network nodes during the TLS handshake phase, resulting in ”domain name cannot be resolved” or even ”web page cannot be opened”; as another example, when some users access developer community websites (such as GitHub, Docker Hub, Stack Overflow, etc.), they encounter occasional connection anomalies, a phenomenon that is neither easy to troubleshoot nor follows any pattern.

For ordinary users, this may just be ”occasionally unable to open a certain website”—they can choose to switch content or avoid the problem; but for technical users, cross-border office workers, and developers of self-built services, the challenge behind this is much deeper:the unpredictability of connections and the structural uncertainty of communications. In this context, if the traditional ”direct access” mode is still used for communication, friends who need to communicate with overseas servers will find it extremely difficult.

How to solve this? The most common way is to use scientific internet access to build a ”communication tunnel” that bypasses the intervention path, thereby avoiding interference from the transparent ”wall” when accessing overseas content.

Currently, the methods of scientific internet access can be roughly divided into two categories:

The first category is using paid services provided by third parties。

The characteristic of this type of service is “out-of-the-box”: users only need to purchase an account and subscribe to the configuration to connect to overseas nodes with one click, without needing to care about technical details such as underlying protocols, back-to-source mechanisms, or traffic splitting. It is almost the most hassle-free solution, with a low barrier to entry and an intuitive experience, making it highly popular among novice users. However, at the same time, this solution also carries certain hidden risks:

• The phenomenon of some cheap service providers ”running away” is common, and user assets and data security cannot be guaranteed;
• Just ”running away” is still fine, but if you encounter an officially-led ”honeypot” provider, well...;
• Some high-end services are stable but expensive, resulting in higher long-term usage costs;

The second category is building your own circumvention nodes.

The core of this approach lies in: you own acontrollable overseas VPS, deploy the server-side program yourself (such as sing-box, xray, trojan-go, etc.), and manage the connection protocols and policies on your own. The advantages of this path are obvious:

• You can freely choose protocol types, encryption methods, and transmission paths,avoiding the traffic characteristics of mainstream services;；
• you can deploy multiple nodes on demand, integrate transit, and access tunnel/CDN methods to achievehigher block-resistance and flexibility;；
• costs are more controllable: the monthly traffic included with a typical VPS is sufficient for multiple people to use;

but its disadvantages are equally obvious:

• it requires basic network knowledge, understanding operations such as VPS management, domain name resolution, and certificate application;
• you need to cope with the policy updates of the transparent ”wall” yourself, dynamically adjusting deployment methods, protocol configurations, and node architectures;
• you also need to deal with occasional IP blocking, certificate revocation, domain name pollution, and other issues, requiring a certain level of troubleshooting capability.

Therefore,The choice between building your own circumvention service nodes and using third-party circumvention services often depends on the user's trade-off between stability, security, cost, and controlAnd the focus of this article is precisely to help users who have some hands-on ability and wish to build a more reliable communication environment understand and master the core principles and evolution of ”building your own circumvention nodes.”

This article does not cover ”using third-party circumvention services,” but only discusses how to use existing overseas VPS to build your own circumvention service nodes for study and work needs. Generally speaking, building your own circumvention nodes offers two major choices: direct connection and non-direct connection, each with its own advantages and disadvantages.

3 Direct Connection Mode: A Circumvention Solution with Directly Exposed Origin Servers

1 Traversing the Transparent ”Wall”: The Natural Challenge of Direct Connection Mode

In the context of circumvention access, the so-called ”direct connection mode” does not mean that users directly access the target website, but rather that users, through acommunication link established by themselves with an overseas VPS that they control and trust, forward subsequent access requests to the overseas VPS, which forwards them on their behalf. This can actually be broken down into two key stages:

1. Connection Stage: Directly connect from the local device to the overseas VPS, establishing a communication channel that traverses the transparent ”wall”;
2. Forwarding Stage: Send access requests for target websites and services to the overseas VPS, which makes the requests on your behalf and returns the response content.

The second stage is easy to implement, but the critical first stage, the ”connection stage,” is very difficult:How to smoothly ”pass through” the transparent ”wall”?

2 Connection Phase: Can You Connect to the VPS?

In the domestic network environment, if a client wants to directly connect to an overseas VPS (usually a public IP on some cloud service), it must go through an ”unpredictable” outbound path. On this path, there is an invisible mechanism that screens, judges, and processes cross-border traffic in real-time: What service are you trying to connect to? Does the protocol look like HTTPS? Have you been ”abusing” this link recently? Has it triggered established rules?

This mechanism is seemingly invisible but actually runs on key nodes such as backbone egress routers and ISP edge gateways, relying mainly on the following methods:

• Deep Packet Inspection (DPI): Analyzing SNI fields, JA3 fingerprints, ALPN protocol flags, etc., during the TLS handshake phase to identify the server type and communication intent;
• Behavioral Pattern Matching: Establishing signature databases for the behavior of non-standard protocols (such as proxies masquerading as HTTPS, QUIC, or DoH) to perform targeted blocking;
• Path Pressure Monitoring: If non-browser-like connection requests frequently appear on a certain egress path, it may also be dynamically rate-limited, have connections reset, or have packets dropped directly.

This means:Even if you listen to the VPS service on port 443 and wrap the communication content in the TLS protocol, it does not guarantee a smooth connection; even if connected, it does not guarantee stability.

Protocols and Ports: ”Morphological Characteristics” Affecting Direct Connection Pass Rates”

When facing policy identification by intermediate devices,the combination of communication protocol types and ports usedwill directly affect whether data packets pass through smoothly. The transparent ”wall” will not explicitly state ”who is blocked,” but behaviorally, it will be more sensitive to certain characteristics and more prone to interference. The following are the more common ”release priorities” in the current network environment:

• TCP Port 443 (HTTPS)
  This is the mainstream port for modern encrypted communication, and a large amount of traffic, such as browser access, system updates, and mobile app backends, goes through this path. To avoid accidentally disrupting compliant communications,policy systems tend to be more restrained with traffic on port 443, possessing the highest ”release priority.” Therefore, many circumvention protocols will actively ”borrow the shell” of port 443 to improve their disguise.
• TCP Port 80 (HTTP)
  A plaintext protocol, but still widely used for various services with low security requirements. Despite the low level of encryption, due to its widespread use, it also has a certain ”basis for release.” However, because it is plaintext, it is easy to be completely parsed,making it suitable for obfuscation but not for carrying sensitive traffic itself.。
• The UDP protocol as a whole is in a ”highly sensitive zone”
  Unlike TCP, UDP is connectionless and stateless, naturally better suited for high-speed transmission and instant messaging, but also easier to abuse. The default policy of policy systems toward UDP is usually more aggressive, commonly manifested as:
  • QUIC (HTTP/3): Explicitly based on UDP, it is often used to improve performance when accessing services like Google and YouTube. However, due to its obvious behavioral characteristics and conspicuous initial handshake, it often encounters connection failures or downgrades back to TCP.
  • WireGuard / OpenVPN (UDP mode): In the early days, they were the mainstays for self-built censorship-circumvention nodes, but these protocolshave fixed handshakes, obvious characteristics, and unique fingerprints, which have been widely mastered by DPI systems, leading to easy instant disconnection, high latency, and poor stability.
  • Emerging high-performance tunneling protocols such as Hysteria / TUIC: Although transmitted over UDP, they are designed with a greater emphasis on anti-identification and anti-blocking capabilities,possessing a higher degree of ”anti-interference” attributes to some extent, but it still depends on the actual deployment method and path conditions.
• “Hybrid protocols” or ”TCP protocol simulating UDP”
  Some tools (such as Trojan-Go), although mainly based on TCP, can optionally enable UDP forwarding. This mode performs inconsistently in policy judgment:It is relatively safe when not enabled, but may trigger more interference once enabled。
• DoH (DNS over HTTPS)
  is actually a variant of DNS queries encapsulated via HTTPS, running on TCP port 443. But because of its ”atypical HTTPS” behavior (such as extremely short handshakes and small packet exchanges), on some pathsit may still be judged as abnormal communication and blocked。

Therefore, one cannot just look at the protocol name or tool name, but must also focus on itsrunning mode, port used, whether it uses UDP, and whether it has typical handshake characteristicsamong other dimensions. What truly affects the success rate of traversal is not ”what protocol is used”, butwhether your protocol behavior is ”normal enough”、whether it is treated as ”traffic that should be allowed through” by the transparent ”wall”。

3.3 Conventional traffic obfuscation schemes are not necessarily foolproof

To pass the first stage, many ”protocol obfuscation” schemes have appeared on the market. Their core idea is to make your traffic look like an ordinary person opening a webpage (http + tls). Below is a comparison of obfuscation schemes for different protocols:

These schemes did bring some breakthroughs when they first appeared, but their subsequent drawbacks are also very realistic:

• Traffic characteristics are stable,and protocol fingerprints are gradually being figured out, especially protocols like Trojan,which have not been updated for years and have distinct characteristics；
• Interference methods such as DNS pollution, TLS Reset, and active probing (e.g., probing response behavior) are frequently encountered;
• Even if TLS is enabled, the SNI (Server Name Indication) remains in plaintext and can be exploited;
• Most obfuscation strategies rely on HTTP Host Headers or traffic padding, making them increasingly vulnerable to sophisticated DPI.
• The origin IP and service port are exposed for long periods, making them easy to probe and block;

3.4 Don't get me wrong, connecting to a VPS ≠ successful censorship circumvention

It must be emphasized that connecting to an overseas VPS is only the starting point of censorship circumvention.The core of censorship circumvention lies in: whether you can smoothly access restricted overseas resources through the VPS and safely bring the response back to your local machine.

And this process is also subject to various types of interference:

• Is the path for the VPS itself to access external network resources reliable? For example, is access also restricted when visiting Google, YouTube, or GitHub?
• Are data packets reset midway due to ”abnormal traffic characteristics”? For example, even though you are just opening an ordinary webpage, the connection suddenly returns a large amount of data and occupies bandwidth for a long time during the page loading process. This ”behavior inconsistent with expectations” may be regarded as ”suspicious communication” by the identification system, which then forcibly terminates the connection by sending an RST.
• Does the overall link have sufficient stability and stealth? For example, some friends have configured nodes based on Hysteria or WireGuard, which perform excellently during speed tests, but experience frequent disconnections or even direct connection resets during actual use. This is often not an issue with the VPS itself, but rather that the link is detected as abnormal when passing through certain critical routing segments, resulting in strategic interference—such as abnormal handshake characteristics, sudden packet changes, or ”unnatural” traffic behavior, all of which can become triggers.

This is the natural limitation of the direct connection mode: it relies too heavily on ”direct communication” and exposes the target too easily.

Note 1: When using the ”direct connection” method to build censorship circumvention services, a potential requirement is the latency when directly accessing the VPS. Therefore,the choice of the node's physical location becomes particularly important—you not only need to consider bandwidth, price, and region, but also need to considerthe quality of the link starting from your locationOtherwise, even if the node is set up, the client will not get a good user experience due to high latency or severe packet loss. In addition, the ”direct connection” solution also means that the server's real IP will be directly exposed to the public network. If the network to which this IP belongs has poor anti-interference capabilities, the ISP is niche, or the behavior pattern is too ”obvious”, it can easily be precisely identified and blocked. Therefore, the server VPS is usually required to use a ”premium line.” This is precisely one of the root causes why many people start considering ”non-direct connection” solutions:It's not that direct connection is bad, but that ”direct exposure” is not stable or durable enough in today's environment。

Note 2: Although ”direct connection + TLS” itself already has a certain level of encryption, this is often not enough in the current detection environment.Therefore, we can use middleware that supports reverse proxying, such as Nginx, Caddy, or HAProxy, to ”wrap another layer of normal Web traffic shell” on the VPS”, such as running a blog, a CDN cache site, or returning a static webpage response at the same time, to obfuscate traffic characteristics and make it ”look more like a normal HTTPS website.” Although this type of ”multi-layer masquerade” cannot completely avoid identification, it can significantly increase fault tolerance and stability during passive interference.

Note 3: Of course, this does not mean that the “direct connection” mode is unusable; after all, users who build their own censorship circumvention nodes using the “direct connection” mode still account for a significant proportion. Many rely on its simple configuration and low latency, especially in the early stages when nodes were unrestricted or still had good effects in specific regions, making it the preferred solution for many. However, looking at the trend, this mode will face increasing difficulties: on one hand, the methods used by operators and platforms to identify and interfere with encrypted traffic are continuously evolving, making simple direct connections easier to probe, speed-limit, or even block; on the other hand, more and more services need to seek a more balanced solution among anti-censorship, stability, and stealth, which means that adopting more complex architectures, such as relaying, tunnel encapsulation, and multi-location traffic splitting, will gradually become mainstream.

4 Non-Direct Connection Mode: Hiding Origin Server IP with Transit Entry Points

1 Why Do We Need ”Non-Direct Connection”?

In the early stages of ”censorship circumvention,” the direct connection mode was a seemingly simple and straightforward way: as long as the client was connected to an overseas VPS and requests were forwarded through a controlled channel, the external internet could be accessed. However,This ”seemingly connected” path is actually extremely fragile.: Once the IP address of an overseas VPS is exposed to the domestic network, it may become a key target of DPI (Deep Packet Inspection) systems, behavior recognition models, and keyword monitoring systems. Once flagged, the connection will experience the following issues:

• Traffic being rate-limited, interference injected, or even directly reset；
• The VPS IP is added to the blocklist, completely interrupting the connection；
• Cross-border communication suffers ”periodic death” without clear error messages, making it difficult to locate the source of the problem。

The core of the problem:The transparent ”wall” does not target a specific service or site, but rather attempts to identify ”abnormal connection behavior”And when an overseas VPS is accessed by dozens of clients in the same way, with fixed traffic characteristics and abnormal access frequencies, the ”identity” of this VPS is no longer that of an ordinary Web server, but a suspicious communication transit point.

In this context, continuing to persist with a ”direct connection” strategy means:

• Constantly changing VPS;
• Dealing with connection instability at any time;
• Every user must bear the high risk of connection failure and traffic blocking.

But the more fundamental problem lies in:If the user's request directly points to the real address of the target service every time, the server ”cannot hide,” and the identification system will always have room to operate。

2 The Key to Implementing “Non-Direct Connection”: Transit Entry Points

In fact, the true significance of the non-direct connection mode is to prevent the ”origin server” IP from being exposed to the public network, which requires it to be used in conjunction with a transit entry point. A true ”non-direct connection” solution should be a link like this: Domestic Client ── Connection ──> Transit Entry Point ── Forwarding ──> Real VPS / Origin Service. Under this design, as far as the transparent ”wall” is concerned, it only ever sees the domestic client accessing the transit entry point, while remaining completely oblivious to the origin server behind it.

How to find a ”transit entry point”?

To serve as a ”transit entry point” in today's network environment, not just any machine will do; it must meet several key conditions:

• The IP will not be easily blocked: Ideally, IPs from major providers with a ”trusted background” that won't be immediately blocked due to a bit of ”atypical traffic”
• Possess a certain degree of neutrality: Such as CDNs and distributed network platforms, which the wall is naturally more ”gentle” towards and will not easily target
• Support custom traffic forwarding: Such as the ability to establish reverse tunnels, WebSocket forwarding, or direct TCP/QUIC forwarding

Taken together, these conditions actually rule out the vast majority of personal servers or cheap commercial VPSs: what you need is not a springboard that ”anyone can deploy,” but a”disguise point” that won't easily run into trouble”。

In reality, the preferred choice for a transit entry point is Cloudflare, because it happens to possess all the aforementioned qualities, making it in itself aA highly promising transit gateway：

• Stable IP with extremely high reputation: Its network nodes widely serve millions of websites globally, acting as the ”infrastructure” of the modern Web world;
• A natural CDN platform: The firewall's policy handling of CDNs is more restrained, often prioritizing ”availability”;
• Supports flexible reverse proxy logic: Relays public network traffic back to your real service through its own ingress network.

3 Prerequisite Knowledge: How Cloudflare's Reverse Proxy Function is Implemented

When using Cloudflare to build a ”non-direct connection” transit gateway, what really plays a role is not its traditional function as a CDN, but itsglobally covered edge networkandhighly flexible reverse proxy capabilities, so it is necessary to first understand the ”reverse proxy” methods it provides.

From an overall mechanism perspective, Cloudflare provides two typical ”reverse proxy” methods:

1. Public IP Origin Pull (Public IP Origin)

In this mode, Cloudflare acts as an edge proxy, merely forwarding requests from clients, and then pointing via DNS to your configured public server IP, pulling content from the origin. Although deployment is simple, it also exposes a fatal issue:Your real server IP must be publicly visible, which is precisely what ”non-direct connection” aims to avoid.

2. Cloudflare Tunnel (Intranet penetration reverse proxy)

This is our main focus: Tunnel is started by yourself on the server side, actively initiating a connection to Cloudflare to create areverse channel, allowing Cloudflare to securely forward user requests to services on intranet/non-public IPs. Throughout this process,there is no need to expose the origin IP, nor is there any need to open any public ports.

From the perspective of stealth, security, and survivability, Tunnel mode is clearly more in line with the design goals of ”non-direct connection”:

• The origin IP is never exposed in DNS, scanners, or direct connection tests;
• The entire link is established from the inside out, avoiding the interference and blocking faced by traditional connection methods;
• Even if the service is deployed in home broadband, NAT intranet, or even IPv6-only environments, it can be easily connected.

Therefore, in the current complex network environment, Cloudflare Tunnel has become one of the mainstream implementations of the ”non-direct connection” model, especially suitable for use in combination with self-built proxy services.

4 The Cost and Limitations of “Non-Direct Connection”

In the previous section, we mentioned:Cloudflare Tunnel has become one of the mainstream implementations of the ”non-direct connection” model, which hides the real origin IP and only exposes Cloudflare's edge nodes, allowing many self-built solutions to continue to survive in today's environment.

But unfortunately, if you want to ”seamlessly integrate” your existing proxy service into Cloudflare Tunnel, you will find that not all protocols are supported—Tunnel does not equal an ”all-purpose reverse proxy”，, it only supports a very small number of protocol stacks that can be ”successfully disguised”. This is because Cloudflare Tunnel was originally designed toserve Web applications, and by default, it expects you to provide a standard HTTP or HTTPS service, while also preventing abuse. This also means:Only those proxy protocols that themselves ”look like HTTP services” can be smoothly integrated and successfully transmitted by Tunnel. Typical representatives are Trojan and VLESS —they themselves emphasize ”disguising as browser access” through TLS, WebSocket, etc., which happens to align with Cloudflare's traffic policy.

Therefore, if you want to transit proxy protocols through Tunnel, the recommended combination is:

What is WebSocket? Why do we need it?

WebSocket is a ”persistent connection” mechanism running on top of the HTTP protocol, originally designed to establish achannel for real-time, bidirectional communicationand its magic lies in:

• The initial handshake phase looks just like a standard HTTPS request (which is crucial for ”disguise”);

• Once the connection is successfully established, any type of data can be transmitted through this seemingly ordinary ”web channel”—including the proxy traffic we want to route.

  For Cloudflare Tunnel, it expects to proxy website requests by default, so if you want to ”secretly” slip in other non-standard traffic, you must firstencapsulate these proxy protocols into WebSocketto disguise them as compliant traffic and bypass detection. This is also why protocols like Trojan and VLESS are often recommended to be paired with WebSocket:Not only can they disguise themselves better as website visits, but they can also pass through Cloudflare Tunnel's ”Web inspection”.

5 Is the Speed of “Non-Direct Connection” Scientific Nodes Necessarily Slower Than ”Direct Connection” Scientific Nodes?

This is a question, or even a misconception, in the minds of many self-hosting users. Intuitively,“non-direct connection” solutions take a detour in the link, which inevitably leads to performance degradation. But the truth is, this judgment does not hold true in today's network environment, and in fact, it is often quite the opposite—“non-direct connection” is actually faster and more stable. The main reasons are as follows:

1、Direct connection ≠ smooth access; in many cases, it is ”constantly blocked after being identified”

“The biggest problem with ”direct connection" proxy nodes is not bandwidth, but whetherthe traffic is delivered completely and stably to the target VPS. In reality, many so-called ”direct connection” connections are not truly ”smooth”:

• Packets are dropped midway or actively reset (RST);
• Communication is possible after the connection is established, but the speed is extremely slow and unstable;
• Sudden inability to connect during certain periods, followed by miraculous recovery.

These phenomena are not uncommon, and what they actually reflect is thatthe link is untrusted. Therefore, the root cause of the slow speed of many ”direct connections” is not that they take a direct route, but that this routesimply does not welcome you。

2、“Non-direct connection” avoids traffic identification through transit, improving overall link quality

In contrast, ”non-direct connection” hides the true origin server through a transit entry, making the traffic in the first half of the link look like it is accessing a regular service (such as Cloudflare nodes, well-known cloud provider IPs, CDN distribution centers, etc.), thereby obtaining higher link fault tolerance and stability on the access side。

Moreover, the connection between the transit entry and the origin server usually uses standard international routes and is free from intermediate interference,and the quality of this link is often much higher than ”direct connection through the firewall”。

3、Latency and throughput are not only affected by ”short path”

Many people mistakenly believe that ”the shorter the path, the lower the latency,” but in today's network environment:

• Whether the path is rate-limited, interfered with, or suppressed
• The egress quality of the data center where the origin server is located
• The throughput bottleneck of the transit server
• The connection recovery/retransmission efficiency of the protocol

These factors are often more critical than path length. For example, a ”direct connection” VPS located in a small Asian data center might have poor egress and frequent TCP handshake failures; whereas a ”non-direct connection” VPS, although detouring through Cloudflare Tunnel, uses high-quality major provider lines like GCP or Azure, making it much more stable and faster.

4、“Non-direct connection” can also easily build mechanisms such as multi-point transit, load balancing, and failover

This is difficult to achieve in ”direct connection” mode: once a node is identified and blocked, the entire solution fails. In contrast, ”non-direct connection”, by its nature, possessesflexible entry configuration and protocol disguise capabilities, making it highly suitable for building more engineering-resilient architectures such as multi-link parallel and dynamic switching.

Conclusion:“Non-direct connection” is not a ”second-best choice”, but a realistic choice with better stealth, anti-interference, and scalability in modern network environments. Whether its performance is slower than ”direct connection” does not depend on ”whether it takes a straight line”, but onthe overall security, stealth, and scheduling capability of the link。

6 Cloudflare Tunnel and Compliance Issues of Scientific Purposes

Although Cloudflare Tunnel is almost naturally an ideal tool for ”non-direct connection” mode—it is stable, globally distributed, does not require exposing public IPs, and can seamlessly work with protocols like VLESS/Trojan to complete a fully disguised TLS + WebSocket link—a solemn reminder must be made here:Cloudflare explicitly prohibits the use of its services for proxies, VPNs, bypassing internet censorship, etc.

Cloudflare's Terms of Service (https://www.cloudflare.com/terms/) contains multiple mentions prohibiting the use of its infrastructure for behaviors such as ”bypassing access control,” ”unauthorized access,” and ”violating local laws or service provider policies.” In its community, ticket replies, and actual account suspension cases, it has also been clearly pointed out multiple times that:

• Establishing proxy, VPN, or traffic forwarding services through Cloudflare Tunnel is not allowed;
• If a large amount of atypical traffic or proxy behavior is detected, it may automatically trigger rate limiting, subdomain bans, or even account suspension;
• It particularly emphasizes high sensitivity to traffic ”unrelated to the public network” (such as intranet proxies and censorship circumvention purposes).

This means that,although technically feasible, it is actually non-compliant: being usable does not mean it should be used. In the current environment, Cloudflare Tunnel is indeed one of the few channels that can be stably used for ”non-direct connection” scientific internet access links, but from the perspective of service agreements and actual risks,it is more suitable as a tunnel service for ”reasonable uses” such as development, demonstration, and remote management。

If you insist on using it for scientific internet access services:

• it is recommended to limit it topersonal low-frequency use；
• as much as possibleset up access control、hide paths, and avoid high-traffic behavior;
• Most importantly,do not publicly disclose or share the usage methods or service addresses, to avoid affecting the entire Tunnel ecosystem.

After all, Cloudflare is not here to help you with ”scientific internet access”; its goal is to provide secure, compliant acceleration and protection services for Web applications.

5 Building Scientific Nodes Based on sing-box

1 Introduction to sing-box

Actually, apart from the theoretical content mentioned earlier, I didn't originally plan to explain the use of specific tools in detail. On one hand, this kind of content is always somewhatsensitive, and on the other hand, the choice of tools and protocols itself does not have an absolute ”optimal solution” — what is more important is to understandthe underlying principles and structuresHowever, to make the structure of this article more complete, and to help some beginners better ”implement” what was discussed earlier, I will still briefly explain a configuration demonstration of the tools.

Currently, the more mainstream choices include tools like Xray, Hysteria, NaïveProxy, tuic, etc., each with its own characteristics and use cases. But considering stability, flexibility, and update activity, I ultimately chosesing-boxas an example.

Unlike the traditional approach of ”running one protocol to the end,”sing-box is more like a highly modular proxy frameworkIts positioning is very clear: integrating multiple proxy protocols, providing extremely strong configurability, and offering advanced users the ability to build complex scientific internet access scenarios.

In terms of protocol support, sing-box is currently one of the few proxy tools that simultaneously features broad support for both inbound and outbound protocols. It can run as a client, as a remote server, or even be used to build layered multi-level forwarding structures (such as ”DNS split routing + TLS forwarding + multi-exit outbound”). Common proxy protocols like VLESS, Trojan, Shadowsocks, Hysteria2, Tuic, SOCKS, and WireGuard are fully supported, and outbound protocols even include VMess (compatibility mode), HTTP, DNS split routing, etc., covering almost all mainstream needs.

In addition to the protocols themselves, sing-box's support for the transport layer is also comprehensive. It natively supports transport mechanisms such as TLS, Reality, WebSocket, gRPC, QUIC, and XTLS. Users can flexibly combine them according to actual needs to achieve both covert and stable traffic obfuscation.

In terms of configuration, the advantage of sing-box lies in being ”clear and powerful.” Although it does not have ”one-click configuration” like some GUI clients, the JSON configuration file structure is clear, the official documentation is complete, comments are supported, and the logic is highly self-consistent. Unlike Xray, which hides many behaviors in default logic that ”you wouldn't guess unless told,” it encourages you to explicitly define every behavioral detail. Once you understand the core architecture, you can write completely controllable and behaviorally transparent configuration files. Not only that, it also comes with a command-line debugging tool that can be used to check routing matches, test connections, and analyze links, which is crucial for troubleshooting.

It is worth mentioning that in terms of support for new protocols, sing-box is also significantly ahead of other tools. For example, it is one of the earliest proxy projects to support Reality, a new mechanism that does not rely on certificates and simulates real TLS traffic, greatly improving stealthiness; another example is Hysteria 2 and Tuic 2, these QUIC-based anti-interference protocols, which also received immediate support in sing-box. In addition, it has a built-in obfuscation plugin system, allowing users to customize obfuscation rules to further enhance anti-interference capabilities.

Overall, if you hope that you canfully control node behavior, flexibly define every inbound and outbound traffic, and finely control obfuscation methods and protocol details, then sing-box is currently one of the core tools most worth studying and using in depth: it was not born to ”simplify scientific internet access,” but to maintain freedom even in complex environments.

2 Installing sing-box

2.1 Installation via APT

mkdir -p /etc/apt/keyrings

curl -fsSL https://sing-box.app/gpg.key -o /etc/apt/keyrings/sagernet.asc

chmod a+r /etc/apt/keyrings/sagernet.asc

   echo '
Types: deb
URIs: https://deb.sagernet.org/
Suites: *
Components: *
Enabled: yes
Signed-By: /etc/apt/keyrings/sagernet.asc
' | tee /etc/apt/sources.list.d/sagernet.sources

apt-get update

apt-get install sing-box

Check version and features:

sing-box version

Note: Installing via the default apt method only installs the latest official release version.

2.2 Directly Downloading Official Builds

In addition to the apt method, you can also directly use the officially built version, taking version v1.11.10 as an example:

wget https://github.com/SagerNet/sing-box/releases/download/v1.11.10/sing-box-1.11.10-linux-amd64.tar.gz

tar -xzf sing-box-1.11.10-linux-amd64.tar.gz

cp sing-box-1.11.10-linux-amd64/sing-box /usr/local/bin

chmod +x /usr/local/bin/sing-box

2.3 Installation via Docker

2.3.1 Via docker run:

docker run -d \
  -v /etc/sing-box:/etc/sing-box/ \
  --name=sing-box \
  --restart=always \
  ghcr.io/sagernet/sing-box \
  -D /var/lib/sing-box \
  -C /etc/sing-box/ run

2.3.2 Configuration File for docker compose Method

version: "3.8"
services:
  sing-box:
    image: ghcr.io/sagernet/sing-box
    container_name: sing-box
    restart: always
    volumes:
      - /etc/sing-box:/etc/sing-box/
    command: -D /var/lib/sing-box -C /etc/sing-box/ run

3 Creating Configuration Directory and Configuration File

3.1 Ramblings

One annoying thing about sing-box is that configuration files between different versions can vary significantly, because its development pace is extremely fast, updates are frequent, and many features are constantly being refactored and renamed. For example, some fields in older versions are merged or split in newer versions, and the behavioral logic of certain modules changes with version iterations. This leads to many tutorials online, and even official documentation, having sample configurations written at different times that are incompatible with each other, making it very easy for beginners to run into issues.

Especially when you refer to others” configurations, if there is a large gap between the version numbers on both sides (actually, it doesn't necessarily have to be a large gap to cause problems; even a difference of a minor version can be hard to say~), it is very likely that ”the configuration looks correct, but it won't run at all" will happen. Therefore, when using sing-box, you must pay attention toensuring the consistency among the tutorial examples, your own program version, and the official documentation, otherwise the debugging process can become very painful.

Friendly reminder: If you pursue stability, it is recommended tolock the version for use after verifying a working configuration; if you want to use the latest features, such as advanced functions like Reality and Tuic2, you must be mentally prepared to constantly update your configuration along with the release logs.

3.2 Server-Side Configuration Example (v1.11.10)

Create a new directory and create the config.json configuration file:

mkdir -p /etc/sing-box
vim /etc/sing-box/config.json

Using the ”vless+tls+websocket” method, fill in the following configuration (server-side configuration):

{
  "log": {
    "level": "info" // 设置日志等级，可选: trace/debug/info/warn/error。这里设为 info，表示输出一般运行信息。
  },
  "inbounds": [
    {
      "type": "vless", // 入站协议类型为 VLESS
      "listen": "0.0.0.0", // 监听所有网卡的 IP 地址
      "listen_port": 8443, // 监听端口为 8443，客户端需连接此端口
      "users": [
        {
          "uuid": "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx" // 用户认证使用的 UUID，客户端配置中需保持一致
        }
      ],
      "tls": {
        "enabled": true, // 启用 TLS 加密
        "server_name": "xxx.exapmle.com", // SNI（Server Name Indication），应与证书中的域名一致
        "certificate_path": "/etc/certs/xxx.exapmle.com/fullchain.pem", // TLS 证书路径
        "key_path": "/etc/certs/xxx.exapmle.com/key.pem" // TLS 私钥路径
      },
      "transport": {
        "type": "ws", // 使用 WebSocket 作为传输层
        "path": "/websocket" // WebSocket 的访问路径，客户端需匹配
      }
    }
  ],
  "outbounds": [
    {
      "type": "direct" // 出站类型为直接连接（不代理），表示这是一个终端节点（非转发代理）
    }
  ]
}

The uuid in the above configuration can be generated using an online tool, or you can use mine:Online UUID Generator Tool。

Run the sing-box server side:

sing-box run -c /etc/sing-box/config.json

Note 1: In this example, because this is deployed on an overseas VPS node, ”outbounds” can simply use the direct method for direct outbound; if you plan to have this server continue to proxy the received traffic out, then ”outbounds” should not be direct, but should point to other proxy nodes (such as an outbound configuration for shadowsocks, vless, or trojan).

Note 2: In addition to vless, you can also use trojan, which depends on your preference. With the support of Cloudflare Tunnel, there is actually no difference between using vless or trojan (TLS is all handled by Cloudflare), vless is just slightly more lightweight.

3.3 Client-Side Configuration Example (v1.11.10)

Create a new directory and create the config.json configuration file:

mkdir -p /etc/sing-box
vim /etc/sing-box/config.json

Using the ”vless+tls+websocket” method, fill in the following configuration (client-side configuration):

{
  "log": {
    "level": "info" // 设置日志等级，这里为 info，表示输出常规信息
  },
  "inbounds": [
    {
      "type": "http", // 入站类型为 HTTP 代理
      "tag": "http-in", // 标记名称，可用于路由等功能中引用
      "listen": "0.0.0.0", // 监听所有网卡地址
      "listen_port": 8080 // HTTP 代理监听端口为 8080
    },
    {
      "type": "socks", // 入站类型为 SOCKS5 代理
      "tag": "socks-in", // 标记名称
      "listen": "0.0.0.0", // 监听所有网卡地址
      "listen_port": 1080 // SOCKS5 代理监听端口为 1080
    }
  ],
  "outbounds": [
    {
      "type": "vless", // 出站协议类型为 VLESS，用于连接服务端
      "tag": "vless-out", // 出站标记，可用于路由匹配
      "server": "xxx.exapmle.com", // VLESS 服务端域名或 IP 地址
      "server_port": 443, // 服务端监听的端口，配合 TLS 使用
      "uuid": "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx", // 身份验证用 UUID，需与服务端配置一致
      "tls": {
        "enabled": true, // 启用 TLS 加密
        "server_name": "xxx.exapmle.com" // TLS 握手时使用的 SNI，应与服务端证书一致
      },
      "transport": {
        "type": "ws", // 使用 WebSocket 传输方式
        "path": "/websocket" // WebSocket 的路径，应与服务端配置一致
      }
    }
  ],
  "route": {
    "auto_detect_interface": true, // 自动检测默认网络接口（比如出口网卡）
    "final": "vless-out" // 所有未被其他规则匹配的流量最终走 "vless-out" 这个出站
  }
}

This configuration is suitable for forwarding local HTTP/SOCKS requests to the remote VLESS server uniformly, making it suitable as a proxy entry point for browsers or local applications in a home intranet.

Run the sing-box client side:

sing-box run -c /etc/sing-box/config.json

Note: The Client-side UUID must be consistent with the Server-side UUID.

4 Configuring Auto-Start on Boot

Create the service file:

vim /etc/systemd/system/sing-box.service

Paste and save the following content:

[Unit]
Description=Sing-box Service
After=network.target

[Service]
ExecStart=/usr/bin/sing-box run -c /etc/sing-box/config.json
Restart=on-failure
RestartSec=5s
LimitNOFILE=1048576

[Install]
WantedBy=multi-user.target

Description=Sing-box Service

systemctl daemon-reexec
systemctl daemon-reload
systemctl enable --now sing-box

[Service]

systemctl status sing-box

6 Summary

Restart=on-failureRestartSec=5sLimitNOFILE=1048576[Install]。

WantedBy=multi-user.target

• Enable and start the service:systemctl daemon-reexecsystemctl daemon-reloadsystemctl enable --now sing-boxCheck service status:systemctl status sing-box。
• In fact, whether you use "direct connection" mode or "non-direct connection" mode,almost no differentiated adjustments are needed at the sing-box server/client configuration level. The core that determines the access method often only lies in the xxx.example.com
  1. domain name resolution pointing in the configuration fileTaking a domain name hosted on Cloudflare as an example:
  2. If youturn off Cloudflare's proxy function

(i.e., turn off that ”orange cloud” icon), allowing the domain name to resolve directly via an A record“to the public IP of the sing-box deployment node

, while the node opens and listens on the corresponding port, then when the client accesses the domain name, it is actually connecting directly to the node, which belongs todnscrypt-proxy (v2.1.8) Multi-Scenario Configuration Guide: From Upstream Deployment to Downstream Integration。