Nginx: O subdomínio falha enquanto o domínio primário, que volta ao subdomínio, é bem-sucedido

Question

Introdução :

Tenho uma máquina na minha rede local rodando NginX. Ele não me permite acessar meu subdomínio diretamente; em vez disso, me direciona para a página de índice do NginX. Se eu acessar o domínio primário, sou redirecionado para o subdomínio que carrega o site proxy corretamente.

Esse acesso git.lini.lansimplesmente falhará e carregará a página de índice do NginX.

O que espero que aconteça é que git.lini.lano site com proxy, GitlabHQ, seja carregado.

O acesso ao domínio primário lini.lanrecorre ao único site/host virtual configurado, git.lini.lan, que carrega o site com proxy, GitlabHQ, conforme esperado.

Assim, posso acessar o site com proxy por meio de uma solicitação indireta ao domínio primário, mas não consigo acessá-lo especificando diretamente o subdomínio.

Observações:

Meu entendimento é que o acesso lini.lanredireciona para o host virtual "padrão". Como não defini um usando a diretiva, listen ... default_server;o NginX assume como padrão o primeiro host virtual, que serve git.lini.lan. Quando alguém acessa git.lini.landiretamente, no entanto, o NginX volta para a página de índice sem motivo aparente.

Trabalho de casa :

Para comparação, tenho outra máquina que funciona conforme o esperado, mas essa máquina está online, tem sua própria configuração de registros DNS e usa SSL, portanto não há uma comparação de 1 para 1 entre as configurações do NginX nas duas máquinas. Por exemplo, pode ser possível que o registro DNS resolva de alguma forma qualquer coisa estranha que o NginX possa estar fazendo. Eu diferenciei os arquivos de configuração entre as duas máquinas e as duas configurações são realmente equivalentes, depois de ignorar o material SSL.

Também examinei meus arquivos de log, mas não há nada que pareça estar fora do lugar.

Teoria:

Enquanto estive brincando com isso esta tarde, aqui está o que aprendi. Minha configuração de host/servidor virtual "padrão" deve ser lida corretamente, caso contrário eu não poderia ter acesso ao GitlabHQ. Ou seja, o proxy é bem-sucedido e carrega conforme o esperado. É o roteamento NginX que parece um pouco incorreto.

Informação :

Minha configuração para a máquina que está estranhando está abaixo. Esta é a minha saída para 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;
  }
}

Literatura:

eu passeinomes de servidoreseprocessamento de solicitação. Também revisei algumas das outras questões do SO que pareciam relevantes, mas nenhuma parecia cobrir meu cenário.

Problema:

Meu problema é que quando entro no subdomínio no meu navegador, obtenho a página de índice do NginX e não o site com proxy no subdomínio, ou seja, git.lini.lanredireciono para o NginXíndicepágina e não paraGitlabHQinterface. Não sei por que isso está acontecendo?

Talvez alguém possa ter encontrado isso e possa lançar alguma luz? Como alternativa, existe um meio de registrar tudo o que o NginX faz para que eu possa ter mais informações para pesquisar.

Answer 1

Acontece que meu servidor DHCP que gerencia minha rede foi configurado incorretamente. As máquinas da rede eram as seguintes:

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

O registro do nome do host no servidor DNS foi configurado da seguinte forma:

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

Onde git.lini.lanapontou incorretamente para 192.168.1.10meu devbox, e não para 192.168.1.11o servidor Gitlab.

Portanto, as solicitações lini.lanprosseguiriam conforme mostrado na pergunta original. Eles alcançaram a caixa correta, o NginX padronizaria o primeiro host virtual e serviria a página principal do gitlab. Solicitações para o próprio nome da máquina, linitambém funcionariam, pois o servidor DHCP as mapearia para lini.lan.

As solicitações para git.lini.lan, no entanto, redirecionariam incorretamente de volta para minha máquina, onde o servidor local não reconhece a URL e exibe a página de índice padrão.

Observação :

Originalmente, me deparei com esse problema ao realizar a autoverificação do gitlab, sudo -u git bundle exec rake gitlab:env:info --trace RAILS ENV=productione continuei recebendo a mensagem"Verifique o acesso à API do GitLab: FAILED: Falha ao conectar à API interna". A autoverificação usa a URL git.lini.lanem seus testes, fazendo com que todas as solicitações sejam direcionadas para a caixa de desenvolvimento e não para o servidor gitlab, conforme descrito acima.