Puncte:0

1 Gateway 2 Mașini 2 Domenii 3 Subdomenii, Cum să

drapel ug

Aveam o configurație de lucru în nginx doar pentru unul dintre site-urile mele web, dar am rupt-o când am încercat să o fac să funcționeze cu 2 domenii diferite, dintre care unul are 2 subdomenii, toate deservind site-uri sau aplicații diferite. Pentru a îngreuna lucrurile pentru mine, domeniul care rulează 2 aplicații se află pe o mașină separată și încerc să trimit cererile pentru acel domeniu către mașina corectă de pe LAN-ul meu. Vezi mai jos:

Arhitectura mea

Configurația mea NGINX este un dezastru, dar este după cum urmează:

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

    root /home/pi/sites/main;

    # Adăugați index.php la listă dacă utilizați PHP
    index index.html index.htm index.nginx-debian.html domain1_index.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;
    }
}

Server {

    root /home/pi/sites/main;

    index index.html index.htm index.nginx-debian.html;
    nume_server intern.domeniu1.info; # gestionat de Certbot


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


    asculta [::]:443 ssl ipv6only=on; # gestionat de Certbot
    asculta 443 ssl; # gestionat de Certbot
    ssl_certificate /etc/letsencrypt/live/internal.domain1.info/fullchain.pem; # gestionat de Certbot
    ssl_certificate_key /etc/letsencrypt/live/internal.domain1.info/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 {
    dacă ($gazdă = intern.domeniu1.info) {
        returnează 301 https://$host$request_uri;
    } # gestionat de Certbot


    asculta 80 ;
    asculta [::]:80 ;
    nume_server intern.domeniu1.info;
    întoarce 404; # gestionat de Certbot


}

Server {
  nume_server shiba.com www.shiba.com whispering.shiba.com;
  Locație / {
    proxy_pass http://<IP-ul mașinii2>:8888;
  }
}

Server {
  nume_server yelling.shiba.com;
  Locație / {
    proxy_pass http://<IP-ul mașinii2>:8555;
  }
}

Cum pot face ca acest lucru să servească site-uri web așa cum este specificat în imaginea mea? Mulțumiri.

Editare: noua configurație propusă de mine

|site-uri disponibile | link simbolic --> | site-uri activate
   conf1 | | conf1
#https site-ul web
Server {
    root /home/pi/sites/main;

    index index.html index.htm index.nginx-debian.html;
    
    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;
    }

    asculta [::]:443 ssl ipv6only=on; # gestionat de Certbot
    asculta 443 ssl; # gestionat de Certbot
    ssl_certificate /etc/letsencrypt/live/internal.domain1.info/fullchain.pem; # gestionat de Certbot
    ssl_certificate_key /etc/letsencrypt/live/internal.domain1.info/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
}
#http redirecționarea site-ului web
Server {
    dacă ($gazdă = intern.domeniu1.info) {
        returnează 301 https://$host$request_uri;
    } # gestionat de Certbot

    asculta 80 ;
    asculta [::]:80 ;
    nume_server intern.domeniu1.info;
    întoarce 404; # gestionat de Certbot
}
|site-uri disponibile | link simbolic --> | site-uri activate
   conf2 | | conf2
Server {
    asculta 80 ;
    asculta [::]:80 ;
    nume_server whispering.shiba.info;

    returnează 301 http://xxx.xxx.x.xx:8555;
}
|site-uri disponibile | link simbolic --> | site-uri activate
   conf3 | | conf3
Server {
    asculta 80 ;
    asculta [::]:80 ;
    nume_server yelling.shiba.info;

    returnează 301 http://xxx.xxx.x.xx:8888;
}
drookie avatar
drapel za
Folosești „server{}” implicit catchall împreună cu „server {}” care nu au „ascultă”. Probabil de aceea nimic nu funcționează corect. Și da, o parte a cauzei este că configurația ta este o mizerie. Se pare că urăști UNIX și nginx în special. Totul pare atât de temporar și dezastruos.
WhisperingShiba avatar
drapel ug
@drookie Este demoish, este prima mea configurație pe primul meu proiect. Am vrut să-mi piratez configurația existentă, dar în mod clar nu știu suficient. Sugerați să fac configurații separate în site-urile disponibile și să fie activate linkuri simbolice către site-uri sau ar trebui să am o configurație cu 3 servere pentru întreaga mea arhitectură sau 1 config, 1 server și 3 locații? Îmi este greu să caut chiar și metoda preferată de configurare a unui sistem ca acesta.
Nikita Kipriyanov avatar
drapel za
Fiecare server (vitualhost) ar trebui să fie pus în propriul fișier de configurare. Nu difuzați niciodată site-uri țintă cu server implicit; ar trebui să fie folosit doar ca suport pentru a detecta configurațiile greșite. Nu este la fel de important dacă puneți fișiere în site-uri disponibile și apoi le legați simbol, dar aceasta este metoda preferată deoarece face mai puțin posibilă ștergerea accidentală a configurației.
WhisperingShiba avatar
drapel ug
@NikitaKipriyanov Mi-am editat întrebarea cu configurațiile propuse. Intuiția mea este că acest lucru nu va funcționa, deoarece ascult pe portul 80 de 3 ori și, prin urmare, nginx nici măcar nu va porni. În plus, nu sunt sigur dacă doar afirmarea numelui serverului va direcționa cererile pentru yelling.shiba.info către xxx.xxx.x.xx:8555. Trebuie să fac dacă ($host == yelling.shiba.info> { return 301 http://xxx.xxx.x.xx:PORT } așa cum arăt în exemplul meu? Mulțumesc.

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.