Борис Сёмов

Надо создать второй виртуальный хост в apache, и в нём настроить reverse proxy. https://httpd.apache.org/docs/2.4/howto/reverse_pr...

Зачем вам Hyper-V? Лишние накладные расходы на ровном месте.

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

А вот проблема у вас, вероятнее, не в CLOSE_WAIT, всё же, и не в сетевом стеке, а в том, что все процессы апача заняты обработкой существующих запросов, т.е. отдачей ваших аудио данных. И лучше бы это делать не с помощью Apache вовсе.

Ошибка 324 это пустой ответ от сервера, вероятно? Да, тогда связано.

Signal 7 это SIGBUS, чаще всего это проблемы с доступом к памяти. Может вызываться и проблемами железа, и ошибками в софте. Ну и не важно сколько той памяти - это не проблема с её объёмом - это проблема что что-то не по тем адресам обращается.

Чтобы побороться, стоит попробовать обновить серверное ПО для начала.
Если проблема не уйдёт, попробовать отключить opcache, и если поможет поиграться с его настройками.
Если проблема не решится, локализовать при каких запросах она возникает и посмотреть, какие расширения или внешние программы вызываются (обычно именно в таких сценариях вылезает такое). Также, можно установить ПО с отладочными символами, включить снятие дампов и проанализировать их, чтобы получить дополнительную информацию.

Если у вас nginx висит на 8080, то и сайт придётся открывать на sitename.tld:8080
А если так не работает, проверьте, а не закрыт-ли порт 8080 снаружи фаерволом.

Перед апачем стоит поставить nginx, как reverse-proxy, чтобы процессов апача стало меньше.
Проверить установлен-ли кешер опкода php, и достаточно-ли ему выделено памяти.
Если приложение может работать под php 7+ убедиться что он и используется.
Посмотреть настроен-ли ваш сервер БД, под ваш проект.

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

Не с помощью самого апача.
Если не обрабатываются скрипты на других языках, то да.
Можно загрузить, но напрямую выполнить нельзя. Потенциально, можно через дыру в других скриптах выполнить.

Можно. На вкладке "сеть" при повторных запросах будет код состояния не 200, а 304 (Not Modified) для этих файлов.

Если у вас php-fpm слушает сокет, то зачем пытаться к нему подключаться по tcp, да ещё и на 127.0.0.1?

Либо надо чтобы сокет был доступен где-то снаружи, и его использовать, либо надо использовать сеть докера и подключаться по tcp используя адреса внутри неё.

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

Я думаю, ваша ошибка о превышении количества обработчиков не связана с проблемой, которую вы пытаетесь решить. На это намекает "ERR_CONTENT_DECODING_FAILED". Вот тут, например почитайте в конце: https://dev.1c-bitrix.ru/support/forum/forum32/top...

MaxRequestsPerChild ставить не стоит - лучше где-то 500-1000(это количество запросов, которые последовательно обрабатывает один процесс-обработчик, прежде чем будет перезапущен, и ограничивается он для борьбы с утечками памяти).

MaxClients выставлять больше чем ServerLimit нет смысла. И то, и другое нельзя выставлять слишком большим - у вас должно хватать памяти на то, чтобы запустить столько процессов, и чтобы остальной софт на сервере тоже мог работать. Если количество процессов будет слишком большим, это может быть хуже, чем их недостаток...

Зачем вам на малинке, где и так ресурсов не много, какая-то панелька вообще? (тем более Webmin + Virtualmin это ужас).
Также, разумнее будет использовать nginx + php-fpm, а не apache, из тех же соображений.
Для работы с mysql лучше использовать какой-нибудь mysql клиент через ssh, например, heidisql, или вообще использовать консольный клиент.
Тупит, потому, что с производительностью, мягко скажем, не очень, а при повторном обращении что-то закешировано уже.

Добавить второе условие:
RewriteCond %{REQUEST_URI} !^/page1$

Про врождённое ограничение php на размер загрузки выше писали. Для обхода используйте, например, nginx upload, или аналогичный модуль, для своего любимого веб сервера, а потом в скрипте уже просто обрабатывайте по необходимости загруженное.

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

Банально настроить максимальное количество «деток», согласно вашим ресурсам.
Если у вас разрастается сами процессы, что вряд-ли — надо искать причину, т.к. это не нормально, и надо не городить костыли, а решать проблему.

По поводу мониторинга и процессов по ресурсам/наличию/работоспособности, и их запуска/перезапуска/алертов, посмотрите monit, но это надо делать не вместо решения проблемы, а как «вариант на всякий случай» для повышения надёжности.

Настроить proxy_cache для статики. И она начнёт отдаваться со второго запроса с фронтэнда, без дополнительных ухищрений.