Я тут даже не буду приводить никаких личных примеров, а просто упомяну Hetzner, у которого бОльшая часть железа бытового уровня. И прекрасно оно у них работает годами и даже десятилетиями.
Попробовал снова - результат как и был раньше: раздача идёт только непосредственно во время скачивания кеша. Раздача прекращается как только кеш заполняется. А можете, пожалуйста, скинуть ссылку на PR? Среди открытых ничего похожего не нашёл
Эта возня не нужна для просмотра фильма или сериала, поэтому я и назвал её ненужной.
А в целом я в сами согласен, даже специально ставил TorrServe отдельно на тот самый, ставший ненужным, медиасервер в надежде на то, что TorrServe будет оставаться на раздаче хотя бы той части, которая попадает в кеш. Но, к сожалению, либо это не работает by-design, либо у меня руки кривые. Если кто подскажет как это решить - буду благодарен
Если ещё не пробовали и есть устройство с Android / Google TV, то очень советую попробовать NUM (https://4pda.to/forum/index.php?showtopic=959756) - это совсем другой уровень удобства, которой сопоставим с "обычными" онлайн кинотеатрами: изучаешь ленту новых релизов, выбираешь понравившееся и прямо сейчас смотришь. Без ожидания скачивания, без всей этой ненужной возни - оно просто работает само.
У меня тоже раньше для этого был сервер с торрентами и такой-то матерью, с которого я через TV Box смотрел фильмы на проекторе.
Потом мне друг посоветовал NUM, я его поставил на тот самый TV Box и мой шаблон просмотра фильмов полностью поменялся: я больше не выбираю фильмы заранее, не веду каталог, не скачиваю и не удаляю это всё потом. Я сажусь на диван, не представляя что буду смотреть, выбираю среди свежего какой-то фильм и смотрю
всё ещё не знаю как в Homebrew, но после обновления арча все релевантные пакеты из AUR нужно обязательно пересобрать.
Я в "своём" пакете в brew на такое не натыкался, но, насколько помню, это решается явным PR с изменением ревизии, чтобы зафорсить пересборку новой версии пакета. То есть так же как и в AUR.
Как в таких условиях менять политику AUR, мне не очень понятно
На мой взгляд, тут всё просто - если ты используешь AUR то ты должен _один раз_ принять на себя все риски его использования. То есть риск возникает не в момент установки очередного пакета, а в момент установки ПЕРВОГО пакета из AUR. После этого у тебя нет пути назад.
Как следовало бы изменить политику:
добавить условный yay (или любой другй AUR-менеджер) в основной реп и объявить этот пакет официально поддерживаемым (именно сам пакет yay, но не AUR-пакеты, которые через него ставятся)
установку этого пакета считать акцептом рисков (можно даже добавить ради этого отдельный ключ в CLI)
очень спорный момент, который никогда не будет реализован, но я бы просто добавил AUR в pacman, и ставил пакеты через `pacman -S aur/something` с явным флагом "принять все риски". И уже тогда обновления через `pacman -Suy` обновляли бы все пакеты: и AUR и обычные
В целом, за то, чтобы дать удобство людям, которые хотят осознанно использовать AUR и понимают и принимают все риски этого использования.
Я вот сейчас ради интереса зашёл в официальную вики про AUR (https://wiki.archlinux.org/title/Arch_User_Repository). Обратите внимание на описание установки пакетов. Напомню, мы в 2026 году живём, а не в 2006. В 2026 обычно не нужно качать описания пакетов и тарболы с сорцами руками. Причём, на этой странице всё же есть в Related и ссылка на AUR helpers, спасибо хоть за это.
Мне тут непонятна именно эта двойственность подхода - с одной стороны мы описываем AUR в официальной вики и в целом его поддерживаем. Но с другой - не даём никаких штатных удобных механизмом его использовать. Как так? Почему такая шизофрения в отношении?
Насколько я смог понять из гугла, обновления в core и cask обязательно проходят через мейнтейнеров в виде пулл-реквестов на гитхабе, что абсолютно не похоже на AUR
Да, всё через PR делается. А в чём разница с AUR? Ни там ни там нет на самом деле никакого контроля над тем, что именно пушится. В Homebrew любой может добавить свой пакет и залить туда всё что угодно. Да, кто-то этот PR будет аппрувить, но никто же не в сам код.
Я одно время "мейнтейнил" пакет в brew и весь аппрув там - это просто формальность.
Почему-то есть подозрение, что вы перепутали с do-release-upgrade
Да, вы правы, посыпаю лысую голову пеплом. Именно dist-upgrade на серверах у меня ничего не ломал
Сервера тоже разные бывают. До недавнего времени я вообще не мог использовать Ubuntu без PPA (про дебиан не знаю) потому, что там вообще не было OpenZFS, а докер был настолько замшелой версии, что это просто стыдно.
Не так давно ситуация поменялась и OpenZFS появился в официальном репе. А вот с докером беда так и осталась - приходится всё-равно добавлять сторонние PPA, а если так, то о какой стабильности вообще идёт речь.
Если забыть про докер, то в LTS уже изначально идёт люто устаревший софт. Это возможно было нормально когда весь софт компилировался под конкретный дистр с кучей дистрозависимых патчей и поставлялся в бинарниках. Но сейчас, когда огромная часть софта написана на скриптовых языках, жёстко завязана на версию рантайма и зависит от кучи сторонних библиотек, такой подход тупо не работает.
Это в любом случае вынуждает либо подключать PPA для получения более новых версий, либо вообще использовать nvm и npm, venv и rvm. Всё это идёт вразрез с философией дистрибутивов (не только Ubuntu). Более того, сам концепт "стабильных" дистрибутивов в этом месте ломается и никакого решения, кроме контейнеризации, нет.
Не очень понятно, как вы собрались менять политику AUR, если он наполняется абсолютно левыми людьми, которые могут делать (и, что ещё хуже, не делать) что хотят
Да и пусть делают что хотят. По похожим правилам существует Homebrew, например. И ничего - нормально всё. Честно, у меня доверия к нонейм-мейнтейнеру из "команды" арча не больше чем к такому же нонейм-мейнтейнеру случайного пакета из AUR: и там и там может прилететь бяка и и там и там надо так или иначе принимать риск.
Немного отвлечённо, но я жду момента когда можно будет вообще избавиться от мейнтейнеров и исключить их из цепочки разработчик -> пользователь. Это лишнее звено, которое не приносит абсолютно никакой пользу, зато приносит риски.
Сломанные правила apparmor, из-за которых часть приложений тупо не запускается, виртуалбокс портящий память внутри виртуалок, сломанный питон с утечкой памяти, снос видеодрайвера после простого apt dist-upgrade...
Я уже зарёкся делать dist-upgrade. Это всегда тонна багов, которые и вылазят и вылазят и вылазят в будущем после обновления. Да, полагаю, что мне сейчас многие скажут что у них всё работает. Верю (неохотно). Но у меня это нормально не работало ни разу: ни на серваках, где вообще кроме докера считай ничего нет, ни на десктопе. Всегда потом (а то и сразу) вылазят проблемы.
Таким образом ключи будут обновляться раз в неделю.
На это у меня есть два вопроса:
Почему это не включено по умолчанию?
Зачем мне обновлять ключи чаще, чем я обновляю систему? Если всё настолько ушло далеко вперёд, что обновились даже ключи archlinux-keyring, то ок - я ССЗБ и буду страдать. Но несколько месяцев между обновлениями - это вообще не срок
В арче есть несколько довольно странных решений, которые почему-то не хотят исправить и сделать более удобным для юзера.
В основном, конечно, претензии к политике по отношению к AUR. Как по мне, нужно:
добавить пакадж-менеджер для AUR в основной репозиторий. Как же замучало каждый раз разбираться со сборкой yay, которому в очередной раз не нравится версия libalpm. Сделал pacman -Suy вместо yay -Suy и привет
изменить политику по отношению к AUR - это должна быть часть основной инфраструктуры. Сейчас к нему официальное отношение Арча примерно как к сборищу бомжей под мостом, которые норовят тебя ограбить и изнасиловать. Отсюда миллион подтверждений при попытке установки любого пакета через тот yay или почивший yaourt и другие
собственно, выбрать какой-нибудь PM для AUR и назвать его официальным
Но в с pacman не всё гладко: не понимаю что мешает починить проблему с archlinux-keyring - всего-то нужно, чтобы pacman -Suy (обновить все пакеты) сначала обновлял archlinux-keyring, а уже потом всё остальное.
Сейчас, если пару месяцев не обновляться, то у части мейнтейнеров пакетов обновятся ключи, а может и появятся новые мейнтейнеры. Далее мы делаем pacman -Suy и он радостно в каком-то своём порядке начинает качать пакеты, проверять их подписи, а они не совпадают с теми, которые сохранены в системном keyring (он же уже устарел к этому моменту).
Что делает pacman? Нет, он не обновляет archlinux-keyring перед обновлением всего остального, что полностью решило бы проблему, и не советует его обновить тебе самому, и вообще его нигде не упоминает правильное решение. Вместо этого он предлагает абсолютно ошибочное и неработающее решение - вручную добавить ключ мейнтенера в свой keyring. Это никак не помогает, а делает только хуже.
Наверное, настоящие арчеводы обновляются каждый день и даже не знают о существовании этой проблемы, но она живёт десятилетия, она постоянно плодит вопросы на форумах и она потратила, наверное, миллионы человекочасов у разных пользователей на своё решение. А ведь исправление заняло бы примерно 5 минут, но...
Давно использую арч на домашнем сервере, но уже принял решение перейти на Ubuntu. Замучали постоянные мелкие проблемы: правда, в основном они касаются докера - то он вообще не работает при установке определённой версии, то перестаёт работать автоматический рестарт контейнеров после ребута (это вообще загадочная проблема, которая попила немало крови, потому что заметить её заранее невозможно), то он перестаёт работать поверх zfs. В Ubuntu хватает своих проблем, но по совокупности всё же она для меня выигрывает.
Простите, накипело. Просто нужно было выговориться, а тут внезапно кто-то упомянул арч :)
Читал и проверял. И даже обнаружил, что описанный метод всё ещё работает на мегафоне для домена szfwp.megafon.ru. Он действительно обогощает заголовки запроса и добавляет X-IMSI, X-SGSN, X-IMEISV, X-3GPP-USER-LOCATION-INFO и X-MSISDN - проверяется простой подменой Host.
Но ни один из перечисленных в статье доменов так себя не ведёт, по крайней мере если запрашивать корень. О чём я и написал
Вот именно это я и проверял до того как написать свой первый комментарий. Если это и работает, то помимо домена нужен какой-то ещё маркер: специальный путь, или заголовок, или ещё что-то такое. Одного домена тут явно недостаточно
Если он не добавляет эти заголовки в ответ клиенту, то как MAX их получает?
Ваше объяснение не согласуется само с собой:
cleartextTrafficPermitted включен только для доменов операторов, но не для доменов MAX'а, то есть клиент MAX'а не сможет сделать http:// запрос на свой сервер, а значит, ОПСОС не сможет добавить в него никакие хедеры, а значит сервер MAX напрямую эту информацию от ОПСОСов получить не сможет
То, что внутри инфраструктуры оператора в запросы добавляются служебные хедеры - возможно, но вопрос в том, каким образом эта служебная информацию должна попасть в клиент MAX?
Делает HTTP-запрос (открытым текстом) на оператор-ный эндпоинт.
Оператор на своём оборудовании дописывает в заголовки ваш MSISDN (номер телефона).
Сервер MAX видит заголовки → знает, кто вы. Без SMS-кода.
Я попробовал на Мегафоне, МТС и Билайне - позапрашивал через них соответствующие домены через HTTP и в ответ не получил никаких странных хедеров (единственное что подозрительное нашлось - кука cookiesession1 от idgw.mobileid.mts.ru .
Ещё непонятен момент про Header Enrichment: зачем он нужен, если мы всё-равно запрашиваем эндпоинт самого оператора, ведь он в ответ может со стороны сервера без каких-то дополнительных манипуляций добавить в ответ нужные данные.
В общем, буду благодарен, если распишите этот момент более подробно
Зависит от провайдера, но в Москве сейчас MTProxy банится на ТСПУ как протокол у многих. Неважно на какой именно сервер вы подключаетесь - в РФ или нет.
ТСПУ ловит какой-то маркер в рукопожатии и всё соединение после этого идёт лесом.
И да, это касается именно последней версии Телеграма и EE-режима. Причём, если у вас включен режим с фоллбеком на собственный https-сервер с валидным сертификатом, то обычные https:// запросы из браузера и курла на этот же сервер и на этот же 443 порт проходят без проблем. Палится именно хендшейк mtproxy и палится мгновенно. Это не probe и это не блеклистед IP, просто РКН нашёл какой-то очень качественный маркер в самом трафике и использует его
Напрямую получить состояние сетевых интерфейсов они, конечно, не могут. Зато могут поотправлять запросы на домены из разных зарубежных зон и посмотреть под каким IP вы туда ходите. Если на ya.ru вы зашли из РФ, а на some-metric-tracker.io - из Нидерландов, то тут явно что-то нечисто, а значит, надо ваш нидерландский IP слить в РКН, который радостно заблокирует к нему доступ из РФ.
А если ещё вспомнить про я.метрику, которая есть но почти всех российский сайтах, то становится понятно, что от этого точечно не защититься
Откуда у вас такая уверенность?
Я тут даже не буду приводить никаких личных примеров, а просто упомяну Hetzner, у которого бОльшая часть железа бытового уровня. И прекрасно оно у них работает годами и даже десятилетиями.
Что скажете на это?
Попробовал снова - результат как и был раньше: раздача идёт только непосредственно во время скачивания кеша. Раздача прекращается как только кеш заполняется.
А можете, пожалуйста, скинуть ссылку на PR? Среди открытых ничего похожего не нашёл
К сожалению или к счастью я такие фильмы не смотрю. Как правило, даже на старых (но популярных) фильмах всегда есть достаточное количество сидов
О, шикарно. Значит пришло время попробовать ещё раз. Спасибо!
Эта возня не нужна для просмотра фильма или сериала, поэтому я и назвал её ненужной.
А в целом я в сами согласен, даже специально ставил TorrServe отдельно на тот самый, ставший ненужным, медиасервер в надежде на то, что TorrServe будет оставаться на раздаче хотя бы той части, которая попадает в кеш. Но, к сожалению, либо это не работает by-design, либо у меня руки кривые. Если кто подскажет как это решить - буду благодарен
Если ещё не пробовали и есть устройство с Android / Google TV, то очень советую попробовать NUM (https://4pda.to/forum/index.php?showtopic=959756) - это совсем другой уровень удобства, которой сопоставим с "обычными" онлайн кинотеатрами: изучаешь ленту новых релизов, выбираешь понравившееся и прямо сейчас смотришь. Без ожидания скачивания, без всей этой ненужной возни - оно просто работает само.
У меня тоже раньше для этого был сервер с торрентами и такой-то матерью, с которого я через TV Box смотрел фильмы на проекторе.
Потом мне друг посоветовал NUM, я его поставил на тот самый TV Box и мой шаблон просмотра фильмов полностью поменялся: я больше не выбираю фильмы заранее, не веду каталог, не скачиваю и не удаляю это всё потом. Я сажусь на диван, не представляя что буду смотреть, выбираю среди свежего какой-то фильм и смотрю
Удачи вам с доступом клиентов из РФ к серверу на OVH. Он давно уже "деградировал" силами РКН. Как и Hetzner, например
Подобные хостинги в Европе и берут отчасти потому, что не хочется держать всё в РФ. Или же если есть клиенты и из РФ и со всего остального мира
Я в "своём" пакете в brew на такое не натыкался, но, насколько помню, это решается явным PR с изменением ревизии, чтобы зафорсить пересборку новой версии пакета. То есть так же как и в AUR.
На мой взгляд, тут всё просто - если ты используешь AUR то ты должен _один раз_ принять на себя все риски его использования. То есть риск возникает не в момент установки очередного пакета, а в момент установки ПЕРВОГО пакета из AUR. После этого у тебя нет пути назад.
Как следовало бы изменить политику:
добавить условный
yay(или любой другй AUR-менеджер) в основной реп и объявить этот пакет официально поддерживаемым (именно сам пакетyay, но не AUR-пакеты, которые через него ставятся)установку этого пакета считать акцептом рисков (можно даже добавить ради этого отдельный ключ в CLI)
очень спорный момент, который никогда не будет реализован, но я бы просто добавил AUR в pacman, и ставил пакеты через `pacman -S aur/something` с явным флагом "принять все риски". И уже тогда обновления через `pacman -Suy` обновляли бы все пакеты: и AUR и обычные
В целом, за то, чтобы дать удобство людям, которые хотят осознанно использовать AUR и понимают и принимают все риски этого использования.
Я вот сейчас ради интереса зашёл в официальную вики про AUR (https://wiki.archlinux.org/title/Arch_User_Repository). Обратите внимание на описание установки пакетов. Напомню, мы в 2026 году живём, а не в 2006. В 2026 обычно не нужно качать описания пакетов и тарболы с сорцами руками. Причём, на этой странице всё же есть в Related и ссылка на AUR helpers, спасибо хоть за это.
Мне тут непонятна именно эта двойственность подхода - с одной стороны мы описываем AUR в официальной вики и в целом его поддерживаем. Но с другой - не даём никаких штатных удобных механизмом его использовать. Как так? Почему такая шизофрения в отношении?
Хм. Это для новых установок? На старых я не далее как месяц назад в очередной раз поймал именно эту проблему
Да, всё через PR делается. А в чём разница с AUR? Ни там ни там нет на самом деле никакого контроля над тем, что именно пушится. В Homebrew любой может добавить свой пакет и залить туда всё что угодно. Да, кто-то этот PR будет аппрувить, но никто же не в сам код.
Я одно время "мейнтейнил" пакет в brew и весь аппрув там - это просто формальность.
Да, вы правы, посыпаю лысую голову пеплом. Именно
dist-upgradeна серверах у меня ничего не ломалСервера тоже разные бывают. До недавнего времени я вообще не мог использовать Ubuntu без PPA (про дебиан не знаю) потому, что там вообще не было OpenZFS, а докер был настолько замшелой версии, что это просто стыдно.
Не так давно ситуация поменялась и OpenZFS появился в официальном репе. А вот с докером беда так и осталась - приходится всё-равно добавлять сторонние PPA, а если так, то о какой стабильности вообще идёт речь.
Если забыть про докер, то в LTS уже изначально идёт люто устаревший софт. Это возможно было нормально когда весь софт компилировался под конкретный дистр с кучей дистрозависимых патчей и поставлялся в бинарниках. Но сейчас, когда огромная часть софта написана на скриптовых языках, жёстко завязана на версию рантайма и зависит от кучи сторонних библиотек, такой подход тупо не работает.
Это в любом случае вынуждает либо подключать PPA для получения более новых версий, либо вообще использовать nvm и npm, venv и rvm. Всё это идёт вразрез с философией дистрибутивов (не только Ubuntu). Более того, сам концепт "стабильных" дистрибутивов в этом месте ломается и никакого решения, кроме контейнеризации, нет.
Да и пусть делают что хотят. По похожим правилам существует Homebrew, например. И ничего - нормально всё. Честно, у меня доверия к нонейм-мейнтейнеру из "команды" арча не больше чем к такому же нонейм-мейнтейнеру случайного пакета из AUR: и там и там может прилететь бяка и и там и там надо так или иначе принимать риск.
Немного отвлечённо, но я жду момента когда можно будет вообще избавиться от мейнтейнеров и исключить их из цепочки разработчик -> пользователь. Это лишнее звено, которое не приносит абсолютно никакой пользу, зато приносит риски.
Я уже зарёкся делать
dist-upgrade. Это всегда тонна багов, которые и вылазят и вылазят и вылазят в будущем после обновления. Да, полагаю, что мне сейчас многие скажут что у них всё работает. Верю (неохотно). Но у меня это нормально не работало ни разу: ни на серваках, где вообще кроме докера считай ничего нет, ни на десктопе. Всегда потом (а то и сразу) вылазят проблемы.Поэтому да - только полная переустановка
Таким образом ключи будут обновляться раз в неделю.На это у меня есть два вопроса:
Почему это не включено по умолчанию?
Зачем мне обновлять ключи чаще, чем я обновляю систему? Если всё настолько ушло далеко вперёд, что обновились даже ключи
archlinux-keyring, то ок - я ССЗБ и буду страдать. Но несколько месяцев между обновлениями - это вообще не срокВ арче есть несколько довольно странных решений, которые почему-то не хотят исправить и сделать более удобным для юзера.
В основном, конечно, претензии к политике по отношению к AUR. Как по мне, нужно:
добавить пакадж-менеджер для AUR в основной репозиторий. Как же замучало каждый раз разбираться со сборкой
yay, которому в очередной раз не нравится версияlibalpm. Сделалpacman -Suyвместоyay -Suyи приветизменить политику по отношению к AUR - это должна быть часть основной инфраструктуры. Сейчас к нему официальное отношение Арча примерно как к сборищу бомжей под мостом, которые норовят тебя ограбить и изнасиловать. Отсюда миллион подтверждений при попытке установки любого пакета через тот
yayили почившийyaourtи другиесобственно, выбрать какой-нибудь PM для AUR и назвать его официальным
Но в с pacman не всё гладко: не понимаю что мешает починить проблему с
archlinux-keyring- всего-то нужно, чтобыpacman -Suy(обновить все пакеты) сначала обновлялarchlinux-keyring, а уже потом всё остальное.Сейчас, если пару месяцев не обновляться, то у части мейнтейнеров пакетов обновятся ключи, а может и появятся новые мейнтейнеры. Далее мы делаем
pacman -Suyи он радостно в каком-то своём порядке начинает качать пакеты, проверять их подписи, а они не совпадают с теми, которые сохранены в системном keyring (он же уже устарел к этому моменту).Что делает pacman? Нет, он не обновляет
archlinux-keyringперед обновлением всего остального, что полностью решило бы проблему, и не советует его обновить тебе самому, и вообще его нигде не упоминает правильное решение. Вместо этого он предлагает абсолютно ошибочное и неработающее решение - вручную добавить ключ мейнтенера в свой keyring. Это никак не помогает, а делает только хуже.Наверное, настоящие арчеводы обновляются каждый день и даже не знают о существовании этой проблемы, но она живёт десятилетия, она постоянно плодит вопросы на форумах и она потратила, наверное, миллионы человекочасов у разных пользователей на своё решение. А ведь исправление заняло бы примерно 5 минут, но...
Давно использую арч на домашнем сервере, но уже принял решение перейти на Ubuntu. Замучали постоянные мелкие проблемы: правда, в основном они касаются докера - то он вообще не работает при установке определённой версии, то перестаёт работать автоматический рестарт контейнеров после ребута (это вообще загадочная проблема, которая попила немало крови, потому что заметить её заранее невозможно), то он перестаёт работать поверх zfs.
В Ubuntu хватает своих проблем, но по совокупности всё же она для меня выигрывает.
Простите, накипело. Просто нужно было выговориться, а тут внезапно кто-то упомянул арч :)
Читал и проверял. И даже обнаружил, что описанный метод всё ещё работает на мегафоне для домена
szfwp.megafon.ru. Он действительно обогощает заголовки запроса и добавляетX-IMSI,X-SGSN,X-IMEISV,X-3GPP-USER-LOCATION-INFOиX-MSISDN- проверяется простой подменойHost.Но ни один из перечисленных в статье доменов так себя не ведёт, по крайней мере если запрашивать корень. О чём я и написал
Вот именно это я и проверял до того как написать свой первый комментарий. Если это и работает, то помимо домена нужен какой-то ещё маркер: специальный путь, или заголовок, или ещё что-то такое. Одного домена тут явно недостаточно
Если он не добавляет эти заголовки в ответ клиенту, то как MAX их получает?
Ваше объяснение не согласуется само с собой:
cleartextTrafficPermittedвключен только для доменов операторов, но не для доменов MAX'а, то есть клиент MAX'а не сможет сделать http:// запрос на свой сервер, а значит, ОПСОС не сможет добавить в него никакие хедеры, а значит сервер MAX напрямую эту информацию от ОПСОСов получить не сможетТо, что внутри инфраструктуры оператора в запросы добавляются служебные хедеры - возможно, но вопрос в том, каким образом эта служебная информацию должна попасть в клиент MAX?
Можете пояснить как это работает?
Я попробовал на Мегафоне, МТС и Билайне - позапрашивал через них соответствующие домены через HTTP и в ответ не получил никаких странных хедеров (единственное что подозрительное нашлось - кука
cookiesession1отidgw.mobileid.mts.ru.Ещё непонятен момент про Header Enrichment: зачем он нужен, если мы всё-равно запрашиваем эндпоинт самого оператора, ведь он в ответ может со стороны сервера без каких-то дополнительных манипуляций добавить в ответ нужные данные.
В общем, буду благодарен, если распишите этот момент более подробно
Зависит от провайдера, но в Москве сейчас MTProxy банится на ТСПУ как протокол у многих. Неважно на какой именно сервер вы подключаетесь - в РФ или нет.
ТСПУ ловит какой-то маркер в рукопожатии и всё соединение после этого идёт лесом.
И да, это касается именно последней версии Телеграма и EE-режима.
Причём, если у вас включен режим с фоллбеком на собственный https-сервер с валидным сертификатом, то обычные https:// запросы из браузера и курла на этот же сервер и на этот же 443 порт проходят без проблем. Палится именно хендшейк mtproxy и палится мгновенно. Это не probe и это не блеклистед IP, просто РКН нашёл какой-то очень качественный маркер в самом трафике и использует его
Напрямую получить состояние сетевых интерфейсов они, конечно, не могут. Зато могут поотправлять запросы на домены из разных зарубежных зон и посмотреть под каким IP вы туда ходите. Если на ya.ru вы зашли из РФ, а на some-metric-tracker.io - из Нидерландов, то тут явно что-то нечисто, а значит, надо ваш нидерландский IP слить в РКН, который радостно заблокирует к нему доступ из РФ.
А если ещё вспомнить про я.метрику, которая есть но почти всех российский сайтах, то становится понятно, что от этого точечно не защититься