Использую туннели cloudflared для доступа к свой сети/приложениям, около недели как пропала возможность нормально к ним соединяться. Я понимаю, что начали блочить QUIC, но может есть какой способ заставить их работать? Пробовал в настройках изменить квик на http2 (поддерживаются только эти два варианта) коннект вроде как есть, но туннель все равно не работает. Самое забавное, что это не про обход блокировок 
, а реально рабочая штука..поломали все, до чего дотянулись
да, поломалось все самым непонятным образом. В сети одного и того же провайдера два туннеля на разных компьютерах (две локальные подсети), один Down, другой Healthy. Все параметры запуска туннеля одинаковые (то есть --protocol http2 поскольку quic вырублен). Тестовые соединения, рекомендованные в документации CF:
tnc region1.v2.argotunnel.com -port 443
tnc region1.v2.argotunnel.com -port 7844
проходят и там, и там, но один туннель работает, а другой нет.
Обезьяны с тумблерами?
а оно точно на один endpoint коннектится ?
ну и конфиги может попробовать копировать “целиком”
как я понимаю на моменте регистрации создаются уникальные ID которые могут по разному “выдавать внутренние CF IP”
warp gool IPv4, warp IPv6, usque (не обязятельно в том же порядке.)
ip=2a09:bac5:5151:
ip=104.28.230.z
ip=2a09:bac1:61e0:
ip=104.28.198.y
ip=2a09:bac5:51ad:
ip=104.28.198.x
нет, конечно, в журналах cloudflared легко видеть, как клиент долбится по разным ip (в документации четко сказано, сколько разных ip должно быть открыто для доступа).
Записи в журнале такие:
{"level":"error","event":0,"ip":"198.41.200.33","connIndex":0,"error":"TLS handshake with edge error: read tcp 172.2x.x.x:52377->198.41.
200.33:7844: i/o timeout","time":"2025-06-14T18:36:56Z","message":"Unable to establish connection with Cloudflare edge"}
{"level":"error","event":0,"ip":"198.41.200.33","connIndex":0,"error":"TLS handshake with edge error: read tcp 172.2x.x.x:52377->198.41.
200.33:7844: i/o timeout","time":"2025-06-14T18:36:56Z","message":"Serve tunnel error"}
...
{"level":"error","event":0,"ip":"198.41.192.107","connIndex":0,"error":"TLS handshake with edge error: read tcp 172.2x.x.x:52406->198.41
.192.107:7844: i/o timeout","time":"2025-06-14T18:37:36Z","message":"Unable to establish connection with Cloudflare edge"}
{"level":"error","event":0,"ip":"198.41.192.107","connIndex":0,"error":"TLS handshake with edge error: read tcp 172.2x.x.x:52406->198.41
.192.107:7844: i/o timeout","time":"2025-06-14T18:37:36Z","message":"Serve tunnel error"}
то есть схема подключения не такая, как у CF Warp, и никакие фейки zapret применить не удается.
да уже тыщи их
cloudflare / cloudfire / amazon
принцип ИМХО один и тот же. есть то что работает. а есть …
Просто для замены я даже не вижу альтернативы..
Ну хожу теперь напрямую через nginx к своим приложениям, но 2х факторку гуугла уже так легко не прикрутить..мб есть альтернативы? т.к ждать когда “вдруг” решат откатить все в зад - можно вечность
пользуюсь этим, можно прикрутить oauth
какой нибудь igdrassil p2p (или вообще TOR)
Только ygg надо делать приватную личную сеть с ключами или файервол грамотно настраивать, а то будут лазить все кому не лень.
Есть ли гайды по настройке? Нужно же что-то придумать на чёрный день.
На сколько я понял, он через WireGuard, а он у нас вроде тоже на ладон дышит)
Все мои туннели cloudflared с воскресенья вернулись в статус Healthy. Разные провайдеры, Москва
Интересно, Ростелеком (мск) - продолжает сыпаться хэндшейк еррор
У меня один из туннелей, домашний, как раз на Ростелекоме Москва. Пару дней назад перешел в состояние Healthy (протокол http2). Сейчас попробовал его перевести на quic - не перешел и перестал работать как раньше: ошибки handshake, Down.
Вывод - если пробился туннель, будет работать, отключишь - заново не поднимется.
И то может порваться через сутки, если на тспу что-то мутят.
Мой вариант решения №1. завернул трафик cloudflared (всего две /24 подсети) агента в Amneziawg туннель, который выходит в другой стране.
Минусы: нагрузка на VPS и удлинение пути
Плюсы: делается довольно просто (если можете развернуть AWG)
Решение №2 (предпочтительное):
zapret и стратегия для него. (запрет на роутере для youtube и так стоит)
--new \
--filter-udp=7844 \
--dpi-desync=fake \
--dpi-desync-repeats=11 \
--dpi-desync-fake-quic=/usr/home/fake/quic_initial_www_google_com.bin \
и мои туннели снова на DME-шных серверах в статусе healthy
Интересно, как пример, у меня есть сервер X-Ray, возможно ли в контейнер к cloudflared добавить клиента, который подключался бы к X-Ray? Это что-то типа Вашего первого варианта, только я могу разворачивать туннель только из контейнера. А то я уже собирался полностью отказываться от cloudflare
Если всё-таки выбирать первый сценарий, то Я бы все же рекомендовал настроить ВПН-клиент на хосте, где крутится контейнер с CFd и прописать в нем маршрутизацию для двух подсетей 24, в которые CFd ломится.
Возможно, потом вы в этот же туннель захотите ещё что-то завернуть.
Идея с туннелем через AWG ломает изначально настроенные маршруты до внутренней сети. Если у меня, предположим, есть внутренняя сеть 192.168.0.0/24, и я хочу иметь доступ не к одному компьютеру и сервисам на нем, а к многим. Чтобы разрешались адреса на внутреннем DNS-сервере и т.д. Я все это настраиваю, специально прописываю, через какие адреса CF должна маршрутизировать трафик внутрь и т.д.
Ясно, что если я подключусь через AWG, то внутренняя сеть будет уже с теми адресами, которые клиент получит от той же Cloudflare (если AWG к Warp подключается). То есть какое-то масло масляное.
Я не смог пробить zapret’ом блокировку туннеля, используя примерно такие же параметры, что у Вас. Кажется, fake-пакет использовал по умолчанию. Попробую еще.
Повторюсь, данный вариант реализации считаю неоптимальным, но он работает.
у меня CFd используется только для проброса mydomain.com в мою домашнюю сеть на мой NAS, где в DOCKER стоит много разных контейнеров, один из которых в docker_network с приватным адресом. в эту же докер-подсеть смотрит одной ногой мой traefik, который другими ногами смотрит в другие докер-подсети для доступа к разным web-сервисам. А в интернет на адрес region1.v2.argotunnel.com этот самый контейнер cloudflared стучится как раз поверх того туннеля AWG, в который я завернул маршрутизацию 198.41.192.0/24 и 198.41.200.0/24, так что внутри L3 туннеля между моим NAS и Европейским VPS этот трафик прекрасно пролетает и устанавливает TCP/UDP (http2 /quic ) сессию с серверами Cloudflare.
В любом случае сделать это c помощью zapret оказалось намного логичнее и эффективнее.