cloudflare
🐛 Cloudflare tunnels inoperative in Russia
This issue is critical and impacts an entire product across an entire region.
Recently Tunnels became entirely inoprtative in Russia. I have a server there that I use Tunnels to access. I found a very small group of other people with the same issue on Russian censorship circumvention forums; presumably Tunnels are not that popular. This started happening at the beginning of the month, and slowly got worse and worse until it could simply not connect anymore.
To reproduce
- Be in Russia
- Attempt to use Cloudflare Tunnels normally (following the start tutorial will be enough) Verified on Windows and Ubuntu 22.04 LTS This happens on any config, with any tunnel, on any system, to any person.
Environment and versions
- OS: Windows, Linux
- Architecture: AMD64
- Version: 2025.4.0
- Country/ISP region: Russia
Logs and errors
Click here to expand logs
HTTP/2 Logs, Tunnel errors (1033), no further messages:
апр 25 10:42:11 server cloudflared[792469]: 2025-04-25T05:42:11Z INF GOOS: linux, GOVersion: go1.22.10, GoArch: amd64
апр 25 10:42:11 server cloudflared[792469]: 2025-04-25T05:42:11Z INF Settings: map[no-autoupdate:true p:http2 protocol:http2 token:*****]
апр 25 10:42:11 server cloudflared[792469]: 2025-04-25T05:42:11Z INF Generated Connector ID: [snip]
апр 25 10:42:11 server cloudflared[792469]: 2025-04-25T05:42:11Z INF Initial protocol http2
апр 25 10:42:11 server cloudflared[792469]: 2025-04-25T05:42:11Z INF ICMP proxy will use 192.168.1.5 as source for IPv4
апр 25 10:42:11 server cloudflared[792469]: 2025-04-25T05:42:11Z INF ICMP proxy will use [snip] in zone enp4s0 as source for IPv6
апр 25 10:42:11 server cloudflared[792469]: 2025-04-25T05:42:11Z INF ICMP proxy will use 192.168.1.5 as source for IPv4
апр 25 10:42:11 server cloudflared[792469]: 2025-04-25T05:42:11Z INF ICMP proxy will use [snip] in zone enp4s0 as source for IPv6
апр 25 10:42:11 server cloudflared[792469]: 2025-04-25T05:42:11Z INF Starting metrics server on 127.0.0.1:20241/metrics
~
QUIC Logs, 502s with the Cloudflare plug (although I also experienced timeouts and 1033s, it is inconsistent, presumably due to it restarting infinitely). Logs repeating cyclically:
апр 25 10:58:31 server cloudflared[798455]: 2025-04-25T05:58:31Z INF Registered tunnel connection connIndex=1 connection=[snip] event=0 ip=198.41.192.37 location=led01 protocol=quic
апр 25 10:58:32 server cloudflared[798455]: 2025-04-25T05:58:32Z INF Using [CurveID(4588) CurveID(25497) CurveP256] as curve preferences connIndex=2 event=0 ip=198.41.192.77
апр 25 10:58:33 server cloudflared[798455]: 2025-04-25T05:58:33Z INF Using [CurveID(4588) CurveID(25497) CurveP256] as curve preferences connIndex=3 event=0 ip=198.41.200.63
апр 25 10:58:36 server cloudflared[798455]: 2025-04-25T05:58:36Z WRN Failed to serve tunnel connection error="timeout: no recent network activity" connIndex=0 event=0 ip=198.41.200.73
апр 25 10:58:36 server cloudflared[798455]: 2025-04-25T05:58:36Z WRN Serve tunnel error error="timeout: no recent network activity" connIndex=0 event=0 ip=198.41.200.73
апр 25 10:58:37 server cloudflared[798455]: 2025-04-25T05:58:37Z ERR Failed to serve tunnel connection error="context canceled" connIndex=2 event=0 ip=198.41.192.77
Additional context
Russian ISPs interfere or block with Cloudflare IPs. According to one user, routing 198.41.128.0/17 through a VPN fixes the issue. I haven't tried since I can't configure my hosts like that. Potentially, the Russian government messes with everything on here
Despite all of this, I am able to access the IP (even the exact one that fails in cloudflared) and receive a valid, expected error from Cloudflare, so there seems to be something fishy going on here.
igmn@server:~$ curl -v 198.41.192.37
* Trying 198.41.192.37:80...
* Connected to 198.41.192.37 (198.41.192.37) port 80 (#0)
> GET / HTTP/1.1
> Host: 198.41.192.37
> User-Agent: curl/7.81.0
> Accept: */*
>
* Mark bundle as not supporting multiuse
< HTTP/1.1 403 Forbidden
< Date: Fri, 25 Apr 2025 23:02:32 GMT
< Content-Type: text/plain; charset=UTF-8
< Content-Length: 16
< Connection: close
< X-Frame-Options: SAMEORIGIN
< Referrer-Policy: same-origin
< Cache-Control: private, max-age=0, no-store, no-cache, must-revalidate, post-check=0, pre-check=0
< Expires: Thu, 01 Jan 1970 00:00:01 GMT
< Server: cloudflare
< CF-RAY: [SNIP]-LED
<
* Closing connection 0
error code: 1003
igmn@server:~$
Proposed solutions Switch IP ranges, some kind of proxying, some kind of censorship bypass tech. Potentially, use port 80 since that doesn't seem to be blocked?
Related topic https://community.cloudflare.com/t/cloudflare-tunnels-inoperative-in-russia/792558/4
On Monday, the same problem appeared, and on Tuesday it disappeared by itself. The next day again. Is it possible to somehow solve it? VPN does not help
This is not something cloudflare will be able to fix. We've seen this before.
As a short-term solution you might have some success with Nebula (https://github.com/slackhq/nebula), where server IP is under your control, and P2P connection can be direct if direct path is not blacklisted. Otherwise, traffic will go through your server which will be substantially worse than cloudflare.
Also, "thoroughness" of blocking depends on ISP. Having 2 different connections will help.
I fail to see how Nebula is relevant given that Cloudflare Tunnels operate on the public internet as opposed to a peer-to-peer overlay network. In my limited experience, most people use them to expose local services on a public endpoint, e.g. for selfhosting. With Nebula - want to share a Nextcloud link to a friend? Too bad, you can’t without setting up an entire overlay client on their device. Nebula is more similar to Tailscale or Wireguard (both of which are much easier to set up). Unless I’m under the wrong impression about Nebula.
There is nothing quite like Cloudflare Tunnels available anywhere, except maybe Tailscale Funnels which lack support for custom domains and subdomains, or ngrok which is just bad.
I fail to see how Nebula is relevant given that Cloudflare Tunnels operate on the public internet as opposed to a peer-to-peer overlay network. In my limited experience, most people use them to expose local services on a public endpoint, e.g. for selfhosting.
This is correct, but centralized nature of Cloudflare tunnels (and Tailscale) will always make them vulnerable to censorship. Nebula gives a chance to cross the wall at the cost of loosing anonymity.
Proposed solutions Switch IP ranges, some kind of proxying, some kind of censorship bypass tech. Potentially, use port 80 since that doesn't seem to be blocked?
From first Telegram war we know how this ends. At the moment only tunnel endpoints are partially blocked. If you do port 80 or try to shuffle IP's - you end up with whole IP range associated with Cloudflare blocked, which will affect accessibility of all services, not just tunnels.
The project zapret seems to remedy this. Leads me to the conclusion that this is definitively government interference.
ISPs may be specifically blocking Cloudflare Tunnel (usually port 7844) even if plain TCP works. The default zapret configuration does not handle this, so some minor extra configuration is needed (this is based on the standard zapret configuration):
-
In
/opt/zapret/configor your config file, change the ports and add 7844 for both protocols:NFQWS_PORTS_TCP=80,443,7844 NFQWS_PORTS_UDP=443,7844 -
Add the same ports in
NFQWS_OPTaccordingly:NFQWS_OPT="\ --filter-tcp=80 --dpi-desync=fake,multisplit --dpi-desync-split-pos=method+2 --dpi-desync-fooling=md5sig <HOSTLIST> --new \ --filter-tcp=443 --dpi-desync=fake,multidisorder --dpi-desync-split-pos=1,midsld --dpi-desync-fooling=badseq,md5sig <HOSTLIST> --new \ --filter-tcp=7844 --dpi-desync=fake,disorder --dpi-desync-fooling=md5sig <HOSTLIST> --new \ --filter-udp=443 --dpi-desync=fake --dpi-desync-repeats=6 <HOSTLIST_NOAUTO> --new \ --filter-udp=7844 --dpi-desync=fake --dpi-desync-repeats=6 <HOSTLIST_NOAUTO>" -
Restart
zapret:sudo systemctl restart zapret
After that, cloudflared tunnel run ... works, more or less. There are some errors, but the main functionality is working and it doesn't drop any connections.
It’s necessary to specify --protocol http2 in the tunnel service args; QUIC doesn’t work here at all.
Neither a proxy nor zapret worked for me. Then I found out pangolin is a great self-hosted alternative that covers everything I used Cloudflare Tunnels for. At least it works until Roskomnadzor blocks Wireguard entirely.
All my Russian Home Assistant instances using CloudFlare tunnels to make them accessible from the Internet all went down too some days ago.. Pity to hear it is a deliberate service blocking. I was thinking CloudFlare was blocked Russian networks, but it looks like it is the other side... Why?
Same issue. Neither Cloudflare Tunnels nor Pangolin is working. Pangolin uses WireGuard, which is also being blocked.
I had same issue since May - default wireguard and tunnels were blocked simultaneously. But tunnel has come online yesterday, wireguard is offline.
RKN turn on and turn of the their rules. Today it started working again. Looks like they are experimenting, not dear to block the complete Cloudflare as it is too distructive.
It’s necessary to specify
--protocol http2in the tunnel service args; QUIC doesn’t work here at all.
For those who don't work with zapret: try QUIC, for me it only works with QUIC, http2 doesn't work.
Got the same problem. zapret didn't fixed for me, but i got slightly different error:
2025-06-29T12:06:10Z ERR Unable to establish connection with Cloudflare edge error="TLS handshake with edge error: read tcp 192.168.31.33:53566->198.41.200.63:7844: i/o timeout" connIndex=0 event=0 ip=198.41.200.63
2025-06-29T12:06:10Z ERR Serve tunnel error error="TLS handshake with edge error: read tcp 192.168.31.33:53566->198.41.200.63:7844: i/o timeout" connIndex=0 event=0 ip=198.41.200.63
2025-06-29T12:06:10Z INF Retrying connection in up to 2s connIndex=0 event=0 ip=198.41.200.63
2025-06-29T12:06:27Z ERR Unable to establish connection with Cloudflare edge error="TLS handshake with edge error: read tcp 192.168.31.33:57848->198.41.200.193:7844: i/o timeout" connIndex=0 event=0 ip=198.41.200.193
2025-06-29T12:06:27Z ERR Serve tunnel error error="TLS handshake with edge error: read tcp 192.168.31.33:57848->198.41.200.193:7844: i/o timeout" connIndex=0 event=0 ip=198.41.200.193
2025-06-29T12:06:27Z INF Retrying connection in up to 4s connIndex=0 event=0 ip=198.41.200.193
2025-06-29T12:06:42Z ERR Unable to establish connection with Cloudflare edge error="TLS handshake with edge error: read tcp 192.168.31.33:40148->198.41.200.53:7844: i/o timeout" connIndex=0 event=0 ip=198.41.200.53
2025-06-29T12:06:42Z ERR Serve tunnel error error="TLS handshake with edge error: read tcp 192.168.31.33:40148->198.41.200.53:7844: i/o timeout" connIndex=0 event=0 ip=198.41.200.53
2025-06-29T12:06:42Z INF Retrying connection in up to 8s connIndex=0 event=0 ip=198.41.200.53
2025-06-29T12:06:58Z ERR Unable to establish connection with Cloudflare edge error="TLS handshake with edge error: read tcp 192.168.31.33:42042->198.41.192.7:7844: i/o timeout" connIndex=0 event=0 ip=198.41.192.7
2025-06-29T12:06:58Z ERR Serve tunnel error error="TLS handshake with edge error: read tcp 192.168.31.33:42042->198.41.192.7:7844: i/o timeout" connIndex=0 event=0 ip=198.41.192.7
2025-06-29T12:06:58Z INF Retrying connection in up to 16s connIndex=0 event=0 ip=198.41.192.7
2025-06-29T12:07:23Z ERR Unable to establish connection with Cloudflare edge error="TLS handshake with edge error: read tcp 192.168.31.33:40254->198.41.192.37:7844: i/o timeout" connIndex=0 event=0 ip=198.41.192.37
2025-06-29T12:07:23Z ERR Serve tunnel error error="TLS handshake with edge error: read tcp 192.168.31.33:40254->198.41.192.37:7844: i/o timeout" connIndex=0 event=0 ip=198.41.192.37
2025-06-29T12:07:23Z INF Retrying connection in up to 32s connIndex=0 event=0 ip=198.41.192.37
2025-06-29T12:07:41Z ERR Unable to establish connection with Cloudflare edge error="TLS handshake with edge error: read tcp 192.168.31.33:59410->198.41.192.77:7844: i/o timeout" connIndex=0 event=0 ip=198.41.192.77
2025-06-29T12:07:41Z ERR Serve tunnel error error="TLS handshake with edge error: read tcp 192.168.31.33:59410->198.41.192.77:7844: i/o timeout" connIndex=0 event=0 ip=198.41.192.77
2025-06-29T12:07:41Z INF Retrying connection in up to 1m4s connIndex=0 event=0 ip=198.41.192.77
2025-06-29T12:08:11Z ERR Unable to establish connection with Cloudflare edge error="TLS handshake with edge error: read tcp 192.168.31.33:52920->198.41.192.27:7844: i/o timeout" connIndex=0 event=0 ip=198.41.192.27
2025-06-29T12:08:11Z ERR Serve tunnel error error="TLS handshake with edge error: read tcp 192.168.31.33:52920->198.41.192.27:7844: i/o timeout" connIndex=0 event=0 ip=198.41.192.27
2025-06-29T12:08:11Z INF Retrying connection in up to 1m4s connIndex=0 event=0 ip=198.41.192.27
2025-06-29T12:08:33Z ERR Unable to establish connection with Cloudflare edge error="TLS handshake with edge error: read tcp 192.168.31.33:50922->198.41.200.113:7844: i/o timeout" connIndex=0 event=0 ip=198.41.200.113
2025-06-29T12:08:33Z ERR Serve tunnel error error="TLS handshake with edge error: read tcp 192.168.31.33:50922->198.41.200.113:7844: i/o timeout" connIndex=0 event=0 ip=198.41.200.113
2025-06-29T12:08:33Z INF Retrying connection in up to 1m4s connIndex=0 event=0 ip=198.41.200.113
Same issue. Zapret doesnt work for me too. Getting TLS handshake error
Jul 30 14:15:52 privatekey-pc cloudflared[41273]: 2025-07-30T07:15:52Z INF Initial protocol http2
Jul 30 14:15:52 privatekey-pc cloudflared[41273]: 2025-07-30T07:15:52Z INF ICMP proxy will use 192.168.1.52 as source for IPv4
Jul 30 14:15:52 privatekey-pc cloudflared[41273]: 2025-07-30T07:15:52Z INF ICMP proxy will use fe80::a907:f502:f3e0:a6c in zone wlan0 as source for IPv6
Jul 30 14:15:52 privatekey-pc cloudflared[41273]: 2025-07-30T07:15:52Z INF ICMP proxy will use 192.168.1.52 as source for IPv4
Jul 30 14:15:52 privatekey-pc cloudflared[41273]: 2025-07-30T07:15:52Z INF ICMP proxy will use fe80::a907:f502:f3e0:a6c in zone wlan0 as source for IPv6
Jul 30 14:15:52 privatekey-pc cloudflared[41273]: 2025-07-30T07:15:52Z INF Starting metrics server on 127.0.0.1:20241/metrics
Jul 30 14:16:08 privatekey-pc cloudflared[41273]: 2025-07-30T07:16:08Z ERR Unable to establish connection with Cloudflare edge error="TLS handshake with edge error: read tcp 192.168.1.52:36868->198.41.200.43:7844: i/o timeout" connIndex=0 event=0 ip=198.41.200.43
Jul 30 14:16:08 privatekey-pc cloudflared[41273]: 2025-07-30T07:16:08Z ERR Serve tunnel error error="TLS handshake with edge error: read tcp 192.168.1.52:36868->198.41.200.43:7844: i/o timeout" connIndex=0 event=0 ip=198.41.200.43
Jul 30 14:16:08 privatekey-pc cloudflared[41273]: 2025-07-30T07:16:08Z INF Retrying connection in up to 2s connIndex=0 event=0 ip=198.41.200.43```
Found fix to this issue with another zapret config. Should work with HTTP2 and QUIC protocols.
NFQWS_PORTS_TCP=80,443,7844
NFQWS_PORTS_UDP=443,50000-50100,7844
NFQWS_TCP_PKT_OUT=9
NFQWS_TCP_PKT_IN=3
NFQWS_UDP_PKT_OUT=9
NFQWS_UDP_PKT_IN=0
NFQWS_PORTS_TCP_KEEPALIVE=
NFQWS_PORTS_UDP_KEEPALIVE=
NFQWS_OPT="
--filter-tcp=80 --dpi-desync=fake,multisplit --dpi-desync-autottl=2 --dpi-desync-fooling=md5sig --dpi-desync-split-pos=method+2 <HOSTLIST> --new
--filter-tcp=443 --dpi-desync=fake --dpi-desync-repeats=6 --dpi-desync-fooling=md5sig --dpi-desync-fake-tls=/opt/zapret/bin/tls_clienthello_www_google_com.bin <HOSTLIST> --new
--filter-tcp=7844 --dpi-desync=fake --dpi-desync-repeats=6 --dpi-desync-fooling=md5sig --dpi-desync-fake-tls=/opt/zapret/bin/tls_clienthello_www_google_com.bin <HOSTLIST> --new
--filter-udp=443 --dpi-desync=fake --dpi-desync-repeats=6 --dpi-desync-fake-quic=/opt/zapret/bin/quic_initial_www_google_com.bin <IPSET> --new
--filter-udp=50000-50100 --dpi-desync=fake --new
--filter-udp=50000-50100 --filter-l7=discord,stun --dpi-desync=fake --new
--filter-tcp=443 --dpi-desync=fake --dpi-desync-repeats=6 --dpi-desync-fooling=md5sig --dpi-desync-fake-tls=/opt/zapret/bin/tls_clienthello_www_google_com.bin <IPSET> --new
--filter-udp=7844 --dpi-desync=fake --dpi-desync-repeats=12 --dpi-desync-any-protocol=1 --dpi-desync-cutoff=n3 --dpi-desync-fake-unknown-udp=/opt/zapret/bin/quic_initial_www_google_com.bin <IPSET> --new"
and you will need quic_initial_www_google_com.bin and tls_clienthello_www_google_com.bin
Create a folder named "bin" and place these files inside it and it should work.
Here is the minimum zapret configuration that only affects cloudflared. With it, cloudflared with QUIC works fine on my ISP.
The IP addresses are taken from here: https://developers.cloudflare.com/cloudflare-one/connections/connect-networks/configure-tunnels/tunnel-with-firewall/#required-for-tunnel-operation.
--filter-udp=7844 \
--ipset-ip=198.41.192.167,198.41.192.67,198.41.192.57,198.41.192.107,198.41.192.27,198.41.192.7,198.41.192.227,198.41.192.47,198.41.192.37,198.41.192.77,198.41.200.13,198.41.200.193,198.41.200.33,198.41.200.233,198.41.200.53,198.41.200.63,198.41.200.113,198.41.200.73,198.41.200.43,198.41.200.23 \
--dpi-desync=fake
My config: /opt/zapret/hostlist.txt
warp.cloudflare.com
engage.cloudflareclient.com
connect.cloudflareclient.com
control.cloudflareclient.com
/opt/zapret/config
NFQWS_PORTS_TCP=7844
NFQWS_PORTS_UDP=7844,443
NFQWS_OPT="\
--filter-tcp=7844 --dpi-desync=fake,disorder --dpi-desync-fooling=md5sig hostlist.txt --new \
--filter-udp=7844 --dpi-desync=fake --dpi-desync-repeats=6 hostlist.txt --new \
--filter-udp=443 --dpi-desync=fake --dpi-desync-repeats=6 hostlist.txt --new"