-1

I'm trying to troubleshoot why a server won't respond to public requests. I have nginx running and the conf files are:

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/production.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;
      }

I have started 4 thin servers attached to sockets as such:

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

I can see that the sockets are where they are supposed to be, I have tried deleting one and running wget http://localhost, which returns:

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"

This error only appears in the log when I've deleted one of the sockets, so it's reading them as it should. The access log is:

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)"

This log only shows local requests, when I visit the public IP remotely it doesn't register.

I've tried searching but can't find any advice as to how to get nginx to respond to someone visiting the IP address rather than a local request. Any help is greatly appreciated

EDIT: sudo netstat -tulpn returns:

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  
Mark
  • 99
  • 2
  • What OS do you use? Might be silly, but maybe firewalld is blocking you? Also, consider commenting out `include /etc/nginx/conf.d/*.conf;` and adding a .conf to the end of `include /etc/nginx/sites-enabled/*;` Also.... have you linked your conf file to /etc/nginx/sites-enabled and restarted nginx? – Bert Mar 14 '18 at 14:08
  • Thanks for the help - turned out there was another server inbetween the one I had access to and public requests - they were all being redirected before they even hit nginx - thanks again for the help – Mark Mar 14 '18 at 14:09

1 Answers1

0

Turns out the server I was accessing didn't have direct access to public requests but was being routed through a second server, which wasn't forwarding any requests to nginx as it should have

Mark
  • 99
  • 2