Два веб-сервера в одной локальной сети, на которых работают apache2 и nginx соответственно, под одним IP-адресом WAN — подключение к правильному серверу по (суб) доменному имени

У меня есть два физических сервера, работающих в одной локальной сети. Оба работают с веб-серверами; на одном работает apache2, на другом nginx. Каждый из них имеет другое доменное имя, но один и тот же внешний IP-адрес WAN. Допустим, схема сети выглядит так:

                глобальная сеть
            20.10.30.40
      |----------|----------|
      | |
   Домен 1 Домен 2
примерABC.com (суб.)exampleXYZ.com
      | |
      |----------|----------|
                 |
            Единая локальная сеть
                 |
      |----------|----------|
      | |
  IP-адрес 1 IP-адрес 2
192.168.0.10 192.168.0.20
      | |
      | |
  Сервер 1 Сервер 2
   апач2 нгинкс

Сервер apache2 принадлежит мне, а сервер nginx — нет. Оба сервера имеют выделенные поддомены для каждой службы, которую они предоставляют — например, (www.)exampleABC.com для главной веб-страницы, cloud.exampleXYZ.com для облачной службы с обратным прокси, media.exampleXYZ.com для мультимедиа и т. д.

По неизвестным причинам сервер nginx имеет приоритет при подключении к IP-адресу WAN — изначально оба домена будут вести к главной веб-странице, размещенной на nginx, но со следующей (текущей) конфигурацией nginx exampleABC.com будет правильно вести к сервер apache2, а exampleXYZ.com продолжает вести к серверу nginx.

сервер {
    слушать 80;

    # слушать на всех поддоменах
    имя_сервера exampleABC.com *.exampleABC.com;
    
    место расположения / {
        # прозрачный прокси на другой сервер (порт 443)
        прокси_пасс http://192.168.0.10:80;

        # установить заголовок "Host", передаваемый другому серверу, на полное доменное имя, запрошенное клиентом, чтобы другой сервер знал, какой субдомен запрашивается
        proxy_set_header Хост $http_host;
    }
}

сервер {
    слушать 443 ssl;

    имя_сервера exampleABC.com *.exampleABC.com;
    
    место расположения / {
        прокси_пароль https://192.168.0.10:443;
        proxy_set_header Хост $http_host;
    }
}

Однако поддомены, размещенные на сервере apache2 (docs.exampleABC.com и т. д.), продолжают подключаться к nginx. (Поддомены nginx работают нормально.)

Вот одна из конфигураций поддоменов, которые я настроил через apache2:

<Виртуальный хост *:80>
    Имя сервера ft.exampleABC.com
    Перенаправление постоянное / https://ft.exampleABC.com/
    RewriteEngine включен
    RewriteCond %{SERVER_NAME} =ft.exampleABC.com
    RewriteRule ^ https://%{SERVER_NAME}%{REQUEST_URI} [END,NE,R=permanent]
</ виртуальный хост>

<IfModule mod_ssl.c>
    <Виртуальный хост _default_:443>
        # Директива ServerName устанавливает схему запроса, имя хоста и порт, которые
        # сервер использует для идентификации себя. Это используется при создании
        # URL-адреса перенаправления. В контексте виртуальных хостов ServerName
        # указывает, какое имя хоста должно отображаться в заголовке Host: запроса, чтобы
        # соответствует этому виртуальному хосту. Для виртуального хоста по умолчанию (этот файл) это
        # значение не имеет решающего значения, так как оно все равно используется в качестве хоста последней инстанции.
        # Тем не менее, вы должны явно установить его для любого последующего виртуального хоста.

        Имя сервера ft.exampleABC.com
        #ServerAlias ​​*.exampleABC.com

        Веб-мастер администратора сервера@localhost
        DocumentRoot /mnt/external/webserver/ft

        # Доступные уровни логов: trace8, ..., trace1, debug, info, note, warn,
        # ошибка, крит, оповещение, эмердж.
        # Также можно настроить уровень логирования для конкретного
        # модули, например.
        # Информация об уровне журнала ssl: предупреждение

        Журнал ошибок ${APACHE_LOG_DIR}/error.log
        CustomLog ${APACHE_LOG_DIR}/access.log вместе

        # Для большинства конфигурационных файлов из conf-available/, которые
        # включено или отключено на глобальном уровне, можно
        # включить строку только для одного конкретного виртуального хоста. Например
        # следующая строка включает конфигурацию CGI только для этого хоста
        # после глобального отключения с помощью "a2disconf".
        # Включить conf-available/serve-cgi-bin.conf
        
        <Каталог /mnt/external/webserver/ft>
            Индексы опционов FollowSymLinks
            Аллововеррайд
            Требовать все предоставленные
        </Каталог>

        # Переключатель ядра SSL:
        # Включить/отключить SSL для этого виртуального хоста.
        SSLEngine включен

        <отрезано: строки добавлены certbot>

    </ виртуальный хост>
</ЕслиМодуль>

# vim: синтаксис=apache ts=4 sw=4 sts=4 sr noet

Хотелось бы сделать так, чтобы при подключении к exampleABC.com, ft.exampleABC.com и т.д. клиент корректно подключался к серверу apache2. Конечно, exampleXYZ.com и его субдомены должны подключаться к серверу nginx.

Другая информация:

Изначально клиент (например, веб-браузер) не мог проверить подлинность TLS-сертификата exampleABC.com.(Обратите внимание, что у меня были правильно настроены сертификаты TLS в apache2.) Это было решено путем добавления моих доменов apache2 в сертификаты сервера nginx. Хотя я не думаю, что это должно было быть необходимо - мои сертификаты (под apache2) должны быть переданы через обратный прокси-сервер, не так ли?

Если я попытаюсь подключиться к серверу apache2 через curl, вручную указав заголовок Host (через curl -vL -H "Хост: ft.exampleABC.com" https://192.168.0.10), я буду перенаправлен на главную веб-страницу сервера nginx. Я не уверен, что это значит.

РЕДАКТИРОВАТЬ:

Это результат нгинкс-Т, по словам системного администратора системы nginx:

- обрезать -

Кроме того, сервер nginx работает в контейнере через «SWAG» LinuxServer.io.

РЕДАКТИРОВАТЬ:

SWAG LinuxServer.io загружает другую конфигурацию nginx, чем по умолчанию. Следующая команда получает правильную конфигурацию:

docker exec -it swag /usr/sbin/nginx -c /config/nginx/nginx.conf -T

Результат указанной команды можно найти по адресу эта паста. (слишком много символов для StackExchange)

Я владелец дома, в котором находится их сервер. Я ни в коем случае не эксперт; Я просто хорошо следую инструкциям. У меня есть доменное имя DuckDNS, и я запускаю контейнеры Docker для Plex, Sonarr, SABnzbd и т. д. Я также запускаю контейнер SWAG для обратного прокси-сервера.

Unilock ввел свой собственный сервер. Он имеет собственное доменное имя и использует apache2 для всех своих конфигураций сервера. Этот сервер, прежде чем попасть в мою сеть, прослушивал все те же порты, что и мой (80, 443 и т. д.).

Мне сказали, что если Unilock сможет запускать свои службы на нестандартных портах, мы сможем изменить настройки моего маршрутизатора pfSense для запуска обоих серверов. Мне также сказали, что я могу добавить доменные имена их сервера в переменную EXTRA_DOMAINS моего контейнера SWAG. Я сделал это, и это не помогло.

Я также добавил дополнительный блок сервера в файл по умолчанию SITE_CONF. Дополнительный блок выглядит так:

#второй серверный блок
сервер {
    слушать 443 ssl;
    слушать [::]:443 ssl;
    server_name <его доменное имя>; # измените это на свой поддомен
    #include /config/nginx/ssl.conf;
    client_max_body_size 0;
    место расположения / {
    #include /config/nginx/proxy.conf;
    преобразователь 127.0.0.11 действительный = 30 с;
    # установить $upstream_app 192.168.0.10;
    # установить $upstream_port 443;
    #установить $upstream_proto https;
    #proxy_pass $upstream_proto://$upstream_app:$upstream_port;
    прокси_пароль https://192.168.0.10:443; 
    proxy_max_temp_file_size 2048 м;
   }

Мой основной серверный блок — это файл по умолчанию. Если мне нужно опубликовать всю конфигурацию, я это сделаю; хотя, похоже, unilock уже сделал это на Pastebin.После того, как я ввел вышеуказанное, я мог получить доступ к главной странице unilock, но их поддомены по-прежнему перенаправляли на стартовую страницу моего сервера nginx по умолчанию.