Михаил Григорьев

Если я правильно понял вашу хотелку, то может так:

...
        location /aaaa {
                root /var/www/aaaa;
                index index.php index.html index.htm;
                location ~ (.+\.php)$ {
                       try_files $uri = 404;
                       root /var/www/aaaa/;
                       include /etc/nginx/fastcgi_params;
                       fastcgi_pass unix:/var/lib/php5-fpm/aaaa.sock;
                       fastcgi_index index.php;
                       fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
                }
        }
...

Думаю Алексей Виноградов хочет сделать красивый конфиг nginx для работы WP Super Cache без горы if, как во многих статьях типа этой, что похвально, т.к. If is Evil

Но судя по всему в map у nginx для нескольких значений регулярка не работает, поэтому ни так ~* ни так ~(.*) и ни так ~^(.*)$ работать не будет.

Но я бы позвал сюда эксперта по nginx, чтобы он авторитетно либо подтвердил мою догадку, либо опроверг.

1. Постоянный редирект с / на index.php

location = / {
        rewrite ^ $scheme://$host/index.php permanent;
    }

    location / {
        deny all;
        return 404;
    }
    location ~* ^/index\.php$ {
        try_files $uri $uri/ =404;
        fastcgi_index index.php;
        fastcgi_pass php5-fpm-sock;
        fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
        include /etc/nginx/fastcgi_params;
    }

Очень странная логика, особенно использование $host и некорректное использование try_files. Про try_files почитайте тут.

$host
в порядке приоритета: имя хоста из строки запроса, или имя хоста из поля “Host” заголовка запроса, или имя сервера, соответствующего запросу

Если у вас не определен default_server и server_name site.ru; стоит первым в списке, то к вам будут прилетать все запросы с любым полем Host, в том числе пустым, что является очень опасной практикой.
Лучше использовать переменную $server_name, но все равно, если вам нужно обращения по любым url обрабатывать только через index.php, то правильно это делается так:

/NONEXISTENTFILE меняете на заранее фейковый файл который не может существовать, например /d7sdhsdhsdf8sfhgsfd8fh438dfjh

...
        error_page 404 = @cms;

        location / {
            try_files /NONEXISTENTFILE @cms;
        }

        location @cms {
                fastcgi_pass      unix:/var/lib/php5-fpm/xxxxx.sock;
                fastcgi_index    index.php;
                fastcgi_param   SCRIPT_FILENAME $document_root/index.php;
                fastcgi_param   SCRIPT_NAME /index.php;
                include             /etc/nginx/fastcgi_params;
        }
...

2. Запрещаем любую статику кроме gif|jpg|png|js|css|ttf|woff|ico

location ~* \.(gif|jpg|png|js|css|ttf|woff|ico)$ {
        try_files $uri =404;
        expires 30d;
    }

Логичнее и правильнее будет сделать так:

try_files $uri =404; нам не понадобится, т.к. у нас есть error_page 404 = @cms; который в случае отсутствия картинки перенаправит запрос в @cms

...
        error_page 404 = @cms;

        location ~* ^.+\.(gif|jpg|png|js|css|ttf|woff|ico)$ {
                expires 30d;
                access_log off;
                log_not_found off;
        }

        location / {
            try_files /NONEXISTENTFILE @cms;
        }
...

По поводу json.php и в принципе ограничения доступа, правильнее делать это через map или geo, например так:

http {
....
        geo $my_client_ip $denied {
                default 1;
                127.0.0.1 0;
                XX.XX.XX.XX 0; # <- IP1 с которого можно заходить
                YY.YY.YY.YY 0;    # <- IP2 с которого можно заходить
        }

server {
        listen       443 ssl;
        server_name  site.ru;
        root         /var/www/html/;
...
        set $my_client_ip $remote_addr;
        if ($http_x_forwarded_client_ip ~ "\d{1,3}\.\d{1,3}\.\d{1,3}\.\d{1,3}") {
                set $my_client_ip $http_x_forwarded_client_ip;
        }

        error_page 403 = @deny;

        location @deny {
                root /var/www/deny;
                rewrite ^(.*)$ /index.html break;
        }

        location ~* ^/json\.php$ {
                if ($denied) {
                        return 403;
                }
                try_files /NONEXISTENTFILE @json;
        }

        location @json {
                try_files       $uri = 404;
                fastcgi_pass    unix:/var/lib/php5-fpm/xxxxx.sock;
                fastcgi_index   index.php;
                fastcgi_param   SCRIPT_FILENAME $document_root$fastcgi_script_name;
                include         /etc/nginx/fastcgi_params;
        }

}
}

4. Разрешаем доступ к /admin только с 1-го IP, для /admin/phpmyadmin

Не делайте так! Организуйте для phpMyAdmin отдельный поддомен с отдельным виртуальным сервером и отдельной обработкой php5-fpm через отдельный сокет.
Никогда не храните "левые" (вспомогательные) утилиты в общем каталоге web-приложения, это плохая практика. К примеру: Если в phpMyAdmin будет найдена критическая уязвимость, то даже в случае ограничения доступа к нему с определенного IP существует вероятность, что она может быть проэксплуатирована и тогда через неё поломают ваше web-приложение - оно вам нужно?

По поводу location ~* /admin/ аналогично как для json.php.

Ну и все рекомендации выше от Кирилл Несмеянов относительно hsts, ssl, ciphers, dh, ocsp stapling поддерживаю.

В контексте выданного SQL запроса конечно сложно предположить, что может быть не так, Вы бы хоть сказали сколько сотен или тысяч записей он выдает.

Для начала попробуй выставить UniDirectional в true

Вообще если честно, то блокировка админки WordPress базовой аутентификацией или смена её местоположения - это глупость.
Куда надежнее использовать двух факторную аутентификацию, fail2ban для блокировки попыток доступа к админке с ошибочными паролями, обязательно HTTPS и конечно же самое главное - надежные пароли.

Скорее всего подибась какая-то таблица.

Добавьте опцию log_error в секцию mysqld в файл конфигурации /etc/mysql/my.cnf (если её там нет), возможно файл будет другой, например

[mysqld]
...
log_error = /var/log/mysql_error.log
...

и перезапустите maria

systemctl restart mariadb.service

потом смотрите лог на предмет ошибок

Для понимания принципов того как правильно хранить большие объемы в БД, рекомендую ознакомиться с хорошей статьей Масштабирование базы данных через шардирование и п...

Если Вы уверены, что Web-приложение справляется с нагрузкой, то возможно на балансировщике стоит увеличить таймауты, добавьте в location /

proxy_connect_timeout 120s;
proxy_send_timeout 120s;
proxy_read_timeout 120s;

На 3-х вебсерверах если Вы используете php-fpm то лучше работать через unix-сокеты, а не через tcp, через сокеты будет быстрее.

Возможно стоит посмотреть в сторону параметра least_conn в upstream, то есть запросы сначала будут отправляются бэкенду с наименьшим количеством активных подключений (но с учетом весов). Подробнее тут.
Если какой-то бэкенд мощнее других, то используйте определение веса через weight
Так же настройте директивы max_fails и fail_timeout в блоке upstream (в моем примере ниже параметры проставлены для примера).

Так же включите логи на балансировщике, это сильно упростит отладку:

http {
    ...
    log_format upstream_log '[$time_local] $remote_addr - $remote_user - $server_name to: $upstream_addr: $request upstream_response_time $upstream_response_time msec $msec request_time $request_time';

upstream servers {
                least_conn;
                server ip1;
                server ip2 max_fails=3 fail_timeout=30s;
                server ip3 max_fails=5 fail_timeout=30s;
                keepalive 16;
        }

server {
                listen 80;
                access_log /var/log/nginx/servers-access.log upstream_log;
                error_log /var/log/nginx/servers-error.log debug;

                location / {
                        proxy_pass http://servers;
                        proxy_http_version 1.1;
                        proxy_set_header Connection "";
                        proxy_connect_timeout 120s;
                        proxy_send_timeout 120s;
                        proxy_read_timeout 120s;
        }
}

git-secret.io или https://www.agwa.name/projects/git-crypt/ вам в помощь

Если ПК не в домене АД, то импортировать серитификаты можно с помощью утилиты certutil.exe (в архиве 2 версии утилиты, эта утилита входит в состав CryptoPro и WindowsSDK)

certutil.exe -f -user -addstore Root myROOTcertFile.cer

или

certutil.exe -f -user -addstore CA myCAcertFile.cer

1. Percona Server for MySQL, кое где MariaDB
2. Отличия в работе есть и колоcсальные если сравнивать с MySQL от Oracle
3. Разница будет, опять же если сравнивать с MySQL от Oracle. MariaDB и Percona сложнее сравнить, но тоже есть плюсы и минусы, все зависит от задач.

Что мешает обратиться к официальной документации с примерами настроек, а не городить огород?

https://github.com/ONLYOFFICE/document-server-prox...

У меня в одном проекте проксирование HTTPS-to-HTTPS на Nginx настроено так:

http {

        # Websocket
        map $http_upgrade $connection_upgrade {
                default upgrade;
                ''      close;
        }

server {
...  
          lingering_time 86400;
          proxy_ssl_verify off;
          proxy_ssl_session_reuse on;
          proxy_ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
          proxy_cache off;
          proxy_store off;

          set $ssl off;
          set $port 80;
          if ($scheme = https) {
              set $ssl on;
              set $port 443;
          }

        location / {
            proxy_pass https://192.168.XX.XX:8443/;
            gzip off;
            proxy_read_timeout          600s;
            proxy_connect_timeout       600s;
            proxy_redirect              off;
            proxy_buffering             off;
            proxy_request_buffering     off;
            proxy_http_version          1.1;
            proxy_set_header Host                   $http_host;
            proxy_set_header X-Real-IP              $remote_addr;
            proxy_set_header X-Forwarded-Ssl        $ssl;
            proxy_set_header X-Forwarded-For        $proxy_add_x_forwarded_for;
            proxy_set_header X-Forwarded-Proto      $scheme;
            proxy_set_header X-Forwarded-Port       $port;
            proxy_set_header X-Frame-Options        SAMEORIGIN;
            proxy_set_header Upgrade                $http_upgrade;
            proxy_set_header Connection             $connection_upgrade;
            proxy_set_header Referer "";
        }
}
}

Госпиди:
select user_id from order where status_id = '0';

или

select user_id from order where status_id = '1';

1. Для понимания того как Nginx обрабатывает запросы обязательно почитайте это
2. Так же обязательно определите default_server, например в файле /etc/nginx/conf.d/fallback.conf (путь может меняться, см. include в nginx.conf) можно написать:

server {
        listen XX.XX.XX.XX:80 default_server;
        server_name _;
        return 444;
}

default_server пригодиться для обработки неправильных запросов, например запросов без поля "Host"
В моем примере чуть выше nginx просто будет закрывать соединение для таких запросов, для этого служит спец. код 444.

Причин появления ошибки No input file specified несколько:
1. У вас не установлена переменная SCRIPT_FILENAME в конфиге nginx;
2. Задан неправильный аргумент root в конфиге nginx;
3. Переменная open_basedir в /etc/php5/fpm/php.ini или в конфиге php5-fpm пула содержит путь, который не соответствует аргументу root в конфиге nginx;
4. Пользователь с правами которого работает php5-fpm или конкретный пул php5-fpm не имеет прав доступа к каталогу или файлу с php-скриптом;

Пример правильного конфига nginx + php5-fpm:

server {
....
root /var/www/mysite.com;
index index.php index.html index.htm;

location / {
        try_files $uri $uri/ =404;
}
location ~ \.php$ {
        try_files $uri = 404;
        fastcgi_pass unix:/var/lib/php5-fpm/mysite.sock;
        fastcgi_index index.php;
        fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
        include /etc/nginx/fastcgi_params;
}
...
}