Я запускаю экземпляры сайтов 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 основных урока (по крайней мере, для меня):
Nginx -T
- инструмент-убийца: вывод встроенной версии каждой отдельной строки каждого файла конфигурации дает мощный способ немедленно найти виновника: nginx -T | grep ':80'
поставил бы меня на верный путь за секунды!