Михаил Р.

Тут надо для себя логику и задачи определить: редиректы и переклейка – для чего? В индексе остаться подольше? Ссылки не потерять? Чуть дольше побегать от РКН? Трафик как можно быстрее вернуть?
В любом варианте схема какая-то странная. Обычно под Гугл в цепочку обязательно встраивается 302 (временный) редирект, не позволяющий потерять хостовые. РКН-то не везде муравьишками управляет. В Яндекс 302 не нужен.
Вот для примера реализация от одного из нехороших сайтов, которые блокают как по расписанию. Тут схема для гуглобота, для Яндекса 302 исключается. Обратите внимание на субдомен в редиректе, это часть процесса.
А дальше – логика.

Я бы сказал - да, влияет. Яндекс использует все источники данных для оценки. Свои "автоцели" они также не зря так навязчиво втыкали и активировали. С их помощью он пытается оценить микроконверсии и конверсии. Если сайт не продаёт, а должен бы - это, вероятно, не совсем хороший сайт.
Во времена экспериментов с накруткой ПФ я это использовал, и это работало. Как минимум, это источник информации, что именно пытается оценить Яндекс и какие данные использует. Ликвидация автоцелей с нулевыми показателями и проработка реально коммерческих целей давала неплохой буст.
Сейчас у них акцент сместился в сторону собственных задач (экосистема Яндекса, фиды товаров и услуг сразу на выдаче и т.п.), однако это не значит, что оценка конверсий потеряла значение - просто, возможно, приоритеты отдаются конверсиям по другим каналам.
Как минимум, я бы снёс из метрики ненужные автоцели типа "просмотрел больше 1 страницы", "написал в ватсап" и т.п. - и те, что вообще не работают и показывают нулевую конверсию.

1) Самописный сайт — это очень размытое и зависит от навыка самописца, можно собрать лютого франкенштейна, который будет ползать и просить его убить, а можно ультра-мега шустрый сайт, буквально залетающий в клиент.

2) Элементор — мусор, без дикого кэширования и кучи работ по оптимизации и микрооптимизации и грамотной
настройки сервера более-менее серьезный сайт на нём не собрать. Все хвалёные билдеры — фигня, из них наиболее легкий — Бобер (Beaver Builder), но это не значит, что он хороший. Все они — куча инлайна и лютая вложенность, огромное, адски огромное количество подтягивающихся на фронт ресурсов, для даже вывода контента, в отличии от Гутенберга, требует от движка закатать рукава, обновления Элементора — это отдельная песня и боль, билдеры дырявые, как гей-парад.
Они имеют право на жизнь для всяких там личных бложиков, ну или в качестве инструмента прототипирования.

3) Гутенберг - ему не может не хватать возможностей, если не хватает каких-то готовых блоков, полно плагинов даже в офф репе WP, которые добавляют их практически не ограниченное количество, и ничего не мешает написать свои блоки, такие как надо. вот пример довольно толковой либы под него https://wordpress.org/plugins/kadence-blocks/
Он во всём лучше сторонних билдеров.

строчка условий из моего .pac файла автонастройки прокси для браузера

dnsDomainIs(host,'.youtube.com')||dnsDomainIs(host,'.googlevideo.com')||dnsDomainIs(host,'.ggpht.com')||dnsDomainIs(host,'.ytimg.com')||host=='googleads.g.doubleclick.net'||host=='youtu.be'

WSUS

Нужен ли апгрейд?
99.9 и остальное говорит о хорошей самооценке.
Искажение названий инструментов говорит о соответствующем к ним отношении.
Любой человек (и такой разраб) может проапгрейдить себя с помощью подходящих инструментов. Как? Только осознанно.

ЗЫ: Или библиотека размазана по множеству C++ файлов движка v8?

Да

1. Смысл RAID в первую очередь не в сохранности информации, а в минимизации простоев. Если один диск выходит из строя, система некоторое время может работать на деградировавшем массиве. Но, если произошёл системный сбой и разрушилась файловая система, то она разрушится разом на всех дисках массива. Если до ваших дисков добрался шифровальщик, то он тоже с удовольствием зашифрует всё, не смотря на уровень RAID.
2. Надёжность RAID определяется количеством дисков, вероятностью выхода из строя одного диска и максимальным количеством неисправных дисков в системе. В вашем случае, поскольку вы приобретёте диски одновременно, то есть вероятность, что и из строя они выйдут примерно в одно время.
3. Потеря скорости, в основном, идёт при записи, поскольку надо записать не один диск, а два. А на высоких рейдах (5, 6) ещё и надо прочитать старую контрольную сумму и старое содержимое сектора.

Ну и бэкапы. Всегда бэкапы. Причём версионированные. С версионированного бэкапа, вынесенного на другой компьютер, можно восстановить данные на последнюю точку, обычно на конец предыдущего дня. Если поймали шифровальщик, то восстанавливаем на начало недели или месяца, где последняя незашифрованная версия.

ну потому что тебе не рейд15 надо..(а такой вообще существует???)
а рейд 10

Нужно убрать SNAT в POSTROUTING и на приёмнике маршрутизировать ответные пакеты в VPN. Тогда сервер-получатель будет видеть реальные адреса. Но придётся или весь интернет на той стороне завернуть в VPN (сделать дефолтный роут в VPN, что может быть неприемлемо), или упражняться с policy routing.

Объяснения по поводу настройки policy routing см. Сложная маршрутизация на linux роутере. Как правильно готовить policy based routing?

Второй вариант - поставить на VPS nginx и передавать IP в заголовках http. На той стороне доработать/донастроить своё веб-приложение, что оно умело брать IP из заголовка X-Forwarded-For или X-Real-Ip. Но это только для http.

Ставите iperf/3 из пакетов и тестируете, сколько влезет. Правда, с другой стороны тоже должен iperf быть, или в режиме сервера, или в режиме клиента.
С одной стороны, на удаленном сервере
iperf3 -s
С другой стороны
iperf3 -c <server-IP-address>
или
iperf3 -c <server-IP-address> -R