Я ж и спрашиваю, как называется ваш хостинг? :) Никак? Ну тогда откуда вам знать что там у других.
Конечно многие сайты нормально сделаны и ничего не помирает ни под каким натиском. Но есть и совсем другие... и ну нигде вам не дадут грузить ядер 10+ на 100% хоть какое-то продолжительное время. Или отключат или заблокируют источник вредного траффика.
Я ж говорю, блокировать сайт - это п.1 - нежелательная мера для самого хостера (т.к. клиент вероятно уйдет). Потому они выбирают п.2
Независимы? Возможно в плане доступа и независимы, чтоб подцепив заразу на одном сайте не задело другие. Но это же shared хостинг - исполняются скрипты всех пользователей на одном процессоре (ладно, 2 если речь про бегет). Потому и выгоняют на vps - там он одно свое ядро если на 100% загрузит, то только его, а не все сразу. Опять же, чтоб не терять клиента (да и вдобавок больше денег с него получить) - пусть у него там на vps сляжет только его ядро и его сайт раз он такой терпила, готов потерпеть неудобства за свои же деньги, лишь бы кто-то там смог нормально спарсить его сайт.
Про блок через яву/куку знаю, также есть в своем арсенале такие методы. И некоторым кстати (с их согласия конечно же) такое внедрено. По все той же причине - владельцы без понятия как сдедать чтоб их поделка работала быстро и либо так, либо съезжать... а куда? Отовсюду их еще быстрей попрут.
Про 90е, кластеры и т.п. облака - опять же, если речь про классический shared, то это тупо один физический сервер с кучкой пользователей. Безо всяких виртуализаций и подобного. Тот же бегет - пару раз доводилось переносить оттуда клиентов, давали доступ глянуть что/как - просто двухпроцессорный серверок с большим числом ядер, памяти... и огромным LA.
А у тех модных/молодежных с бэкэндами на разных серверах, со всякими удаленными mysql и сетевыми дисковым хранилищами - там же почти всегда более тормознуто получается по итогу. Ну не может оно работать также быстро с такими же минимальными задержками как на классическом одном сервере. Да и все равно не поверю что не предпримут там никаких мер если на сайт, который генерирует страницы секунды и при этом на 100% грузит 1 ядро свалится пару десятков запросов в секунду. Соседей может и не положит, но к сайту/владельцу санкции будут наверняка. И что для владельца в итоге лучше будет - если блокнет хостер каких-то отдельных ботов или вообще вырубит неожиданно сайт целиком?
И пару слов в защиту бегета (никак не связан с ним).
У кого-то из вас тут есть хостинг свой, видели картину с другой стороны? Почему, видев лишь одну сторону медали, позволяете себе "праведный гнев"?
Вы все конечно красавцы, сайты у вас идеальные и естественно что блочить лишних ботов совершенно ни к чему. Но к сожалению вас таких менее 1%. Все остальные владельцы сайтов, нет не идиоты, но у них просто совершенно другая жизнь. Без вот этих ваших вордпресиков и т.п. ерунды. И даже больше, вероятно сами они вообще понятия не имеют как делать сайты - им их склепал фрилансер за 3 копейки и ушел в закат. Дальше владелец остается 1 на 1 с хостером и сайтом, который генерирует каждую страницу по пол-секнуды, но владелец вообще не в теме и считает это совершенно нормальным. Да и с его 3 посетителями в день у хостера также нет претензий никаких. Но вот появляется наш человек-пустышка83 и запускает по несколько (а то и несколько десятков или сотен) запросов в секунду. Что происходит дальше и что и кто в этой ситуации должен делать?
1) Хостер блокировует этот сайт/аккаунт чтоб не тормозил сервер и все остальные сайты на нем. Хостер предлагает владельцу съехать на более дорогой тариф или vps. Владелец в недоумении как так, все было отлично год на минимальном тарифе, а теперь начался какой-то развод. Вывод - хостер плохой, надо переезжать к другому.
2) Хостер, имея представление о большинстве своих клиентов, понимает что просить кого-то улучшить сайт чтоб тот отдавал страницы быстрей - бесполезно в 99% случаев. И видя явно аномальную активность предпринимает действия по блокировке ее по определенному шаблону, предполагая что вреда никакого для сайта не будет - никто же яндексы с гуглами не блокирует. А владелец в 99.99% случаев даже не заметит ничего. И в итоге клиент не уйдет и вреда от него не будет. А если и увидит/уйдет, ну что ж, мы хотябы попытались...
Так как надо правильней поступить? Ничего не делать вообще, пусть все сляжет у всех клиентов?
Я полностью согласен что вмешиваться не стоит и стараюсь держать контакт с клиентами чтобы в случае чего помочь/подсказать или даже с разрешения влезть в админку, подшаманить сайт.
Но вы представляете себе уровень бегета и какое количество проблемных сайтов у них там? При всем желании, это просто невозможно ни у какого более-менее крупного хостера. Там проще массово что-то с этим делать... ну или терять клиентов и превращаться в менее крупного хостера.
Что ж вы все такие тяжелые...
Еще раз повторяю. О каком сайте говорит ТС? Кто-то его видел? Нет.
Тот сайт закрыт CF или нет? Не знает никто.
403 ответ идет на уровне хостера там или на уровне владельца сайта? Тоже никто не знает.
И еще раз вопрос. Вы некий человек-пустышка83, парсите чужой сайт (и плевать вам что возможно за нагрузку владельца сайта заблокируют или разведут на более дорогой тариф), получаете 403 в ответ... но откуда вам знать чьих рук это дело? Почему утверждение что это делает хостер - единственно верное?
Еще раз, откуда инфа что именно хостер это делает? Может сам владелец через .htaccess
Хоть каплю критического мышления... вам неизвестно кто сказал свою фантазию по поводу неизвестного сайта - и давай на ровном месте поливать бегеты и т.д. Никто не видел тот сайт и не знает на каком уровне выдается там 403. Блочится там все подряд вместе с гуглоботами или может вообще вручную ip ТС'а владелец сайта заблочил какраз за то что бомбил запросами - ну не знаем же мы всей истории, зачем вы начинаете выдумывать дальше сказки какие-то?
Я ж говорю, так ведь можно предположить, что он хотел спарсить сайт Mik Foxi и получив ответ:
побежал регистрироваться на сёрче и утверждать что именно хостинг этого сайта блокирует именно screaming frog.
Так а по первому посту разве понять можно, блок это хостера или тоже просто под cloudflare сайт? Еще и бегет приплели зачем-то...
Т.е. какой-то там неизвестный сайт отдает 403 (неизвестно еще по какой причине) - это примитив, а когда ваши сайты ровно также 403 в ответ выдают - это другое, так и задумано :)
действительно
site.ru у вас там default'ный на его ip? https://site.ru/ открывает то же что https://ip/ ?
Есть вероятность, что с сервера где site.ru dns запрос site2.ru возвращает ip от site.ru (а не ip от site2.ru). Может в hosts прописано, может ip для site2.ru вы недавно сменили и еще какой-то кэш не истек.
Узнайте какой ip у site2.ru видится с сервера site.ru
Например php скриптом:
<?echo `dig +short site2.ru`;?>
или:
<xmp><?print_r(dns_get_record('site.2.ru',DNS_A));?>
Если действительно покажет ip от site.ru, то ничего удивительного что запрос в итоге приходит на site.ru
Это лишь ваш опыт, не надо его выдавать за абсолютную истину... "и все" 😏
Не все...
Как сделано у некоторых:
Запущено несколько копий apache/mod_php с разными версиями php. И когда пользователь выбирает для сайта1 php5, то конфиг этого сайта вешается на копию1 - apache/php5. Следующий сайт2 соответственно под php7 хочет - он вешается на другую копию2 - apache/php7. И в таком духе.
Как сделано у меня:
Есть пользователь. В рамках этого пользователя задается версия php, конфиг php.ini (конечно же с возможностью править, вкл/выкл расширения и т.д.). И заходя к примеру по ssh он запускает php -v или php --ini и видит свою версию php и свой конфиг. От имени этого пользователя запускаются отдельные (независимые от соседей) процессы apache/mod_php (или php-fpm, на выбор) с конечно же этой же самой версией php/php.ini и к примеру весь opcache кэш является личной собственностью этого пользователя/его сайтов. И нет такого что более посещаемые сайты соседей постоянно будут перетягивать одеяло на себя - у каждого все его личное. Ну и точно также с mysql сделано - версия, my.cnf, независимые процессы и память/кэш.
Да, есть минус что получается нет возможности в рамках одного аккаунта сделать выбор версии php для каждого сайта. Хотя нет, возможность конечно есть, можно точно также в рамках пользователя запускать несколько копий с разными версиями. Однако это ну совсем уж расточительно будет по ресурсам (количеству процессов и памяти). По опыту, очень мало кому это нужно. Большинство аккаунтов имеет 1-3 сайта и одной какой-то версии на все сайты обычно за глаза хватает. В случае если вдруг не хватает - заводится еще один аккаунт и все, не супер удобное, но всеж решение.
Так сильно лучше, чем как обычно - на один (или несколько с разными версиями) апач вешаются сотни-тысячи сайтов разных пользователей. Там наверняка постоянная конкуренция за кэш и главное (такое случалось пару раз у меня давным давно когда стоял один apache-itk со всеми пользователями) - кто-то один чем-нибудь подвешивает или просто сильно нагружает этот общий апач и у всех остальных начинаются тормоза или вообще ничего не открывается пока не решится проблема с тем подвисшим. С независимыми же апачами - никаких проблем из-за соседей и "холодный старт" сильно лучше т.к. из памяти не вытесняется ничего соседями.
Короче посыл в том что apache/mod_php вполне можно организовать с разными версиями php. И если этого нельзя сделать на большинстве shared'ов, то это не значит что так везде.
Это ж надо... школа недалеко от дома моего.
