Новый виртуальный хост на apache возвращает vhost по умолчанию, в других случаях возвращает обычный контент

У меня действительно странное поведение на одном из серверов Debian. При запросе stuff.com (пример) или stuff.com/image.jpg, скажем, 50% раз я имею правильный ответ, другие 50% раз я имею 404, в случае изображения, если я запрашиваю обычный HTML-файл я получаю страницу по умолчанию apache.

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

Virtual Host Config:

<VirtualHost *:80>
       ServerAdmin webmaster@localhost
       ServerName stuff.com
       DocumentRoot /var/www/html/stuff/stuff-test
       <Directory /var/www/html/stuff/stuff-test >

       Options -Indexes +FollowSymLinks
       AllowOverride All
       Require all granted

       </Directory>
       ErrorLog /var/log/apache2/stuff/stuff/error.log
       CustomLog /var/log/apache2/stuff/stuff/access.log combined

</VirtualHost>

Default config:

<VirtualHost *:80>
        ServerAdmin webmaster@localhost
        DocumentRoot /var/www/html

        ErrorLog ${APACHE_LOG_DIR}/error.log
        CustomLog ${APACHE_LOG_DIR}/access.log combined
</VirtualHost>

Это был сложный сайт, созданный с помощью Symfony, поэтому я подумал, что он может быть связан с этим, поэтому установлен на другом сервере и все работает. Затем мы начали вырубать еще больше наших возможностей, и теперь у нас есть только index.html и image.jpg в папке, и это все равно происходит то же самое.

Мы пробовали все, кроме перезапуска Apache с перезапуском service apache2, мы обычно используем перезагрузку.

Следует отметить, что на этом сервере настроено 97 виртуальных хостов, мы увеличили уровень всех журналов, apache (до trace8), на рассматриваемом виртуальном хосте и на виртуальном хосте по умолчанию.

Мы также проверили dmesg ,/var/log/messages ,/var/log/kern.log ,/var/log/syslog.

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

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

На сервере ничего не менялось (последнее изменение было 3 декабря), ни обновления программного обеспечения, ни перезапуска, ничего.

Мы собираемся перезапустить apache сегодня вечером, не хочу рисковать перезапуском apache в течение дня и внезапно все сайты падают. И посмотрите, что будет.

Кто-нибудь имеет представление?

Вещи, которые мы проверили, не по специальному заказу:

• Перезапущен php-fpm, но это происходит при запросе одного файла или файла * .html, так что это не оттуда.
• Проверили ulimit, чтобы убедиться, что все в порядке, и мы не достигли предела. - Проверял каждый файл журнала, который мы могли найти, который мог указывать где угодно и не мог ничего найти.

Версии программного обеспечения: Debian: 10,2

Apache: Apache/2.4.38 (Debian)

PHP: 7,2,34 (не то, чтобы это имело значение)

Этот вопрос был вызван этим потоком

Гипотетический сценарий для контекста таков:

1. SSH-серверы, независимо от того, являются ли они маршрутизаторами, брандмауэрами и т.д., сначала конфигурируются в частной + безопасной среде перед развертыванием. Ключи SSH генерируются локально на сервере в этой среде.
2. Серверы SSH имеют собственные списки ACL для отказа в подключении от чего-либо, кроме наших хостов
3. Хост-машина будет представлять собой машину Linux с несколькими пользователями

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

1. Во время работы в безопасной среде и после конфигурирования импортируйте идентификационный код RSA сервера в контейнер известных _ хостов нашего хост-компьютера (или где бы он ни хранился, я еще не слишком знаком с Linux) использование ssh-keyscan -H x.x.x.x > > ~/.ssh/knowledge _ hosts

2. Общий доступ/зеркальное отображение этого контейнера идентификационных данных RSA для всех пользователей на этой хост-машине

3. Настройте узел/каждого пользователя на отклонение/удаление/отказ от подключения при наличии следующей подсказки, чтобы

Аутентичность хоста Отпечаток ключа RSA - [отпечаток ключа]. Вы действительно хотите продолжить подключение (да/нет)?

4. Они не могут подключиться к серверу, который не прошел эту процедуру, тогда
5. Возможно, создайте изолированного отдельного пользователя для случаев, когда эти вышеупомянутые процессы + ограничения не могут быть реализованы, но там, где все еще требуется удаленная конфигурация, чтобы основные более часто используемые пароли не были скомпрометированы поддельным SSH-сервером.