☰

Nginx: el subdominio falla mientras que el dominio principal, que recurre al subdominio, tiene éxito

tag-icon • tag-icon nginx subdomain
Nginx: el subdominio falla mientras que el dominio principal, que recurre al subdominio, tiene éxito

Introducción :

Tengo una máquina en mi red local que ejecuta NginX. No me permitirá acceder a mi subdominio directamente, sino que me dirige a la página de índice de NginX. Si accedo al dominio principal, me redirigen al subdominio que carga el sitio proxy correctamente.

El acceso git.lini.lansimplemente fallará y cargará la página de índice de NginX.

NginX no puede cargar el sitio proxy dado el subdominio

Lo que espero que suceda es que git.lini.lanse cargue el sitio proxy, GitlabHQ.

Sitio proxy NginX con subdominio correctamente asignado

El acceso al dominio principal lini.lanrecurre al único sitio/host virtual configurado, git.lini.lan, que carga el sitio proxy, GitlabHQ, como se esperaba.

NginX redirige el dominio principal al subdominio y carga el sitio proxy

Entonces puedo acceder al sitio proxy mediante una solicitud indirecta al dominio principal, pero no puedo acceder especificando directamente el subdominio.

Observaciones:

Según tengo entendido, el acceso lini.lanredirige al host virtual "predeterminado". Como no he configurado uno usando la directiva, listen ... default_server;NginX establece de forma predeterminada el primer host virtual, que sirve git.lini.lan. Sin embargo, cuando uno accede git.lini.landirectamente, NginX vuelve a la página de índice sin motivo aparente.

Tarea :

A modo de comparación, tengo otra máquina que funciona como se esperaba, pero esa máquina está en línea, tiene sus propios registros DNS configurados y usa SSL, por lo que no hay una comparación 1 a 1 entre las configuraciones de NginX en las dos máquinas. Por ejemplo, es posible que el registro DNS sirva de alguna manera para solucionar cualquier cosa extraña que NginX pueda estar haciendo. He diferenciado los archivos de configuración entre las dos máquinas y las dos configuraciones son realmente equivalentes, después de ignorar el tema SSL.

También revisé mis archivos de registro pero no hay nada que parezca estar fuera de lugar.

Teoría :

Mientras he estado jugueteando con esto esta tarde, esto es lo que he aprendido. Mi configuración de servidor/host virtual "predeterminada" debe leerse correctamente, de lo contrario no podría tener acceso a GitlabHQ. Ese es el proxy que tiene éxito y se carga como se esperaba. Es el enrutamiento de NginX el que parece un poco incorrecto.

Información :

Mi configuración para la máquina que está siendo extraña se encuentra a continuación. Este es mi resultado 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:

He pasado pornombres de servidoresyprocesamiento de solicitudes. También revisé algunas de las otras preguntas de SO que parecían relevantes, pero ninguna parecía cubrir mi escenario.

Problema:

Mi problema es que cuando ingreso al subdominio en mi navegador, aparece la página de índice de NginX, no el sitio proxy en el subdominio, es decir, git.lini.lanredirecciones a NginX.índicepágina y noGitlabHQLa interfaz de. ¿No estoy seguro de por qué sucede esto?

¿Quizás alguien podría haberse encontrado con esto y podría arrojar algo de luz? Alternativamente, ¿existe alguna forma de registrar todo lo que hace NginX para poder tener más información para buscar?

Respuesta1

Resulta que mi servidor DHCP que administra mi red estaba mal configurado. Las máquinas en la red fueron las siguientes:

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

El registro de nombre de host en el servidor DNS se configuró de la siguiente manera:

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

Donde git.lini.lanapuntaba incorrectamente a 192.168.1.10mi devbox y no 192.168.1.11al servidor Gitlab.

Entonces, las solicitudes lini.lanprocederían como se muestra en la pregunta original. Llegaron al cuadro correcto, NginX establecería de forma predeterminada el primer host virtual y mostraría la página principal de gitlab. Las solicitudes al nombre de la máquina en sí, lini, también funcionarían ya que el servidor DHCP las asignaría a lini.lan.

Sin embargo, las solicitudes a git.lini.lan, redirigirían incorrectamente a mi máquina, donde el servidor local no reconoce la URL y muestra la página de índice predeterminada.

Nota :

Originalmente me encontré con este problema mientras realizaba la autocomprobación de gitlab sudo -u git bundle exec rake gitlab:env:info --trace RAILS ENV=productiony seguí recibiendo el mensaje."Verifique el acceso a la API de GitLab: FALLADO: No se pudo conectar a la API interna". La autocomprobación utiliza la URL git.lini.lanen sus pruebas, lo que hace que todas las solicitudes se dirijan al cuadro de desarrollo en lugar de al servidor gitlab, como se describe anteriormente.

información relacionada