înregistrare Logare
Puncte:1
avatar Server

Site-ul web NginX returnează pagina implicită cu HTTP (HTTPS funcționează corect)

drapel br
Andrew Swift

Acest are sa fie un duplicat, dar caut de mult si nu am gasit nimic.

Când introduc adresa site-ului meu folosind http, înțeleg Pagina implicită NginX (https funcționează bine):

http://svija.love

Fișierul de configurare NginX conține, la sfârșit:

Server {
    if ($gazdă = svija.love) {
        returnează 301 https://$host$request_uri;
    } # gestionat de Certbot

    nume_server svija.love;
    asculta 80;
    întoarce 404; # gestionat de Certbot
}

Acesta a fost adăugat automat de Certbot.

M-aș aștepta ca declarația dacă ($gazdă = svija.love) ar prinde cererea http și va redirecționa către HTTPS.

Dar nu funcționează așa.

Nefiind expert, mi se pare că al doilea bit, începând cu nume_server svija.love, este în contradicție directă cu prima parte:

  • primul bloc redirecționează dacă gazda este svija.love
  • al doilea bloc returnează 404 dacă gazda este svija.love

Numele actual al serverului configurat este live.svija.love, dacă asta face diferența.

Orice clarificare ar fi foarte apreciată.

[ACTUALIZAȚI] Am eliminat fișierul de configurare implicit NginX și HTTP acum redirecționează către HTTPS așa cum era de așteptat.

Totuși, dacă cineva poate explica cele două blocuri de configurare de mai sus, mi-ar plăcea să înțeleg mai bine ce fac.

[ACTUALIZAȚI] Aceasta nu a fost o soluție bună (vezi mai jos).

[ACTUALIZAȚI Iată configurația dată de nginx -T:

# fișier de configurare /etc/nginx/nginx.conf:
utilizator www-date;
worker_proceses auto;
pid /run/nginx.pid;
includ /etc/nginx/modules-enabled/*.conf;

evenimente {
    conexiuni_muncitor 768;
    # multi_accept on;
}

http {

    ##
    # Setări de bază
    ##

    sendfile dezactivat;
    tcp_nopush activat;
    tcp_nodelay activat;
    keepalive_timeout 65;
    types_hash_max_size 2048;
    # server_tokens off;

    # server_names_hash_bucket_size 64;
    # server_name_in_redirect off;

    includ /etc/nginx/mime.types;
    aplicație de tip_default/octet-stream;

    ##
    # Setări SSL
    ##

    ssl_protocols TLSv1 TLSv1.1 TLSv1.2 TLSv1.3; # Eliminarea SSLv3, ref: POODLE
    ssl_prefer_server_ciphers activat;

    ##
    # Setări de înregistrare
    ##

    access_log /var/log/nginx/access.log;
    error_log /var/log/nginx/error.log;

    ##
    # Setări Gzip
    ##

    gzip on;

    # gzip_vary on;
    # gzip_proxied orice;
    # 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;

    ##
    # Configurații gazdă virtuală
    ##

    includ /etc/nginx/conf.d/*.conf;
    includ /etc/nginx/sites-enabled/*;
}

# fișier de configurare /etc/nginx/modules-enabled/50-mod-http-image-filter.conf:
load_module modules/ngx_http_image_filter_module.so;

# fișier de configurare /etc/nginx/modules-enabled/50-mod-http-xslt-filter.conf:
load_module modules/ngx_http_xslt_filter_module.so;

# fișier de configurare /etc/nginx/modules-enabled/50-mod-mail.conf:
load_module modules/ngx_mail_module.so;

# fișier de configurare /etc/nginx/modules-enabled/50-mod-stream.conf:
load_module modules/ngx_stream_module.so;

# fișier de configurare /etc/nginx/mime.types:

Server {

    # trebuie să se potrivească cu numele de domeniu sau adresa IP
    # sau altfel va fi afișată pagina Nginx implicită
    nume_server antretoise.svija.site;

    # director cu elementele statice ale site-ului
    locație /static/ {
        rădăcină /acasă/antretoise;
    }

    access_log /opt/logs/access.antretoise;
    error_log /opt/logs/error.antretoise eroare;

    # transmiteți toate întrebările suplimentare aplicației noastre
    Locație / {

        # parametri din /etc/nginx/uwsgi_params
        include uwsgi_params;

        # trece traficul la priză
        # pe care serverul uWSGI îl setează
        # PRIZE TREBUIE SE POATE ÎN:
        # /etc/uwsgi/sites/antretoise.ini
        uwsgi_pass unix:/run/uwsgi/antretoise.sock;
    }

    asculta 443 ssl; # gestionat de Certbot
    ssl_certificate /etc/letsencrypt/live/antretoise.svija.site/fullchain.pem; # gestionat de Certbot
    ssl_certificate_key /etc/letsencrypt/live/antretoise.svija.site/privkey.pem; # gestionat de Certbot
    includ /etc/letsencrypt/options-ssl-nginx.conf; # gestionat de Certbot
    ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem; # gestionat de Certbot

}


Server {
    if ($gazdă = antretoise.svija.site) {
        returnează 301 https://$host$request_uri;
    } # gestionat de Certbot


    asculta 80;
    nume_server antretoise.svija.site;
    întoarce 404; # gestionat de Certbot


}
# fișier de configurare /etc/nginx/uwsgi_params:

uwsgi_param QUERY_STRING $șir_interogare;
uwsgi_param REQUEST_METHOD $cerere_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 $schemă;
uwsgi_param HTTPS $https dacă_nu_vide;

uwsgi_param REMOTE_ADDR $adresă_la distanță;
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 dezactivat;

ssl_ciphers „EC-AES128-SHA”;

#… ½ âââââââ implicit

Server {
    asculta 80 default_server;
    asculta [::]:80 default_server;

    rădăcină /var/www/html;

    # Adăugați index.php la listă dacă utilizați PHP
    index index.html index.htm index.nginx-debian.html;

    numele serverului _;

    Locație / {
        # Mai întâi încercați să serviți cererea ca fișier, apoi
        # ca director, apoi reveniți la afișarea unui 404.
        try_files $uri $uri/ =404;
    }

}

#… ½ âââââââ svija.love

Server {

    nume_server svija.love;

    # director cu elementele statice ale site-ului
    locație /static/ {
        rădăcină /home/svijalove;
    }

    access_log /opt/logs/access.svijalove;
    error_log /opt/logs/error.svijalove eroare;

    # transmiteți toate întrebările suplimentare aplicației noastre
    Locație / {

        # parametri din /etc/nginx/uwsgi_params
        include uwsgi_params;

        # trece traficul la priză
        # pe care serverul uWSGI îl setează
        # PRIZE TREBUIE SE POATE ÎN:
        # /etc/uwsgi/sites/svijalove.ini
        uwsgi_pass unix:/run/uwsgi/svijalove.sock;
    }

    asculta 443 ssl; # gestionat de Certbot
    ssl_certificate /etc/letsencrypt/live/svija.love/fullchain.pem; # gestionat de Certbot
    ssl_certificate_key /etc/letsencrypt/live/svija.love/privkey.pem; # gestionat de Certbot
    includ /etc/letsencrypt/options-ssl-nginx.conf; # gestionat de Certbot
    ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem; # gestionat de Certbot
}

Server {
    if ($gazdă = svija.love) {
        returnează 301 https://$host$request_uri;
    } # gestionat de Certbot

    nume_server svija.love;
    asculta 80;
    întoarce 404; # gestionat de Certbot
}

# 6 alte site-uri la final, toate configurate la fel
# cu excepția faptului că în ultimele două rânduri,
# asculta 80; este uneori listat ÎNAINTE de returnare 404;
449
0 + 0
drapel in
Gerald Schneider
FYI: Când întreb `http://svija.love`, primesc o redirecționare către `https://svija.love/` care are ca rezultat un 500. După aceea, wget reîncearcă a doua solicitare și primește un 200. Nu obțineți un 404. Pentru 500 trebuie să vă verificați jurnalele serverului.
0
Răspunde
drapel br
Andrew Swift
Cum ai făcut interogarea? Îmi dau seama că am afirmat greșit problema â nu este un 404 pe care îl primesc (în browserul meu), ci pagina implicită NginX (am rezolvat întrebarea). Nu văd eroarea 500, dar voi verifica jurnalul.
0
Răspunde
drapel in
Gerald Schneider
Doar un simplu `wget -S http://svija.love`
1
Răspunde
drapel br
Andrew Swift
Am eliminat configurația implicită NginX, iar acum redirecționează corect. Mă aștept că a fost pentru că a interpretat configurația implicită înainte de a ajunge la configurația svija.love.
0
Răspunde
drapel us
Tero Kilkanen
Vă rugăm să adăugați configurația completă nginx care este dată de comanda `nginx -T`.
0
Răspunde
drapel us
Tero Kilkanen
Singura mea presupunere este că blocul `if` înainte de `server_name` deranjează cumva nginx. De obicei, încep blocul `server` cu `ascultă`, `nume_server` deasupra pentru lizibilitate și apoi alte directive.
1
Răspunde
drapel us
Tero Kilkanen
O altă opțiune pentru depanare este să activați jurnalele de depanare nginx utilizând `error_log /opt/logs/error.antretoise debug;` În funcție de distribuție, ar putea fi necesar ca nginx să fie pornit cu o comandă diferită. Cu jurnalul de depanare, se poate vedea cum exact nginx gestionează cererea intern.
0
Răspunde
drapel br
Andrew Swift
Am petrecut câteva ore uitându-mă la jurnalele și am încercat diverse modificări ale fișierelor de configurare, fără succes. În cele din urmă, a început să funcționeze cu configurația originală (vezi răspunsul pe care l-am postat) â posibil un fel de problemă de cache DNS. Vă mulțumesc pentru sugestii, mi-au dat curajul să continui să încerc și idei despre ce să încerc.
0
Răspunde
Puncte:2
avatar Server
drapel us
Tero Kilkanen

If there is no matching virtual host for the Host header in the request, then nginx will serve the default virtual host content.

In your case, your virtual host matches the Host field with svija.love. However, it seems you were testing with live.svija.love.

Since nginx cannot find the matching virtual host, it uses its default one.

After you deleted the default virtual host configuration, nginx uses your virtual host as the default virtual host. That is not a good practice. Anyone could set up a DNS record for a domain that points to your website. The end result would be that http://example.com would show contents of http://live.svija.love.

That could result in Google penalties for duplicate content.

To prevent this, you should restore the default virtual host, and adjust your current configuration for correct server_name.

0 + 0
drapel br
Andrew Swift
Nu testam cu live.svija.love â acesta este numele serverului (/etc/hosts), dar nu am încercat niciodată să vizitez serverul la acea adresă. Voi restabili setarea implicită așa cum sugerați și voi vedea dacă o pot face să funcționeze pe baza răspunsului dvs.
0
Răspunde
drapel br
Andrew Swift
Acum, când vizitez svija.love, primesc din nou pagina implicită NginX. Ceea ce nu înțeleg este de ce svija.love nu se potrivește cu „dacă ($host = svija.love) {” în configurație.
0
Răspunde
drapel br
Andrew Swift
Am adăugat configurația completă nginx la întrebare.
0
Răspunde
Puncte:0
avatar Server
drapel br
Andrew Swift

Am rezolvat problema fara sa inteleg cu adevarat.

Există șapte site-uri web pe serverul meu și șase funcționează corect (http redirecționează către https așa cum era de așteptat.)

Toate cele șapte site-uri conțin un bloc la sfârșitul fișierelor lor de configurare NginX, care seamănă cu acesta:

Server {

# redirecționează traficul de la http la https pentru fiecare domeniu relevant

    if ($gazdă = svija.love) {
        returnează 301 https://$host$request_uri;
    } # gestionat de Certbot

# se asigură că orice cereri capturate nu sunt redirecționate din greșeală

    asculta 80;
    nume_server svija.love;
    întoarce 404; # gestionat de Certbot
}

Gazda serverului real este live.svija.love, dar site-ul care a avut probleme este pur și simplu svija.dragoste (nu există niciun site web configurat pentru live.svija.love).

A devenit evident că problema a fost cauzată de faptul că următoarea linie nu a fost evaluată corect:

if ($gazdă = svija.love) {

Între paranteze, nu a existat o configurație IPv6 pentru server (live.svija.love), și a existat o configurație IPv6 pentru site-ul web (svija.love), care nu ar fi trebuit să existe.

Am adăugat înregistrarea IPv6 pentru server și am șters-o pentru site-ul web.
Acest lucru nu a afectat problema.

Apoi m-am gândit că poate $gazdă variabila a fost setată la live.svija.love (cine știe de ce), așa că am încercat un test unde m-am schimbat

if ($gazdă = svija.love) {

la

dacă ($gazdă = live.svija.love) {

După cum era de așteptat, pagina implicită NginX a fost înlocuită cu o eroare 404 (vezi blocul de configurare de mai sus).

Deci, am pus înapoi

dacă ($gazdă = live.svija.love) {

și acum totul funcționează corect. Solicitările HTTP către svija.love sunt redirecționate către https://svija.love si problema mea este rezolvata.

Presupun că a existat un fel de mecanism de stocare în cache DNS în NginX care a eșuat, probabil din cauza faptului că am schimbat numele serverului la un moment dat în trecut.

0 + 0
drapel romania
SEF 777
întrebarea această in alte limbi:

Postează un răspuns

Majoritatea oamenilor nu înțeleg că a pune multe întrebări deblochează învățarea și îmbunătățește legătura interpersonală. În studiile lui Alison, de exemplu, deși oamenii își puteau aminti cu exactitate câte întrebări au fost puse în conversațiile lor, ei nu au intuit legătura dintre întrebări și apreciere. În patru studii, în care participanții au fost implicați în conversații ei înșiși sau au citit transcrieri ale conversațiilor altora, oamenii au avut tendința să nu realizeze că întrebarea ar influența – sau ar fi influențat – nivelul de prietenie dintre conversatori.