NGINX n'exécute pas de fichiers PHP


9

Je n'ai pas pu trouver de réponse à cela. Installé PHP5 + NGINX + PHP-FPM et ne peut pas exécuter les fichiers php, il obtient un "Oups! Ce lien semble être rompu." erreur dans CHROME. Je n'ai pas de rapport de journal d'erreurs précieux, j'ai un index.php à la racine, j'ai essayé de créer un fichier phpinfo.php personnalisé, ni travaillé.

Je fais peut charger des fichiers HTML, mais ne peux pas PHP.

Voici ma configuration de site local dans NGINX:

server {
    listen       80;
    server_name  im;
    access_log /var/www/website/access.log;
    error_log /var/www/website/error.log;

    location / {
        root   /var/www/website;
        index  index.html index.htm index.php;
    }


    location ~ \.php$ {
        fastcgi_pass 127.0.0.1:9000;
        fastcgi_index index.php;
        fastcgi_param  SCRIPT_FILENAME  /var/www/website$fastcgi_script_name;
        include /etc/nginx/fastcgi_params;
    }

}

Changement de propriété de tout le répertoire en www-data: www-data, fait un 777 sur le fichier php, rien. Nginx redémarré, FPM, rien.

Aidez-moi? :(


regardez dans votre journal des erreurs
Mike

Déjà, "Je n'ai pas de rapport de journal d'erreurs précieux". C'est complètement vide.
Gabriel A. Zorrilla

Vous avez besoin de plus de données pour diagnostiquer le problème. Je suggère de commencer par ajouter "fastcgi_intercept_errors on;" dans votre configuration (sinon dans fastcgi_params) pour enregistrer les erreurs FPM. Ajoutez également 'debug' à votre ligne error_log pour obtenir beaucoup plus de détails (vérifiez également le nginx error_log principal (éventuellement dans / var / log)). Votre directive nom_serveur semble inhabituelle - vous ne savez pas si vous l'avez remplacée pour ce message ou si c'est vraiment comme ça. En tant que recommandation générale, déplacez votre directive racine hors de votre bloc de localisation. (Dernière suggestion (peu probable): assurez-vous que votre serveur par défaut ne sert pas les pages html que vous pouvez voir).
cyberx86

Réponses:


9

il obtient un "Oups! Ce lien semble être rompu." erreur dans CHROME.

Chrome affiche sa propre page d'erreur si la page d'erreur est inférieure à 512 octets.

Je soupçonne que vous avez la ligne suivante fastcgi_params:

fastcgi_param  SCRIPT_FILENAME  $document_root$fastcgi_script_name;

et si c'est le cas, parce que la rootdirective est définie dans location /ne sera jamais appliquée location ~ \.php$, le SCRIPT_FILENAMEdevient l'URI.

Cela peut être résolu en déplaçant la rootdirective dans le servercontexte de niveau:

server {
    listen       80;
    server_name  im;
    access_log /var/www/website/access.log;
    error_log /var/www/website/error.log;

    root   /var/www/website;

    location ~ \.php$ {
        fastcgi_pass 127.0.0.1:9000;
        fastcgi_index index.php;
        fastcgi_param  SCRIPT_FILENAME  $document_root$fastcgi_script_name;
        include fastcgi_params;
    }

}

Bingo. Déplacé root le bloc serveur comme suggéré et travaillé. Merci!
Gabriel A. Zorrilla

@quanta: L'OP a-t-il modifié la configuration dans sa question? Comme il s'agit d'un chemin codé en dur, il devrait toujours fonctionner parfaitement bien lorsque la directive racine est définie dans le contexte de l'emplacement. Le seul cas où cela ne fonctionnerait pas était s'il définissait SCRIPT_FILENAME dans son fichier fastcgi_params en utilisant $ document_root et remplaçait ainsi son code dur.
Martin Fjordvald

@MartinF: Non, l'OP n'a pas modifié la configuration. Tu as raison. Je vais modifier ma réponse.
quanta

-3

Dans mon cas, il manquait le paquet php-zip. Pour résoudre ce problème, j'ai couru:

yum install -y php-zip
systemctl restart php-fpm nginx

3
Apparemment, la cause de l'OP était entièrement autre chose.
Sven

Cela ne signifie pas que quelqu'un qui trouve son chemin vers cette page avec ce problème aura la même cause que le PO, il peut très bien avoir la cause que wejdross a trouvée et trouver cette réponse utile. La question n'est pas spécifique à cette cause, elle est spécifique à ce symptôme, et il y a évidemment plusieurs causes à cela, donc des personnes de causes différentes pourraient se retrouver ici.
Synetech

-4
    fastcgi_pass unix:/var/run/php5-fpm.sock;

4
Bienvenue dans Server Fault! Il semble que vous ayez les connaissances nécessaires pour fournir une bonne réponse ici, mais pensez à lire Comment écrire une bonne réponse? dans notre centre d'aide, puis révisez et développez votre réponse. Vos commandes / code / paramètres peuvent être techniquement la solution, mais certaines explications sont les bienvenues. Merci d'avance.
HBruijn

4
Aussi: même si cette seule ligne résout le problème, où va-t-elle? L'OP en montre deux locations. Est-ce que la ligne va en un? L'autre? Tous les deux? Veuillez modifier votre réponse pour la compléter.
David Makogon
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.