16 октября через АнтиЗапрет перестали работать анонсеры Рутрекера.
Проверочная ссылка http://bt.t-ru.org/ann_time.php сообщает Error code 522 от Cloudflare.
Можно как-то с вашей стороны диагностировать причину «бана» АнтиЗапрета?
На форуме трекера с начала лета регулярно появляются сообщения о недоступности анонсеров с кодами ошибок 521 и 522 от Cloudflare. Однако администрация не связывается с поддержкой Cloudflare, а у самого Рутрекера, по их словам, всё работает. Администрация Рутрекера считает это плавающей ошибкой самого Cloudflare, и точка.
Тут не причина бана, а лежащие с завидным постоянством сервера с рутрекера - Free site availability checks all over the world: Ping-Admin.Com - web site and server monitoring. Site availability checks
С других IP-адресов доступ к анонсерам Рутрекера есть.
скорее похоже на защиту от ДДОС/етк кривоработающюю
РТ напрямую не работает
ВПН не работает
TOR не работает
все 522 ошибка
опера-прокси работает
< HTTP/1.1 200 OK
(answer from real tracker)
p.s. warp+ тоже работает
Не проблема АнтиЗапрета. С одного моего сервера (Oracle, Германия) отвал по таймауту, с другого (Aeza, Швеция) - нормально. Я тоже склоняюсь к тому, что там просто закрыт доступ с диапазонов популярных хостеров, чтобы не ддосили.
Сделать с этим ничего не получится, т.к. исправить это может лишь владелец домена, а он, по вашим словам, не собирается ничего делать.
А смысл от анонсеров рутрекера, если все равно на большинстве раздач там работает dht/pex
Вы хотя бы умеете читать текст ошибки? Даже если не умеете, это наглядно показано картинкой.
Cloudflare работает как прокси-сервер и отображает данную ошибку если не может достучаться до хоста где размещается сайт. Если увидели данную ошибку, можете быть полноценно уверены что проблема глобальная, а не только у вас.
Когда это раздача популярного свежего фильма со Скалой - это одно дело. Когда это какая-то раздача из 2009, где один сид - вы с ним запросто можете друг друга никогда не найти без трекера.
Вы хотя бы умеете читать текст ошибки?
Да, умею.
Cloudflare работает как прокси-сервер и отображает данную ошибку если не может достучаться до хоста где размещается сайт.
Как я и писал ранее, администрация Рутрекера заявляет, что у них нет никаких проблем и это проблема на стороне Cloudflare.
Если увидели данную ошибку, можете быть полноценно уверены что проблема глобальная, а не только у вас.
Проблема не глобальная. На моих скриншотах IP АнтиЗарета 51.75.75.245 и проверка подключения через Сингапур, Франкфурт и Амстердам сообщает Error code 522. При этом с другого IP АнтиЗапрета 51.158.181.228 анонсеры Рутрекера всегда доступны, и никакой «недоступности хоста» нет.
Когда это раздача популярного свежего фильма со Скалой - это одно дело. Когда это какая-то раздача из 2009, где один сид - вы с ним запросто можете друг друга никогда не найти без трекера.
Ситуация осложняется тем, что на некоторых ресурсах, например на 4pda, рекомендуют отключать DHT и PeX для повышения уровня конфиденциальности. Кроме того, перестали работать DHT bootstrap-серверы router.utorrent.com и router.bittorrent.com. Также стоит учесть, что за NAT может находиться единственный сид на раздаче, а для соединения с ним его клиент должен сам инициировать подключение. Однако, если в клиенте отключены DHT и PeX для «приватности», а также нет связи с анонсером, то с этим единственным сидом за NAT не получится установить соединение.
И ещё усугубляется тем, что в qBittorrent при включении прокси, отваливается DHT.
Могу подтвердить проблемы с доступом к анонсерам, под VPN. Помогает rutracker proxy, но при этом отваливается DHT в qBittorrent, если не принять особых мер. Вроде прозрачного проксирования через iptables, что естественно большинство не будет делать. Поэтому рекомендую Tixati торрент клиент, в нём можно раздельно настроить.
Если отключены DHT и PEX, а также нельзя достучаться до трекера/анонсера, то вы вообще никаких пиров не найдете, вне зависимости от особенностей их подключения к сети.
Также стоит учесть, что за NAT может находиться единственный сид на раздаче, а для соединения с ним его клиент должен сам инициировать подключение.
Если его клиент получает список пиров (от анонсера или через DHT) и видит пира с <100%, разве он не может сам постучаться к нему и предложить посидировать, если это прямо не запрещено конфигурацией?