☰

Nginx 与 Varnish：所有 listen 指令都指向 808* 端口，但 nginx 仍然监听 80

tag-icon • tag-icon nginx varnish
Nginx 与 Varnish：所有 listen 指令都指向 808* 端口，但 nginx 仍然监听 80

我在两台 Debian 服务器上运行 Symfony 或 Drupal 网站的实例，其中 Nginx 监听 443，Varnish 监听 80，并将监听每个 vhost 的自定义端口 80** 传递给 nginx。

最近，我在一台服务器上添加了一个新网站。然后我开始遇到这个有据可查的错误nginx：[emerg] bind() 至 [::]: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正确的新语法，并且尝试了，据我所知，所有可能的语法，例如下面，但没有办法。

崩溃前的工作指令：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;
}

其中一个站点可用的虚拟主机（它们都遵循完全相同的模式）：

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;
        }
}

猫/etc/默认/清漆有关部分

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 中）。

答案1

好吧，感谢@MichaelHampton，我意识到搜索到的 listen 指令隐藏在certbot 挑战，在 nginx.conf 中通过 include 调用：

# 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;}}

这强调了两个基本教训（至少对我自己而言）：

  1. 紧急情况下，不要快速搜索，但速度较慢，花时间真正评价您阅读的每一行：这包括我的 HTTP 块的第一行！
  2. 具体来说，对于 Nginx 来说，这个简单的 CLINginx -T是一个杀手级工具：输出每个配置文件的每一行的内联版本，它提供了一种强大的方法来立即找到罪魁祸首：nginx -T | grep ':80'会让我在几秒钟内走上正轨！

相关内容