☰

Nginx : 하위 도메인으로 대체되는 기본 도메인이 성공하는 동안 하위 도메인은 실패합니다.

tag-icon • tag-icon nginx subdomain
Nginx : 하위 도메인으로 대체되는 기본 도메인이 성공하는 동안 하위 도메인은 실패합니다.

소개 :

내 로컬 네트워크에 NginX를 실행하는 컴퓨터가 있습니다. 내 하위 도메인에 직접 액세스할 수는 없고 대신 NginX 색인 페이지로 연결됩니다. 기본 도메인에 액세스하면 프록시 사이트를 올바르게 로드하는 하위 도메인으로 리디렉션됩니다.

즉, 액세스가 git.lini.lan실패하고 NginX 인덱스 페이지가 로드됩니다.

NginX가 하위 도메인이 지정된 프록시 사이트를 로드하지 못함

내가 기대하는 것은 git.lini.lan프록시 사이트인 GitlabHQ를 로드하는 것입니다.

NginX 프록시 사이트에 하위 도메인이 올바르게 지정됨

기본 도메인에 액세스하면 예상대로 프록시 사이트인 GitlabHQ를 로드하는 lini.lan구성된 사이트/가상 호스트만 대체됩니다 .git.lini.lan

NginX는 기본 도메인을 하위 도메인으로 리디렉션하고 프록시 사이트를 로드합니다.

그래서 기본 도메인에 대한 간접 요청을 통해 프록시된 사이트에 접근할 수 있지만, 하위 도메인을 직접 지정하여 접근할 수는 없습니다.

관찰 :

lini.lan내 이해는 액세스가 "기본" 가상 호스트로 리디렉션된다는 것입니다 . NginX 지시문을 사용하여 호스트를 설정하지 않았으므로 listen ... default_server;기본적으로 git.lini.lan. 그러나 직접 액세스하면 git.lini.lanNginX는 뚜렷한 이유 없이 인덱스 페이지로 돌아갑니다.

숙제 :

비교를 위해 예상대로 작동하는 다른 컴퓨터가 있지만 해당 컴퓨터는 온라인이고 자체 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.lanNginX로 리디렉션됩니다.색인페이지와 그렇지 않은GitlabHQ의 인터페이스입니다. 왜 이런 일이 발생하는지 잘 모르겠습니다.

아마도 누군가가 이것을 접하고 약간의 빛을 비출 수 있었을 것입니다. 또는 NginX가 수행하는 모든 작업을 기록하여 더 많은 정보를 살펴볼 수 있는 방법이 있습니까?

답변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
...

Gitlab Server 가 아닌 내 devbox를 git.lini.lan잘못 가리켰습니다 .192.168.1.10192.168.1.11

따라서 요청은 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계속해서 메시지를 받았습니다."GitLab API 액세스 확인: 실패: 내부 API에 연결하지 못했습니다.". 자체 검사는 git.lini.lan테스트에서 URL을 사용하여 위에서 설명한 대로 모든 요청이 gitlab 서버가 아닌 개발 상자로 전달되도록 합니다.

관련 정보