AUser0

Прописывайте все-все header-ы, которые в своём запросе отправляет настоящий браузер, в том числе cookie. Ну и раз уж смотрите его запросы - задно смотрите, документ скачивается сразу по запросу, или через какой-нибудь редирект?

Всё очень просто, пишите правила перенаправления для поддоменов на нужные TLD.

P.S. Каков вопроос - таков и ответ.

У вас в

в основном конфиге gitlab

и в /etc/nginx/conf.d/gitlab прописан один и тот же server_name gitlab.company.ltd;. Удалите один из server { ... } - конфликт пропадёт, очевидно же!

P.S. И уберите listen [::]:34080 default_server;, именно это не даёт стартовать nginx-у.

И опять, минимум подробностей. Компьютеры находятся в одной сети 192.168.1.X, так? VipNet стоит на каком именно компьютере? Только не надо отвечать "на левом" или "на втором", используйте слова "сервер" и "клиент". Проблема появляется после перезагрузки какого именно компьютера? И как удаётся восстановить доступ к сайту, или проблема возникла один раз и навсегда? IP-адреса компьютеров не поменялись, случаем? На сервере служба WEB-сервера запущена, активна? На клиенте команду telnet 192.168.1.40 6024 запускать пробовали, что команда выводит на экран? А на сервере? Службу VipNet отключать пробовали? Ах, да, и с какой именно ошибкой не получается доступ к сайту?

sudo chown -R apache /var/www/domain.local/

Просто скрипт для проверки вариантов доменов делает запрос на перевод доменного имени в IP-адрес (например командой nslookup domain.com). Это самый простой способ, но не полноценный. Доменное имя может быть куплено, но сайт ещё не создан, IP-адреса у него нет. Но в базе данных ICAAN этот домен уже прописан, в сервисах whois о нём будут подробности. И нет, ICAAN этот список не публикует. И нет, генерации всех-всех-всех доменов тоже нет, ни кто не хранит у себя всевозможные варианты d0ma1n-my-4ouse.net, которые ни кто не регистрировал. Нет регистрации - значит нет и домена, физически.

При размещении сайта силами хостинговой компании частенько хостеры предлагают "помочь" в покупке доменного имени, либо просто "дарят" клиенту нужное доменное имя. Так вот это тот случай и есть. При регистрации доменного имени через таких "добрых" посредников-хостеров все права на доменное имя переходят самим посредникам. То есть вы платите хостерам за домен, они его регистрируют на себя, делают поддержку DNS, привязывают к своему серверу (где будет физически работать сайт), и вуаля. Считается, что вы владеете доменным именем, но это только аренда. Попытайтесь уйти от хостера вместе с доменным именем - узнаете этот "сюрприз". По крайней мере лет 15 назад дело обстояло так.

Вы пытаетесь отправлять письмо с адреса support@test.ru, или просто так спрятали реальный домен? А 1 час после создания ящика подождали? Если всё сделано правильно, а ошибка появляется - прямой путь в техподдержку, больше ни кто и не исправит.

Связано с тем, что линк между 87.245.228.192 и 87.245.233.73 нестабилен - или провод плохо обжат, или в воду попал, или болтается на ветру, или второй роутер виснет и перезагружается, или коденсатор у него вздулся, или BGP решает перестроить маршрут, или что-то ещё... Пинайте провайдера, в его интересах это исправить.

Кроме того, что chown -R :apache /home/main/sites/test.local,
стоит ещё

echo -ne "\n\n127.0.0.1     test.local\n" >>/etc/hosts

Но доступ через домен test.local появится только у той Linux-like машины, на которой выполнена эта команда. И для Windows расположение hosts сооооовсем другое.

$data = json_decode("[{......}]", true);
var_dump($data);

Понимаете ли, RDP - вещь весьма интимная. И поэтому стоит посмотреть встроенные правила Windows Firewall, тобишь Брандмауэра, что порт 3389 НЕ запрещён для НЕлокальной сети. По логике он как раз должен быть запрещён для НЕлокальной сети.

P.S. Можно проверить tcpdump-ом хоть на Микротике, хоть на Windows, что все пакеты долетают, но...

Называется конвейер (канал, pipe, |):

find  -type f -iname "*.html" -exec grep -Him1 'TEXT' {} \; | head -n500

У вас уже какой-то сервис занял порт 80, на котором должен работать nginx. Найдите и остановите, а лучше удалите сервис, занимающий 80-й порт. Поможет команда netstat -nltp |grep :80, в конце строки - имя сервиса.

Если в меню нет управления пользователем/паролем - возможно оно спрятано уровнем выше. Либо, как вариант - в этой версии его не сделали.
А прямо из операционки управлять не пробовали? Под Linux есть пакет ipmitool, эта утилита умеет коннектиться к локальному BMC, и управлять... Блин, ей тоже пароль нужен.
Ну тогда вынимать батарейку на материнке, наверное. Но это сбросит все настройки BIOS, и остаётся надеяться, что и BMC пользователя. А дальше - назначать IP и дефолтные ADMIN/PASSW0RD (вместо O цифра 0, такой прикол, ага). У некоторых производителей вместо PASSW0RD используется серийный номер с этикетки на корпусе сервера. И смотрите в SSH, есть там включение HTTP, или нет.

Проверяйте /etc/passwd, там в первой строке (у пользователя root) в конце строки указано :/bin/bash, верно?