Nginx: Субдомен выходит из строя, в то время как основной домен, который возвращается к субдомену, работает успешно

Question

Введение :

У меня есть машина в локальной сети, на которой запущен NginX. Он не позволяет мне напрямую получить доступ к моему поддомену, вместо этого он направляет меня на страницу индекса NginX. Если я захожу на основной домен, меня перенаправляют на поддомен, который правильно загружает прокси-сайт.

То есть доступ git.lini.lanпросто прервется и загрузится индексная страница NginX.

Я ожидаю, что произойдет git.lini.lanзагрузка прокси-сайта GitlabHQ.

Доступ к основному домену lini.lanосуществляется через единственный настроенный сайт/виртуальный хост, git.lini.lanкоторый загружает прокси-сайт GitlabHQ, как и ожидалось.

Таким образом, я могу получить доступ к проксированному сайту через косвенный запрос к основному домену, но не могу получить к нему доступ, напрямую указав поддомен.

Наблюдения:

Насколько я понимаю, при доступе lini.lanпроисходит перенаправление на виртуальный хост "по умолчанию". Поскольку я не установил его с помощью директивы, listen ... default_server;NginX по умолчанию использует первый виртуальный хост, который обслуживает git.lini.lan. git.lini.lanОднако при прямом доступе NginX возвращается на страницу индекса без видимой причины.

Домашнее задание :

Для сравнения у меня есть другая машина, которая работает как и ожидалось, но эта машина в сети, имеет собственные настройки записей DNS и использует SSL, поэтому нет абсолютного сравнения конфигураций NginX на двух машинах. Например, возможно, что запись DNS каким-то образом исправляет какие-то странные вещи, которые может делать NginX. Я сравнил файлы конфигурации между двумя машинами, и эти две конфигурации действительно эквивалентны, если не обращать внимания на SSL.

Я также просмотрел свои файлы журналов, но не обнаружил ничего подозрительного.

Теория:

Пока я этим днём возился, вот что я узнал. Моя "стандартная" конфигурация виртуального хоста/сервера должна быть правильно прочитана, иначе я не смогу получить доступ к GitlabHQ. То есть прокси-сервер успешно загружается и работает так, как и ожидалось. Похоже, что маршрутизация NginX немного некорректна.

Информация :

Моя конфигурация для машины, которая ведет себя странно, приведена ниже. Это мой вывод для nginx -T.

nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
nginx: configuration file /etc/nginx/nginx.conf test is successful
# configuration file /etc/nginx/nginx.conf:
user nginx nginx;
worker_processes 1;

error_log /var/log/nginx/error_log info;

events {
        worker_connections 1024;
        use epoll;
}

http {
        include /etc/nginx/mime.types;
        default_type application/octet-stream;

        log_format main
                '$remote_addr - $remote_user [$time_local] '
                '"$request" $status $bytes_sent '
                '"$http_referer" "$http_user_agent" '
                '"$gzip_ratio"';

        client_header_timeout 10m;
        client_body_timeout 10m;
        send_timeout 10m;

        connection_pool_size 256;
        client_header_buffer_size 1k;
        large_client_header_buffers 4 2k;
        request_pool_size 4k;

        gzip on;
        gzip_min_length 1100;
        gzip_buffers 4 8k;
        gzip_types text/plain;

        output_buffers 1 32k;
        postpone_output 1460;

        sendfile on;
        tcp_nopush on;
        tcp_nodelay on;

        keepalive_timeout 75 20;

        ignore_invalid_headers on;

        index index.html;

        include /etc/nginx/sites/*.conf;

}

# configuration file /etc/nginx/mime.types:

types {
    text/html                             html htm shtml;
    ...
    List of MIME Types
    ...
    video/x-msvideo                       avi;
}

# configuration file /etc/nginx/sites/gitlab.conf:

upstream git.lini.lan {
  server unix:/opt/gitlabhq-8.15/tmp/sockets/gitlab.socket;
}

server {
  listen 80;

  server_name git.lini.lan;

  root /opt/gitlab-8.15/public;

  access_log  /var/log/nginx/gitlab_access.log;
  error_log   /var/log/nginx/gitlab_error.log;

  location / {
    try_files $uri $uri/index.html $uri.html @gitlab;
  }

  location @gitlab {
    proxy_read_timeout 300;    # https://github.com/gitlabhq/gitlabhq/issues/694
    proxy_connect_timeout 300; # https://github.com/gitlabhq/gitlabhq/issues/694
    proxy_redirect     off;

    proxy_set_header   X-Forwarded-Proto $scheme;
    proxy_set_header   Host              $http_host;
    proxy_set_header   X-Real-IP         $remote_addr;

    proxy_pass http://git.lini.lan;
  }
}

Литература:

Я прошел черезимена серверовиобработка запроса. Я также рассмотрел некоторые другие вопросы SO, которые показались мне релевантными, но ни один из них не охватывал мой сценарий.

Проблема:

Моя проблема в том, что когда я ввожу поддомен в своем браузере, я получаю страницу индекса NginX, а не проксированный сайт на поддомене, т.е. git.lini.lanперенаправляет на NginX.индексстраница и неGitlabHQИнтерфейс. Я не уверен, почему это происходит?

Может быть, кто-то сталкивался с этим и мог бы пролить свет? Или есть ли способ регистрировать все, что делает NginX, чтобы у меня было больше информации, которую можно было бы выудить.

Answer 1

Оказывается, мой DHCP-сервер, который управляет моей сетью, был неправильно настроен. Машины в сети были следующими:

...
192.168.1.10 devbox.lan The machine I was on
192.168.1.11 lini.lan   The target server
...

Запись имени хоста на DNS-сервере была настроена следующим образом:

...
192.168.1.10 git.lini.lan
...

Где git.lini.lanневерно указано обратно на 192.168.1.10мой devbox, а не на 192.168.1.11сервер Gitlab.

Поэтому запросы к lini.lanбудут выполняться так, как показано в исходном вопросе. Они достигнут правильного поля, NginX по умолчанию установит первый виртуальный хост и обслужит главную страницу gitlab. Запросы к самому имени машины, lini, также будут работать, поскольку DHCP-сервер сопоставит их с lini.lan.

Однако запросы к git.lini.lanбудут неправильно перенаправляться обратно на мой компьютер, где локальный сервер не распознает URL-адрес и обслуживает индексную страницу по умолчанию.

Примечание :

Первоначально я столкнулся с этой проблемой во время выполнения самопроверки gitlab, sudo -u git bundle exec rake gitlab:env:info --trace RAILS ENV=productionи продолжал получать сообщение«Проверка доступа к API GitLab: НЕУДАЧНО: Не удалось подключиться к внутреннему API». Самопроверка использует URL git.lini.lanв своих тестах, в результате чего все запросы направляются в среду разработки, а не на сервер gitlab, как описано выше.