у меня работает:
Что именно не работает, какая ошибка теперь?
При чем тут забанили ip и конкретно та ошибка несоответствия сертификата? Была бы другая скорей всего.
Нет, я почти уверен что у него в fsockopen версии скрипта вбито с www. Ждем ответа.
Короче я все понял.
Проверил у себя - curl скрипт из первого поста работает нормально даже если не делать CURLOPT_SSL_VERIFYPEER false
И скрипт вида:
<?php$fp = fsockopen("ssl://wood-petr.ru", 443, $errno, $errstr, 30);if (!$fp) { echo "$errstr ($errno)<br />\n";} else { $out = "GET / HTTP/1.1\r\n"; $out .= "Host: wood-petr.ru\r\n"; $out .= "Connection: Close\r\n\r\n"; fwrite($fp, $out); while (!feof($fp)) { echo fgets($fp, 128); } fclose($fp);}?>
также без проблем работает.
Но! Только с доменом wood-petr.ru
Меня потому и раздражают все подобные "шифровальщики" (ну что ты там от кого прячешь, ну...), что говорит тут одно а на деле у себя пробует другое, с маааленьким нюансом. И все должны гадать что не так.
Короче, если запрашивать домен с www. то действительно натыкаемся на ошибку:
А все почему? Потому что вот так через одно место настроен тот wood-petr.ru - при запросе www.wood-petr.ru отдается сертификат от другого food-udm.ru
Я почему сразу спросил проверить работу скрипта на любом другом (нормально настроенном) домене.
Соболезнуем...
Взглянуть бы на все как есть, без секретностей. К какому конкретно домену подключение идет?
В скриптах скорей всего все в норме, но тот домен отдает в своем сертификате другой домен. Но не видя домена, это лишь гадание...
Можно попробовать этим (или curl версией) скриптом другой домен запросить, например searchengines.guru, в сертификате которого проверенно указаны searchengines.guru и *.searchengines.guru
А эти файлы вы хоть не удалили? :)
Их там может быть тьма, разбросанных по всем папкам. Стоило в них всмотреться, найти общие части и поиском по всем файлам поискать такое же.
Главная суть - поймать момент когда произошли изменения и смотреть по логам что происходило, к каким файлам шли запросы и внимательно их изучить. Во-первых нужные это файлы или левые, потом нет ли в нужных файлах левых кусков кода.
Обычно ничего сверъестественного там не бывает, все находится и вычищается, главное внимательность.
У вас есть конкретная дата и время, открываете access.log и смотрите что в это время делал 159.242.228.170
Может к какому-нть xmlrpc.php POST какой-то слал, может еще что-то, к какому-то из файлов среди сайта (возможно это и есть бэкдор). Возможно файл куда он обращался сам по-себе невиновный, но "зараженный" - есть какой-то левый кусок кода в нем (часто через кучу пробелов чтоб не так заметно было)... есть масса возможных вариантов. Собственно я и предлагал же вам изучить активность по логам и найти проблему... бесплатно. Но не хотите - как хотите, смотрите в логах все запросы этого 159.242.228.170 для начала.
Можно и в личку заглянуть для разнообразия.
Если попадать в кэш...
А если нет, то проблема действительно имеется:
Тут же обновляю страницу и уже из кэша совсем другое время ожидания:
А что ping-admin покажет? У вас разве с сетью проблема? Да и какая связь между сайтом хостинга и лично вашей vps'кой... никакой. Сайт хостинга вполне может быть размещен на быстром сервере, а ваша vps на медленном.
Сам сервер медленно генерирует страницы. Никакой litespeed, никакой 10гигабитный интернет канал не спасет. Только кэш-плагин немного скрашивает ситуацию.
Чтоб было быстрей, надо либо меньше cpu работы, либо быстрей cpu (не мощней. больше таких же медленных ядер ничего особо не ускорят). Иначе никак.
