Внешний IP у другого компа тот же? Если да, то видимо вы там видите просто кеш.
Меняйте пароли на фтп и админку сайта.
Хотя, если ломают через дыру в одном из плагинов, то это не поможет.
Как временный костыль - можно поставить права 444 на файл, который меняют.
Но все равно нужно искать источник взлома, иначе поменяют другие файлы :)
Я могу ошибаться, но вроде бы ошибка ушла.
Когда я проверял сайт в самом начале темы, то действительно ловил 403 при первом переходе. Сейчас же мне не удается это повторить ни каким образом.
Я конечно не могу видеть полной картины, но спрошу на всякий: serg-smirnoff, вы проверяли логи более свежей даты?
Если всё это возникает в пределах одного впс и главное одной панели управления, то возникает два предположения на выбор:
1) Это глюк. Для некоторых сайтов создались конфиги с каким то багом. Либо, если глючные сайты были последними установленными, то общую конфигурацию шаблонов nginx подпортила установка чего либо в систему.
2) Шаблоны nginx не до конца совместимы с некоторыми движками или с определенными конфигурациями движков.
Попробуйте метод с индексом и юзером. Больше вариантов - пока теряюсь в догадках.
Если не пройдет, то можно попробовать пересоздать аккаунты для этих сайтов.
Попробуйте такой вариант:
После строчки:
location / {
Добавить:
index index.php;
Если не сработало - попробуйте на всякий перенести новую строчку в конец этого же блока условия корневой локации.
Например после строчки: proxy_set_header X-Real-IP $remote_addr;
т.е. получится так:
proxy_set_header X-Real-IP $remote_addr;
}
Суть операции. Основываясь на жалобах лога апаче, что он не желает выдавать листинг директории, так как это ему не разрешено. Делаем вывод, что иногда nginx почему то не запрашивает индексный файл, обращаясь просто за листингом в корневую папку. А поскольку в представленном конфиге nginx я не вижу явного указания на стартовый файл, то пробуем указать ему его принудительно.
Еще можно попробовать сменить пользователя www-data на того же, что в апаче. Но это в последнюю очередь.
Это не мое утверждение было, я всего-лишь пояснил подробнее принцип его действия.
Да и потом, чтобы знать сколько народу забанено в конкретном месте, нужно быть там админом.
Сисадмин ресурса может использовать любые типы защиты и их комбинации, в зависимости от того, что требуется.
А поскольку мы не знаем о каком месте вообще идет речь, то можно только гадать и каждое предположение может быть по умолчанию верным, пока не доказано обратное методом проверки, либо заведомо известной информацией от тех, кто проверял.
Да, это означает, что некоторые ip уже в бане.
Это вполне реально, вы же не думаете, что вы единственный в мире, кто знает и использует ТОР?:)
А, это уже другой разговор. Всё нужно вытягивать клещами.
Тогда понятно, почему от .htaccess никакого эффекта.
Из чего следует, что вероятно виноват конфиг nginx. Так что нужно смотреть его логи и конфиг.
Для начала можно проверить права на корневую папку сайта, поставить 755. Затем проверить от какого юзера работает nginx и убедится, что этот юзер имеет доступ.
Например IP из китая, а в регистрации на сайте локация сша или еще какая другая.
В поводе для бана может много разных критериев быть.
Ставить 301й редирект сразу - не советую.
Сначала лучше сделать старый домен алиасом, а на новом указать в robots.txt главный домен, согласно директивам Яндекс. Далее подождать пока переиндексируется и Яша будет считать главным новый домен, а старый зеркалом. Затем уже сделать 301 редирект, чтобы и гугл переключился.
Почему: исхожу из личного опыта. Когда делаю сразу 301й редирект, почему то сначала вылетает надолго из индекса Яши. Так что если желаете перестраховаться ... .
Видимо ломится "на скорую руку" туда, где продумали систему защиты. Возможно что-то популярное.
Скорее всего палится на чем-то другом. Это могут быть даже вводимые данные и(или) схожесть действий.
