ky0

Можно хранить в файловой системе, поддерживающей сжатие на лету.

Вам нужно два локейшена, = / и просто /. Первый будет обрабатывать главную страницу, второй - всё остальное.

Зачем же вы наружу секретные хедеры-то вываливаете? Не надо.

Так же, как и для обычного HTTP.

nginx.org/en/docs/http/websocket.html

Пихаем 8080 порт в proxy_pass нгинкса. IP клиента забираем из X-Real-IP или с помощью модуля realip пихаем в стандартный заголовок.

В вашей конфигурации, если нет других серверных блоков, всё и так будет работать.

Просто надо поменять вот эту кривоту:

location /test1 {
    root /var/www/test1;

location /test2 {
    root /var/www/test2;

на вот такое:

location / {
    root /var/www;

Вы пытаетесь поиспользовать map в качестве if`а - это архитектурно довольно неизящно. Просто разделить обработку доменов на два серверных блока вам по какой-то причине проблематично?

proxy_pass https://www.google.com; - вот так, разумеется, работать не будет. Иначе любой смог бы взять и начать проксировать любые сервисы, сниффя по дороге пароли. Вам нужно, чтобы по урлу /redirect открывалась главная страница Гугла или чего?

Апач тоже работает с FPM или всё-таки с модулем? Если да - дело в настройках PHP.

Если есть реальная необходимость (что бывает, имхо, довольно редко), чтобы работало на нескольких устройствах - распространяйте корневой сертификат, которым подписывали. Но вообще, если устройства не исчисляются десятками - проще добавить в исключения руками.

А вообще - вполне можно тестировать и без шифроавния, добавляя его на этапе публикации в интернет. Ну или, как правильно заметили выше - выпустить валидный сертификат для домена через LE, особенно удобно в этом случае подтверждание через DNS.

СУБД в продакшене лучше не в докер. Ну или хотя бы реплику настройте с автофейловером.

Ну, сравните в консоли, что происходит, когда вы на кнопку нажимаете и когда просто по урлу переходите.

Всё, что после знака вопроса - не часть урла, а параметры. Можно, например, передавать их нгинксу в отдельных заголовках, а внутри него прицеплять к урлу. Никаких экзотических модулей это не потребует.

proxy_pass http(s)://letstt; потому что. Ну и просто писать в серверном блоке listen 443, никак не настраивая потом HTTPS - странно.

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

Ну вон, в последней строке всё отлично описано. Вы отправляете HTTP-запрос без указания метода - любой нормальный веб-сервер на такое, естессна, ответит ошибкой.

Возможно, вдобавок, у вас на сервере как-то неправильно настроена обработка обращений по IP-адресу. А ещё, возможно, ваше ПО ожидает валидного сертификата (который можно получить на доменное имя, а не "11.11.11.1").

Это скорее к настройке сетевой подсистемы ОС (у того же дебиана, например, дефолтные настройки на гигабит не расчитаны), а не к FTP-серверу. Забит-то у вас исходящий канал - а проблемы почему-то со входящим.

Вообще, шейпинг трафика, как уже подсказал Константин, выглядит вполне уместным. Это можно сделать, опять же, на уровне фаерволла ОС.

Ну так не проксируйте с / на ваш бэк, обрабатывайте корень как-то иначе (редирект, возврат кода ошибки). Делов-то.