Это ситуация обратного прокси-сервера и поддерживается основными веб-серверами, такими как nginx, apache и IIS.
В каждом из них вы можете определить путь, такой как «/application» - и вместо того, чтобы искать в соответствующем локальном каталоге и доставлять файл или вызывать интерпретатор сценариев, он вместо этого будет общаться с другим веб-сервером. Затем он перешлет обратно полученный ответ.
Если вы укажете HTTPS-сайт, он будет связываться по HTTPS с "внутренним" веб-сервером, как если бы это был веб-браузер. С большинством веб-серверов вы можете контролировать, какие заголовки из запроса "frontend" копируются в запрос бэкэнда, изменять или фильтровать веб-сервер или добавлять дополнительные.
А даже не знаю, С существует, и это то, что вы хотите. В идеале C должен быть доступен только для B, и если вы уверены в этом на 100%, вы можете обойтись без HTTPS между B и C для некоторой производительности, если это имеет значение для вашего оборудования и нагрузки (когда вы получаете тысячи запросов на во-вторых, это может иметь значение). Если ваш "бэкэнд" веб-сервер действительно находится на той же машине или виртуальной машине и слушает 127.0.0.1, HTTPS может быть излишним, например.
Nginx хорошо известен своей скоростью и часто используется для кэширования. Комбинация Nginx с путями, перенаправленными обратно на другой веб-сервер, такой как Apache, является распространенной и часто используемой.
Если вы хотите получить подробную информацию и ваши веб-приложения спроектированы для ее поддержки, вы можете указать несколько внутренних серверных веб-серверов для одного пути для балансировки нагрузки или восстановления после сбоя.
Настройка обратного прокси-сервера зависит от конкретного веб-сервера, но его легко можно найти по "обратному прокси-серверу nginx" и т.д.
