Ich habe einen Nginx-Server mit PHP-5-Fpm eingerichtet. Wenn ich versuche, die Site zu laden, erhalte ich eine leere Seite ohne Fehler. HTML-Seiten werden in Ordnung geliefert, nicht jedoch in PHP. Ich habe versucht, display_errors in php.ini einzuschalten, aber kein Glück. php5-fpm.log erzeugt keine Fehler und auch nginx nicht.
nginx.conf
server {
listen 80;
root /home/mike/www/606club;
index index.php index.html;
server_name mikeglaz.com www.mikeglaz.com;
error_log /var/log/nginx/error.log;
location ~ \.php$ {
#fastcgi_pass 127.0.0.1:9000;
# With php5-fpm:
fastcgi_pass unix:/var/run/php5-fpm.sock;
fastcgi_index index.php;
include fastcgi_params;
}
}
EDIT
hier ist mein Nginx-Fehlerprotokoll:
2013/03/15 03:52:55 [error] 1020#0: *55 open() "/home/mike/www/606club/robots.txt" failed (2: No such file or directory), client: 199.30.20.40, server: mikeglaz.com, request: "GET /robots.txt HTTP/1.1", Host: "mikeglaz.com"
Zu Referenzzwecken füge ich meinen location
-Block hinzu, um Dateien mit der Erweiterung .php
abzufangen:
location ~ \.php$ {
include /path/to/fastcgi_params;
fastcgi_pass 127.0.0.1:9000;
fastcgi_index index.php;
fastcgi_param SCRIPT_FILENAME $document_root/$fastcgi_script_name;
}
Überprüfen Sie den /path/to/fastcgi-params
noch einmal und stellen Sie sicher, dass er vom nginx-Benutzer vorhanden und lesbar ist.
ersetzen
include fastcgi_params;
mit
include fastcgi.conf;
und entfernen Sie fastcgi_param SCRIPT_FILENAME ... in der nginx.conf
Hatte auch dieses Problem und fand schließlich die Lösung hier . Kurz gesagt, Sie müssen Ihrer nginx fastcgi-Konfigurationsdatei die folgende Zeile hinzufügen (/ etc/nginx/fastcgi_params in Ubuntu 12.04)
fastcgi_param PATH_TRANSLATED $document_root$fastcgi_script_name;
Viele Benutzer fallen in diesen Thread und erwarten, eine Lösung für leere Seiten zu finden, die angezeigt werden, während nginx + php-fpm verwendet wird, wobei ich einer von ihnen bin. Dies ist eine Zusammenfassung dessen, was ich nach dem Lesen vieler Antworten und meiner eigenen Untersuchungen (aktualisiert auf php7.2) getan habe:
1) Öffnen Sie /etc/php/7.2/fpm/pool.d/www.conf
und überprüfen Sie den Wert des Parameters listen
.
listen = /var/run/php/php7.2-fpm.sock
2) Der Parameter listen
sollte mit dem fastcgi_pass
-Parameter in Ihrer Site-Konfigurationsdatei (i, e: /etc/nginx/sites-enabled/default
) übereinstimmen.
fastcgi_pass unix:/var/run/php/php7.2-fpm.sock;
3) Prüfen Sie, ob die Datei tatsächlich existiert:
$ file /var/run/php/php7.2-fpm.sock
/var/run/php/php7.2-fpm.sock: socket
4) Wenn es nicht existiert, bedeutet dies, dass php7.2-fpm nicht ausgeführt wird. Daher müssen Sie es neu starten:
$ Sudo /etc/init.d/php7.2-fpm restart
[ ok ] Restarting php7.2-fpm (via systemctl): php7.2-fpm.service.
.__ bezüglich des location
-Abschnitts in /etc/nginx/sites-enabled/default
:
# pass PHP scripts to FastCGI server
#
location ~ \.php$ {
include snippets/fastcgi-php.conf;
# With php-fpm (or other unix sockets):
fastcgi_pass unix:/var/run/php/php7.2-fpm.sock;
}
Überprüfen Sie, ob die Datei snippets/fastcgi-php.conf
am Speicherort /etc/nginx/
vorhanden ist:
$ file /etc/nginx/snippets/fastcgi-php.conf
/etc/nginx/snippets/fastcgi-php.conf: ASCII text
Diese Datei enthält eine Liste der von php7.2-fpm erforderlichen Variablendefinitionen. Die Variablen werden direkt oder durch ein Include einer getrennten Datei definiert.
include fastcgi.conf;
Diese Datei befindet sich unter /etc/nginx/fastcgi.conf
und sieht folgendermaßen aus:
fastcgi_param QUERY_STRING $query_string;
fastcgi_param REQUEST_METHOD $request_method;
...
fastcgi_param REDIRECT_STATUS 200;
nginx enthält zwei mögliche Parameterdateien: fastcgi_params und fastcgi.conf. Der Unterschied zwischen beiden ist die Definition der Variablen SCRIPT_FILENAME
:
$ diff fastcgi_params fastcgi.conf
1a2
> fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
Um es kurz zu machen, sollte fastcgi.conf immer funktionieren. Wenn Sie aus irgendeinem Grund fastcgi_params verwenden, sollten Sie SCRIPT_FILENAME
definieren:
location ~ \.php$ {
include snippets/fastcgi-php.conf;
# With php-fpm (or other unix sockets):
fastcgi_pass unix:/var/run/php/php7.2-fpm.sock;
fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
}
Laden Sie nun die Nginx-Konfiguration neu:
$ Sudo nginx -s reload
Und prüfen Sie, ob eine PHP-Datei korrekt angezeigt wird. Zum Beispiel:
/var/www/html/test.php
<pre><?php var_export($_SERVER)?></pre>
Dabei ist /var/www/html
der Pfad zum Dokumentenstamm.
Wenn trotz allem immer noch eine leere Datei angezeigt wird, stellen Sie sicher, dass für Ihren php.ini
short_open_tag
aktiviert ist (wenn Sie eine PHP - Seite mit kurzen Tags testen).
Stellen Sie sicher, dass Sie dies in/etc/nginx/fastcgi_params haben
fastcgi_param SCRIPT_FILENAME $ anforderungsdateiname;
Wer weiß, warum das nicht schon da ist? Die Zeit, die dies kollektiv vergeuden muss!
Ich habe ein kurzes C-Programm geschrieben, das die von nginx an die fastCGI-Anwendung übergebenen Umgebungsvariablen zurückgibt.
#include <stdlib.h>
#include <fcgi_stdio.h>
extern char **environ;
int main(int argc, char **argv) {
char *envvar;
int i;
int count = 0;
while(FCGI_Accept() >= 0) {
printf("Content-type: text/html\n\n"
"<html><head><title>FastCGI Call Debug Tool</title></head>\n"
"<body><h1>FastCGI Call Debugging Tool</h1>\n"
"<p>Request number %d running on Host <i>%s</i></p>\n"
"<h2>Environment Variables</h2><p>\n",
++count, getenv("SERVER_NAME"));
i = 0;
envvar = environ[i];
while (envvar != NULL) {
printf("%s<br/>",envvar);
envvar = environ[++i];
}
printf("</p></body></html>\n");
}
return 0;
}
Speichern Sie dies in einer Datei, z. fcgi_debug.c
Installieren Sie zum Kompilieren zuerst gcc
und libfcgi-dev
und führen Sie dann Folgendes aus:
gcc -o fcgi_debug fcgi_debug.c -lfcgi
Um es auszuführen, installieren Sie spawn-fcgi
und führen Sie dann Folgendes aus:
spawn-fcgi -p 3000 -f /path/to/fcgi_debug
Ändern Sie dann Ihre nginx fcgi config so, dass sie auf das Debug-Programm verweist:
fastcgi_pass 127.0.0.1:3000;
Starten Sie nginx neu, aktualisieren Sie die Seite, und Sie sollten alle Parameter in Ihrem Browser für das Debuggen sehen! :-)
Diese Hinweise haben mir bei der Installation von Ubuntu 14.04 LTS geholfen,
Außerdem musste ich den short_open_tag
in /etc/php5/fpm/php.ini
einschalten.
$ Sudo kate /etc/php5/fpm/php.ini
short_open_tag = On
$ Sudo service php5-fpm restart
$ Sudo service nginx reload
Fügen Sie dies in /etc/nginx/conf.d/default.conf
hinzu:
fastcgi_param PATH_TRANSLATED $document_root$fastcgi_script_name;
Der Grund für dieses Problem ist, dass die fastcgi-Konfigurationen in nginx nicht wie erforderlich funktionieren und an Ort und Stelle oder in Verarbeitung als HTML-Daten reagieren. Es gibt zwei Möglichkeiten, wie Sie Ihren Nginx konfigurieren können, um dieses Problem zu vermeiden.
Methode 1:
location ~ \.php$ {
fastcgi_split_path_info ^(.+\.php)(/.+)$;
# With php5-fpm:
fastcgi_pass unix:/run/php5-fpm.sock;
fastcgi_index index.php;
include fastcgi.conf;
}
Methode 2:
location ~ \.php$ {
fastcgi_split_path_info ^(.+\.php)(/.+)$;
include snippets/fastcgi-php.conf;
# With php5-fpm:
fastcgi_pass unix:/var/run/php5-fpm.sock;
include fastcgi_params;
}
Beide Methoden funktionieren einwandfrei. Sie können jede dieser Methoden verwenden. Sie führen fast die gleichen Operationen mit wenigen Unterschieden aus.
Für den Fall, dass jemand dieses Problem hat, aber keine der oben genannten Antworten das Problem löst, hatte ich das gleiche Problem und es fiel mir am schwersten, es zu finden, da meine Konfigurationsdateien korrekt waren und meine Ngnix- und PHP-Fpm-Jobs einwandfrei liefen Es wurden keine Fehler durch Fehlerprotokolle gemeldet.
Dummer Fehler, aber ich habe die Variable Short Open Tag in meiner php.ini-Datei, die auf short_open_tag = Off
eingestellt war, nie überprüft. Da meine PHP-Dateien <?
anstelle von <?php
verwendeten, wurden die Seiten leer angezeigt. Short Open Tag sollte in meinem Fall auf On
gesetzt sein.
Hoffe das hilft jemandem.
Keine der obigen Antworten funktionierte für mich - PHP hat alles richtig dargestellt, außer Seiten, die auf mysqli angewiesen waren und für die eine leere Seite mit einem Antwortcode von 200 gesendet und keine Fehler ausgegeben wurden. Da ich unter OS X bin, war der Fix einfach
Sudo port install php56-mysql
gefolgt von einem Neustart von PHP-FPM und nginx.
Ich habe von einem älteren Apache/PHP-Setup zu Nginx gewechselt und konnte den Versionskonflikt im Treiber für php-mysql
und php-fpm
nicht feststellen.
location ~ [^/]\.php(/|$) {
fastcgi_pass unix:/PATH_TO_YOUR_PHPFPM_SOCKET_FILE/php7.0-fpm.sock;
include fastcgi_params;
fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
fastcgi_param SCRIPT_NAME $fastcgi_script_name;
}
Viel Glück
Dies löste mein Problem:
location ~ \.php$ {
fastcgi_split_path_info ^(.+\.php)(/.+)$;
include snippets/fastcgi-php.conf;
# With php5-fpm:
fastcgi_pass unix:/var/run/php5-fpm.sock;
include fastcgi_params;
}
Dies ist mein vhost für UBUNTU 18.04 + Apache + php7.2
server {
listen 80;
server_name test.test;
root /var/www/html/{DIR_NAME}/public;
location / {
try_files $uri /index.php?$args;
}
location ~ \.php$ {
try_files $uri =404;
fastcgi_split_path_info ^(.+\.php)(/.+)$;
fastcgi_pass unix:/run/php/php7.2-fpm.sock;
fastcgi_index index.php;
include fastcgi_params;
fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
}
}
Die letzte Zeile unterscheidet sich von den anderen Antworten.
Ich hatte ein ähnliches Problem. Nginx bearbeitete eine Seite zur Hälfte und stoppte dann. Keine der hier vorgeschlagenen Lösungen funktionierte für mich. Ich habe das Problem behoben, indem ich die Nginx-Fastcgi-Pufferung geändert habe:
fastcgi_max_temp_file_size 0;
fastcgi_buffer_size 4K;
fastcgi_buffers 64 4k;
Nach den Änderungen sah mein location
-Block folgendermaßen aus:
location ~ \.php$ {
try_files $uri /index.php =404;
fastcgi_split_path_info ^(.+\.php)(/.+)$;
fastcgi_pass 127.0.0.1:9000;
fastcgi_index index.php;
fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
fastcgi_max_temp_file_size 0;
fastcgi_buffer_size 4K;
fastcgi_buffers 64 4k;
include fastcgi_params;
}
Für Details siehe https://www.namhuy.net/3120/fix-nginx-upstream-response-buffered-temporary-file-error.html
Wenn Sie einen leeren Bildschirm erhalten, kann dies zwei Gründe haben:
Browser blockiert die Anzeige der Frames. In einigen Browsern werden die Frames als unsicher angesehen. Um dies zu überwinden, können Sie die rahmenlose Version von phpPgAdmin mit starten
http://-your-domain-name-/intro.php
Sie haben eine Sicherheitsfunktion in Nginx für X-Frame-Options aktiviert. Versuchen Sie es zu deaktivieren.