The original text is from the left and right bosses, 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 the use of Cloudflare's CDN, overall the effect is still good. But recently, it has become more and more troublesome. The running Cloudflared container is always unable to establish a tunnel with Cloudflare, resulting in the website going offline and inaccessible.
It is the situation below, and the website cannot be accessed at this time.
Troubleshooting#
Checking the CloudFlared container logs#
As the saying goes: when in doubt, use quantum mechanics! You don't say, this sentence is really right!
I logged into the NAS and opened the logs of the Cloudflared container, only to see 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 that the creation of a new quic connection failed, and the quic protocol cannot connect to the edge server. In simple terms, the tunnel cannot be successfully established using the quic protocol!
It's a coincidence that Cloudflare calls the tunnel established by the quic protocol the "post-quantum tunnel". You can say that 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. I'll directly quote the original words from a certain encyclopedia:
QUIC stands 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 enlightening?
CloudFlare's official explanation#
The reasons and the underlying reasons are clear, but there is still a question in my mind that I can't let go of. 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, I 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
quicprotocol 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 is only available for the QUIC protocol. Therefore, it is frustrating for users to start a tunnel with the default protocol as http2 (which does not support UDP proxy) 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 downgrade/switch 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 many users!
Solution#
After unraveling the problem and finding the solution, the rest is simple. Just make a small change in the startup parameters of the Cloudflared container, changing 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 has been 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 I will try my best 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.