Pierwszy raz korzystam z Nginx, ale jestem bardziej niż zaznajomiony z Apache i Linuksem. Korzystam z istniejącego projektu i kiedy próbuję zobaczyć plik index.php, nie mogę znaleźć pliku 404.
Oto wpis access.log:
2013/06/19 16:23:23 [error] 2216#0: *1 FastCGI sent in stderr: "Primary script unknown" while reading response header from upstream, client: 127.0.0.1, server: localhost, request: "GET /index.php HTTP/1.1", upstream: "fastcgi://127.0.0.1:9000", host: "www.ordercloud.lh"
A oto plik dostępny na stronach:
server {
set $host_path "/home/willem/git/console/www";
access_log /www/logs/console-access.log main;
server_name console.ordercloud;
root $host_path/htdocs;
set $yii_bootstrap "index.php";
charset utf-8;
location / {
index index.html $yii_bootstrap;
try_files $uri $uri/ /$yii_bootstrap?$args;
}
location ~ ^/(protected|framework|themes/\w+/views) {
deny all;
}
#avoid processing of calls to unexisting static files by yii
location ~ \.(js|css|png|jpg|gif|swf|ico|pdf|mov|fla|zip|rar)$ {
try_files $uri =404;
}
# pass the PHP scripts to FastCGI server listening on 127.0.0.1:9000
#
location ~ \.php {
fastcgi_split_path_info ^(.+\.php)(.*)$;
#let yii catch the calls to unexising PHP files
set $fsn /$yii_bootstrap;
if (-f $document_root$fastcgi_script_name){
set $fsn $fastcgi_script_name;
}
fastcgi_pass 127.0.0.1:9000;
include fastcgi_params;
fastcgi_param SCRIPT_FILENAME $document_root$fsn;
#PATH_INFO and PATH_TRANSLATED can be omitted, but RFC 3875 specifies them for CGI
fastcgi_param PATH_INFO $fastcgi_path_info;
fastcgi_param PATH_TRANSLATED $document_root$fsn;
}
location ~ /\.ht {
deny all;
}
}
Mój / home / willem / git / console jest własnością www-data: www-data (mój użytkownik korzystający z php itp.) I dałem mu 777 uprawnień z frustracji ...
Domyślam się, że coś jest nie tak z konfiguracją, ale nie mogę tego rozgryźć ...
AKTUALIZACJA
Więc przeniosłem go /var/www/
i użyłem znacznie bardziej podstawowej konfiguracji:
server {
#listen 80; ## listen for ipv4; this line is default and implied
#listen [::]:80 default ipv6only=on; ## listen for ipv6
root /var/www/;
index index.html index.htm;
# Make site accessible from http://localhost/
server_name console.ordercloud;
location / {
root /var/www/console/frontend/www/;
fastcgi_pass 127.0.0.1:9000;
fastcgi_index index.php;
fastcgi_param SCRIPT_FILENAME /var/www;
include fastcgi_params;
}
location ~ \.(js|css|png|jpg|gif|swf|ico|pdf|mov|fla|zip|rar)$ {
try_files $uri =404;
}
location /doc/ {
alias /usr/share/doc/;
autoindex on;
allow 127.0.0.1;
deny all;
}
}
Również jeśli zadzwonię localhost/console/frontend/www/index.php
, dostanę 500 PHP, co oznacza, że tam służy. To po prostu nie służy off.cloudcloud ...
Odpowiedzi:
Komunikat o błędzie „podstawowy skrypt nieznany” jest prawie zawsze związany z niepoprawnie ustawionym
SCRIPT_FILENAME
wfastcgi_param
dyrektywie nginx (lub niepoprawnymi uprawnieniami, zobacz inne odpowiedzi).Używasz
if
w konfiguracji, którą opublikowałeś jako pierwszy. Cóż, do tej pory powinno być dobrze znane, że jeśli jest zły i często powoduje problemy.Ustawienie
root
dyrektywy w bloku lokalizacji to zła praktyka, oczywiście, że działa.Możesz spróbować czegoś takiego:
Pamiętaj, że powyższa konfiguracja nie została przetestowana. Powinieneś wykonać go
nginx -t
przed zastosowaniem, aby sprawdzić problemy, które nginx może natychmiast wykryć.źródło
root
lokalizacji w obrębie?http
części, co następuje:log_format scripts '$document_root$fastcgi_script_name > $request';
(lub cokolwiek masz karmienia SCRIPT_FILENAME), a do Twojegoserver
:access_log /var/log/nginx/scripts.log scripts
. Przeładuj i spójrz na swój nowy dziennik skryptów;)Nie zawsze
SCRIPT_FILENAME
jest tak, że coś jest nie tak.Być może PHP działa jako niewłaściwy użytkownik / grupa .
Ten przykład jest specyficzny dla Mac OS X , który z mojego doświadczenia jest najbardziej kłopotliwy w konfiguracji (Debian jest łatwy do porównania) - właśnie zaktualizowałem PHP z wersji 5.6 do 7.0, używając homebrew i doskonałych pakietów josegonzalez.
Problem polegał na tym, że utworzono nową kopię plików konfiguracyjnych.
Głównym plikiem konfiguracyjnym jest
/usr/local/etc/php/7.0/php-fpm.conf
, ale zwróć uwagę na sekcję Definicje puli na końcu, która zawiera cały podkatalog.include=/usr/local/etc/php/7.0/php-fpm.d/*.conf
W
php-fpm.d
istniejewww.conf
plik. Domyślnie ma to:W systemie OS X może być konieczna zmiana tego ustawienia na:
(powinieneś znaleźć to pasujące do
ls -lh
twojego root_dokumentu)Niestety bez tej zmiany nadal będzie to widoczne w dzienniku błędów Nginx, nawet jeśli szuka pliku we właściwym miejscu .
Sprawdź, co aktualnie działa jako:
lub bardziej czysto:
Jak sprawdzić, czy nazwa pliku skryptu jest poprawna:
(skradziony z igorsantos07 w innej odpowiedzi)
Dodaj do
http
bloku głównego/usr/local/etc/nginx/nginx.conf
:(gdzie pierwszym bitem musi być to, czego aktualnie używasz, abyś mógł sprawdzić, czy to prawda).
Aby użyć dziennika, który właśnie zdefiniowałeś, w
server
bloku witryny :Jeśli jest to poprawne, żądanie przykład.com/phpinfo.php spowoduje wygenerowanie czegoś takiego:
Czy możesz uprościć istniejącą konfigurację?
Czy używasz
location ~ \.php {
bloku, który skopiowałeś / wkleiłeś z Internetu? Większość pakietów pozwala ci to zrobić szybciej i czysto. np. w OS X potrzebujesz teraz tego:Dostępne są rzeczy takie jak fastcgi_split_path_info, try_files i fastcgi_index (domyślnie index.php)
/usr/local/etc/nginx/snippets/fastcgi-php.conf
.To z kolei obejmuje
/usr/local/etc/nginx/fastcgi.conf
listęfastcgi_param
ustawień, w tym kluczową SCRIPT_FILENAME.Nigdy nie duplikuj
root
w bloku lokalizacji PHP.źródło
/etc/php/7.0/php-fpm.d/www.conf
pliku. Na zdrowie, kolego. :) O wiele więcej osób może zacząć widzieć ten problem, ponieważ popularność rośnie./usr/local/etc/nginx/snippets/fastcgi-php.conf
na moim komputerze .. ale znalazłem/usr/local/etc/nginx/fastcgi.conf
Ok, więc 3 rzeczy znalazłem po całym dniu walki
Mam nadzieję, że zaoszczędzi to komuś kłopotów!
źródło
Miał ten sam problem z nowszym nginx (v1.8). Nowsze wersje zalecają używanie
snippets/fastcgi-php.conf;
zamiastfastcgi.conf
. Więc jeśli skopiujesz / wkleiszinclude fastcgi.conf
z samouczka, możesz skończyć zPrimary script unknown
błędem w dzienniku.źródło
„Podstawowy skrypt nieznany” jest spowodowany kontekstem bezpieczeństwa SELinux.
klient otrzymuje odpowiedź
Nginx error.log ma następujący komunikat o błędzie
więc po prostu zmień typ kontekstu bezpieczeństwa internetowego folderu głównego na httpd_sys_content_t
dla konfiguracji nginx / php-fpm jest 3 użytkowników
/etc/nginx/nginx.conf
/etc/nginx/conf.d/www.conf
/etc/php-fpm.d/www.conf
użytkownik-1 i użytkownik-2 nie muszą być tacy sami.
w przypadku gniazda unix użytkownik-1 musi być taki sam jak użytkownik-3, ponieważ nginx fastcgi_pass musi mieć uprawnienia do odczytu / zapisu w gnieździe unix.
w przeciwnym razie nginx otrzyma 502 Bad Gateway , a nginx error.log wyświetli następujący komunikat o błędzie
a użytkownik / grupa folderu głównego (/ var / www / show) nie musi być taki sam jak którykolwiek z tych 3 użytkowników.
źródło
Miałem również ten problem i rozwiązałem go, wymieniając linie
include fastcgi_params
ifastcgi_param SCRIPT_FILENAME ...
.Rzeczywiście nginx ustawia ostatnią wartość każdego parametru FastCGI, więc musisz umieścić swoją wartość po wartości domyślnej zawartej w fastcgi_params.
źródło
Rozwiązałem ten problem, zamykając SELINUX w systemie CentOS7.3
kroki:
setenforce 0
vim /etc/selinux/config set SELINUX to disabled
źródło
Znalazłem twoje pytanie szukające tego samego komunikatu o błędzie, ale używając apache + php-fpm (bez nginx). Dla mnie problemem był ukośnik w niewłaściwym miejscu: wiele sugestii dotyczących konfiguracji zawiera wiersz formularza:
Umieszczając ostatni ukośnik po numerze portu w następujący sposób:
problem zniknął dla mnie. Może możesz zrobić coś podobnego
źródło
źródło
Sklonowałem zdalną witrynę, a już istniejąca wp-config.php zawierała informacje o bazie danych zdalnego serwera.
Rozwiązałem ten problem, konfigurując moją lokalną konfigurację wordpress z informacjami o mojej lokalnej bazie danych.
źródło
Zrobiłem wszystko z góry, straciłem 2 godziny waląc głową i problem nadal występował. Wreszcie zrobiłem:
I altówka zadziałała!
Przy okazji, tworzyłem nowy projekt symfony 3.4 z nginx conf z linku: https://symfony.com/doc/3.4/setup/web_server_configuration.html
To był mój piąty raz, kiedy zaczynałem nowy projekt symfony i nie mogłem uwierzyć, że dzieje się ten „scenariusz podstawowy nieznany”.
źródło
Sprawdź uprawnienia do pliku skarpety php-fpm, jakoś nie był dostępny:
chmod 755 /usr/local/var/run/php-fpm.sock
następnie spróbuj zrestartować nginx.
źródło
Bardzo dziwna wiadomość mnie uwięziła. Nie jestem pewien co do przyczyny, ponieważ wszystko działało przez chwilę, a potem nagle przestało działać.
Skracałem adresy URL wiki zgodnie z zaleceniami MediaWiki, używając Bitnami / Nginx na Lightsail.
Przeszukałem i przeczytałem wiele postów, ten wydaje się podsumowywać wszystkie możliwe scenariusze, a ja wypróbowałem je wszystkie:
root
do serwera, nie działałoWięc musiałem spróbować ostateczności, ponieważ folder główny php działa i podfoldery nie było, tylko duża różnica między nimi inny niż
root
jest folderów korzeń używany$request_filename
i podfolderów lokalizacje wykorzystywane$document_root
i$fastcgi_script_name
tak zmieniłem ustawienia lokalizacji podfolder, aby dopasować te folderze głównym.Potem zadziałało ... Nadal nie jestem pewien, dlaczego zadziałało. Ponieważ kiedy sprawdzam dziennik dostępu php-fpm, widzę ten sam URI, jeden miał 404, a drugi 200.
Jedyną różnicą była konfiguracja. Ponieważ produkują taką samą wydajność, nie wiem, dlaczego wynik wyszedł inaczej.
W każdym razie postanowiłem tutaj zamieścić 2 centy, mam nadzieję, że to pomoże.
PS: Naprawdę mam nadzieję, że PHP dostarczy lepsze komunikaty o błędach i tryb gadatliwy, ponieważ jest to naprawdę frustrujące, ponieważ nie mogę wyodrębnić problemu i nie ma sposobu, aby zobaczyć pełne dane wyjściowe i informacje debugowania.
źródło
Spróbuj dodać dyrektywę root w swojej lokalizacji php.
źródło
root
Dyrektywa powinna być ustawiona w przeliczeniu naserver
zasadach i nie powinny być wykorzystywane w jakichkolwieklocation
bloków (chyba, że jesteś pro i chcą obejść pewne bardzo szczególne błędy nginx w konfiguracji).root
dyrektywę wewnątrzlocation
bloku.root
dyrektyw w wielulocation
blokach jest wyraźnie pod nagłówkiem ZŁE.