☰

Nginx: サブドメインは失敗するが、サブドメインにフォールバックするプライマリドメインは成功する

tag-icon • tag-icon nginx subdomain
Nginx: サブドメインは失敗するが、サブドメインにフォールバックするプライマリドメインは成功する

導入 ：

ローカル ネットワーク上に NginX を実行しているマシンがあります。サブドメインに直接アクセスすることはできませんが、代わりに NginX のインデックス ページにリダイレクトされます。プライマリ ドメインにアクセスすると、プロキシされたサイトを正しく読み込むサブドメインにリダイレクトされます。

つまり、アクセスはgit.lini.lan単に失敗し、NginX インデックス ページが読み込まれます。

NginX はサブドメインを指定してプロキシされたサイトの読み込みに失敗する

私が期待しているのは、git.lini.lanプロキシされたサイト GitlabHQ が読み込まれることです。

NginX はサブドメインを正しく指定したサイトをプロキシします

プライマリ ドメインにアクセスすると、lini.lan唯一構成されているサイト/仮想ホストにフォールバックしgit.lini.lan、プロキシ サイト GitlabHQ が期待どおりに読み込まれます。

NginXはプライマリドメインをサブドメインにリダイレクトし、プロキシサイトをロードします。

したがって、プライマリ ドメインへの間接的なリクエストを介してプロキシ サイトにアクセスすることはできますが、サブドメインを直接指定してアクセスすることはできません。

観察:

私の理解では、アクセスするとlini.lan「デフォルト」の仮想ホストにリダイレクトされます。ディレクティブを使用して設定していないため、 listen ... default_server;NginX はデフォルトで最初の仮想ホストを使用しますgit.lini.lan。このホストは を提供します。ただし、直接アクセスするとgit.lini.lan、NginX は理由もなくインデックス ページにフォールバックします。

宿題 ：

比較のために、期待通りに動作する別のマシンがありますが、そのマシンはオンラインで、独自の DNS レコードが設定されており、SSL を使用しているため、2 台のマシンの NginX 構成を 1 対 1 で比較することはできません。たとえば、DNS レコードによって、NginX が実行している可能性のある奇妙な動作をある程度修正できる可能性があります。2 台のマシンの構成ファイルを比較しましたが、SSL 関連の項目を無視すると、2 つの構成は実際には同等です。

ログファイルも確認しましたが、異常なところは何もありませんでした。

理論 ：

今日の午後、これをいじっていたら、次のことがわかりました。私の「デフォルト」の仮想ホスト/サーバー構成を正しく読み取らなければ、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にリダイレクトされます。索引ページとギットラボ本社のインターフェース。なぜこのようなことが起こるのか分かりません。

おそらく、これに遭遇した人がいて、何らかの説明をしてくれるかもしれません。あるいは、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 サーバーではなく、私の devboxgit.lini.lanにポイントバックされていました。192.168.1.10192.168.1.11

したがって、 へのリクエストは、lini.lan元の質問に示されているように処理されます。 が正しいボックスに到達すると、NginX は を最初の仮想ホストにデフォルト設定し、gitlab のメイン ページを提供します。 マシン名自体へのリクエストも、liniDHCP サーバーがこれらを にマップするため機能しますlini.lan。

しかし、へのリクエストはgit.lini.lan誤って私のマシンにリダイレクトされ、ローカル サーバーは URL を認識せず、デフォルトのインデックス ページを提供します。

注記 ：

もともと私はgitlabのセルフチェックを実行しているときにこの問題に遭遇しsudo -u git bundle exec rake gitlab:env:info --trace RAILS ENV=production、メッセージが表示され続けました。「GitLab API アクセスを確認: 失敗: 内部 API への接続に失敗しました」セルフチェックではテストで URL が使用されるgit.lini.lanため、上記のように、すべてのリクエストが GitLab サーバーではなく開発ボックスに送信されます。

関連情報