Principle of GFW#
To combat the GFW, one cannot merely focus on surface phenomena such as what can or cannot be accessed. Knowing that YouTube is inaccessible is of no help for bypassing the firewall. However, understanding how the GFW prevents access to YouTube is crucial for selecting and implementing the next steps in bypassing it. Therefore, before discussing how to bypass it, one must first delve into the principles of how the GFW operates.
In general, the GFW is a distributed intrusion detection system, rather than a firewall in the strict sense. Not every IP packet entering or leaving the country needs to pass through the GFW first. As an intrusion detection system, the GFW treats each visit to Facebook as an intrusion, and upon detecting an intrusion, it takes countermeasures, which commonly involve connection resets.
There are two methods of detection: manual detection and machine detection. Reporting a website to the National Internet Information Office is participating in manual detection. After detecting an "inappropriate" website, some countermeasures will be taken to prevent domestic internet users from accessing that site. For this type of blocking, evading detection is not a technical issue; one can only take countermeasures based on the responses taken by the GFW. The other type of detection is machine detection, which can be further subdivided:
Reconstruction refers to the GFW listening to incoming IP packets on the network, analyzing the TCP protocol within them, and ultimately reconstructing a complete byte stream. Analysis is performed on this reconstructed byte stream to examine specific application protocols, such as HTTP. Then, it searches for any inappropriate content within the application protocol and decides on the appropriate response.
Thus, the first step of machine detection by the GFW is to reconstruct a byte stream. So how does the GFW obtain the original IP packets? The actual deployment method of the GFW is unknown to outsiders. It is speculated that the GFW is deployed on the bypass of the country's exit routers, using a "splitting" method to copy IP packets to another fiber optic line, thereby obtaining all IP packets entering and leaving the country. The following image is referenced from gfwrev.blogspot.com:
However, Google has its own data center in Beijing. Thus, savvy internet users utilize the GAE service provided by Google's Beijing data center, using Goagent software to achieve high-speed circumvention. However, some users have confirmed https://twitter.com/chengr28/status/260970749190365184 that even the Beijing data center can experience packet loss due to the backbone network. In fact, Google's data center in Beijing has an independent AS (BGP concept). This AS has a direct IPV6 connection to Google's headquarters, allowing access to the outside world without restrictions through IPV6. However, this AS must pass through the GFW when connecting domestically or internationally. Therefore, even a data center in Beijing cannot guarantee that domestic access will not be blocked. The GFW can configure BGP routing rules for the backbone network, allowing domestic data centers to also pass through it. Another example is when we access a blocked website and trigger a connection reset; we often receive two RST packets, but with different TTLs. Another example is that for blocked IPs, the IP packets are discarded before reaching the international exit. Therefore, the GFW is likely to have deployed equipment elsewhere, speculated to be at the provincial backbone router level.
Regarding the topic of where the GFW is located, recently, foreign friends have expressed interest https://github.com/mothran/mongol. The author has built a more comprehensive detection tool based on previous work https://github.com/fqrouter/qiang. Its principle is based on a characteristic of the IP protocol called TTL. TTL stands for Time to Live. Each time an IP packet passes through a router, the router decrements the TTL by 1. If the TTL reaches zero, the router will not forward the IP packet to the next router. We know that the GFW sends back RST packets to reset TCP connections upon detecting inappropriate IP packets. By setting different TTL values, one can determine how many routers the packet has passed through from your computer to the GFW. For example, if the TTL is set to 9 and does not trigger an RST, but 10 does trigger an RST, then it has passed through 10 routers to reach the GFW. Another characteristic of the IP protocol is that when the TTL expires, the router should send back a TTL EXCEEDED ICMP packet, setting its own IP address as the SRC (source). Combining these two points allows one to detect which router the IP packet reached before being detected by the GFW. With the IP address, one can then use a geographic database to determine its location. It is said that the resulting location is approximately as follows:
However, is the detected IP actually that of the GFW or the backbone router? It is more likely to be the IP of the backbone router. The GFW operates as an intrusion detection device using a "splitting" method adjacent to the main backbone router. Regardless, the GFW can obtain all IP packets exchanged between you and foreign servers through some mysterious means. More rigorous theoretical research can be found in: Internet Censorship in China: Where Does the Filtering Occur?
Once the GFW has these IP packets, it faces a difficult decision: whether to allow communication between you and the server to continue. The GFW cannot be overly aggressive, as a nationwide inability to access foreign websites would contradict its own existence. The GFW needs to understand the meaning behind the IP packets before deciding whether it is safe to block the connection between you and foreign servers. This understanding is based on the previously mentioned "reconstruction" step. To illustrate what reconstruction entails:
Reconstruction involves combining the GET /index from packet 1, the x.html H from packet 2, and the TTP/1.1 from packet 3 into GET /index.html HTTP/1.1. The resulting data may be plain text or binary encrypted protocol content. What exactly it is depends on the agreement between you and the server. As an eavesdropper, the GFW needs to guess the content of your conversation. For the HTTP protocol, this is relatively easy to guess, as the HTTP protocol is standardized and unencrypted. Therefore, after reconstruction, the GFW can easily determine that you are using the HTTP protocol and which website you are accessing.
One challenge of reconstructing such byte streams is how to handle the massive traffic. This issue has been clearly explained in this blog http://gfwrev.blogspot.tw/2010/02/gfw.html. Its principle is similar to that of a website load balancer. For a given source and destination, a HASH algorithm is used to obtain a node value, and then all traffic matching this source and destination is directed to that node. Thus, a unidirectional byte stream of a TCP session can be reconstructed at one node.
Finally, to complete the discussion, two more points should be mentioned. Although the GFW's reconstruction occurs on the bypass using splitting, this does not mean that all GFW devices are on the bypass. It will be mentioned later that some GFW countermeasures must involve deploying certain GFW devices on the backbone router, such as the intermittent packet loss experienced with Google's HTTPS, indicating that the GFW is involved in part of the IP routing work. Another point is that reconstruction is a unidirectional TCP flow, meaning the GFW does not care about the content of the bidirectional conversation; it only makes judgments based on the content observed in one direction. However, the monitoring itself is bidirectional, meaning that whether data is sent from domestic to foreign or from foreign to domestic, it will be reconstructed and analyzed. Therefore, a TCP connection will be reconstructed into two byte streams for the GFW. Specific evidence will be discussed later regarding how to penetrate the GFW in detail.
Analysis#
Analysis is the second step the GFW takes after reconstructing the byte stream. For reconstruction, the GFW primarily deals with the IP protocol, as well as the upper layers of TCP and UDP protocols. However, for analysis, the GFW needs to understand various peculiar application layer protocols. In fact, we can even invent new protocols ourselves.
In general, the GFW has two similar but distinct purposes for protocol analysis. The first purpose is to prevent the dissemination of inappropriate content, such as searching for "forbidden" keywords on Google. The second purpose is to prevent the use of circumvention tools to bypass GFW's censorship. Below are some known protocols that the GFW can handle.
The specific methods the GFW uses to achieve its first purpose, which is to prevent the dissemination of inappropriate content, involve plaintext inspection of several protocols, including HTTP and DNS. The general approach is as follows:
Protocols like HTTP have very obvious characteristics for detection, so there is not much to say about the first step. When the GFW detects that a packet is an HTTP packet, it will unpack it according to HTTP protocol rules. This unpacking process is done by the GFW based on its understanding of the protocol. For example, it extracts the requested URL from the HTTP GET request. The GFW then takes this requested URL and matches it against keywords, such as checking if Twitter is in the requested URL. Why is there an unpacking process? First, unpacking allows for more precise targeting and prevents false positives. Additionally, unpacking in advance may be more resource-efficient than full-text matching. Secondly, the core of xiaoxia and liruqi's jjproxy is based on a vulnerability in GFW's HTTP unpacking, which has since been patched. The principle is that the GFW did not handle the situation where there were extra \r\n characters when unpacking HTTP packets, but your access to google.com could correctly handle the additional \r\n. This example demonstrates that the GFW first seeks to understand the protocol before performing keyword matching. The keyword matching likely employs some efficient regular expression algorithms, which require no further discussion.
Both HTTP proxies and SOCKS proxies can be recognized by the GFW. Previously, the author believed that the GFW could unpack the internal HTTP protocol body after detecting HTTP and SOCKS proxies, essentially performing two unpacking processes. However, analysis has shown that the keyword lists for HTTP proxies and HTTP are different, so the author now believes that HTTP proxy protocols and SOCKS proxy protocols are treated as separate protocols, rather than unpacking the HTTP request payload for further analysis.
The known protocol analyses that the GFW performs are as follows:
DNS Queries#
The GFW can analyze DNS queries over UDP on port 53. If the queried domain name matches a keyword, it will be DNS hijacked. It is certain that this matching process uses a regex-like mechanism, rather than just a blacklist, because there are simply too many subdomains. Evidence of this is that on November 9, 2012, at 3:30 PM, the Great Firewall conducted widespread pollution of Google's wildcard domain .google.com, causing all domains ending in .google.com to be polluted and resolve incorrectly, including even non-existent domains (source http://zh.wikipedia.org/wiki/%E5%9F%9F%E5%90%8D%E5%8A%AB%E6%8C%81）
So far, queries outside of port 53 have not been hijacked. However, TCP DNS queries can already be cut off by TCP RST, indicating that the GFW has this capability, but does not bother with large-scale deployment. Moreover, the keywords for TCP queries are much fewer than those for UDP hijacked domains. Currently, only dl.dropbox.com triggers TCP RST. Related research papers include:
Hold-On: Protecting Against On-Path DNS Poisoning
The Great DNS Wall of China
HTTP Requests#
The GFW can recognize the HTTP protocol and check the GET URL and HOST. If it matches a keyword, it will trigger a TCP RST block. As mentioned earlier, the method used by jjproxy to construct special HTTP GET requests to deceive the GFW has already failed; now the GFW simply triggers a TCP RST block upon seeing \r\n (source https://plus.google.com/u/0/108661470402896863593/posts/6U6Q492M3yY). Related research papers include:
The Great Firewall Revealed
Ignoring the Great Firewall of China
ConceptDoppler: A Weather Tracker for Internet Censorship
Analysis and Identification of Circumvention Traffic#
The second purpose of the GFW is to block circumvention software. To achieve this goal, the GFW employs more aggressive measures. The reason is simple: if the GFW does not handle HTTP protocol blocking well, it could affect the normal operation of the internet. The GFW and the internet have a symbiotic relationship; it will not do things that threaten its own existence. However, for protocols like TOR, which exist almost purely for circumvention, once detected, they are ruthlessly blocked. How the GFW specifically blocks various circumvention protocols is not entirely clear, and the situation is still evolving. However, here are two examples that demonstrate the GFW's advanced technology.
The first example is the GFW's automatic blocking of TOR, which reflects the GFW's utmost effort to understand the protocol itself. According to this blog https://blog.torproject.org/blog/knock-knock-knockin-bridges-doors, using a Chinese IP to connect to an American TOR bridge will be detected by the GFW. Then, the GFW will pretend to be a client and connect to that bridge using the TOR protocol after 15 minutes. If it confirms that it is a TOR bridge, it will block that port. After changing the port, it can be used for a while before being blocked again. This demonstrates the GFW's advanced detection capabilities, as it can keenly identify your connection to the TOR bridge from international exit traffic. According to TOR colleagues, this is because the handshake process in the TOR protocol has very obvious characteristics. Another point reflects the GFW's diligence, as it even pretends to be a client to connect and check.
The second example shows that the GFW does not care whether the specific content of encrypted traffic contains sensitive words. As long as it is suspected of circumvention, especially if it provides commercial services to multiple circumvention users, it will be blocked. According to this post http://www.v2ex.com/t/55531, the ShadowSocks protocol used was pre-deployed with keys and had no obvious handshake process, yet it was still blocked. It is said that the GFW has upgraded to be able to machine-identify which encrypted traffic is suspected of being circumvention services.
Regarding how the GFW identifies and blocks circumvention servers, I recently wrote an article proposing my hypothesis; everyone can take a look: http://fqrouter.tumblr.com/post/45969604783/gfw.
Recently, it has been discovered that the GFW can achieve near real-time blocking of IPs (ports) for OpenVPN and SSL certificates. The principle should involve offline deep packet analysis to extract suspicious IP lists, which are then confirmed manually before being blocked. Because OpenVPN has significant protocol characteristics and is not commonly used in commercial scenarios, it is easy to confirm as a circumvention service. However, the ability to filter based on "certificates" for SSL, which is the encryption protocol used for HTTPS, is quite impressive. The author of Shadowsocks, Clowwindy, specifically wrote an article titled "Why SSL Should Not Be Used for Circumvention": https://gist.github.com/clowwindy/5947691.
In summary, the GFW has essentially completed all the work related to its first purpose. Plaintext protocols from HTTP to SMTP can be analyzed and subjected to keyword detection, even protocols like eMule, which are not as mainstream, have been targeted by the GFW. From a theoretical standpoint, there is not much to study; it is simply plaintext, unpacking, and keyword matching. The GFW's recent focus appears to be on analyzing network traffic to identify which traffic is circumvention-related. Research in this area is still relatively scarce, and a notable characteristic is that using it personally is fine, but large-scale deployment can easily lead to issues. I currently do not have much research on how the GFW blocks circumvention tools; I can only rely on hearsay.
Measures#
IP Blocking#
This is generally common as a response after manual detection. I have not heard of any method that allows the GFW's machine detection to directly block IPs. The common phenomenon is that the GFW performs machine detection and then responds with TCP RST resets. After a period, the IP may be blocked, but there is no obvious time pattern. Therefore, my speculation is that global IP blocking likely requires human intervention. Note that I emphasize global IP blocking, as opposed to partial IP blocking, such as blocking access to a specific IP for 3 minutes while others can still access it. This is a completely different blocking method, although the phenomenon is similar, as both cannot be pinged. To observe this, you can ping twitter.com, which has been blocked for a long time.
The implementation method is to add invalid routing black holes to the routing table of the backbone router, allowing these routers on the backbone network to help the GFW drop packets destined for the specified IP. The routing table of routers is dynamically updated, using the BGP protocol. The GFW only needs to maintain a list of blocked IPs and broadcast it using the BGP protocol. Then, the routers on the domestic backbone network seem to become part of the GFW, acting as accomplices.
If we use traceroute to check such globally blocked IPs, we can find that the IP packets are discarded by the routers of China Telecom or China Unicom before reaching the international exit where the GFW is located. This is the effect of BGP broadcasting.
DNS Hijacking#
This is also a common response after manual detection. When a manual detection identifies an inappropriate website, its domain name is added to the hijacking list. The principle is based on the weaknesses of DNS and IP protocols; neither DNS nor IP verifies the authority of the server, and DNS clients blindly trust the first answer received. Therefore, if you query facebook.com, the GFW can respond before the correct answer is returned, pretending to be the DNS server you queried and sending you an incorrect answer.
TCP RST Blocking#
The TCP protocol specifies that upon seeing an RST packet, the connection is immediately interrupted. From the browser's perspective, this means the connection has been reset. I believe most people are familiar with this error. From my personal observation, this blocking method is currently the GFW's primary response. Most RSTs are conditionally triggered, such as when the URL contains certain keywords. Many websites currently experience this treatment, with Facebook being a notable example. Some websites are subject to unconditional RSTs, meaning that for specific IPs and ports, regardless of the packet's content, an RST will be triggered. A well-known example is the HTTPS version of Wikipedia. The GFW's response at the TCP layer exploits the weaknesses of the IPv4 protocol, allowing it to pretend to be anyone sending packets on the network. Thus, the GFW can easily make you believe that the RST is genuinely from Google while making Google believe that the RST is from you.
Port Blocking#
In addition to being an intrusion detection device mounted on the bypass of backbone routers, the GFW also uses splitting technology to capture packets from these backbone routers for intrusion detection (known as IDS). Furthermore, this router can also be used to block ports (known as IPS). When the GFW detects an intrusion, it can not only use TCP RST to block the current connection but also utilize the backbone router to implement various blocking measures, from blocking ports to blocking IPs, for specified IPs or ports. It can be understood that the backbone router has capabilities similar to "iptables" (real-time unpacking at the network and transport layers, matching rules). This iptables capability is referred to as ACL Based Forwarding (ABF) on Cisco routers. Moreover, the rules are deployed nationwide in sync; if one router blocks your port, all backbone routers with the GFW will block it. Generally, this type of port blocking targets circumvention servers. If a server is detected providing circumvention services via SSH or VPN, the GFW will deploy an ACL rule on the national exit backbone routers to block the downstream data packets for that server and port. This means that if a packet is sent from abroad to China, and the src (source IP) is the blocked server IP, and sport (source port) is the blocked port, then this packet will be filtered out. The characteristic of such deployed rules is that upstream packets can be received by the server, while downstream packets will be filtered out.
If a server takes countermeasures by changing ports after being blocked, it will soon be blocked again. After multiple attempts, the IP may be blocked. It is initially inferred that port blocking is not an automatic response of the GFW but is implemented through a blacklist and manual filtering. One reason for this inference is that users have reported that port blocking occurs during daytime working hours.
Reverse Firewall#
Most domestic transit servers used by airports will trigger the GFW if it detects unusually high outbound traffic during special periods, such as the Two Sessions and National Day, causing the server to be reverse firewalled. This is specifically manifested as the foreign server being unable to access the IP that has been reverse firewalled. Testing the domestic server's ping shows a red signal from abroad and a green signal domestically. There are not many solutions: either change the IP or wait for the sensitive period to pass for automatic recovery.
Circumvention Principles#
The principles of circumvention correspond to the operational principles of the GFW, divided into two main categories. The first category is the commonly used detour method. IP packets are encrypted and routed through a third party to pass the GFW's inspection. This approach resembles "翻" (flipping) the wall, as it circumvents it from outside. The second category involves identifying certain bugs in the GFW's detection process and exploiting these bugs to prevent the GFW from accurately knowing the session content, thereby allowing passage.
Circumvention methods based on detours, whether VPN or SOCKS proxies, operate on similar principles. They all assume the existence of a proxy server abroad, with you communicating with the proxy server, which then communicates with the target server.
In addition to basic proxy protocols like HTTP, L2TP, and SOCKS5, the current mainstream protocols for accessing foreign websites include ss, vmess, ssr, vless, trojan, kcp, hysteria, etc.
Protocols (Direct Connection)#
Shadowsocks#
Shadowsocks (ss) is an encrypted transmission protocol based on SOCKS5 proxying. The first version was released on April 20, 2012. Shadowsocks uses a self-designed protocol for encrypted communication. The encryption algorithms include AES, Blowfish, ChaCha20, RC4, etc. It does not require a handshake beyond establishing a TCP connection, forwarding only one connection per request, and does not need to maintain a continuous connection state, making it relatively power-efficient on mobile devices.
Currently, this protocol is detected and can be blocked by the GFW, including but not limited to blocking, port blocking, and IP blocking. Therefore, if it is a direct connection to SS, it is essentially a head-on confrontation.
Due to its low latency, it remains a choice for many mainstream airports. (Airports use transit, not direct SS connections, so blocking does not affect them.)
Supported Software#
The accompanying derivative software, Shadowsocks and ShadowsocksR, has largely been phased out.
Mainstream software such as clash, v2rayn, v2rayng, shadowrocket, and quantumultx are compatible with this protocol.
ShadowsocksR#
ShadowsocksR (ssr / 酸酸乳) can be considered an upgraded version of ss. SSR is a branch of Shadowsocks initiated by a user named breakwa11, which adds some obfuscation methods to fix certain security issues and improve QoS priority. Later contributor Librehat also added some of these features to Shadowsocks, even incorporating a pluggable transport layer function similar to Tor.
Supported Software#
The accompanying derivative software, Shadowsocks and ShadowsocksR, has largely been phased out.
Mainstream software such as clash, v2rayn, v2rayng, shadowrocket, and quantumultx are compatible with this protocol.
VMess#
VMess is a TCP-based encrypted transmission protocol, with all data transmitted using TCP. It consists of inbound and outbound parts, typically serving as a bridge between V2Ray clients and servers. Based on the v2ray core.
VMess relies on system time; please ensure that the system's UTC time error is within 90 seconds when using V2Ray, regardless of the time zone. In Linux systems, the ntp service can be installed to automatically synchronize system time.
Due to its encryption, it is now one of the mainstream encryption protocols. When setting up direct connection nodes, the protocol mainly used is vmess + websocket + tls + nginx disguise, which is theoretically one of the least likely to be blocked.
The main feature of the vmess protocol is its strict encryption, but the accompanying problem is also evident: with more handshake attempts, the latency naturally increases compared to ss/ssr. However, its speed is faster than ss/ssr (as tested, comparing the speeds of ss and vmess+ws on the same server, there are also speed comparison videos for YouTube).
Supported Software#
The accompanying derivative software, v2rayn and v2rayng, remains widely used, and they now default to using xray-core.
Mainstream software such as clash, v2rayn, v2rayng, shadowrocket, and quantumultx are compatible with this protocol.
Vless#
Vless can also be seen as an upgraded version of vmess, based on the xray core. VLESS is a stateless lightweight transmission protocol, divided into inbound and outbound parts, serving as a bridge between V2Ray clients and servers. Unlike VMess, VLESS does not rely on system time, and the authentication method is also UUID, but it does not require alterId.
Compared to vmess, vless has faster protocol speeds, with similar latency.
Supported Software#
Vless requires the use of xray-core to operate.
Mainstream software such as v2rayn, v2rayng, shadowrocket, and quantumultx are compatible with this protocol. Unfortunately, clash does not support it.
Trojan#
In contrast to Shadowsocks, Trojan does not use a custom encryption protocol to hide itself. Instead, it uses the clearly defined TLS protocol (TLS/SSL), making the traffic appear similar to that of normal HTTPS websites. TLS is a mature encryption system, and HTTPS uses TLS to carry HTTP traffic. With a correctly configured encrypted TLS tunnel, the transmission can be guaranteed.
Trojan differs from vmess in that it can be configured to use or not use TLS encryption; however, trojan is forced to use TLS encryption. This means that a domain name is required to set up trojan.
In terms of speed, trojan is comparable to vmess. However, the biggest advantage of trojan is its minimal server-side resource usage, making it very lightweight, even low-spec servers can run it smoothly.
Supported Software#
Mainstream software such as clash, v2rayn, v2rayng, shadowrocket, and quantumultx are compatible with this protocol.
Hysteria#
Hysteria is a feature-rich network tool optimized for harsh network environments (bidirectional acceleration), such as satellite networks, crowded public Wi-Fi, and connecting to foreign servers from China. It is based on a modified version of the QUIC protocol.
Hysteria is an excellent "lightweight" proxy program written in Go, effectively addressing the biggest pain point when setting up a powerful magic server—line instability.
During peak hours, the most challenging aspect is not the setup and maintenance but the delivery quality. When the three major telecom operators experience issues like: unstable connections, inability to connect, or slow speeds, we all feel it. Although it uses UDP, it provides obfuscation, making it temporarily immune to targeted QoS from operators (even without obfuscation, it won't be subject to QoS).
This is a recently popular new protocol. Its main advantage is that even with poor lines, it does not require transit or CF CDN; using hysteria can save the situation. Currently, it appears to be very friendly for non-domestically optimized lines.
Supported Software#
The latest versions of v2rayn and shadowrocket now support hysteria.
Transit#
Having discussed direct connections, let's talk about transit.
Transit is mainly divided into three types: one is direct transit through domestic high-bandwidth servers. The main advantage is that compared to direct connections, it can better adapt to the complex network situation of domestic operators. It is also evident that it is helpless against IPs blocked abroad and fears reverse firewalls. Moreover, a single domestic server cannot handle all foreign servers. Some foreign servers may be friendly with Unicom, but using a Telecom server to connect may lead to poor performance.
The second type is tunnel transit, which is a new method that has emerged in recent years. Tunnel transit involves one domestic server and one foreign server. Because foreign servers generally have BGP sessions, they can handle complex network situations relatively well. The tunnel's foreign end to your node server typically has a more favorable line. The tunnel's foreign end to the domestic end will also be encrypted, which, although slightly increasing latency, allows ignoring situations where foreign machines are blocked. However, domestic servers also fear reverse firewalls. Using a tunnel, a single tunnel node can generally handle most foreign servers.
The third type is dedicated line transit, which is also the most expensive. A Gbps dedicated line costs about 25,000+ RMB per month, which is not affordable for airports without significant funds. In fact, dedicated lines are similar to tunnels, also divided into domestic and foreign ends. Dedicated lines are classified as IEPL and IPLC; for definitions, you can refer to https://www.cheshirex.com/2005.html. The biggest advantage of dedicated lines is low latency and stability, so there is no need to worry about node servers being blocked or domestic reverse firewalls. It can be said that dedicated lines are basically never offline, except for routine maintenance or special circumstances. This is why they are highly favored.
Self-Built#
Many novices want to set up their own nodes but find that after setting up, they either experience disconnections or are blocked again. Here, I recommend that using vmess+ws+tls+nginx disguise or vless+ws+tls+nginx disguise is a reasonable setup method (in the case of direct connections without transit). For servers with dynamic IPs, using vmess+ws is sufficient to ensure speed without being blocked. For low-quality lines, using hysteria is advisable.
Summary#
The battle of wits with the GFW continues~ ~
Reprinted and edited from http://www.oneyearago.me
https://cloud.tencent.com/developer/article/1740977