- Поисковые системы
- Практика оптимизации
- Трафик для сайтов
- Монетизация сайтов
- Сайтостроение
- Социальный Маркетинг
- Общение профессионалов
- Биржа и продажа
- Финансовые объявления
- Работа на постоянной основе
- Сайты - покупка, продажа
- Соцсети: страницы, группы, приложения
- Сайты без доменов
- Трафик, тизерная и баннерная реклама
- Продажа, оценка, регистрация доменов
- Ссылки - обмен, покупка, продажа
- Программы и скрипты
- Размещение статей
- Инфопродукты
- Прочие цифровые товары
- Работа и услуги для вебмастера
- Оптимизация, продвижение и аудит
- Ведение рекламных кампаний
- Услуги в области SMM
- Программирование
- Администрирование серверов и сайтов
- Прокси, ВПН, анонимайзеры, IP
- Платное обучение, вебинары
- Регистрация в каталогах
- Копирайтинг, переводы
- Дизайн
- Usability: консультации и аудит
- Изготовление сайтов
- Наполнение сайтов
- Прочие услуги
- Не про работу
В 2023 году Одноклассники пресекли более 9 млн подозрительных входов в учетные записи
И выявили более 7 млн подозрительных пользователей
Оксана Мамчуева
Зачем быть уникальным в мире, где все можно скопировать
Почему так важна уникальность текста и как она влияет на SEO
Ingate Organic
Авторизуйтесь или зарегистрируйтесь, чтобы оставить комментарий
Всем привет!
В одно время сайт атаковали боты, заблочил множество их ip в .htaccess путем добавления записей Require not ip. Из-за чего появилась другая проблема - долгий ответ сервера.
Есть ли какая-то альтернатива Require not ip, сильно не влияющая на скорость загрузки сайта? (сайт на Wordpress)
В одно время сайт атаковали боты, заблочил множество их ip в .htaccess путем добавления записей Require not ip. Из-за чего появилась другая проблема - долгий ответ сервера.
Правильно, потому что при каждом обращении сервер считывает и обрабатывает правила .htaccess, всё это влияет на ответ сервера.
Есть ли какая-то альтернатива Require not ip, сильно не влияющая на скорость загрузки сайта? (сайт на Wordpress)
Да, либо писать собственную обработку на php, либо использовать плагин в виде брэндмауэра, который блокирует IP-ники по заданным правилам.
Реализация на php работает быстрее.
Т.к. htaccess - часть апача, то надо от него уходить ибо:
- апач в принципе небыстрый и
- если перейдешь на чистый хардкор (NGINX) то он просто перестанет работать.
Почему не сделаешь все то же средствами сервера, а именно iptables? Можно сделать и через NGINX , так будет на порядок быстрее.
Реализация на php работает быстрее.
Запустить php и всё причастное, какие-то функции сайта и будет быстрее и легче? Нужны подробности, никогда не проверял.
ТС, у вас какие-то настройки самого сервера не в порядке, либо мощности приближаются к нулю или вы заблочили 10 мб IP. Блокировку по гео, с некоторыми разрешениями, плюс 1000+ cidr не самый мощный тариф шареда потянет легко и без критического замедления.
Запустить php и всё причастное
По сравнению с htaccees - да. При условии что нормально настроено кеширование PHP и MySQL.
По сравнению с htaccees - да. При условии что нормально настроено кеширование PHP и MySQL.
Вот прямо сейчас проверяю на тестовом wp, даже с учетом запуска блокировки до wp не вижу ничего легче и быстрее ( htaccees в два раза выигрывает). Но по позже проверю под нагрузкой побольше.
Если еще подождать кеширование и мускул, будет раз в 10 выигрывать htaccees. Он до, до и до всего стартует в данном случаи.
Мудрость Джедаев - Блокировка в .htaccess быстрее, так как её синтаксический анализ в Apache происходит быстрее, чем процесс PHP. Это связано с тем, что .htaccess выполняется раньше PHP-кодов.
Вот прямо сейчас проверяю на тестовом wp, даже с учетом запуска блокировки до wp не вижу ничего легче и быстрее ( htaccees в два раза выигрывает). Но по позже проверю под нагрузкой побольше.
Если еще подождать кеширование и мускул, будет раз в 10 выигрывать htaccees. Он до, до и до всего стартует в данном случаи.
Мудрость Джедаев - Блокировка в .htaccess быстрее, так как её синтаксический анализ в Apache происходит быстрее, чем процесс PHP. Это связано с тем, что .htaccess выполняется раньше PHP-кодов.
чтение htaccess стартует при запросе каждого запроса. если у вас при отдачи страницы будет десяток файлов стилей, скриптов, еще десяток картинок шаблона... вот столько же раз и будет прочитан этот файл. В среднем если размер htaccess больше 200 кб это уже плохая идея и надо что-то менять. не зависимо от того что там, баны ипов или ручное прописывание 100500 реврайтов.
php + sqlite, с поиском вхождения ипа в диапозоны (с правильными индексами), не зависимо от количества ипов и диапозонов в базе будет мгновенно и легко. у меня так.
php + sqlite, с поиском вхождения ипа в диапозоны (с правильными индексами), не зависимо от количества ипов и диапозонов в базе будет мгновенно и легко. у меня так.
Вот я как раз про индексы и задумался и все описанное вами. Список приготовлю из нескольких тысяч cidr и загружу в базу, проверю на одном сайтике, там us трафик позволяет проверить кучу сеток.
Вот я как раз про индексы и задумался и все описанное вами задумался. Список приготовлю из нескольких тысяч cidr и загружу в базу, проверю на одном сайтике, там us трафик позволяет проверить кучу сеток.
CREATE TABLE IF NOT EXISTS ipv4rules (
ip1 INTEGER NOT NULL default '',
ip2 INTEGER NOT NULL default '',
ban INTEGER NOT NULL default '0'
);");
// индекс:
CREATE INDEX IF NOT EXISTS ipv4range ON ipv4rules (ip1, ip2);
начальный и конечный ип подсети хранить в числовом виде.