Nginx dazu bringen, auf eine Remote-Anforderung zu antworten

Question

Ich versuche herauszufinden, warum ein Server nicht auf öffentliche Anfragen reagiert. Ich habe nginx laufen und die Conf-Dateien sind:

ngingx.conf

   user www-data;
    worker_processes 4;
pid /run/nginx.pid;

events {
        worker_connections 768;
        # multi_accept on;
}

http {

        ##
        # Basic Settings
        ##

        sendfile on;
        tcp_nopush on;
        tcp_nodelay on;
        keepalive_timeout 65;
        types_hash_max_size 2048;
        # server_tokens off;

        # server_names_hash_bucket_size 64;
        # server_name_in_redirect off;

        include /etc/nginx/mime.types;
        default_type application/octet-stream;


        ##
        # Logging Settings
        ##

        access_log /var/log/nginx/access.log;
        error_log /var/log/nginx/error.log;

        ##
        # Gzip Settings
        ##

        gzip on;
        gzip_disable "msie6";

        # gzip_vary on;
        # gzip_proxied any;
        # gzip_comp_level 6;
        # gzip_buffers 16 8k;
        # gzip_http_version 1.1;
        # gzip_types text/plain text/css application/json application/x-javascript text/xml application/xml application/xml+rss text/javascript;

        ##
        # nginx-naxsi config
        ##
        # Uncomment it if you installed nginx-naxsi
        ##

        #include /etc/nginx/naxsi_core.rules;

        ##
        # nginx-passenger config
        ##
             # Uncomment it if you installed nginx-passenger
        ##

        #passenger_root /usr;
        #passenger_ruby /usr/bin/ruby;

        ##
        # Virtual Host Configs
        ##

        include /etc/nginx/conf.d/*.conf;
        include /etc/nginx/sites-enabled/*;
}


#mail {
#       # See sample authentication script at:
#       # http://wiki.nginx.org/ImapAuthenticateWithApachePhpScript
#
#       # auth_http localhost/auth.php;
#       # pop3_capabilities "TOP" "USER";
#       # imap_capabilities "IMAP4rev1" "UIDPLUS";
#
#       server {
#               listen     localhost:110;
#               protocol   pop3;
#               proxy      on;
#       }
#
#       server {
#               listen     localhost:143;
#               protocol   imap;
#               proxy      on;
#       }
#}

sites-available/produktion.conf

    upstream mip-production-backend {

          server unix:///home/rails/apps/mip/production/shared/sockets/thin.0.sock;

          server unix:///home/rails/apps/mip/production/shared/sockets/thin.1.sock;

          server unix:///home/rails/apps/mip/production/shared/sockets/thin.2.sock;

          server unix:///home/rails/apps/mip/production/shared/sockets/thin.3.sock;
          }

    map $http_upgrade $connection_upgrade {
      default upgrade;
      ''      close;
    }

    server  {
      listen 80 default_server;

      root /home/rails/apps/mip/production/current/public;

      location / {
        proxy_redirect off;
        proxy_http_version 1.1;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header Host            $http_host;
        proxy_set_header Upgrade         $http_upgrade;
        proxy_set_header Connection      $connection_upgrade;

        if (!-f $request_filename) {
          proxy_pass http://mip-production-backend;
          break;
        }
      }

      error_page 500 502 503 504 /500.html;
      location = /500.html {
        root /home/rails/apps/mip/production/current/public;
      }

Ich habe 4 Thin-Server gestartet, die wie folgt an Sockets angeschlossen sind:

RAILS_ENV=production bundle exec thin start --socket /home/rails/apps/mip/production/shared/sockets/thin.1.sock

Ich sehe, dass die Sockets dort sind, wo sie sein sollen. Ich habe versucht, einen zu löschen und wget auszuführen.http://localhost, das Folgendes zurückgibt:

2018/03/14 10:23:34 [error] 184654#0: *1 connect() to unix:///home/rails/apps/mip/production/shared/sockets/thin.3.sock failed (111: Connection refused) while connecting to upstream, client: 127.0.0.1, server: , request: "GET /login HTTP/1.1", upstream: "http://unix:///home/rails/apps/mip/production/shared/sockets/thin.3.sock:/login", host: "localhost"

Dieser Fehler erscheint nur im Protokoll, wenn ich einen der Sockets gelöscht habe, sodass sie wie vorgesehen gelesen werden. Das Zugriffsprotokoll lautet:

27.0.0.1 - - [14/Mar/2018:10:23:34 +0000] "GET / HTTP/1.1" 302 99 "-" "Wget/1.15 (linux-gnu)"
127.0.0.1 - - [14/Mar/2018:10:23:34 +0000] "GET /login HTTP/1.1" 200 1231 "-" "Wget/1.15 (linux-gnu)"
127.0.0.1 - - [14/Mar/2018:10:29:40 +0000] "GET / HTTP/1.1" 302 99 "-" "Wget/1.15 (linux-gnu)"
127.0.0.1 - - [14/Mar/2018:10:29:40 +0000] "GET /login HTTP/1.1" 200 1231 "-" "Wget/1.15 (linux-gnu)"
127.0.0.1 - - [14/Mar/2018:10:29:46 +0000] "GET /login HTTP/1.1" 200 1231 "-" "Wget/1.15 (linux-gnu)"

Dieses Protokoll zeigt nur lokale Anfragen. Wenn ich die öffentliche IP remote besuche, wird es nicht registriert.

Ich habe versucht zu suchen, kann aber keinen Rat finden, wie ich nginx dazu bringen kann, auf jemanden zu antworten, der die IP-Adresse besucht, anstatt auf eine lokale Anfrage. Jede Hilfe ist sehr willkommen

BEARBEITEN: sudo netstat -tulpn gibt zurück:

tcp        0      0 127.0.0.1:3306          0.0.0.0:*               LISTEN      1556/mysqld     
tcp        0      0 127.0.0.1:6379          0.0.0.0:*               LISTEN      1605/redis-server 1
tcp        0      0 0.0.0.0:80              0.0.0.0:*               LISTEN      194492/nginx    
tcp        0      0 0.0.0.0:22              0.0.0.0:*               LISTEN      1469/sshd       
tcp        0      0 127.0.0.1:6392          0.0.0.0:*               LISTEN      1429/redis-server 1
tcp6       0      0 :::22                   :::*                    LISTEN      1469/sshd  

Answer 1

Es stellte sich heraus, dass der Server, auf den ich zugegriffen habe, keinen direkten Zugriff auf öffentliche Anfragen hatte, sondern über einen zweiten Server geleitet wurde, der keine Anfragen an nginx weiterleitete, wie es vorgesehen war.