Isso deve ser uma duplicata, mas estou procurando há muito tempo e não encontrei nada.
Quando digito o endereço do meu site usando http , recebo a página padrão do NginX (https funciona bem):
http://svija.love
O arquivo de configuração do NginX contém, no final:
server {
if ($host = svija.love) {
return 301 https://$host$request_uri;
} # managed by Certbot
server_name svija.love;
listen 80;
return 404; # managed by Certbot
}
Isso foi adicionado automaticamente pelo Certbot .
Eu esperaria que a declaração if ($host = svija.love) pegasse a solicitação http e redirecionasse para HTTPS.
Mas não está funcionando assim.
Não sendo especialista, parece-me que o segundo bit, começando com server_name svija.love , está em contradição direta com a primeira parte:
- o primeiro bloco redireciona se o host for svija.love
- o segundo bloco retorna 404 se o host for svija.love
O nome real do servidor configurado é live.svija.love , se isso fizer diferença.
Qualquer esclarecimento seria muito apreciado.
[ATUALIZAÇÃO] Eu removi o arquivo de configuração padrão do NginX e o HTTP agora redireciona para HTTPS conforme o esperado.
Ainda assim, se alguém puder explicar os dois blocos de configuração acima, adoraria entender melhor o que eles estão fazendo.
[ATUALIZAÇÃO] Esta não foi uma boa solução (veja abaixo).
[UPDATE Aqui está a configuração dada por nginx -T :
# configuration file /etc/nginx/nginx.conf:
user www-data;
worker_processes auto;
pid /run/nginx.pid;
include /etc/nginx/modules-enabled/*.conf;
events {
worker_connections 768;
# multi_accept on;
}
http {
##
# Basic Settings
##
sendfile off;
tcp_nopush on;
tcp_nodelay on;
keepalive_timeout 65;
types_hash_max_size 2048;
# server_tokens off;
# server_names_hash_bucket_size 64;
# server_name_in_redirect off;
include /etc/nginx/mime.types;
default_type application/octet-stream;
##
# SSL Settings
##
ssl_protocols TLSv1 TLSv1.1 TLSv1.2 TLSv1.3; # Dropping SSLv3, ref: POODLE
ssl_prefer_server_ciphers on;
##
# Logging Settings
##
access_log /var/log/nginx/access.log;
error_log /var/log/nginx/error.log;
##
# Gzip Settings
##
gzip on;
# gzip_vary on;
# gzip_proxied any;
# gzip_comp_level 6;
# gzip_buffers 16 8k;
# gzip_http_version 1.1;
# gzip_types text/plain text/css application/json application/javascript text/xml application/xml application/xml+rss text/javascript;
##
# Virtual Host Configs
##
include /etc/nginx/conf.d/*.conf;
include /etc/nginx/sites-enabled/*;
}
# configuration file /etc/nginx/modules-enabled/50-mod-http-image-filter.conf:
load_module modules/ngx_http_image_filter_module.so;
# configuration file /etc/nginx/modules-enabled/50-mod-http-xslt-filter.conf:
load_module modules/ngx_http_xslt_filter_module.so;
# configuration file /etc/nginx/modules-enabled/50-mod-mail.conf:
load_module modules/ngx_mail_module.so;
# configuration file /etc/nginx/modules-enabled/50-mod-stream.conf:
load_module modules/ngx_stream_module.so;
# configuration file /etc/nginx/mime.types:
server {
# must match domain name or IP address
# or else the default Nginx page will be shown
server_name antretoise.svija.site;
# directory of site's static elements
location /static/ {
root /home/antretoise;
}
access_log /opt/logs/access.antretoise;
error_log /opt/logs/error.antretoise error;
# pass all additional queries to our application
location / {
# parameters from /etc/nginx/uwsgi_params
include uwsgi_params;
# pass the traffic to the socket
# that the uWSGI server sets up
# SOCKETS MUST MATCH IN:
# /etc/uwsgi/sites/antretoise.ini
uwsgi_pass unix:/run/uwsgi/antretoise.sock;
}
listen 443 ssl; # managed by Certbot
ssl_certificate /etc/letsencrypt/live/antretoise.svija.site/fullchain.pem; # managed by Certbot
ssl_certificate_key /etc/letsencrypt/live/antretoise.svija.site/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
}
server {
if ($host = antretoise.svija.site) {
return 301 https://$host$request_uri;
} # managed by Certbot
listen 80;
server_name antretoise.svija.site;
return 404; # managed by Certbot
}
# configuration file /etc/nginx/uwsgi_params:
uwsgi_param QUERY_STRING $query_string;
uwsgi_param REQUEST_METHOD $request_method;
uwsgi_param CONTENT_TYPE $content_type;
uwsgi_param CONTENT_LENGTH $content_length;
uwsgi_param REQUEST_URI $request_uri;
uwsgi_param PATH_INFO $document_uri;
uwsgi_param DOCUMENT_ROOT $document_root;
uwsgi_param SERVER_PROTOCOL $server_protocol;
uwsgi_param REQUEST_SCHEME $scheme;
uwsgi_param HTTPS $https if_not_empty;
uwsgi_param REMOTE_ADDR $remote_addr;
uwsgi_param REMOTE_PORT $remote_port;
uwsgi_param SERVER_PORT $server_port;
uwsgi_param SERVER_NAME $server_name;
ssl_session_cache shared:le_nginx_SSL:10m;
ssl_session_timeout 1440m;
ssl_session_tickets off;
ssl_protocols TLSv1.2 TLSv1.3;
ssl_prefer_server_ciphers off;
ssl_ciphers "EC-AES128-SHA";
#———————————————————————————————————————— default
server {
listen 80 default_server;
listen [::]:80 default_server;
root /var/www/html;
# Add index.php to the list if you are using PHP
index index.html index.htm index.nginx-debian.html;
server_name _;
location / {
# First attempt to serve request as file, then
# as directory, then fall back to displaying a 404.
try_files $uri $uri/ =404;
}
}
#———————————————————————————————————————— svija.love
server {
server_name svija.love;
# directory of site's static elements
location /static/ {
root /home/svijalove;
}
access_log /opt/logs/access.svijalove;
error_log /opt/logs/error.svijalove error;
# pass all additional queries to our application
location / {
# parameters from /etc/nginx/uwsgi_params
include uwsgi_params;
# pass the traffic to the socket
# that the uWSGI server sets up
# SOCKETS MUST MATCH IN:
# /etc/uwsgi/sites/svijalove.ini
uwsgi_pass unix:/run/uwsgi/svijalove.sock;
}
listen 443 ssl; # managed by Certbot
ssl_certificate /etc/letsencrypt/live/svija.love/fullchain.pem; # managed by Certbot
ssl_certificate_key /etc/letsencrypt/live/svija.love/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
}
server {
if ($host = svija.love) {
return 301 https://$host$request_uri;
} # managed by Certbot
server_name svija.love;
listen 80;
return 404; # managed by Certbot
}
# 6 other sites at end, all configured the same way
# except that in the last two lines,
# listen 80; is sometimes listed BEFORE return 404;
Se não houver um host virtual correspondente para o
Host
cabeçalho na solicitação, o nginx servirá o conteúdo do host virtual padrão.No seu caso, seu host virtual corresponde ao
Host
campo comsvija.love
. No entanto, parece que você estava testando comlive.svija.love
.Como o nginx não pode encontrar o host virtual correspondente, ele usa o host padrão.
Depois de excluir a configuração de host virtual padrão, o nginx usa seu host virtual como o host virtual padrão. Isso não é uma boa prática. Qualquer pessoa pode configurar um registro DNS para um domínio que aponta para seu site. O resultado final seria que
http://example.com
mostraria o conteúdo dehttp://live.svija.love
.Isso pode resultar em penalidades do Google por conteúdo duplicado.
Para evitar isso, você deve restaurar o host virtual padrão e ajustar sua configuração atual para o
server_name
.Eu resolvi o problema sem realmente entendê-lo.
Existem sete sites no meu servidor e seis funcionam corretamente (o http redireciona para https conforme o esperado.)
Todos os sete sites contêm um bloco no final de seus arquivos de configuração NginX semelhantes a este:
O host do servidor real é live.svija.love , mas o site que teve problemas é simplesmente svija.love (não há site configurado para live.svija.love).
Tornou-se óbvio que o problema foi causado pela seguinte linha não sendo avaliada corretamente:
Então pensei que talvez a variável $host estivesse configurada para live.svija.love (quem sabe por quê), então tentei um teste onde alterei
para
Como esperado, a página padrão do NginX foi substituída por um erro 404 (veja o bloco de configuração acima).
Então, eu coloquei de volta
e tudo agora funciona corretamente. As solicitações HTTP para svija.love são redirecionadas para https://svija.love e meu problema está resolvido.
Eu suponho que havia algum tipo de mecanismo de cache DNS no NginX que estava falhando, possivelmente porque eu mudei o nome do servidor em algum momento no passado.