NotSlow

А что именно уже делалось по этому поводу? Зачем вам советы, которые вам уже не актуальны. Кто-то смотрел от чего именно нагрузка? Какой смысл советовать запросы к базе оптимизировать, если у вас там php скрипты создают нагрузку например. Если база, то включался ли лог медленных запросов? Выяснялось ли из каких скриптов/модулей сайта эти запросы приходят? Может тяжелых запросов нет, но просто быстрыми мелкими очень активно долбит... откуда именно, опять же. Советы по настройке сервера вам тоже возможно ни к чему, если вы на shared хостинге сейчас. Слишком много неизвестных. Волшебных хаков, не ускоряя сами тормоза сайта, всего два: 1) Увеличить скорость "железа", на котором сайт работает. Не какой-то там тариф по-выше, не ядер каких-то там по-больше, а именно скорость cpu, однопоточную. 2) Добавить модуль кэширования. Тормозить будет все также, но хотябы сгенерированное будет сохраняться и какое-то время отдаваться в готовом виде. Этим и снижая нагрузку общую.

да спамеры чаще всего используют нормальные user agent'ы. и ip используются совершенно разные. причем часто со взломанных устройств нормальных людей. т.е. банить провайдерские ip - такое себе... надо именно отличать нормальный браузер человеческий от скриптовых/программных ботов. капча конечно более надежна, но и более раздражающая

И это только то что вы замечаете. А сколько постоянно по сайтам ботов долбится по всевозможным скриптам, админкам и т.д... У меня практически у всех клиентов сайты под защитой на любые POST запросы. Нормальные люди заходят везде как обычно, и безо всяких разгадываний капч. А боты лишь 403 ответ получают от nginx, даже не напрягая apache/php этим мусором:

километровый .htaccess будет немного замедлять все. еще вариант - повесить домен на cloudflare и там настроить защиты

ну это не совсем так делается... надо подготовиться открыть access.log и error.log (сервера и сайта) походить по сайту, наткнуться на ошибку. потом открыть access.log в конце увидеть ваш запрос с 500 ответом. дальше по этому времени поискать что было в error логах. т.к. в логах и без этой вашей 500й может быть куча других ошибок не связанных

Ну вы конечно можете перепробовать все советы gpt. Можете выслушать догадки незнакомцев на форумах, которые ни сайта не видели вашего, ни тем более логов. А лишь своих "вот у меня было такое..." накидать могут. А если надо просто решить конкретно вашу проблему - пройтись по конкретно вашим логам и там скорей всего найдется причина. Или конечно еще вариант - обратиться к кому-то за помощью. Чтоб опять же не подключать незнакомцев, логично было бы попробовать спросить хостера. У него есть и доступы ко всему, и опыт (наверное).

Вы хвастаетесь или вопрос какой-то спрашиваете? Зачем предполагать или на картах гадать, когда есть же логи... В них по каждой error 500 должна быть четкая причина. Если нет - надо сделать чтобы была.

тут не поспоришь... может раньше xml файлы вам слали без этого BOM заголовка, а теперь с ним. чтоб чем-то помочь, нужно видеть что у вас там за файлы. надо попробовать для начала в текстовом редакторе каком-то сохранить без BOM:

https://en.wikipedia.org/wiki/Word_joiner Так то это маркер в начале utf-8 файлов. Почему плагин их не понимает - этот вопрос к его автору могли бы задать. Но если вы его не покупали, то что ж...

В чем особенность? Ровно также как и jpg, css, js... Как - зависит от того где сайт работает сейчас. Кто ж знает как организовано у вас. Если статику nginx отдает, то в нем и задавать заголовки для кэша. Если apache, то через .htaccess море примеров в инете. Задавать/нет и на сколько - вам решать. Если просто ради оценки по pagespeed, то ставьте. Если эти самые js скрипты часто меняются, то наверное не стоит. Это в любом случае лишь рекомендация для браузеров. Некоторые из без этого сами все подряд больше чем надо кэшируют, чем только мешают тем кто сайты делает/меняет часто. А можно браузер и под себя настроить. У меня например после закрытия весь кэш удаляется. Чтоб независимо что там по кэшу сайт сообщает, я просто прегружаю браузер и открываю сайт как в первый раз, все качается с хоста, а не из кэша берется.

Кстати в соседней теме https://opencartforum.com/topic/186817-problema-s-otobrazheniem-fotografiy-tovarov/ Тоже сайт на thehost.ua и тоже заметно тормозит. Повод задуматься...

Тоже проблемы не наблюдаю

Какая проблема? Куда смотреть? Что сейчас не правильно?

И сайты разные, не только opencart? Тогда вообще не факт, что opencart сайт ваш причина. Возможно заражен какой-то другой, а пострадали все на аккаунте. Или "на хосте" - в смысле на разных аккаунтах на одном хосте? Ну тогда точно надо переносить на другой. В общем все еще не ясно что вы тут хотите на форуме Чистите вручную, переносите на другой хост. Если там не повторится, значит проблему решили. Не умеете? Значит обращайтесь к тому кто умеет. Можно и мне в личку написать, могу глянуть.

*:25 значит на всех ip слушает. Да и если говорите меняли порт и все работает, то что остается? Точно блокировка где-то дальше, что тут поделать... Можно продолжать настаивать чтоб передали вопрос кому-то более сознательному в поддержке. Но проще конечно забить и переехать. Ну или хотябы почтой переехать как выше писал. Есть (видел по крайней мере раньше) варианты за $1/мес или около того. На тех же lowendbox/lowendtalk посмотреть. Главное пробить ip по спам базам прежде чем селиться: https://mxtoolbox.com/blacklists.aspx

А кто тут по вашему знать может? Доступов к сайту и логам нет ни у кого... Скорей всего сами и занесли заразу через модули или скрипты сомнительного происхождения. Или кто-то занес, кому могли давать доступ. Можно попытаться спросить у хостера, но это не их обязанность разбираться. Если проблема появилась недавно, то возможно есть бэкап, где все в норме? Это самое простое решение.

Покажите еще lsof -i -n -P | grep :25 Вдруг там окажется, что listen есть... но только на 127.0.0.1 например Это возможный вариант, при котором локально у вас все работает, а снаружи нет. Если всеж listen именно внешний ip есть, то покажите еще iptables -S

Если уверены, что iptables или еще что-то точно не блокирует у вас, то значит остается блокировка где-то между vps и интернетом. Т.к. из вне порты у вас там действительно недоступны (скрины ниже). Кроме поддержки vps никто вам не поможет. А если они отказываются, то выходов лишь 2: 1) Переехать полностью. 2) Если обосновались и не хочется переезжать, то перенести только почту на другую (где угодно и самую дешевую) vps, где нет таких блокировок. MX запись домена соотв. направить на новый ip Но конечно понадобится еще чтобы почта с сайта уходила через тот ваш smtp. Можно даже установить себе msmtp (или подобный smtp прокси), которая будет ловить всю локально отправляемую почту (по php mail например) и пересылать на указанный smtp с авторизацией. Вот только из-за блокировки вы скорей всего не сможете с ним связаться... я и с таким сталкивался. В таком случае достаточно сменить порт на какой-то нестандартный и все будет работать. Т.е. на почтовой vps открывается 25, 465, 587 как обычно и плюс один нестандартный, по которому будет связь от vps с сайтом. Морока... потому лучше конечно первый вариант. Ну или продолжать требовать от поддержки чтоб разобрались.

Да дело ваше конечно. Если сайт для pagespeed делаете, то ладно. Но выше вон пример как вы чуть не потеряли потенциального клиента, который мог не дождаться 10сек открытия страницы и просто закрыть сайт Повторные заходы да, терпимо. Но если походить по сайту, то много страниц без кэша очень долго генерируются. Главное чтоб не стало только хуже Если это будет 1-2ядерная 2ггц vps

Да есть. Тоже сразу заметил. Не похоже что стоит какой-то кэширующий модуль. Выглядит будто php opcache небольшого размера и многие страницы с "холодным стартом", очень долго генерируются. А повторные уже быстрее... на сколько ~400мс можно назвать быстрым.

У тех кто брал еще вечность не закончилась, пока рано судить.

Если вы утверждаете, что именно хостинг не справляется, так попробуйте на другом. Ну или можно же на нынешнем обратиться в поддержку, показать проблему и спросить их что конкретно оно делает эти 20-60сек.

Поиск всегда надо начинать с логов. Если там есть что-то про memory например, то да, дело в лимитах на память. Например мелкие фотки проходят, а на крупных упирается в ограничения. Но надо смотреть что еще за ошибки есть.

Напишите в поддержку hostpro.ua Боитесь побьют вас или что? Она, поддержка, для того и поддержка. Или в личку. Можно скринами показать что там как, подскажу куда нажать.