nginx: [emerg] dyrektywa „serwera” nie jest tutaj dozwolona

Ponownie skonfigurowałem nginx, ale nie mogę go uruchomić ponownie przy użyciu następującej konfiguracji:

conf:

server {
listen 80;
server_name www.example.com;
return 301 $scheme://example.com$request_uri;
}


server {
listen 80;
server_name example.com;

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

location /robots.txt {
    alias /path/to/robots.txt;
    access_log off;
    log_not_found off;
}

location = /favicon.ico { access_log off; log_not_found off; }

location / {
    proxy_pass_header Server;
    proxy_set_header Host $http_host;
    proxy_redirect off;
        proxy_set_header X-Real-IP $remote_addr;
    proxy_set_header X-Scheme $scheme;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_connect_timeout 30;
    proxy_read_timeout 30;
    proxy_pass http://127.0.0.1:8000;
}

location /static {
    expires 1M;
    alias  /path/to/staticfiles;
}
}

po uruchomieniu w sudo nginx -c conf -tcelu przetestowania konfiguracji zwracany jest następujący błąd Nie mogę dowiedzieć się, na czym naprawdę polega problem

nginx: [emerg] "server" directive is not allowed here in    /etc/nginx/sites-available/config:1
nginx: configuration file /etc/nginx/sites-available/config test failed

To nie jest nginxplik konfiguracyjny. To jest część o nginxpliku konfiguracyjnego.

Plik nginxkonfiguracyjny (zwykle nazywany nginx.conf) będzie wyglądał następująco:

events {
    ...
}
http {
    ...
    server {
        ...
    }
}

serverBlok jest zamknięty wewnątrz httpbloku.

Często konfiguracja jest dystrybuowana w wielu plikach, przy użyciu includedyrektyw do pobierania dodatkowych fragmentów (na przykład z sites-enabledkatalogu).

Służy sudo nginx -tdo testowania całego pliku konfiguracyjnego, który zaczyna się od nginx.confi pobiera dodatkowe fragmenty przy użyciu includedyrektywy. Więcej informacji znajdziesz w tym dokumencie .

Przykład poprawnego nginx.conf dla zwrotnego proxy; Na wypadek, gdyby ktoś utknął jak ja. gdzie 10.x.x.xjest serwer, na którym uruchamiasz serwer proxy nginx iz którym łączysz się za pomocą przeglądarki, i 10.y.y.yjest tam, gdzie działa Twój prawdziwy serwer WWW

events {
  worker_connections  4096;  ## Default: 1024
}
http {
 server {
   listen 80;
   listen [::]:80;

   server_name 10.x.x.x;
 
   location / {
       proxy_pass http://10.y.y.y:80/;
       proxy_set_header Host $host;
   }
 }
}

Oto fragment kodu, jeśli chcesz przejść przez SSL. To znaczy, jeśli 10.y.y.ydziała serwer WWW HTTPS. Tutaj 10.x.x.xlub tam, gdzie działa nignx, nasłuchuje portu 443, a cały ruch do 443 jest kierowany do docelowego serwera internetowego

events {
  worker_connections  4096;  ## Default: 1024
}

stream {
  server {
    listen     443;
    proxy_pass 10.y.y.y:443;
  }
}

i możesz podać to również w dockerze

 docker run --name nginx-container --rm --net=host   -v /home/core/nginx/nginx.conf:/etc/nginx/nginx.conf nginx

Ścieżka do nginx.confpliku, który jest podstawowym plikiem konfiguracyjnym dla Nginx - który jest również plikiem, który powinien ZAWIERAĆ ścieżkę do innych plików konfiguracyjnych Nginx, gdy jest to wymagane /etc/nginx/nginx.conf.

Możesz uzyskać dostęp do tego pliku i edytować go, wpisując go w terminalu

cd /etc/nginx

/etc/nginx$ sudo nano nginx.conf

W dalszej części tego pliku możesz dołączyć inne pliki - które mogą mieć dyrektywę SERVER jako niezależny BLOK SERWERA - które nie muszą znajdować się w blokach HTTP lub HTTPS, jak wyjaśniono w zaakceptowanej odpowiedzi powyżej.

Powtarzam - jeśli potrzebujesz zdefiniować BLOK SERWERA w samym pliku PRIMARY Config, wówczas BLOK SERWERA będzie musiał być zdefiniowany w otaczającym bloku HTTP lub HTTPS w /etc/nginx/nginx.confpliku, który jest podstawowym plikiem konfiguracyjnym dla Nginx.

Zwróć również uwagę, że jest OK, jeśli zdefiniujesz BLOK SERWERA bezpośrednio nie zamykając go w bloku HTTP lub HTTPS, w pliku znajdującym się w path /etc/nginx/conf.d. Aby to zadziałało, musisz dołączyć ścieżkę tego pliku do podstawowego pliku konfiguracyjnego, jak pokazano poniżej: -

http{
    include /etc/nginx/conf.d/*.conf; #includes all files of file type.conf
}

Ponadto możesz skomentować plik PRIMARY Config, wiersz

http{
    #include /etc/nginx/sites-available/some_file.conf; # Comment Out 
    include /etc/nginx/conf.d/*.conf; #includes all files of file type.conf
}

i nie muszę przechowywać żadnych plików konfiguracyjnych, /etc/nginx/sites-available/a także nie ma potrzeby SYMBOLICZNEGO łączenia ich /etc/nginx/sites-enabled/, uprzejmie zauważ, że to działa dla mnie - na wypadek, gdyby ktoś pomyślał, że to dla nich nie działa lub tego rodzaju konfiguracja jest nielegalna itp., itp., proszę zostaw komentarz, aby mogę się poprawić - dzięki.

EDYCJA: - Zgodnie z najnowszą wersją oficjalnego Nginx CookBook, nie musimy tworzyć żadnych konfiguracji wewnątrz - /etc/nginx/sites-enabled/to była starsza praktyka i jest teraz WYCOFANA.

Dlatego nie ma potrzeby stosowania DYREKTYWY INCLUDE include /etc/nginx/sites-available/some_file.conf;.

Cytat ze strony Nginx CookBook - 5.

„W niektórych repozytoriach pakietów ten folder nosi nazwę z włączoną obsługą witryn, a pliki konfiguracyjne są połączone z folderu o nazwie witryna-dostępna; ta konwencja jest przestarzała”.

W pliku importowanym przez konfigurację może znajdować się tylko literówka. Na przykład popełniłem literówkę głęboko w moim pliku konfiguracyjnym:

loccation /sense/movies/ {
                  mp4;
        }

(lokalizacja zamiast lokalizacji), a to powoduje błąd:

nginx: [emerg] "server" directive is not allowed here in /etc/nginx/sites-enabled/xxx.xx:1