Ich habe Nginx zum ersten Mal benutzt, bin aber mit Apache und Linux mehr als vertraut. Ich verwende ein bestehendes Projekt und wenn ich jemals versuche, die index.php zu sehen, erhalte ich eine 404-Datei, die nicht gefunden wurde.
Hier ist der access.log-Eintrag:
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"
Und hier ist die für Websites verfügbare Datei:
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;
}
}
Mein / home / willem / git / console gehört www-data: www-data (mein Webbenutzer, der PHP ausführt, usw.) und ich habe ihm aus Frustration 777 Berechtigungen erteilt ...
Ich vermute, dass etwas mit der Konfiguration nicht stimmt, aber ich kann es nicht herausfinden ...
UPDATE
Also habe ich es verschoben /var/www/
und eine viel grundlegendere Konfiguration verwendet:
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;
}
}
Auch wenn ich anrufe, localhost/console/frontend/www/index.php
bekomme ich 500 PHP, was bedeutet, dass es dort dient. Es dient nur nicht von console.ordercloud ...
Antworten:
Die Fehlermeldung "Primäres Skript unbekannt" bezieht sich fast immer auf eine falsche Einstellung
SCRIPT_FILENAME
in der Nginx-fastcgi_param
Direktive (oder auf falsche Berechtigungen, siehe andere Antworten).Sie verwenden eine
if
in der Konfiguration, die Sie zuerst gepostet haben. Nun, es sollte inzwischen bekannt sein, dass wenn böse ist und oft Probleme erzeugt.Das Setzen der
root
Direktive innerhalb eines Location Blocks ist eine schlechte Praxis, es funktioniert natürlich.Sie können Folgendes ausprobieren:
Bitte beachten Sie, dass die obige Konfiguration nicht getestet wurde. Sie sollten es ausführen,
nginx -t
bevor Sie es anwenden, um zu prüfen, ob Probleme vorliegen, die nginx sofort erkennen kann.quelle
root
?http
Abschnitt die folgenden:log_format scripts '$document_root$fastcgi_script_name > $request';
(oder was auch immer Sie zu SCRIPT_FILENAME Fütterung) und auf Ihreserver
:access_log /var/log/nginx/scripts.log scripts
.Es ist nicht immer so, dass das
SCRIPT_FILENAME
falsch ist.Es kann auch sein, dass PHP als der falsche Benutzer / die falsche Gruppe ausgeführt wird .
Dieses Beispiel ist spezifisch für Mac OS X , das meiner Erfahrung nach am schwierigsten einzurichten ist (Debian ist vergleichsweise einfach). Ich habe gerade ein Upgrade von PHP 5.6 auf 7.0 mit Homebrew und den hervorragenden josegonzalez-Paketen durchgeführt.
Das Problem war, dass eine neue Kopie der Konfigurationsdateien erstellt wurde.
Die Hauptkonfigurationsdatei ist
/usr/local/etc/php/7.0/php-fpm.conf
, aber beachten Sie den Abschnitt " Pooldefinitionen " am Ende, in dem ein ganzes Unterverzeichnis enthalten ist.include=/usr/local/etc/php/7.0/php-fpm.d/*.conf
In
php-fpm.d
gibt es einewww.conf
Datei. Standardmäßig hat dies:Unter OS X müssen Sie möglicherweise Folgendes ändern:
(Sie sollten feststellen, dass dies mit einem
ls -lh
Ihrer document_root übereinstimmt. )Leider wird dies ohne diese Änderung auch dann in Ihrem Nginx-Fehlerprotokoll angezeigt , wenn die Datei an der richtigen Stelle gesucht wird .
Überprüfen Sie, wie es aktuell ausgeführt wird:
oder sauberer:
So überprüfen Sie, ob der Dateiname des Skripts korrekt ist:
(gestohlen von igorsantos07 in der anderen Antwort)
Zum
http
Hauptblock hinzufügen/usr/local/etc/nginx/nginx.conf
:(Wo das erste Bit sein muss, was auch immer Sie gerade verwenden, damit Sie sehen können, ob es richtig ist.)
Um das soeben definierte Protokoll im
server
Block Ihrer Site zu verwenden, gehen Sie wie folgt vor:Wenn es korrekt ist, wird das Anfordern von example.com/phpinfo.php ungefähr so aussehen:
Können Sie Ihre bestehende Konfiguration vereinfachen?
Verwenden Sie einen
location ~ \.php {
Block, den Sie aus dem Internet kopiert / eingefügt haben? Mit den meisten Paketen können Sie dies schneller und sauberer erledigen. zB unter OS X brauchst du jetzt nur noch folgendes:Dinge wie fastcgi_split_path_info, try_files und fastcgi_index (standardmäßig index.php) sind in
/usr/local/etc/nginx/snippets/fastcgi-php.conf
.Dies beinhaltet wiederum
/usr/local/etc/nginx/fastcgi.conf
eine Liste vonfastcgi_param
Einstellungen, einschließlich des entscheidenden SCRIPT_FILENAME.Duplizieren Sie niemals
root
im PHP-Adressblock.quelle
/etc/php/7.0/php-fpm.d/www.conf
Akte zu korrigieren . Prost, Kumpel. :) Viele weitere Menschen werden dieses Problem möglicherweise auch sehen, da die Beliebtheit von Vagabunden weiter zunimmt./usr/local/etc/nginx/snippets/fastcgi-php.conf
Ich konnte auf meinem Mac nichts finden, aber ich fand/usr/local/etc/nginx/fastcgi.conf
Ok, also 3 Dinge, die ich nach einem Tag voller Schwierigkeiten gefunden habe
Hoffe, das erspart jemandem Ärger!
quelle
Hatte das gleiche Problem mit einem neueren Nginx (v1.8). Neuere Versionen empfehlen
snippets/fastcgi-php.conf;
stattfastcgi.conf
. Wenn Sie alsoinclude fastcgi.conf
aus einem Lernprogramm kopieren / einfügen , wird möglicherweise derPrimary script unknown
Fehler im Protokoll angezeigt.quelle
"Primäres Skript unbekannt" wird durch den SELinux-Sicherheitskontext verursacht .
Client erhalten die Antwort
nginx error.log hat die folgende Fehlermeldung
Ändern Sie einfach den Sicherheitskontexttyp des Webstammordners in httpd_sys_content_t
Es gibt 3 Benutzer für nginx / php-fpm config
/etc/nginx/nginx.conf
/etc/nginx/conf.d/www.conf
/etc/php-fpm.d/www.conf
Benutzer-1 und Benutzer-2 müssen nicht identisch sein.
Für Unix- Sockets muss Benutzer-1 mit Benutzer-3 identisch sein , da nginx fastcgi_pass über Lese- / Schreibrechte für den Unix-Socket verfügen muss.
Andernfalls erhält nginx 502 Bad Gateway und nginx error.log hat die folgende Fehlermeldung
und der Benutzer / die Gruppe des Webstammordners (/ var / www / show) muss nicht mit einem dieser 3 Benutzer identisch sein.
quelle
Ich hatte auch dieses Problem und löste es, indem ich die Zeilen
include fastcgi_params
und vertauschtefastcgi_param SCRIPT_FILENAME ...
.In der Tat setzt nginx den letzten Wert jedes FastCGI-Parameters, so dass Sie Ihren Wert nach dem in fastcgi_params enthaltenen Standardwert setzen müssen.
quelle
Ich habe dieses Problem gelöst, indem ich SELINUX im CentOS7.3-System geschlossen habe
Schritte:
setenforce 0
vim /etc/selinux/config set SELINUX to disabled
quelle
Ich fand Ihre Frage nach der gleichen Fehlermeldung suchend, aber Apache + php-fpm (kein nginx) verwendend. Für mich war das Problem ein Schrägstrich an der falschen Stelle: Viele Einrichtungsvorschläge enthalten eine Zeile der Form:
Durch Platzieren des letzten Schrägstrichs nach der Portnummer wie folgt:
Das Problem verschwand für mich. Vielleicht können Sie etwas Ähnliches tun
quelle
quelle
Ich habe eine Remote-Site geklont, und die bereits vorhandene Datei wp-config.php enthielt die Informationen zur Remote-Server-Datenbank.
Ich habe dieses Problem behoben, indem ich meine lokale WordPress-Konfiguration mit meinen lokalen Datenbankinformationen eingerichtet habe.
quelle
Ich tat alles von oben, verlor 2 Stunden meinen Kopf und das Problem blieb bestehen. Endlich habe ich gemacht:
Und Viola hat es geklappt!
Übrigens habe ich ein neues Symfony 3.4-Projekt mit nginx conf über den folgenden Link eingerichtet: https://symfony.com/doc/3.4/setup/web_server_configuration.html
Es war mein fünftes Mal, dass ich ein neues Symfony-Projekt gestartet habe, und ich konnte nicht glauben, dass dieses "Primärskript unbekannt" passiert.
quelle
Überprüfen Sie die Berechtigungen für Ihre PHP-FPM-SOCK-Datei, auf die irgendwie nicht zugegriffen werden konnte:
chmod 755 /usr/local/var/run/php-fpm.sock
Versuchen Sie dann, nginx neu zu starten.
quelle
Ich bin schon sehr lange in dieser seltsamen Botschaft gefangen. Ich bin mir über die Ursache nicht sicher, weil alles eine Weile funktionierte und dann plötzlich aufhörte zu arbeiten.
Ich habe Wiki-URLs verkürzt, wie von MediaWiki vorgeschrieben, mit Bitnami / Nginx auf Lightsail.
Durchsucht und gelesen viele Beiträge, dieser scheint alle möglichen Szenarien zusammenzufassen, und ich habe sie alle ausprobiert:
root
zum Server hinzufügen , hat nicht funktioniertAlso musste ich den letzten Ausweg versuchen, da der Root-Ordner PHP funktionierte und Unterordner nicht, der einzige große Unterschied zwischen ihnen, abgesehen vom verwendeten
root
Root-Ordner$request_filename
und den verwendeten Unterordnerpositionen,$document_root
und$fastcgi_script_name
so änderte ich die Unterordnerpositionseinstellungen, um sie mit denen des Root-Ordners abzugleichen.Dann hat es funktioniert ... Ich bin mir immer noch nicht sicher, warum es funktioniert hat. Denn wenn ich das PHP-FPM-Zugriffsprotokoll überprüfe, sehe ich die gleiche URI, eine war 404 und die andere war 200.
Der einzige Unterschied bestand in der Konfiguration. Da sie die gleiche Ausgabe produzieren, weiß ich nicht, warum das Ergebnis anders ausfiel.
Trotzdem habe ich beschlossen, meine 2 Cent hier zu posten, hoffe das hilft.
PS: Ich hoffe wirklich, dass PHP bessere Fehlermeldungen und einen ausführlichen Modus bietet, da dies sehr frustrierend ist, das Problem nicht eingrenzen zu können und keine Möglichkeit zu haben, ausführliche Ausgabe- und Debug-Informationen zu erhalten.
quelle
Versuchen Sie, die root-Direktive in Ihren PHP-Speicherort einzufügen.
quelle
root
Direktive sollte proserver
Basis gesetzt und nicht inlocation
Blöcken verwendet werden (es sei denn, Sie sind ein Profi und möchten einige sehr spezielle Nginx-Fehler in Ihrer Konfiguration umgehen).root
Direktive innerhalb eineslocation
Blocks.root
Anweisungen in mehrerenlocation
Blöcken ist eindeutig unter der Überschrift BAD.