MVV

Все эти подробности про кабели, что куда подключено - они ниачом. Правильный вопрос, ответ на который все определяет: какой у принтера IP? Если он из той же подсети, что и компьютера - будет доступен без проблем. Иначе могут быть проблемы с обнаружением принтера по имени и с маршрутизацией между подсетями (но все это решаемо).

PS Чтобы правильно хотя бы задавать такие вопросы, а в идеале - избавиться и от необходимости их задавать, освойте многоуровневую модель сети - TCP/IP (она же - DoD) или OSI. После изучения этой теории вам многое станет понятнее.

Если КД имеет возможность (на шлюзе и провадером не запрещено) посылать запросы DNS в интернет на любой сервер (т.е. открыт исходящий доступ по 53/UDP), то можно не указывать ничего: DNS Server на КД сам может послать все нужные запросы, начиная с корневых серверов. Иначе в пересылке следует указать тот сервер DNS, куда доступ открыт.

Следующие фото -то что сделал я,

Вы неправильно понимаете, что такое "второй вход операционного усилителя": на самом деле, это - вход второго транзистора в дифференциальном каскаде (Q2 на вашей схеме), нога 2 - та, которую вы на землю посадили.

А то, что вы приняли за "второй вход" - это один из входов регулировки нуля для напряжения сдвига. И, кстати, на землю входы для регулировки нуля (1,5) сажать не полагается: их через резисторы подтягивают к "минусу": поищите схему включения, там нарисовано. В качестве которых обычно используют одинн подстроечник, со средним контактом к этому минусу подключенным. Если смотреть по схеме, то резисторы регулировки нуля оказываются подключенными параллельно R1 и R2 соответственно и просто корректируют их сопротивление. Так что если от вашего компаратора особой точности не требуется, ноги 1 и 5 можно их вообще не подключать.

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

А вы не задумывались над тем, кто и как будет разрешать зависимости для конструкторов?
В нынешнем 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), но в таком случае ПК должен быть всегда включен. Или - ещё на чем-то постоянно включенном.