Nginx: Subdomäne schlägt fehl, während die primäre Domäne, die auf die Subdomäne zurückgreift, erfolgreich ist

Question

Einführung :

Ich habe in meinem lokalen Netzwerk eine Maschine, auf der NginX läuft. Sie lässt mich nicht direkt auf meine Subdomäne zugreifen, sondern leitet mich auf die NginX-Indexseite weiter. Wenn ich auf die primäre Domäne zugreife, werde ich auf die Subdomäne umgeleitet, die die Proxy-Site korrekt lädt.

Das heißt, der Zugriff git.lini.lanschlägt einfach fehl und die NginX-Indexseite wird geladen.

Ich erwarte, dass git.lini.landie Proxy-Site GitlabHQ geladen wird.

Beim Zugriff auf die primäre Domäne lini.lanwird auf die einzige konfigurierte Site/den einzigen konfigurierten virtuellen Host zurückgegriffen, git.lini.lander wie erwartet die Proxy-Site GitlabHQ lädt.

Ich kann also über eine indirekte Anfrage an die primäre Domäne auf die Proxy-Site zugreifen, aber nicht durch direkte Angabe der Subdomäne.

Beobachtungen:

Nach meinem Verständnis wird beim Zugriff lini.lanauf den virtuellen „Standard“-Host umgeleitet. Da ich mit der Direktive keinen eingerichtet habe, verwendet listen ... default_server;NginX standardmäßig den ersten virtuellen Host, der bedient git.lini.lan. Bei einem git.lini.landirekten Zugriff greift NginX jedoch ohne ersichtlichen Grund auf die Indexseite zurück.

Hausaufgaben :

Zum Vergleich habe ich eine andere Maschine, die wie erwartet funktioniert, aber diese Maschine ist online, hat ihre eigenen DNS-Einträge eingerichtet und verwendet SSL, sodass es keinen 1:1-Vergleich zwischen den NginX-Konfigurationen auf den beiden Maschinen gibt. Es könnte zum Beispiel möglich sein, dass der DNS-Eintrag dazu beiträgt, alle seltsamen Dinge zu beheben, die NginX möglicherweise tut. Ich habe die Konfigurationsdateien zwischen den beiden Maschinen verglichen und die beiden Konfigurationen sind wirklich gleichwertig, wenn man das SSL-Zeug ignoriert.

Ich habe auch meine Protokolldateien durchgesehen, aber da scheint nichts fehl am Platz zu sein.

Theorie:

Während ich heute Nachmittag damit herumgespielt habe, ist Folgendes dabei herausgekommen. Meine „Standard“-Konfiguration des virtuellen Hosts/Servers muss korrekt gelesen werden, sonst hätte ich keinen Zugriff auf GitlabHQ. Das bedeutet, dass der Proxy erfolgreich ist und wie erwartet geladen wird. Das NginX-Routing scheint ein wenig falsch zu sein.

Information :

Unten sehen Sie meine Konfiguration für die Maschine, die sich seltsam verhält. Dies ist meine Ausgabe für 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;
  }
}

Literatur:

Ich habe durchgemachtServernamenUndAnfragebearbeitung. Ich habe auch einige der anderen SO-Fragen geprüft, die relevant erschienen, aber keine schien mein Szenario abzudecken.

Problem:

Mein Problem ist, dass ich, wenn ich die Subdomain in meinem Browser eingebe, die NginX-Indexseite bekomme und nicht die Proxy-Site der Subdomain, d. h. git.lini.lanWeiterleitungen zur NginXIndexSeite und nicht zuGitlabHQ's Schnittstelle. Ich bin nicht sicher, warum das passiert?

Vielleicht ist das jemandem schon einmal begegnet und er könnte etwas Licht ins Dunkel bringen? Gibt es alternativ eine Möglichkeit, alles zu protokollieren, was NginX tut, sodass ich mehr Informationen habe, die ich durchforsten kann?

Answer 1

Es stellte sich heraus, dass mein DHCP-Server, der mein Netzwerk verwaltet, falsch konfiguriert war. Die Maschinen im Netzwerk waren wie folgt:

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

Der Hostname-Eintrag auf dem DNS-Server wurde wie folgt konfiguriert:

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

Wurde fälschlicherweise auf , meine Devbox, und nicht auf , den Gitlab-Server, git.lini.lanzurückverwiesen .192.168.1.10192.168.1.11

Anfragen an lini.lanwürden also wie in der ursprünglichen Frage gezeigt ablaufen. Sie erreichten das richtige Feld, NginX würde standardmäßig den ersten virtuellen Host verwenden und die Gitlab-Hauptseite bereitstellen. Anfragen an den Computernamen selbst, lini, würden auch funktionieren, da der DHCP-Server diese auf zuordnen würde lini.lan.

Anfragen an git.lini.lanwürden jedoch fälschlicherweise zu meinem Computer zurückgeleitet, wo der lokale Server die URL nicht erkennt und die Standardindexseite bereitstellt.

Notiz :

Ursprünglich stieß ich auf dieses Problem, als ich den Gitlab-Selbsttest durchführte sudo -u git bundle exec rake gitlab:env:info --trace RAILS ENV=productionund immer wieder die Meldung erhielt„GitLab-API-Zugriff prüfen: FEHLGESCHLAGEN: Verbindung zur internen API konnte nicht hergestellt werden“. Die Selbstüberprüfung verwendet git.lini.lanin ihren Tests die URL, wodurch alle Anfragen an die Entwicklungsbox und nicht an den GitLab-Server weitergeleitet werden, wie oben beschrieben.