UPD. В комментариях меня поправили, вывод про LACNIC неверен: stat.ripe.net в поле block отдаёт родительский диапазон по разметке IANA, а не регистратора конкретной подсети - спасибо @ValdikSS, GeoIP я привлёк зря.
При этом сама суть подтвердилась с другой стороны: @paulroot проверил по реестру российских блоков - 201.0.0.0/16 там отсутствует, диапазон действительно нетипичен для РФ, но механизм не тот, что я описал.
Замеры, дамп и симптомы - как были, неверно объяснение причины. Разбор ниже оставляю как есть, ошибка типовая, и повторить её легко.
Вчера переехал на свой сервер. Сегодня утром обнаружил, что сайт у меня не открывается. Ни из дома, ни с телефона.
Сервер при этом в Москве, у российского хостера. И с ним всё в порядке.
Дальше про то, как я полдня искал причину, какие шесть версий проверил и выбросил, и чем всё кончилось. Если симптомы похожие, в конце готовая методика: что запускать и как читать результат.
Симптомы
Сайт статический, Next.js, отдаётся через nginx. Рядом два Docker‑контейнера: чат‑виджет и API для демок. Сервер 2 CPU, 4 ГБ, Москва.
Что я видел:
через VPN сайт открывался, но через раз;
без VPN не открывался вообще;
с телефона по мобильному тоже нет;
ping до сервера при этом шёл идеально.
Последний пункт и сбивал с толку. Сеть до сервера есть. Пакеты ходят. А сайт не грузится.
Первое, что я сделал не так
Скажу сразу: час я потратил впустую. Гадал вместо того, чтобы мерить.
Первая версия была про VPN. Внешний адрес показывал Франкфурт, трафик до Москвы шёл через Германию, задержка 100 мс. Вроде логично: туннель теряет пакеты, отсюда и «через раз».
$ curl -s https://ipinfo.io/json { "ip": "203.0.113.10", "city": "Frankfurt am Main", "country": "DE", "org": "AS47447 23M GmbH" }
Версия красивая. И неверная. Без VPN сайт не открывался вообще, а этого она не объясняла.
Вывод, до которого я дошёл поздно: если у гипотезы остаётся симптом, который она не объясняет, гипотеза неверна. Не «почти», не «частично». Неверна.
Как надо было: мерить серией
Одиночная проверка бесполезна, когда отказ плавающий. Нужна серия. Вот с чего надо было начинать:
ok=0; fail=0 for i in $(seq 1 25); do c=$(curl -s -o /dev/null -m 10 -w "%{http_code}" https://titov-ai.ru/) [ "$c" = "200" ] && ok=$((ok+1)) || fail=$((fail+1)) done echo "ok=$ok fail=$fail"
Через VPN получилось ok=18 fail=7. Двадцать восемь процентов запросов не проходит.
Дальше нужна контрольная группа. Без неё замер не значит ничего. Проверяем другие хосты через тот же канал:
google.com → 15 из 15 timeweb.com → 12 из 12 (сайт моего же хостера) мой сервер → 18 из 25
Вот теперь есть факт. Канал живой, чужие сайты открываются, включая сайт того самого хостера. Не открывается конкретный адрес.
Странность, которая всё запутала
Разложил проверку по уровням и получил картину, которая противоречит сама себе:
ping (30 пакетов) → 0% потерь чистый TCP-коннект :443 → 20 из 20 чистый TCP-коннект :22 → 20 из 20 SSH-сессия → работает curl HTTPS → 6 провалов из 20 curl HTTP :80 → 5 провалов из 15
TCP устанавливается всегда. SSH работает. А обычный HTTP‑запрос падает в трети случаев.
Отказ выглядел так:
curl: (28) Connection timed out after 10000 milliseconds time_connect = 0.000000
Ноль в time_connect значит, что соединение не установилось вообще. SYN ушёл, ответа нет. Не разрыв на середине передачи. Молчание.
Шесть версий, которые не подтвердились
Все проверил и выбросил. Пишу целиком, потому что отрицательный результат тоже результат.
Авария на ноде хостера. В панели реально висело уведомление об аппаратном сбое. Отпала, когда я зашёл на сервер: load average 0.00, память свободна, nginx с нулём перезапусков, контейнеры Up 10 часов. Сбоило бы железо, страдал бы и SSH. Не страдал.
Nginx или Docker не принимают соединения. Разумно, если бы падал только веб. Но чистый TCP‑коннект на 443 давал 20 из 20. При переполнении accept‑очереди он бы тоже падал.
MTU и фрагментация. Path MTU до сервера оказался 1300 вместо 1500, типичная подпись туннеля. Отпала на контрольном замере: до старого хостинга MTU был точно такой же, и там всё работало.
Сертификат. Отпала сразу. Нулевой time_connect значит, что до TLS дело не доходит, а сертификат читается уже после установки соединения.
Отсутствие AAAA‑записи. У моей машины IPv6 вообще нет, curl -6 не находит адреса. Все замеры шли по IPv4, форсированный curl -4 давал те же потери.
IP в чёрных списках. Шесть DNSBL, включая Spamhaus и SpamCop. Все чистые.
Что дало ответ
Вот это надо было делать первым. Заходим на сервер и снимаем дамп трафика, пока снаружи бьём запросами:
# на сервере systemd-run --unit=cap --collect \ tcpdump -i any -nn -c 3000 -w /tmp/cap.pcap tcp port 443
systemd-run тут не для красоты. SSH‑сессия рвалась каждые пару минут, а так процесс переживает обрыв.
Снаружи запускаю двадцать пять запросов, три падают. Смотрим, что видел сервер в момент падения:
09:01:32.377365 In IP 203.0.113.10 > сервер.443: Flags [S] 09:01:32.377468 Out IP сервер.443 > 203.0.113.10: Flags [S.] 09:01:32.476632 In IP 203.0.113.10 > сервер.443: Flags [.] ack
SYN пришёл. Сервер ответил SYN‑ACK через одну десятитысячную секунды. Рукопожатие завершилось. А curl на моей стороне в этот момент показывал таймаут.
Всего пришло 25 SYN на 25 запросов. Ни один не потерялся по пути туда. Сервер ответил на все. Терялся ответ, обратно.
Развязка
Оставалось проверить очевидное, до чего я дошёл последним: как ведёт себя сервер с реального канала, мимо VPN. В Windows это делается флагом --interface:
# 192.168.1.50 это реальный интерфейс, не туннель curl --interface 192.168.1.50 https://titov-ai.ru/
Результат:
ping до сервера → 6 из 6, 16 мс, 0% потерь TCP на 443 → 0 из 10 TCP на 443 по IP → 0 из 8 google.com → 3 из 3 timeweb.com → 3 из 3
ICMP проходит идеально. TCP на 80 и 443 не проходит ни разу. Другие сайты с того же интерфейса работают.
Это фильтрация. Не потери, не перегрузка. Избирательная блокировка TCP к конкретному адресу при живом ICMP.
Хостер подтвердил, когда я прислал замеры. Их проверка снаружи: порт открывается, nc -zv отвечает succeeded, но соединение рвётся на TLS‑хэндшейке. Curl виснет сразу после Client hello, браузер даёт ERR_CONNECTION_RESET. Изнутри их сети сайт при этом отдаёт HTTP/2 200.
Ответ поддержки: «изменения в настройках фильтрации со стороны магистральных провайдеров, повлиять на это мы не можем».
Почему именно мой адрес
Вот тут самое интересное. Ради этого стоило копать.
Смотрим, кому принадлежит блок:
$ curl -s "https://stat.ripe.net/data/prefix-overview/data.json?resource=201.x.x.x" \ | jq '.data.block.desc, .data.asns' "LACNIC (Status: ALLOCATED)" [{"asn": 9123, "holder": "TimeWeb-AS JSC \"TIMEWEB\""}]
Здесь ошибка, см. UPD в начале. Поле block показывает родительский /8 по IANA, а не регистратора подсети.
Я решил, что LACNIC это регистратор Латинской Америки. Адрес российского хостера, физически стоящий в Москве, формально принадлежит латиноамериканскому диапазону 201.0.0.0/8.
Хостеры выкупают такие блоки легально. Свободных адресов в RIPE давно нет, а IPv4 нужны. Юридически всё чисто: в базе RIPE запись TW-Cloud, страна RU, организация в Петербурге.
Но магистральные провайдеры фильтруют по спискам. И нетипичные для России диапазоны попадают под них целиком. Хватит того, что сосед по подсети когда‑то дал повод.
Попросил у хостера другой адрес. Выдали из семейства 200.x. Проверяю:
$ curl -s https://ipinfo.io/200.x.x.x/json { "city": "Ji Paraná", "region": "Rondônia", "country": "BR" }
Бразилия. Снова LACNIC. Те же грабли.
Чем кончилось
Переехал к другому хостеру. Перед оплатой проверил их диапазоны через 2ip.io/ru/as/: RIPE, зарегистрированы на Россию. Потом проверил доступность их сетей со своего канала. Пять из пяти.
После переезда тот же замер:
до: 0 из 10 задержка 100 мс после: 12 из 12 задержка 25 мс
Перенос занял часа три. Всё было в Docker, так что механика простая: два архива с проектами, .env с ключами, сертификат (он привязан к домену, перевыпускать не надо), статика сайта, DNS.
Методика, если симптомы похожие
По шагам. Первые три занимают пять минут и отсекают половину версий.
Мерьте серией, а не одиночным запросом. Плавающий отказ на одиночной проверке выглядит как случайность.
Берите контрольную группу. Другие хосты через тот же канал. Без этого замер ничего не доказывает.
Разложите по уровням: ICMP, чистый TCP, TLS, HTTP. Место, где ломается, сужает круг втрое. Ping не идёт, значит маршрут или хост лежит. Ping идёт, TCP нет, это фильтрация. TCP идёт, TLS рвётся, это фильтрация по SNI или DPI. Всё идёт, падает только HTTP, вот тогда смотрите свой сервер.
Проверьте обходной путь. Есть VPN, сравните с ним и без него. В Windows реальный интерфейс задаётся через curl --interface, адреса смотреть в ipconfig.
Снимайте tcpdump на сервере. Он отвечает на главный вопрос: доходят ли SYN и отвечает ли сервер. Остальное догадки.
Проверьте, чей диапазон. Одна команда:
curl -s "https://stat.ripe.net/data/prefix-overview/data.json?resource=ВАШ\\_IP" | jq .data.block
Не смотрите на поле block - оно отдаёт родительский /8 по IANA и уводит не туда, я на этом и попался. Проверяйте, есть ли ваш блок в реестре российских диапазонов: если нет, для магистралей вы «иностранный» адрес, чем бы ни была подписана подсеть.
Что вынес
Гипотеза, которая не объясняет все симптомы, неверна. Я трижды строил версию, объясняющую часть картины. Трижды она разваливалась о факт, который я решил считать неважным.
Дамп с сервера стоит часа гаданий. Полдня я перебирал версии снаружи, хотя SSH работал с самого начала. Одна команда tcpdump дала однозначный ответ там, где шесть гипотез дали шесть тупиков.
Хостер видит только свою сеть. Первая линия честно пропинговала сервер изнутри стойки, получила 0,68 мс и написала, что всё работает. Формально они правы. Сдвинулось, только когда я прислал таблицу: столько успешных, столько таймаутов, вот трассировка, вот дамп. С цифрами не поспоришь.
Спрашивайте про диапазон до оплаты. Одна строчка в чат поддержки, «из какого блока выдаётся IPv4», экономит день переезда. Я узнал это на своих ошибках. Вы теперь знаете заранее.
Комментарии (79)
Akuma
15.09.2026 05:20С первых секунд все было понятно, увы :)
И да, бороться бесполезно, на старте проще выбить себе нормальный IP, что вы по сути и сделали.
Vadtop Автор
15.09.2026 05:20Задним числом очевидно, да. Пока ICMP зелёный и SSH работает, первом делом лезешь в nginx и firewall, а не в реестр адресов.
LakeOfTears
15.09.2026 05:20полгода мучений, клиентский портал у крупнейшего провайдера, датацентр в Москве (ip меняли по запросу - не помогло). Нет доступа если интернет от МТС. Пинги, ссш - идеально, хттп - отсутствует. Выкручивались как могли (слава богу, клиентов на МТС не было). Потом само рассосалось.
Vadtop Автор
15.09.2026 05:20Смена ip не помогла, потому что новый скорее всего был из того же блока. Само рассосалось хуже всего, причину не знаете, значит может вернуться.
Extortioner
15.09.2026 05:20ха. у знакомого через кабельный интернет не работает обновление прошивки на телефоне. через мобильный интернет от того же провайдера - все работает. магистрал у них общий и единственный в регионе в лице того же провайдера.
P1ngZer0
15.09.2026 05:20Формулировка "само рассосалось" пугает похлеще любого понятного сбоя, значит причина осталась на месте и однажды ночью радостно выстрелит снова)
mumische
15.09.2026 05:20Тут причина может в любой момент выстрелить куда угодно, заблокировать что угодно, и ничего ей за это не будет.
MountainGoat
15.09.2026 05:20Нет доступа если интернет от МТС.
клиентов на МТС не было
собака-подозревака.jpg
xitriy87
15.09.2026 05:20Попадал на такую фигню с Яндекс Cloud, разворачивал ВМ через terraform, а они недоступны по ssh, долго не мог понять, что за фигня. А потом попробовал с другого провайдера все норм. Причем один день может работать, другой нет. Как же они надоели с этими блокировками(
mSnus
15.09.2026 05:20Да, фильтрация ТСПУ. Из характерных признаков - мобильный трафик проходит, наземный нет.
Говорят, помогает включение HTTP/2 и выключение TLS 1.3.
Vadtop Автор
15.09.2026 05:20Мобильный проверял, с телефона тоже не открывалось, поэтому на ТСПУ не похоже. Плюс дамп показал, что терялся SYN-ACK на обратном пути, до TLS дело не доходило, так что HTTP/2 и TLS 1.3 в моём случае лечили бы симптом.
P1ngZer0
15.09.2026 05:20ТСПУ обычно вмешивается уже на уровне разбора SNI или характерных сигнатур прикладного протокола. Дроп обратного SYN-ACK больше смахивает на тупую блокировку префикса по BGP
outlingo
15.09.2026 05:20Было такое как раз из за ТСПУ и tls 1.3 - если уже установленный коннект попал под блок (по статистическим факторам например), то на протяжении нескольки минут после этого начинает работать блокировка на сетевом уровне. То есть работает - хоп, один коннект завис, и начинаются таймауты. Через 10-15-20 минут блок протухает и все вроде снова работает и бац, та же картина. Сайт был на клауд-ру, tls 1.3, проблему решил даунгрейд до 1.2
Vadtop Автор
15.09.2026 05:20Вот это похоже на мою картину с плавающими таймаутами, у меня до TLS дело не доходило вообще - терялся обратный SYN-ACK, так что даунгрейд бы не спас. Но механизм «коннект попал под блок, дальше несколько минут глухо» объясняет, почему у меня то 18 из 25, то 0 из 10. Спасибо.
mvv-rus
15.09.2026 05:20Да, фильтрация ТСПУ
Наблюдаемое поведение совершеннно не специфично для ТСПУ: так ведёт себя практически любой брандмауэр, если видит трафик, идущий только в одну сторону – не пропускает ошибочный, с его точки зрения, процесс соединения, подозревая спуфинг.
Я с таким намаялся на MS TMG в свое время (когда ещё TMG был актуален), симптомы те же: ping проходит, TCP - нет. Ну, а оборудование от RDP (которое ТСПУ) - это тоже брандмауэр по первичному предназначению ЕМНИП, и ведет себя соответственно.
И подозреваю, магистральные провайдеры тут тоже не совсем в стоороне, просто они нашли себе удобную позицию из “второго конверта” - валить всё на смежников из ГРЧЦ с их ТСПУ. А ведь если вдруг разбираться по-хорошему, то наверняка выяснится, что трафик в одну сторону, на ТСПУ заворачивает их, провадерское, оборудование с помощю policy routing- по префиксам BGP и портам, или ещё как. Но концов тут простому человеку не найти - что эти монополии, что государство - один чёрт, сплошная бюрократическая кафка. Так что выход тут один, который в статье описан - найти способ уклониться, благо это возможно: ни ГРЧЦ, ни магистралы в данном случае не злонамеренны, просто работать нормально не хотят.И да, следует понимать, что всё это - гипотеза: она объясняет наблюдаемые явления, но возмодности ее верифицировать у меня нет.
Говорят, помогает включение HTTP/2 и выключение TLS 1.3
Ну, если говорят… ;-) . А в данном случае у автора тупо режется согласование соединения TCP (SYN - SYN-ACK - ACK), и до всяких там TLS (не говоря уж об HTTP) дело не доходит.
ganzmavag
15.09.2026 05:20Ну, если говорят… ;-) . А в данном случае у автора тупо режется согласование соединения TCP (SYN - SYN-ACK - ACK), и до всяких там TLS (не говоря уж об HTTP) дело не доходит.
Это реально помогает, если это ТСПУ. Там не так работает. Блокируется не сам TLS, блокируется IP из-за того, что ТСПУ уже зафиксировало много запросов с TLS 1.3 по этому IP, посчитало его подозрительным и на какое-то время отправило в блок.
mvv-rus
15.09.2026 05:20блокируется IP из-за того, что ТСПУ уже зафиксировало много запросов
Только вот такой способ блокировки выглядит нелогичичным. Логично блокировать первоначальный пакет, с SYN - если, конечно, брандмауэр (в т.ч. ТСПУ) его видит.
PS И да, “много запросов” тут - к нераскрученному сайту - явно нет.
saege5b
15.09.2026 05:20ТТК-Иваново, СевероЗападный Интеркомтел.
Блокируется рандомно, то там, то тут. Особенно в играх-пострелушках заметно.
Примерно так и выглядело с месяц назад. У меня ТТРС был на бесплатном российском хостинге, там замаялся что блочили произвольно и обильно. Пару рефрешей сделаешь - и часа три можно отдыхать :/
На платном тарифе блоки в среднем минут на 10-15, за час-полтора.
В мобильном белом чебурнете вообще всё пичалька.
mvv-rus
15.09.2026 05:20Уточните: блокируется именно пакет SYN-ACK (обсуждаемый здесь случай) или вообще что-то непонятно что? Если обсуждаемый здесь случай - готов пообсуждать подробнее. Если блокируется что-то, непонятно что - обсуждать не готов, ибо технических деталей нет. Могу только, разве что, выразить сочувствие.
mSnus
15.09.2026 05:20В моём случае это помогло, блокировок больше не случилось
mvv-rus
15.09.2026 05:20А у вас точно был именно аналогичный случай, как и у автора? Или общего между ними - только то, что сначала не работало, а потом заработало? Вопрос тут чисто технический, связан с тем, что в случае автора ТСПУ (или какой-то другой брандмауэр - хотя откуда там быть другим брандмауэрам) не мог бы дальше проанализировать, что там работает поверх TCP, потому что соединение TCP не устанавливалось.
ganzmavag
15.09.2026 05:20Вопрос тут чисто технический, связан с тем, что в случае автора ТСПУ (или какой-то другой брандмауэр - хотя откуда там быть другим брандмауэрам) не мог бы дальше проанализировать, что там работает поверх TCP, потому что соединение TCP не устанавливалось.
Я же вам выше объяснил - он уже перед этим проанализировал и начал рубить следующие соединения. Дальше через какое-то время он бан снимет, начнет пропускать, увидит несколько подозрительных для себя запросов и опять заблокирует.
mvv-rus
15.09.2026 05:20Вы объясняли общие слова из другого сценария. А у автора весьма конкретная, и довльно странная, блокировка пакетов ответа на соединение была сразу, как я из статьи понял. То есть, если смотреть с технической стороны - нечто совсем другое, другой сценарий.
PS Вот то, что он вижел снаружи РФ - соединения то устанавливаются, то нет - может быть на ваш сценарий похоже. А то, что он видел изутри РФ - нет.
0ka
15.09.2026 05:20https://habr.com/ru/articles/1044396/
mvv-rus
15.09.2026 05:20Повторяю теперь вам вопрос теперь вам: а это тут при чём? Ибо там написано:
Цензор оценивает ClientHello при TLS handshake для каждого TLS соединения.
А при блокировке установления TCP до TLS не доходит, ClientHello отправлен не будет.
Не то, чтобы это имело какое-то практичнеское значение, но меня интересуют чисто технические подробности.
ganzmavag
15.09.2026 05:20Логично блокировать первоначальный пакет, с SYN - если, конечно, брандмауэр (в т.ч. ТСПУ) его видит.
Наоборот, проще и экономичнее блокировать всё при подозрениях. И с каким-то интервалом проверять, остались ли подозрения.
И да, “много запросов” тут - к нераскрученному сайту - явно нет.
Это уже догадки пошли. Мы не знаем, что такое много в понимании ТСПУ и сейчас нейронки даже на пустом сайте могут много запросов создать.
mayorovp
15.09.2026 05:20Да, очень похоже на симптом прохождения трафика с асиметричными маршрутами через statefull firewall, когда в одну сторону он идёт через этот самый файервол, а в другую - не идёт.
Однако я не понимаю как в России в таком случае работает хоть что-то. Для магистрального провайдера такой трафик должен быть самым обычным делом, магистральные ТСПУ не должны полагаться что на то, что они видят оба направления соединения.
mvv-rus
15.09.2026 05:20Однако я не понимаю как в России в таком случае работает хоть что-то.
В целом - чисто божьим промыслом, не иначе ;-) Ибо ничем другим объяснить, что в России всё более-менее работает, невозможно ;-) А если серьезно, то вполне может быть, что это - обычное дело - никто ведь особо ничего не анализирует: как мы видим из дискуссии выше достаточно написать слово ТСПУ и можно дальше особо не думать. Впрочем, в данном случа мы имеем нечастое сочетание факторов: кроилово хостера, который закупает IP подешевле с других континентов, помноженное на (это мое предположение) старые костыли у магистралов, сделанные чтобы разгрузить ТСПУ, когда он начал захлёбываться
Ну, а добиваться, чтобы это всё было сделано по уму - это явно не моя задача, это пусть Шадаев работает, если хочет и может, бабло за это ему капает, не мне. Я же всего занимаюсь безнадежным (ибо мы все в конце концов умрём) делом существования в имеющихся условиях. Ну, и иногда позволяю себе небольшую гимнастику для ума, вроде той, которая в этой ветке комментариев, безо всякой практической пользы, чисто для себя. И, наверное, дальше я эту тему развивать не буду.
ТСПУ не должны полагаться что на то, что они видят оба направления соединения.
Однако как они тогда будут анализировать этот трафик? Не понимаю.
Да ну и чёрт с ними.
Desprit
15.09.2026 05:20Я правильно понял, что у вас сервер московский на Timeweb был? Если да, пробовали их техподдержку спросить? Просто интересно. Я сам давно пользуюсь их услугами, но у меня нет серверов в РФ зоне.
Vadtop Автор
15.09.2026 05:20Хостера намеренно не называю, дело не в компании, блок нестандартного регистратора может оказаться у любой.. Поддержку да, спрашивал, ответили что со своей стороны всё проверили и фильтрацию у магистральных не решают. Формально они правы, это не их зона.
Akuma
15.09.2026 05:20Как не называете? Вы прямым текстом его указали в статье.
Не вижу в этом ничего плохого, если что. У TW такое бывает, но поддержка у них одна из лучших при этом.
An_Tosha
15.09.2026 05:20Немного не так.
Они вполне могут сделать запрос магистралу на проблему блокировок адресов.
И магистрал должен или устранить проблему, в том числе через запрос в ГРЧЦ, или дать мотивированный отказ.
anayks
15.09.2026 05:20У моего коллеги был опыт связывания с этим хостингом, и ему просто рекомендовали найти сервер в пуле с белым айпи, заказывая сервер заново и проверяя руками. И, естественно, чуть позже он отказался от этого хостинга в пользу тех, где он с таким не сталкивался.
CherMet90
15.09.2026 05:20Меня конечно как сетевика поражает, что снять дамп это не самоочевидно при локализации любой сетевой проблемы
Я кстати сам с этой же хернёй столкнулся на связи между инстансом в рф и в каматере. Один к одному: tcp устанавливается, clinet hello прилетает на каматеру, он отправляет ответ, ответ в рф не приходит. Если запускать тестовые коннекты подряд , то проходит меньше половины. Проблема плавающая: то включат эту политику, то выключат.
У меня это вызывает только один вопрос: какая цель? собираются резать весь трафик до хостингов недружественных юрисдикций? или как?
Ну и плюс должен быть какой-то второй фактор для срабатывания фильтрации помимо зарубежного ASN, иначе будут страдать все сайты на зарубежных хостингах. Хотя может в этом и цель...Vadtop Автор
15.09.2026 05:20Дамп снимал, он в статье - SYN доходит, сервер отвечает SYN-ACK, обратно не приходит. У вас то же самое на шаг позже, на client hello. Про второй фактор в точку, соседние адреса того же ЦОД из RIPE работали нормально, значит одного зарубежного ASN мало.
Kyoki
15.09.2026 05:20какая цель? собираются резать весь трафик до хостингов недружественных юрисдикций?
Это "хитрый" план: если просто заблокировать, то начнут возникать и больше юзать средства, а так просто хостер плохо работает, сбоит почти в половине случаев.
8street
15.09.2026 05:20Как же это достало. По моим ощущениям, если трафик идет через ТСПУ, то любая сессия может стопнуться внезапно. К незаблокированным адресам.
Medeyko
15.09.2026 05:20Да, это очень, очень грустно. По интернету, по самым безобидным сайтам ходить без специальных средств стало некомфортно.
ardraeiss
15.09.2026 05:20собираются резать весь трафик до хостингов недружественных юрисдикций?
насколько память не подводит - согласно букве того прошлогоднего закона о защитах интернетов от людей прямым текстом было прописано недопущение до мессенджеров и хостеров, не входящих в реестры или не соблюдающих требования властей.
Так что пессиместично мнение - да, проверют/настраивают кусками/щупают возможность соблюсти полностью если(а то и "когда") зачем-то какой-нибудь из башен понадобится
mvv-rus
15.09.2026 05:20какая цель? собираются резать весь трафик до хостингов недружественных юрисдикций?
IMHO тут цели нет, тут бритва Хэнлона работает. В бюрократической системе оно так устроено - что если цель явно не задавать, то ее части работают несогласованно, и внешне система ведёт себя как тупая - даже если отдельные люди, ее составляющие, очень умны по-своему. То есть, составляющие ее люди поставленные перед ними цели выполняют, с показателями эффективности у них всё норм (а если где не норм - там они обтекатели ставят), а результат выходит чисто по Черномырдину: получается как всегда. Такая вот, понимаете, загогулина с бюрсистемой случается раз за разом.
HappyGroundhog
К сожалению симптомы когда пинг стабильно идет, а SSH и 443 рвутся и фильтруются практически на 100% говорят сейчас, что это "изменения в настройках магистральных провайдеров". Иногда помогают обращения к тому самому ведомству, которое этими "настройками" ведает, но так умеют не все хостеры, к сожалению...
Ваш лайфхак про проверку подсети и её регистратора очень классный, спасибо!
Vadtop Автор
Спасибо) У меня как раз пинг шел идеально, а 443 рвался, поэтому сперва и не думал на магистральных.
raxer
Последние 3 месяца сталкиваюсь с тем что многие мои ресурсы постепенно перестают работать с разных провайдеров. Особенно стремно за рабочие. У тебя может открываться а у клиента - нет. Директ вполне бодро списывает за это деньги
Для себя решил пока установкой reverse proxy в Yandex cloud и selectel
Для тестирования накидал сервис - который бы с локальных компьютеров проверял. ставишь клиента, он получает с сервера какие URL надо curl и отправляет отчет в сам сервис.
Клиент открытый, посмотреть можно на GitHub
Но толком не успел раскидать клиенты по друзьям/знакомым, так что пока там всего две ноды для проверки