The original text is from the author Zuo You, link.
Readers who have followed the author should know that the author's website is built on their own NAS and then accessed publicly using Cloudflare Tunnels, combined with Cloudflare's CDN, the overall effect is still good. But recently, it has become more and more troublesome. The running Cloudflared container cannot establish a tunnel with Cloudflare, resulting in the website going offline and inaccessible.
This is the situation below, and the website cannot be accessed at this time.
Troubleshooting#
Check the CloudFlared container logs#
As the saying goes: when in doubt, use quantum mechanics! You don't say, this saying is really right!
The author logged into the NAS and opened the logs of the Cloudflared container, and saw the following error:
2023-10-13T09:52:58Z ERR Failed to create new quic connection error="failed to dial to edge with quic: timeout: no recent network activity" connIndex=1 ip=198.41.192.227
2023-10-13T09:52:58Z INF Retrying connection in up to 2s seconds connIndex=1 ip=198.41.192.227
2023-10-13T09:52:58Z ERR Connection terminated error="failed to dial to edge with quic: timeout: no recent network activity" connIndex=1
Pay attention to the key line:
ERR Failed to create new quic connection error="failed to dial to edge with quic: timeout: no recent network activity"
It means: Failed to create a new quic connection, unable to connect to the edge server using the quic protocol. In simple terms, the tunnel cannot be successfully established using the quic protocol!
It's quite a coincidence that Cloudflare calls the tunnel established by the quic protocol the "post-quantum tunnel". You can say it's "when in doubt, use quantum mechanics"!
Reasons for quic failure#
Back to the point, why can't a tunnel be created using the quic protocol? This has to do with the characteristics of the quic protocol itself. Let me directly quote the words of a certain encyclopedia:
QUIC is an abbreviation for Quick UDP Internet Connections, which is an experimental transport layer network protocol developed by Google in 2013.
In other words, quic is different from the mainstream http protocol. It is built on top of UDP, and because of the well-known national conditions, UDP is not favored by domestic network operators and is discriminated against. The end result is that UDP-based connections will be blocked! Isn't it clear now?
CloudFlare's official response#
The reasons and the underlying reasons are clear, but there is still a question in the author's mind that cannot be resolved. That is, why doesn't Cloudflared switch to the http protocol after multiple failed attempts to create a tunnel using the quic protocol? In the spirit of perseverance, the author actually found the reason. Here is the official response from Cloudflare on Github (translated into Chinese):
Let me reiterate the reason behind this: we are "forcing" the quic protocol because we (Cloudflare) believe it is an important part of the future of the Internet. However, many networks still block UDP. We have to make the administrators behind these networks feel this "pain" in some way so that people realize and start allowing UDP traffic.
For example, our private DNS resolution uses UDP and only works with the QUIC protocol. Therefore, it is frustrating for users to start a tunnel with the default protocol as http2 (which does not support UDP proxies) and private DNS resolution does not work.
Alright, the mystery is solved. Cloudflare intentionally set the quic protocol as the default parameter and does not support automatic fallback/switching to http2. If you want to use http2, you can specify it manually. It's that simple and straightforward, and it has caused a lot of trouble for users!
Solution#
After unraveling the problem and finding the solution, it becomes simple. Just make a small change in the startup parameters of the Cloudflared container, change the protocol to http2:
version: '3.8'
services:
cloudflared:
container_name: cloudflared
restart: unless-stopped
network_mode: bridge
environment:
- TZ=Asia/Shanghai
command: tunnel --no-autoupdate --protocol http2 run --token <youtoken>
image: 'cloudflare/cloudflared:latest'
Adding
--protocol http2in the compose file is enough. This forcibly specifies the protocol ashttp2, which uses TCP and will not be blocked by network operators.
Of course, you can also set it to
--protocol autoto enable automatic switching. The default is stillquic, but it will automatically switch tohttp2after a failure.
Then recreate and start the container. By checking the logs, you can see that the tunnel was successfully created using http2:
2023-10-13T12:01:28Z INF Registered tunnel connection connIndex=1 connection=b497b5fb-3f4e-45dd-85fb-e18c2439b5d3 event=0 ip=198.41.200.73 location=sjc05 protocol=http2
2023-10-13T12:01:28Z INF Registered tunnel connection connIndex=2 connection=3d668d56-73d9-4c2d-bd4b-2b2becbdecbf event=0 ip=198.41.192.47 location=lax01 protocol=http2
2023-10-13T12:01:28Z INF Registered tunnel connection connIndex=0 connection=b7c5ebd7-84f6-4070-b5af-abf653d0d345 event=0 ip=198.41.192.67 location=lax07 protocol=http2
2023-10-13T12:01:29Z INF Registered tunnel connection connIndex=3 connection=b5af99db-761c-462c-b793-32ef19d0258a event=0 ip=198.41.200.63 location=sjc05 protocol=http2
The Tunnels status in the Cloudflare console has also returned to normal!
Now, my website can be accessed normally!
The above is about the reasons and solutions for the failure of Cloudflare Tunnels to establish a tunnel. Of course, due to the different machine environments, network conditions, etc. of each person, unexpected situations may be encountered during the operation. If you can't solve it, you can leave a comment at the end of this article, and the author will try to help everyone. Original content is not easy. If you find this article helpful, please consider liking, bookmarking, and following. Your encouragement is the driving force behind my continuous creation.