К сожалению по метрике невозможно определить ip, можно только аномалии прослеживать. Вот Ingvarr по вебвизору клики отслеживает, он и определил этого говнопровайдера. К сожалению без работы с лог-файлами развернутый анализ провести сложно, а определить ip гадящих невозможно. Ну по крайней мере я не знаю как это можно сделать.
Проблемы индейцев остаются проблемами индейцев. Вот в случае попадания в этот анус гуглу будет крайне сложно доказать, что ты добропорядочный самаритянин. И смотря на поведение различных ботов на сайте понимаешь, что не такие они и тупые, совершенствуются - твари.
Зайдите по ssh можно при помощи putty и введите указанные строки. В Вашем случае необходимо анализировать лог файлы. И постараться понять, кто конкретно занимается паразитированием.
В htaccess не блокировал, но тоже все просто.
Order Deny,Allow
Deny from 83.97.119.0/24
...
Списано 2,01%---------- Добавлено 01.06.2019 в 17:38 ----------
Анализируйте трафик.
В консоли:
iptables -A INPUT -s 91.214.78.0/24 -j DROP;
iptables -A INPUT -s 77.91.72.0/24 -j DROP;
iptables -A INPUT -s 77.91.111.0/24 -j DROP;
iptables -A INPUT -s 77.91.124.0/24 -j DROP;
iptables -A INPUT -s 178.20.28.0/24 -j DROP;
iptables -A INPUT -s 178.20.29.0/24 -j DROP;
iptables -A INPUT -s 178.20.30.0/24 -j DROP;
iptables -A INPUT -s 178.20.31.0/24 -j DROP;
iptables -A INPUT -s 83.97.116.0/24 -j DROP;
iptables -A INPUT -s 83.97.117.0/24 -j DROP;
iptables -A INPUT -s 83.97.118.0/24 -j DROP;
iptables -A INPUT -s 83.97.119.0/24 -j DROP;
Если используете ispmanager, то можно прямо в его брандмауэре, указанные подсетки заблокировать.
От беды подальше, хоть пока и без прецедентов, заблокировал подсетки "разоблаченные" Вами. Как говаривал Абдулов "в месте встречи изменить нельзя" - береженого бог бережет))
Еще вопрос к специалистам, предложенная выше в теме конструкция работает, но с некоторыми, непонятными ограничениями или лучше сказать нюансами.
В секции http
map $http_user_agent $bad_useragent {
default 0;
"Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:29.0) Gecko/20100101 Firefox/29.0" 1;
}
В секции server
if ($bad_useragent) {
return 444;
В этом случае, если заход с указанным в правиле useragent по протоколу HTTP/1.1, то все отрабатывает правильно, если же по протоколу HTTP/1.0, с этим же useragent то отдается ответ 200, не могу понять почему? То есть один и тот же ip (с прописанным в правиле ограничением в виде useragent ) обращается к одной и той же странице по разным протоколам и в одном случае он фильтруется на 444, в другом ему отдается ответ 200. Почему существует такой костыль и как его обойти? Нужно, чтобы независимо от того по какому протоколу обращается клиент с указанным в правиле useragent он получал ответ 444.
Не хуже и не лучше чем всегда, что, впрочем, в сегодняшних реалиях пожалуй жирный плюс. Хочется надеяться, что гугл классифицирует сайты, как сдл и осыплет благодатью, за многолетний и упорный труд. ))
Первое, внимательно проверьте pub , второе, написано, что возможно кратковременное пропадание рекламы. Не следует убирать редирект, это не из-за него. У меня также переадресует с http на https и все работает.
Читайте внимательно, я не писал о появлении предупреждения, а лишь о возможности увеличения заработка в связи с заливкой данного файла.
Пс думаю очень скоро у всех в аккаунтах появится такое предупреждение. Если Гугл решил, что-то сделать, то он это сделает. Хуавей - аминь.
