fragen stichworte

Nginx wirft weiterhin Nginx: [emerg] bind () auf 0.0.0.0:80 fehlgeschlagen (98: Adresse wird bereits verwendet)

Ich habe viele Websites überprüft und hier in ServerFault viele Fragen/Antworten zu diesem Problem beantwortet. Ich scheine jedoch nicht in die Wurzel des Konfigurationsfehlers zu geraten.

Ich habe 4 Domänen auf meinem Nginx-Server:

  • example.com
  • www.example.com
  • api.example.com
  • blog.example.com

Sie sind alle in den Ports 80 und 443 in Betrieb. Dies ist die Vorlage nginx.conf, die ich für alle verwendet habe, und ändert nur die Direktiven server_name, root, error_log und access_log . Es gibt einige andere Änderungen, die sich im Prinzip jedoch nicht auswirken sollten. Wie anders fastcgi_param.

Dies ist die Vorlage für example.com und www.example.com:

server {
listen 80;

server_name example.com www.example.com;
root/var/www/example.com/public_html/web;

if ($http_host = example.com) {
    return 301 https://www.example.com$request_uri;
}

location/{
    # try to serve file directly, fallback to front controller
    try_files $uri/index.php$is_args$args;
}

location ~ ^/index\.php(/|$) {
    fastcgi_pass   unix:/var/run/php/php7.0-fpm.sock;

    fastcgi_split_path_info ^(.+\.php)(/.*)$;
    include fastcgi_params;
    fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
    fastcgi_param HTTPS off;
    fastcgi_param   DATABASE_NAME           some_database;
    fastcgi_param   DATABASE_USER           some_user;
    fastcgi_param   DATABASE_PASSWORD       some_pwd;
}

#return 404 for all php files as we do have a front controller
location ~ \.php$ {
    return 404;
}

error_log/var/log/nginx/www.example.com_error.log;
access_log/var/log/nginx/www.example.com_access.log;

# Redirect non-https traffic to https
if ($scheme != "https") {
    return 301 https://$host$request_uri;
} # managed by Certbot


listen 443 ssl; # managed by Certbot
ssl_certificate/etc/letsencrypt/live/example.com/fullchain.pem; # managed by Certbot
ssl_certificate_key/etc/letsencrypt/live/example.com/privkey.pem; # managed by Certbot
include/etc/letsencrypt/options-ssl-nginx.conf; # managed by Certbot
ssl_dhparam/etc/letsencrypt/ssl-dhparams.pem; # managed by Certbot

}

Dies ist der genaue Fehler, den ich beim Neustart des Servers bekomme:

root@vps_server:/etc/nginx# journalctl -xe
Mar 09 09:17:16 vps_server systemd[1]: Starting A high performance web server and a reverse proxy server...
-- Subject: Unit nginx.service has begun start-up
-- Defined-By: systemd
-- Support: http://www.ubuntu.com/support
-- 
-- Unit nginx.service has begun starting up.
Mar 09 09:17:16 vps_server nginx[30764]: nginx: [emerg] bind() to 0.0.0.0:80 failed (98: Address already in use)
Mar 09 09:17:16 vps_server nginx[30764]: nginx: [emerg] bind() to 0.0.0.0:443 failed (98: Address already in use)
Mar 09 09:17:16 vps_server nginx[30764]: nginx: [emerg] bind() to 0.0.0.0:80 failed (98: Address already in use)
Mar 09 09:17:16 vps_server nginx[30764]: nginx: [emerg] bind() to 0.0.0.0:443 failed (98: Address already in use)
Mar 09 09:17:17 vps_server nginx[30764]: nginx: [emerg] bind() to 0.0.0.0:80 failed (98: Address already in use)
Mar 09 09:17:17 vps_server nginx[30764]: nginx: [emerg] bind() to 0.0.0.0:443 failed (98: Address already in use)
Mar 09 09:17:17 vps_server nginx[30764]: nginx: [emerg] bind() to 0.0.0.0:80 failed (98: Address already in use)
Mar 09 09:17:17 vps_server nginx[30764]: nginx: [emerg] bind() to 0.0.0.0:443 failed (98: Address already in use)
Mar 09 09:17:18 vps_server nginx[30764]: nginx: [emerg] bind() to 0.0.0.0:80 failed (98: Address already in use)
Mar 09 09:17:18 vps_server nginx[30764]: nginx: [emerg] bind() to 0.0.0.0:443 failed (98: Address already in use)
Mar 09 09:17:18 vps_server nginx[30764]: nginx: [emerg] still could not bind()
Mar 09 09:17:18 vps_server systemd[1]: nginx.service: Control process exited, code=exited status=1
Mar 09 09:17:18 vps_server systemd[1]: Failed to start A high performance web server and a reverse proxy server.
-- Subject: Unit nginx.service has failed
-- Defined-By: systemd
-- Support: http://www.ubuntu.com/support
-- 
-- Unit nginx.service has failed.
-- 
-- The result is failed.
Mar 09 09:17:18 vps_server systemd[1]: nginx.service: Unit entered failed state.
Mar 09 09:17:18 vps_server systemd[1]: nginx.service: Failed with result 'exit-code'.

Wenn ich versuche, die Zertifikate mit sudo certbot renew --dry-run zu erneuern, erhalte ich einen ähnlichen Fehler, obwohl er nicht genau derselbe ist.

Wenn ich die Nginx-Threads abschalte, kann ich den Server neu starten. Aber beim nächsten Neustart wirft es den gleichen Fehler. Und das Schlimmste ist, dass es mir nicht gelingt, meine SSL-Zertifikate zu erneuern (obwohl dies aus einem anderen Grund liegen könnte und ich hier nicht gerne etwas hinzufügen möchte, da dies der Grund sein könnte).

BEARBEITEN

Ich habe einen lokalen Computer mit Vagrant mit derselben Konfiguration eingerichtet, mit der Ausnahme, dass ich die SSL-Zertifikatsdaten kommentiert habe. Ich kann den Server ohne Probleme neu starten. Vielleicht hat es etwas mit der Konfiguration von Certbot/SSL zu tun.

Zur Unterstützung beim Debuggen dieses Problems finden Sie hier die Ausgabe von netstat -tulpn (nur Nginx verwendet die Ports 80 und 443, was meines Erachtens die erwartete Ausgabe ist):

/var/log/nginx# netstat -tulpn
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address           Foreign Address         State       PID/Program name    
tcp        0      0 127.0.0.1:3306          0.0.0.0:*               LISTEN      16700/mysqld        
tcp        0      0 0.0.0.0:5355            0.0.0.0:*               LISTEN      1578/systemd-resolv 
tcp        0      0 0.0.0.0:80              0.0.0.0:*               LISTEN      30608/nginx: master 
tcp        0      0 0.0.0.0:22              0.0.0.0:*               LISTEN      1675/sshd           
tcp        0      0 0.0.0.0:25              0.0.0.0:*               LISTEN      10001/master        
tcp        0      0 0.0.0.0:443             0.0.0.0:*               LISTEN      30608/nginx: master 
tcp6       0      0 :::5355                 :::*                    LISTEN      1578/systemd-resolv 
tcp6       0      0 :::22                   :::*                    LISTEN      1675/sshd           
tcp6       0      0 :::25                   :::*                    LISTEN      10001/master        
udp        0      0 127.0.0.53:53           0.0.0.0:*                           1578/systemd-resolv 
udp        0      0 0.0.0.0:68              0.0.0.0:*                           1343/dhclient       
udp        0      0 0.0.0.0:5355            0.0.0.0:*                           1578/systemd-resolv 
udp6       0      0 :::5355                 :::*                                1578/systemd-resolv

antworten

Wie sieht Ihr nginx.conf aus? Ich gehe davon aus, dass Sie die Konfiguration nicht geändert haben. Möglicherweise haben Sie nur den gzip und einen neuen Include-Ordner hinzugefügt, um einen separaten Speicherort für die Websites zu haben. Für jede Ihrer Domains/Sub-Domains gibt es eine eigene Konfigurationsdatei. Wie:

  • example.com & amp; www.example.com
  • api.example.com
  • blog.example.com

Dies liegt daran, dass ich davon ausgehe, dass dies separate Websites unter derselben Domain sind. Wenn sie sich auf derselben Website befinden und es sich lediglich um eine sogenannte Unterseite handelt, können Sie nur Unterseiten mit den Standortoptionen erstellen.

Um Ihre nginx -Konfiguration neu zu organisieren, würde ich eine com.example.conf -Datei mit 3 separaten Serverabschnitten erstellen. Zuerst müssen Sie die Nicht-WWW-Benutzer zur WWW-Website umleiten:

server {
    listen       80;
    server_name  example.com;
    return       301 https://www.example.com$request_uri;
}

server {
    listen       443 ssl;
    server_name  example.com;
    return       301 https://www.example.com$request_uri;
}

Der dritte Abschnitt enthält die Hauptsite:

server {
    listen 443 ssl;

    server_name example.com www.example.com;

    root/var/www/example.com/public_html/web;

    index    index.php;

    error_log/var/log/nginx/www.example.com_error.log;
    access_log/var/log/nginx/www.example.com_access.log;

    location/{
        # try to serve file directly, fallback to front controller
        try_files $uri/index.php$is_args$args;
    }

    location ~ ^/index\.php(/|$) {
        fastcgi_pass   unix:/var/run/php/php7.0-fpm.sock;

        fastcgi_split_path_info ^(.+\.php)(/.*)$;
        include fastcgi_params;
        fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
        fastcgi_param HTTPS off;
        fastcgi_param   DATABASE_NAME           some;
        fastcgi_param   DATABASE_USER           some_user;
        fastcgi_param   DATABASE_PASSWORD       some_pwd;
    }

    location ~ \.php$ {
        return 404;
    }
}

(Ich muss sagen, Ihr fastcgi-Part in Ihrer index.php-Position sieht für mich komisch aus, aber das überlasse ich Ihnen)

Erstellen Sie dann separate Konfigurationsdateien als com.example.api.conf und com.example.blog.conf. Fügen Sie die ersten beiden Abschnitte der vorherigen Konfiguration auf ähnliche Weise wie zuvor hinzu. Dann können Sie jeder Subdomäne eine andere Konfiguration für die Speicherorte hinzufügen.

Zum Beispiel habe ich folgendes für meine Laravel-Websites:

rewrite ^/index\.php?(.*)$/$1 permanent;

location/{
        try_files $uri @rewrite;
}

location        @rewrite {
        rewrite ^(.*)$/index.php/$1 last;
}
location ~ ^/index.php(/|$) {
        fastcgi_pass 127.0.0.1:9000;
        fastcgi_split_path_info ^(.+\.php)(/.*)$;
        include fastcgi_params;
        fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
        fastcgi_param HTTPS on;
        fastcgi_buffers 16 16k;
        fastcgi_buffer_size 32k;
        fastcgi_read_timeout 299;
}

Ich hoffe, dies hilft Ihnen, wenn Sie Ihre Fragen nicht kommentieren.