我不知道该如何解决这个问题。每当我尝试使用 HTTP 打开网站时,我都会收到类似以下信息:
$ wget example.com
Connecting to example.com (example.com)|<IP_HERE>|:80... failed: No route to host.
同时,HTTPS 运行正常:
$ wget https://example.com
Connecting to example.com (example.com)|<IP_HERE>|:443... connected.
当然,我首先要查看的是防火墙和 nginx 配置。但是,ufw
显示端口 80 已打开:
$ ufw allow http
Skipping adding existing rule
Skipping adding existing rule (v6)
...在我的 nginx 配置中重定向到 HTTPS 背后的逻辑对我来说似乎相当不错:
listen 80; # 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
if ($scheme != "https") {
return 301 https://$host$request_uri;
} # managed by Certbot
我还尝试nmap
过从机器本身 ( nmap localhost
) 和外部位置 ( nmap <ip-here>
) 访问 (Ubuntu 16.04) 服务器。令人惊讶的是,HTTP 似乎从外部位置关闭了。禁用防火墙也无济于事。netstat -lnp | grep "80"
显示 nginx 确实在监听端口 80:
tcp 0 0 0.0.0.0:80 0.0.0.0:* LISTEN 8845/nginx -g daemo
nginx 日志中没有写入任何内容。
我不确定还能去哪里查找。我无法准确指出这个问题。
答案1
服务器重新启动后,我发现 nginx 出了问题(我无法启动它)。
然后我查看了journalctl -xe
一下,发现 nginx 缺少一个单独的 nginx 配置 ( php7.0-mbstring
) 的依赖项,导致它无法启动。奇怪的是,nginx -t
通过 systemd 执行并重新启动 nginx 后,在重新启动之前并没有发现该错误。
重启后,我确保安装了缺少的 PHP 依赖项。这使得 nginx 正确启动,并且从那时起 HTTP 流量转发到 HTTPS。
我对这个问题的核心的假设是,必须重新启动某个 PHP 进程(也许php7.0-fpm
,我真的不熟悉 PHP 生态系统)才能让 nginx 注意到依赖关系的变化,并且这两个问题的组合导致了一些真正意想不到的后果。