MVV

Не легче ли внедрение делать через конструкторы?

А вы не задумывались над тем, кто и как будет разрешать зависимости для конструкторов?
В нынешнем ASP.NET Core этим занимются каркасы приложений ("фрейворки", от английского framework). И делают они это как раз через контейнер сервисов (либо напрямую через GetService, либо через ActvatorUtilities).
Но есть области в ASP.NET Core , которые фремворками не закрываются - наример, в конвейере обработчиков запроса (middleware), там где требуется делегат типа RequestDelegate. И там без прямого обращения к контейнеру сервисов не обойтись.

Есть предположение, что копать надо в сторону DNS - в какие-то моменты она может отдавать для имени сайта не тот адрес, а браузер - запомнить это неправильное соответствие имя-адрес.
Для диагностики в тот момент, когда браузер застревает на таймауте (т.е. ждет перед тем, как выдать эту ошибку) смотрите список соединений TCP: нет ли там попыток подключения на какой-то неправильный IP на порт вашего сайта (80, 443 или какой вы там используете). Смотреть можно командой netstat -n из командной строки, интересующие вас подключения имеют состояние SYN_SENT. Для уверенности можно использовать команду netstat -no, она дополнительно покажет PID процесса, сравните его с PID браузера (его можно увидеть в Диспетчере Задач или в списке задач, который выводит команда tasklist). А потом ищите, какой из серверов DNS отдает этот адрес в ответе для имени сайта (команда nslookup имя_сaйта IP_сервера_DNS).
PS Частая ошибка настройки DNS в сетях с AD - добавление на клиенты в список серверов DNS сторонних серверов DNS: их там быть не должно, там должны быть только контроллеры домена.

T - это параметр-тип обобщенного метода. Как и все параметры, этот параметр задается извне, при вызове конкретной специализации обобщенного метода. И, кстати, компилятор вообще не может знать, что T может принадлежать к одному из трех перечисленных типов: их проверка, с выбрасыванием исключения, производится уже во время выполнения.
Так что изнутри метода, если вы хотите его сохранить, а не выкидывать, придется вам возвращать Object и разбираться с типом возвращенного значения уже после вызова. Причем, возврат Object вместо числового типа - это ещё и лишние накладные расходы на упаковку/распаковку (box/unbox). Так что я бы на вашем месте этот метод выкинул.

Вариант 2 несет риск отказа единственного КД в в процессе замены второго КД. Вариант 1 в этом плане безопаснее. Оставлять тот же адрес IP и имя, чаще всего, не обязательно (для проверки можно выключить второй КД и посмотреть, что все в организации функционирует нормально).
PS Для отказоустойчивости DHCP можно поднять DHCP на другом КД, а зону(ы) для локальной сети настроить отказоустойчивыми через DHCP Failover.

Рекомендуемые варианты использования есть в документации Microsoft. Краткая цитата оттуда:

Чтобы суммировать рекомендуемое HttpClient использование с точки зрения управления временем существования, следует использовать либо долгосрочные клиенты, либо задать PooledConnectionLifetime (.NET Core и .NET 5+) или краткосрочные клиенты, созданные IHttpClientFactory.

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

Вам, если правильно сформулировать задачу технически, требуется переадресация на основании имени узла в (заголовке Host протокола HTTP(S)), к которому производится подключение. Это обычно маршрутизацией не называют, а ПО, которое умеет это делать, чаще всего называют "обратный прокси-сервер". Теоретически оно может быть установлено и на домшнем маршрутизаторе, если он - достаточно мощный, или - на NAS, но и тут, и там надо смотреть про конкретную модель. Если походящих вариантов не найдется, то придется устанавливать обратный прокси-сервер на ПК (нужное ПО есть и под Windows, и под Linux), но в таком случае ПК должен быть всегда включен. Или - ещё на чем-то постоянно включенном.

Вы не инициализуете сами массивы (не содаете для них объекты типа Inline_Keyboard[]) нижнего уровня: rootobject.inline_keyboard[0] и rootobject.inline_keyboard[1]. Ну, и rootobject.inline_keyboard[2] тоже стоило бы создать IMHO.