Назад | Перейти на главную страницу

Nginx с Varnish: все директивы listen указывают на порты 808 *, но nginx по-прежнему слушает 80

Я запускаю экземпляры сайтов Symfony или Drupal на двух серверах Debian, при этом Nginx слушает 443, Varnish слушает 80 и передает nginx для прослушивания пользовательских портов 80 ** для каждого виртуального хоста.

Недавно я добавил новый сайт на один из серверов. Затем я начал работать с этой вполне документированной ошибкой nginx: [emerg] bind () to [::]: 80 не удалось (98: адрес уже используется).

Несмотря на то, что серверный блок nginx вообще не слушает: порт 80, ни один серверный блок без директивы listen, Nginx начал прослушивать порт 80 вместе с настраиваемыми портами.

sudo netstat -tlpn| grep nginx
tcp        0      0 0.0.0.0:8080            0.0.0.0:*               LISTEN      4191/nginx: master  
tcp        0      0 0.0.0.0:80              0.0.0.0:*               LISTEN      4191/nginx: master  
tcp        0      0 0.0.0.0:8081            0.0.0.0:*               LISTEN      4191/nginx: master  
tcp        0      0 x.x.x.x:8082            0.0.0.0:*               LISTEN      4191/nginx: master  
tcp        0      0 y.y.y.y:8083            0.0.0.0:*               LISTEN      4191/nginx: master  
tcp        0      0 z.z.z.z:8084            0.0.0.0:*               LISTEN      4191/nginx: master  
tcp        0      0 0.0.0.0:443             0.0.0.0:*               LISTEN      4191/nginx: master  
tcp        0      0 0.0.0.0:8000            0.0.0.0:*               LISTEN      4191/nginx: master  
tcp6       0      0 :::8080                 :::*                    LISTEN      4191/nginx: master  
tcp6       0      0 :::80                   :::*                    LISTEN      4191/nginx: master  
tcp6       0      0 :::8081                 :::*                    LISTEN      4191/nginx: master  
tcp6       0      0 :::443                  :::*                    LISTEN      4191/nginx: master  
tcp6       0      0 :::8000                 :::*                    LISTEN      4191/nginx: master

Я уже прочитал кучу вопросов и сообщений о обработка двойного стека IPv4 и IPv6 исправьте новый синтаксис и пробовал, AFAIK, все возможные синтаксисы, такие как ниже, никоим образом.

Рабочая директива до сбоя: listen x.x.x.x:8082; Пытался добавить listen [::]:8082 ipv6only=on; . Без изменений.

Я перечислял и убивал процесс много раз с помощью sudo fuser -k 80/tcp перед перезапуском systemctl varnish, nginx, даже daemon-reload ...

Наконец, я проверил свою историю, но не смог найти, что могло вызвать такое внезапное поведение. Единственный момент, в котором я не уверен, я изменил пару параметров sysctl.conf, но, надеюсь, вернул их, на всякий случай, я не привык к этой части администрирования: cat /etc/sysctl.conf | grep net.ipv4.conf

#net.ipv4.conf.default.rp_filter=1
#net.ipv4.conf.all.rp_filter=1
#net.ipv4.conf.all.accept_redirects = 0
# net.ipv4.conf.all.secure_redirects = 1
#net.ipv4.conf.all.send_redirects = 0
#net.ipv4.conf.all.accept_source_route = 0
#net.ipv4.conf.all.log_martians = 1

Вот моя конфигурация.

кот /etc/nginx/nginx.conf (соответствующие 2 строки, в них нет серверного блока)

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

кот /etc/nginx/conf.d/default.conf

server {
        listen 8000 default_server;
        listen [::]:8000 ipv6only=on default_server;
        server_name _;

        listen 443 ssl default_server;
        listen [::]:443 ssl ipv6only=on default_server;
}

Один из доступных на сайтах vhosts (все они следуют одному шаблону):

server { # this block only redirects www to non www
        listen x.x.x.x:443 ssl;
        server_name www.example.com;

        ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
        ssl_certificate /var/www/clients/client0/web3/ssl/example.com-le.crt;
        ssl_certificate_key /var/www/clients/client0/web3/ssl/example.com-le.key;

        return 301 https://example.com$request_uri;
        }

server {
        listen x.x.x.x:443 ssl;
        server_name example.com

        ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
        ssl_certificate /var/www/clients/client0/web3/ssl/example.com-le.crt;
        ssl_certificate_key /var/www/clients/client0/web3/ssl/example.com-le.key;

        location / {
            # Pass the request on to Varnish.
            proxy_pass  http://127.0.0.1;
 
            # Pass some headers to the downstream server, so it can identify the host.
            proxy_set_header Host $host;
            proxy_set_header X-Real-IP $remote_addr;
            proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
 
            # Tell any web apps like Drupal that the session is HTTPS.
            proxy_set_header X-Forwarded-Proto https;
            proxy_redirect     off;
        }
        
}
server {
        listen x.x.x.x:8082;
#       listen [::]:8082 ipv6only=on;

        server_name example.com www.example.com;

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

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

       location ~ ^/index\.php(/|$) {
            fastcgi_pass 127.0.0.1:8998;
            fastcgi_split_path_info ^(.+\.php)(/.*)$;
            include fastcgi_params;
            fastcgi_param SCRIPT_FILENAME $realpath_root$fastcgi_script_name;
            fastcgi_param DOCUMENT_ROOT $realpath_root;
            internal;
        }
        location ~ \.php$ {
           # return 404;
        }

        error_log /var/log/ispconfig/httpd/example.com/error.log;
        access_log /var/log/ispconfig/httpd/example.com/access.log combined;

        location ~ /\. {
                        deny all;
        }

        location ^~ /.well-known/acme-challenge/ {
             access_log off;
             log_not_found off;
             root /usr/local/ispconfig/interface/acme/;
             autoindex off;
             try_files $uri $uri/ =404;
        }

        location = /favicon.ico {
            log_not_found off;
            access_log off;
            expires max;
            add_header Cache-Control "public, must-revalidate, proxy-revalidate";
        }

        location = /robots.txt {
            allow all;
            log_not_found off;
            access_log off;
        }
}

кошка / и т.д. / по умолчанию / лак соответствующая часть

DAEMON_OPTS="-a :80 \
             -T localhost:6082 \
             -f /etc/varnish/default.vcl \
             -S /etc/varnish/secret \
             -s malloc,3G"

Мне интересно, что могло вызвать ошибку в конфигурации, с которой я работаю годами?

Я внимательно изучил эти вопросы и ответы и кучу документов или сообщений, но безуспешно: Nginx пытается запустить 80-й порт, но конфигурации были удалены. ; Nginx не запускается (адрес уже используется) ; nginx - bind () до 0.0.0.0:80 не удалось (98: адрес уже используется)

РЕДАКТИРОВАТЬ

Вот результат nginx -T. (Поскольку тело ограничено 30000 символами, мне пришлось вставить его в pastebin).

Что ж, благодаря @MichaelHampton я понял, что искомая директива listen была скрыта в вызов certbot, вызывается в nginx.conf с включением:

# configuration file /etc/letsencrypt/le_http_01_cert_challenge.conf:
server{listen 80;listen [::]:80;server_name example.org;root /var/lib/letsencrypt/http_01_nonexistent;location = /.well-known/acme-challenge/PlsQNg7nOVxIe6CwwGpco
KTbSudji44JNZVQA57EyNE{default_type text/plain;return 200 PlsQNg7nOVxIe6CwwGpcoKTbSudji44JNZVQA57EyNE.7nkyfxInEw24UW4P7xfgJQGTMXYGQH_mzIOz6F0641Y;}} 

Это подчеркнуло 2 основных урока (по крайней мере, для меня):

  1. В экстренных случаях не ищите быстрее, но медленнее, уделяя время действительно оценить каждая строка, которую вы читаете: это включение было первой строкой моего блока HTTP !!!
  2. В частности, для Nginx этот простой интерфейс командной строки Nginx -T - инструмент-убийца: вывод встроенной версии каждой отдельной строки каждого файла конфигурации дает мощный способ немедленно найти виновника: nginx -T | grep ':80' поставил бы меня на верный путь за секунды!