Уж не знаю чем полюбил один из моих проектов робот MegaIndex но сообщения о блокировке «На сайте …..ru посетитель превысил установленный лимит активности.» уже сильно притомили.
Если учесть, что Мегаиндек это даже не поисковик, и данные собираются роботом только для работы линк-биржи я решил полностью блокировать этого робота.
А представляется он следующим образом:
«UserAgent — Mozilla/5.0 (compatible; MegaIndex.ru/2.0; +https://www.megaindex.ru/?tab=linkAnalyze)»
Соответственно, добавляем в nginx правило
if ($http_user_agent ~ "megaindex") {
return 503;
}
и вуаля, проверочный get запрос с UserAgent Мегаиндекса отдаёт 503ю
ч.т.д.

Новая задачка — клиент подключает на свой сайт Яндекс.Кассу, а там очень настойчиво рекомендуют для взаимодействия использовать шифрованный протокол https.
Ранее с https я лично не сталкивался (вернее сталкивался но только сугубо в роли пользователя)…
Собственно, живём в замечательную эру веб-технологий — нарыл пару отличных статеек (ссылки внизу).
Если в 2х словах — настраиваем nginx на 443 порт и на этом вроде бы всё — на https запрос сайт отвечает, динамику отдаёт, но нет!
При использовании сгенерированного собственноручно сертификата в разных браузерах получаем ругательные ошибки на соединение:

Mozilla Firefox «Это соединение является недоверенным»

google chrome «ошибка нарушения конфиденциальности»

яндекс браузер «Сертификат сайта не является доверенным»,

opera «ошибочный сертификат»

Internet Exploret ЭОшибка в сертификате безопасности этого веб-узла.»

Ответ прост — всем им не понравился мой сертификат, и правильно, ведь я его сам и сделал.
Чтобы подобных предупреждений не было — сертификат нужно приобрести в авторизованных сертификационных центрах. Для шифрования и простой проверки домена (Domain Validation, DV) достаточно базового уровня — и такой сертификат можно получить бесплатно в StartSSL.

P.S.
Плюсом добавлю, что Гугл заявлял о том, что в скором времени защищённость соединения будет положительно учитываться в ранжиновании сайтов для поисковой выдачи.

На этом всё, подробнее в исходных статьях:
1. SSL (https) в Nginx — настраиваем NGINX
2. SSL сертификат для сайта — для чего он нужен и где его взять — тут введение о сертификатах
3. Получаем бесплатный SSL сертификат — тут подробнее о получении бесплатного сертификата

Тузла для проверки SSL сертификата сайта, на примере mega-moda.ru

Довольно часто приходиться использовать редиректы, и правильнее всего это реализовывать конечно же в фронтенде — то есть средствами NGINX,
а в идеале вообще отказаться от использования htaccess или вообще от аппача — значительно ускорим работу сайта.

И первой же проблемой после этого встаёт реализация всех редиректов ранее работающих в .htaccess
Ну или просто нужно какой нить редирект сделать … делаем его в nginx!

Здесь для себя решил собрать в кучку некоторые используемые мною редиректы.

1. Перенаправление после включения режима ЧПУ
Довольно востребованное т.к. адреса страниц меняются и на работающем проекте это череповато потерей посетителей (в поисковиках старый адрес, а на сайте уже новый).
Лично у меня это часть ТЗ для сайта на платформе 1С Битрикс — только что врубил ЧПУ и нужно было настроить редирект со старых на новые странички.
Редирект из разряда сложных т.к. условие находится в переменных GET запроса и сделать Location по этому условию непонятно как
/dir/?ELEMENT_ID=777 на /dir/777/

моё решение (несколько напрягает присутствие if — конфиг nginx с условием заведомо считается неудачным, но как по-другому я не нашел ):
location ~ /dir/ {
if ( $args ~* (.*)ELEMENT_ID=(.*) )
{
set $element_id $2;
set $args '';
rewrite ^(.*)$ /dir/$ELEMENT_ID/ permanent;
}
proxy_pass $proxyserver;
}

2. 301й редирект с сайта с www на сайт без www или наоборот
Реализуется на уровне директивы server
server {
listen 80;
server_name site.ru;
rewrite ^ http://www.site.ru$request_uri? permanent;
}

server {
listen 80;
server_name www.site.ru;
.
.
.


3. Редирект с конкретной страницы на конкретную страницу

location = /price.html { rewrite ^(.*)$ /price.php; }


4. Редирект по условию с передачей переменной /obl/777/ на /obl.php?obl_idx=777

location /obl/ { rewrite /obl\/(.*)$ /obl.php?obl_idx=$1; }

5. Редирект всех несуществующих файлов на index.php (такой редирект пригодится для многих CMS например Joomla)

location / {
try_files $uri $uri/ /index.php$is_args$args;
}

location ~ \.php$ {
fastcgi_index index.php;
include fastcgi_params;
.
.

Итак, очередное ТЗ — реализовать систему откатов для людей порекомендовавших покупателям интернет-магазина медицинских товаров для реабилитации (в моём случае это как правило врачи).
Такая система присутствует в редакции Бизнес, но не каждый начинающий магазин может это дело сразу потянуть т.к. разница в ценнике ровно 2 раза (Бизнес на текущий момент 66 т.р.).
А реализуется необходимый минимальный функционал довольно просто.
Вот как это сделал я:
1. Создаём группу Врачи (присваивать в эту группу будем сами).
2. Создаём скидочный купон, например 1234-1234 и такой же купон прописываем врачу (я прописал в рабочий пейджер — т.к. явно поле неиспользуемое)
3. Раздаём купоны покупателям, теперь при совершении покупки номер купона прописывается в заказ
4. Выводим Врачу информацию о заказах с использованием их купона (позже прикручу фильтра и т.д.)

Итак, тормоза «нагнули» сервак — поисковые роботы и прочая нечисть создаёт очень нехилую нагрузку, с которой в последнее время серваку справляться всё труднее и труднее, а последние дни сообщения о недоступности сайтов просто поставили вопрос ребром.
Специфика некоторых моих проектов это несколько тысяч справочных файлов, и всё это реализовано на связке nginx + apache.
После изучения нескольких хороших статеек (в конце поста приведу ссылки) и неудачной попытки задействовать кэширование NGINX (разбираться с этим не стал, т.к. нашел более правильное решение проблемы) я понял, что самые тормоза — из-за allow override индейца! без которого реврайты htaccess не работают. Собственно, при любом обращении к сайту индеец перечитывает всю файловую структуру — а это с моими тысячами файлов — полная засада. Умножаем количество запросов на несколько десятков в минуту — получаем ступор всего сервака.
Единственное правильное решение — переход на fastcgi, в лице php-fpm, который не обрабатывает htaccess (при этом все правила переносятся «руками» на уровень фронтенда т.е. nginx сервера).
Правда и тут не без подводных камней — немного пришлось переписать движек сайтов т.к. реврайт nginx-a несколько другой по сравнению с реврайтом на htaccess в плане передачи заголовков php.
Тут большое спасибо ребятам с форума php.ru за помощь в моей ветке.
При обработке текущего положения нужно использовать ТОЛЬКО параметр REQUEST_URI — остальные, по крайней мере у меня, не передаются! вернее передаётся фактический обработчик index.php

После перехода на Fast-CGI страничка начала отдаваться где то в 20 раз быстрее, и нагрузка на сервер спала пропорционально. Сообщения о недоступности сайтов сошли на нет.

Цель достигнута!

Хорошие статейки:
Почему NginX с Fast-CGI быстрее, чем Apache с mod_php?
Попытка номер раз создать почти идеальный htaccess
Один конфиг Nginx для работы с кучей разных сайтов
Установка nginx, php-fpm и mysql на CentOS
ngin+php-fpm делаем веб-сервер под высокую нагрузку

Отдельно выделю очень хорошую статью на счёт кэширования nginx
у меня вроде завелось, но почему-то через часок другой, решение падало — может файла слишком у меня много — незнаю, но статья отличная — факт.

Прозрачное кэширование в nginx для всех и каждого

P.S. Ещё 2 проблемы было — не передавался GET в несуществующий php и не уходила почта
первое решилось добалением $is_args$args; в try_files
try_files $uri /index.php$is_args$args;
второе — указание sendmail_path в php-fpm.conf (сразу там до кучи путь для сессий поправил)